Necesito consumir un servicio web externo de mi programa VB6. Quiero ser capaz de implementar mi programa sin el kit de herramientas SOAP, si es posible, pero eso no es un requisito. No tengo el origen del servicio web y no lo creé. Es un servicio proporcionado por el proveedor.¿Cuál es la mejor forma de consumir un servicio web de VB6?
Por lo tanto, fuera del kit de herramientas SOAP, ¿cuál es la mejor manera de consumir un servicio web de VB6?
Utilizo esta función para obtener datos de un servicio web.
Private Function HttpGetRequest(url As String) As DOMDocument
Dim req As XMLHTTP60
Set req = New XMLHTTP60
req.Open "GET", url, False
req.send ""
Dim resp As DOMDocument
If req.responseText <> vbNullString Then
Set resp = New DOMDocument60
resp.loadXML req.responseText
Else
Set resp = req.responseXML
End If
Set HttpGetRequest = resp
End Function
El kit de herramientas SOAP es posiblemente el mejor que podría obtener. Tratar de hacer lo mismo sin esto requeriría un esfuerzo adicional considerable. Debes tener razones bastante serias para hacerlo.
El formato de los mensajes SOAP no es realmente fácil de leer o escribir de forma manual y se recomienda encarecidamente una biblioteca de terceros.
Suponiendo que se ejecuta en Windows XP Professional o superior, un método interesante es utilizar el apodo SOAP. Aquí hay un ejemplo, levantado de alguna página de MSDN. No sé si este servicio en particular funciona, pero tiene la idea ...
set SoapObj = GetObject
("soap:wsdl=http://www.xmethods.net/sd/TemperatureService.wsdl")
WScript.Echo "Fairbanks Temperature = " & SoapObj.getTemp("99707")
Este mecanismo también funciona desde VBScript. Lo cual es bueno.
.NET tiene un buen soporte para servicios web desde el primer día, por lo que puede desarrollar su lógica de cliente del servicio web en .NET como una biblioteca/ensamblado .dll y usarlo en la aplicación VB6 a través de COM Interop.
Pocketsoap funciona muy bien. Para generar sus objetos use WSDL generator. Al usar esto, no tiene que analizar nada usted mismo, además de que todo es agradable y está fuertemente tipado.
Si bien este enlace puede responder a la pregunta, es mejor incluir las partes esenciales de la respuesta aquí y proporcionar el enlace de referencia. Las respuestas de solo enlace pueden dejar de ser válidas si la página vinculada cambia. – Jimbo
@Jimbo, si nota cuando se publicó (3 años antes de que se uniera a StackOverflow), el etiquite sobre enlaces y publicaciones aún no se había formalizado. Dicho esto, no hay otra parte de la respuesta, la sugerencia fue usar la biblioteca de PocketSoap. Pero, como han transcurrido 6 años desde su publicación, diría que PocketSoap ya no es la mejor solución y usar la respuesta de @hyseyint para usar .Net con Interop es la mejor solución a menos que no pueda usar Interop. –
Hola Kris, en realidad no escribí eso anteriormente. En 'REVIEW' en la parte superior derecha, apareció y una de las opciones fue 'Respuesta solo de enlace', que defiendo. El texto anterior se publica automáticamente al revisar las publicaciones de los demás, pruébalo :-) – Jimbo
Consulte este artículo de Scott Swigart en el Centro de recursos de MSDN VB 6.0.
Estaba encantado de encontrar ese artículo. Hasta que me di cuenta de que está usando VB.net con VB6. Un poco derrota el propósito. (Si pudiera usar VB.net como parte de esto, lo haría todo en VB.net). Su conclusión lo dice todo "Construir esta aplicación con solo Visual Basic 6 hubiera sido realmente difícil". –
que he tenido cierto grado de éxito hasta ahora usando PocketSOAP para conectarse a la API de Salesforce. No pude usar el Asistente WSDL porque genera nombres de archivo de clase contenedora usando los primeros 23 caracteres de los nombres de las llamadas, y esto da como resultado duplicados. Sin embargo, PocketSOAP ha funcionado lo suficientemente bien para mí sin el asistente, y es mucho más sencillo que usar XMLHTTP con DOMDocument.
También busqué crear un contenedor en .NET o utilizar una de las librerías "MS Office {MSO versión} Web Services Toolkit", pero hubo importantes inconvenientes de implementación con esas opciones. PocketSOAP es una DLL COM sencilla, no depende de alguna versión particular de MS Office, y tiene licencia bajo MPL.
No es terriblemente útil a menos que el servicio web utilice HTTP. –
@JohnSaunders Seguro, puede utilizar un enfoque diferente para las partes de la web que no usan HTTP. –
Quizás no llame a algo un servicio web si utiliza binario sobre TCP/IP, pero no HTTP? Si ese es el caso, entonces estoy de acuerdo con usted. No creo que el uso de SMTP o TCP/IP como transporte impida que un servicio sea un "servicio web", aunque estoy de acuerdo en que no es un "servicio de Internet". –