Xailer & OZ Software

Es posible consumir y hacer web services en Xailer ?

Yamil,
Me temo que no es la mejor herramienta para hacerlo. Las aplicaciones
gráficas tienen muy poco que decir en el mundo Web, ya que realmente dichas
aplicaciones no tienen salida a pantalla, sino que realmente tan sólo
generan código HTML.
En mi opinión, xHarbour, que no Xailer, puede ser un candidato muy válido en
la elaboración de CGIs siempre que necesites hacer algún módulo de tu
aplicación de gestión accesible via página Web. Por ejemplo, la posibilidad
que desde Internet un cliente compruebe la situación exacta de cada uno de
sus pedidos. Para poder hacer esto, es necesario que el servidor Web este en
la propia empresa, ya que si las páginas Web se van a alojar en un ISP
externo es muy probable que no le haga ninguna gracia que le alojes en tus
páginas archivos EXE que se ejecuten como CGIs,
además del problema que supondría tener los datos a mostrar replicados en el
servidor externo.
En el resto de los casos, creo que el software de scripting y las
herramientas de desarrollo que existen actualmente en la red que además son
gratuitas son con mucho, el mejor sistema para realizar Web services y una
de las mayores pesadillas de Micro$oft.
Un saludo,
.. Entiendo que para hacer Web services existen herramientas más apropiadas
"Yamil Bracho" <YamilBracho@hotmail.com> escribió en el mensaje
news:[email=4411877b@ozsrvnegro.ozlan.local...]4411877b@ozsrvnegro.ozlan.local...[/email]
> Es posible consumir y hacer web services en Xailer ?
>
>

Gracias Ignacio por la inmformacion. Lo que me gustaria es consumir un servicio
desde Xailer porque nuestros clientes (la banca) al tener tantas tecnologias
ejecutando en su entorno la unica manera de integrarlas es via web services.
Tenemos una aplicacion que hace uso de web services para realizar unos calculos
via MathLab y conexion con otros sistemas del banco.
Esta aplicacion la tenemos en Visual Basic.Net pero lo que no me gusta al
igual si hubisese sido Java es la instalacion de un runtime y el deployment
en los clientes que en los bancos es una pesadilla por motivos de seguridad
Basicamente consumir el servicio web es ejecutarlo y recibir la data en forma
de xml. Creo que hay una libreria en lenguaje C o C++ que permite hacer y
consumir servicios web. Seria facil de integrar con Xailer ?

Yamil,
> Basicamente consumir el servicio web es ejecutarlo y recibir la data en
> forma
> de xml. Creo que hay una libreria en lenguaje C o C++ que permite hacer y
> consumir servicios web. Seria facil de integrar con Xailer ?
Vamos a ver... corrígeme si me equivoco, pero yo creo que "web service" no
es algo concreto, sino una forma de trabajar contra un servidor web. Lo más
común es hacer peticiones a través de http y recibir los resultados en
formato xml, ¿no es así?
Si es esto, entonces puedes usar Xailer perfectamente como cliente de un
"web service", usando la clase TInternet para hacer las peticiones y
recibiendo en un buffer el resultado. Después puedes usar el soporte xml de
xHarbour para interpretar el contenido de ese buffer.
Si no es así, o es algo más complejo, dínoslo y podremos orientarte.
--
Un saludo,
José F. Giménez

Jose F. Gimenez escribió:
> Yamil,
>
>
>>Basicamente consumir el servicio web es ejecutarlo y recibir la data en
>>forma
>>de xml. Creo que hay una libreria en lenguaje C o C++ que permite hacer y
>>consumir servicios web. Seria facil de integrar con Xailer ?
>
>
> Vamos a ver... corrí­geme si me equivoco, pero yo creo que "web service" no
> es algo concreto, sino una forma de trabajar contra un servidor web. Lo más
> común es hacer peticiones a través de http y recibir los resultados en
> formato xml, ¿no es así­?
>
> Si es esto, entonces puedes usar Xailer perfectamente como cliente de un
> "web service", usando la clase TInternet para hacer las peticiones y
> recibiendo en un buffer el resultado. Después puedes usar el soporte xml de
> xHarbour para interpretar el contenido de ese buffer.
>
> Si no es así­, o es algo más complejo, dí­noslo y podremos orientarte.
>
Una corrección, un servicio web, sí­ es algo concreto. Es similar a un
DCOM ( objeto COM distribuido ), la diferencia respecto a él es que
utiliza protolos abiertos para ser llamado, en concreto usa HTTP y SOAP.
La arquitectura .NET soporta de manera nativa el uso y la creación de
estos servicios. Microsoft creó el MS SoapToolkit, que se puede bajar
gratuí­tamente de su página. Este producto permite a toda aquella
aplicación capaz de usar objetos COM, invocar webservices, básicamente
lo que hace es crear un objeto COM con los mí­smos métodos que el wS a
invocar. Por lo tanto Xailer es capaz de usar esta tecnologí­a a través
de TOleAuto.
Salu2.

Carlos,
> Una corrección, un servicio web, sí es algo concreto. Es similar a un DCOM
> ( objeto COM distribuido ), la diferencia respecto a él es que utiliza
> protolos abiertos para ser llamado, en concreto usa HTTP y SOAP. La
> arquitectura .NET soporta de manera nativa el uso y la creación de estos
> servicios. Microsoft creó el MS SoapToolkit, que se puede bajar
> gratuítamente de su página. Este producto permite a toda aquella
> aplicación capaz de usar objetos COM, invocar webservices, básicamente lo
> que hace es crear un objeto COM con los mísmos métodos que el wS a
> invocar. Por lo tanto Xailer es capaz de usar esta tecnología a través de
> TOleAuto.
Muchas garcias por la aclaración. Aunque había leido algo sobre WS nunca he
llegado a usarlos.
--
Un saludo,
José F. Giménez

COM es la tecnología que Microsoft intenta imponer como estandar . No es
estandar ni abierta en el mundo internet. No puedes atacar servidores unix o
linux, solo puedes moverte dentro de lo que el mundo com ofrece.
Pero el 99% de los servicios web funcionan a traves de peticiones y
respuestas con un estandar comun como es xml.
Tu me pides algo con un formato xml preestablecido, y yo te lo devuelvo con
otro formato preestablecido.
Como tu lo utilices o lo ataques no es problema del servicio web.
Asi de sencillo y a la vez complejo.
Fichero plano que va con una pregunta, fichero plano que viene con una
respuesta.
Clipxnet puede ejecutar perfectamente servicios web. Asi como tambien puede
perfectamente esperar la respuesta y tratarla como mejor le convenga.
Saludos
Rafa
"Carlos Leyva" <jcleygar@hotmail.com> escribió en el mensaje
news:44144141$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> Jose F. Gimenez escribió:
>> Yamil,
>>
>>
>>>Basicamente consumir el servicio web es ejecutarlo y recibir la data en
>>>forma
>>>de xml. Creo que hay una libreria en lenguaje C o C++ que permite hacer y
>>>consumir servicios web. Seria facil de integrar con Xailer ?
>>
>>
>> Vamos a ver... corrígeme si me equivoco, pero yo creo que "web service"
>> no es algo concreto, sino una forma de trabajar contra un servidor web.
>> Lo más común es hacer peticiones a través de http y recibir los
>> resultados en formato xml, ¿no es así?
>>
>> Si es esto, entonces puedes usar Xailer perfectamente como cliente de un
>> "web service", usando la clase TInternet para hacer las peticiones y
>> recibiendo en un buffer el resultado. Después puedes usar el soporte xml
>> de xHarbour para interpretar el contenido de ese buffer.
>>
>> Si no es así, o es algo más complejo, dínoslo y podremos orientarte.
>>
>
> Una corrección, un servicio web, sí es algo concreto. Es similar a un DCOM
> ( objeto COM distribuido ), la diferencia respecto a él es que utiliza
> protolos abiertos para ser llamado, en concreto usa HTTP y SOAP. La
> arquitectura .NET soporta de manera nativa el uso y la creación de estos
> servicios. Microsoft creó el MS SoapToolkit, que se puede bajar
> gratuítamente de su página. Este producto permite a toda aquella
> aplicación capaz de usar objetos COM, invocar webservices, básicamente lo
> que hace es crear un objeto COM con los mísmos métodos que el wS a
> invocar. Por lo tanto Xailer es capaz de usar esta tecnología a través de
> TOleAuto.
>
> Salu2.

Rafa,
> COM es la tecnología que Microsoft intenta imponer como estandar . No es
> estandar ni abierta en el mundo internet. No puedes atacar servidores unix
> o linux, solo puedes moverte dentro de lo que el mundo com ofrece.
Creo que no has entendido la respuesta de Carlos. Lo que él ha dicho es que
los WS funcionan de forma parecida a DCOM, no que sean COM ni que tengan
nada que ver con MS.
Por otro lado, también ha dicho que MS distribuye gratuitamente "MS
SoapToolkit", que es un paquete que permite invocar WS (vamos, un cliente
WS), y que al ser un servidor OLE sepuede manejar a través de TOleAuto. Es
como decir que puedes manejar IE a través de TOleAuto para mostrar páginas
web desde tu programa, pero para nada significa que Internet sea OLE.
--
Un saludo,
José F. Giménez

Carlos.
> Una corrección, un servicio web, sí­ es algo concreto. Es similar a un
> DCOM ( objeto COM distribuido ), la diferencia respecto a él es que
> utiliza protolos abiertos para ser llamado, en concreto usa HTTP y SOAP.
> La arquitectura .NET soporta de manera nativa el uso y la creación de
> estos servicios. Microsoft creó el MS SoapToolkit, que se puede bajar
> gratuí­tamente de su página. Este producto permite a toda aquella
> aplicación capaz de usar objetos COM, invocar webservices, básicamente
> lo que hace es crear un objeto COM con los mí­smos métodos que el wS a
> invocar. Por lo tanto Xailer es capaz de usar esta tecnologí­a a través
> de TOleAuto.
>
No creo que te sirva en este caso TOleAuto.
Realmente , webservices es como una RPC, pero mas elaborado, es decir,
una Remote Procedure Call y seguro que ya sabéis de que va
Creo recordad que nuestro amigo Walter Negro estuvo jugando con el
tema a traves de una librerí­a de código libre, gSoap, pero no supe
si llego a terminar de implementarlo del todo.
Yo desistí­, puesto que habia que currarse TODO el tema en C , para
que corriera en xHarbour, vamos, algo habitual en nuestro mundillo,
y como el tiempo apremiaba, la gente de delphi en un par de clicks
lo tenia corriendo, asi que ya sabeis quien hizo el soporte de Soap
Saludos
Rafa Carmona

Un servicio WEB es un objeto que expone sus métodos y propiedades utilizando
protocolos y estándares abiertos. Realmente es una evolución de otros sistemas
RPC como CORBA. Traba
thefull <thefull@wanadoo.es> wrote:
>Carlos.
>> Una corrección, un servicio web, sí es algo concreto. Es similar a un
>> DCOM ( objeto COM distribuido ), la diferencia respecto a él es que
>> utiliza protolos abiertos para ser llamado, en concreto usa HTTP y SOAP.
>> La arquitectura .NET soporta de manera nativa el uso y la creación de
>> estos servicios. Microsoft creó el MS SoapToolkit, que se puede bajar
>> gratuítamente de su página. Este producto permite a toda aquella
>> aplicación capaz de usar objetos COM, invocar webservices, básicamente
>> lo que hace es crear un objeto COM con los mísmos métodos que el wS a
>> invocar. Por lo tanto Xailer es capaz de usar esta tecnología a través
>> de TOleAuto.
>>
>No creo que te sirva en este caso TOleAuto.
>
>Realmente , webservices es como una RPC, pero mas elaborado, es decir,
>una Remote Procedure Call y seguro que ya sabéis de que va
>
>Creo recordad que nuestro amigo Walter Negro estuvo jugando con el
>tema a traves de una librería de código libre, gSoap, pero no supe
>si llego a terminar de implementarlo del todo.
>
>Yo desistí, puesto que habia que currarse TODO el tema en C , para
>que corriera en xHarbour, vamos, algo habitual en nuestro mundillo,
>y como el tiempo apremiaba, la gente de delphi en un par de clicks
>lo tenia corriendo, asi que ya sabeis quien hizo el soporte de Soap
>
>Saludos
>Rafa Carmona

Un servicio WEB es un objeto autodescriptivo que expone sus métodos y propiedades
utilizando protocolos y estándares abiertos. Realmente es una evolución
de otros sistemas RPC como CORBA. Para el envío y recepción con el objeto
se usa SOAP a través de HTTP ( por eso se llaman servicios WEB ).
Trabajar directamente en el protolo SOAP es complejo y tedioso. Por ello
la manera habitual de consumir este tipo de servicios es crear una clase
proxy, que implemente todos los métodos y propiedades del WS a usar como
propios de la clase. Así en nuestro código la utilicemos como si de una
clase más se tratase. En entornos de desarrollo basados .NET y en JAVA es
relativamente sencillo el uso de los WS porque incorporan librerías y asistentes
que permiten crear estas clases proxy. Microsoft como una de las impulsoras
de estas tecnologías dió una solución a otros entornos de desarrollo anteriores
al nacimiento de los Servicios WEB, y permitir así su aprovechamiento. La
solución de M$ fué la de crear la clase proxy como un objeto COM que la aplicación
usa como cualquier otro objecto COM. el Microsoft Soap
Toolkit es un producto que permite en base a un asistente, crear un Objeto
COM com que implementa todos los métodos y propiedades del servicio WEB que
necesitemos y permite que esté sea consumido por cualquier aplicación que
sea capaz de hacer uso del COM. Nada más y nada menos. Gracias a MS Toolkit
podemos consumir servicios web desde VBA ( desde excel, access, etc ), Delphi,
Visual Basic, y por supuesto desde Xailer.
>Carlos.
>> Una corrección, un servicio web, sí es algo concreto. Es similar a un
>> DCOM ( objeto COM distribuido ), la diferencia respecto a él es que
>> utiliza protolos abiertos para ser llamado, en concreto usa HTTP y SOAP.
>> La arquitectura .NET soporta de manera nativa el uso y la creación de
>> estos servicios. Microsoft creó el MS SoapToolkit, que se puede bajar
>> gratuítamente de su página. Este producto permite a toda aquella
>> aplicación capaz de usar objetos COM, invocar webservices, básicamente
>> lo que hace es crear un objeto COM con los mísmos métodos que el wS a
>> invocar. Por lo tanto Xailer es capaz de usar esta tecnología a través
>> de TOleAuto.
>>
>No creo que te sirva en este caso TOleAuto.
>
>Realmente , webservices es como una RPC, pero mas elaborado, es decir,
>una Remote Procedure Call y seguro que ya sabéis de que va
>
>Creo recordad que nuestro amigo Walter Negro estuvo jugando con el
>tema a traves de una librería de código libre, gSoap, pero no supe
>si llego a terminar de implementarlo del todo.
>
>Yo desistí, puesto que habia que currarse TODO el tema en C , para
>que corriera en xHarbour, vamos, algo habitual en nuestro mundillo,
>y como el tiempo apremiaba, la gente de delphi en un par de clicks
>lo tenia corriendo, asi que ya sabeis quien hizo el soporte de Soap
>
>Saludos
>Rafa Carmona

Gracias a todos por esta lectura tan amena e informativa.
Si como dice Carlos el Soap ToolKit puede instanciarse via TOleAuto asi que
es muy posible consumir web services desde Xailer.
Lo ideal seria hacerlo en forma natva (quizas integrandose con gSoap)...
Seguire investigando...
"Carlos Leyva" <jcleygar@hotmail.com> wrote in message
news:44156233$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
>
> Un servicio WEB es un objeto autodescriptivo que expone sus métodos y
propiedades
> utilizando protocolos y estándares abiertos. Realmente es una evolución
> de otros sistemas RPC como CORBA. Para el envío y recepción con el objeto
> se usa SOAP a través de HTTP ( por eso se llaman servicios WEB ).
> Trabajar directamente en el protolo SOAP es complejo y tedioso. Por ello
> la manera habitual de consumir este tipo de servicios es crear una clase
> proxy, que implemente todos los métodos y propiedades del WS a usar como
> propios de la clase. Así en nuestro código la utilicemos como si de una
> clase más se tratase. En entornos de desarrollo basados .NET y en JAVA es
> relativamente sencillo el uso de los WS porque incorporan librerías y
asistentes
> que permiten crear estas clases proxy. Microsoft como una de las
impulsoras
> de estas tecnologías dió una solución a otros entornos de desarrollo
anteriores
> al nacimiento de los Servicios WEB, y permitir así su aprovechamiento. La
> solución de M$ fué la de crear la clase proxy como un objeto COM que la
aplicación
> usa como cualquier otro objecto COM. el Microsoft Soap
> Toolkit es un producto que permite en base a un asistente, crear un Objeto
> COM com que implementa todos los métodos y propiedades del servicio WEB
que
> necesitemos y permite que esté sea consumido por cualquier aplicación que
> sea capaz de hacer uso del COM. Nada más y nada menos. Gracias a MS
Toolkit
> podemos consumir servicios web desde VBA ( desde excel, access, etc ),
Delphi,
> Visual Basic, y por supuesto desde Xailer.
> >Carlos.
> >> Una corrección, un servicio web, sí es algo concreto. Es similar a un
>
> >> DCOM ( objeto COM distribuido ), la diferencia respecto a él es que
> >> utiliza protolos abiertos para ser llamado, en concreto usa HTTP y
SOAP.
>
> >> La arquitectura .NET soporta de manera nativa el uso y la creación de
>
> >> estos servicios. Microsoft creó el MS SoapToolkit, que se puede bajar
>
> >> gratuítamente de su página. Este producto permite a toda aquella
> >> aplicación capaz de usar objetos COM, invocar webservices, básicamente
>
> >> lo que hace es crear un objeto COM con los mísmos métodos que el wS a
>
> >> invocar. Por lo tanto Xailer es capaz de usar esta tecnología a través
>
> >> de TOleAuto.
> >>
> >No creo que te sirva en este caso TOleAuto.
> >
> >Realmente , webservices es como una RPC, pero mas elaborado, es decir,
> >una Remote Procedure Call y seguro que ya sabéis de que va
> >
> >Creo recordad que nuestro amigo Walter Negro estuvo jugando con el
> >tema a traves de una librería de código libre, gSoap, pero no supe
> >si llego a terminar de implementarlo del todo.
> >
> >Yo desistí, puesto que habia que currarse TODO el tema en C , para
> >que corriera en xHarbour, vamos, algo habitual en nuestro mundillo,
> >y como el tiempo apremiaba, la gente de delphi en un par de clicks
> >lo tenia corriendo, asi que ya sabeis quien hizo el soporte de Soap
> >
> >Saludos
> >Rafa Carmona
>

Carlos,
> sea capaz de hacer uso del COM. Nada más y nada menos. Gracias a MS Toolkit
> podemos consumir servicios web desde VBA ( desde excel, access, etc ), Delphi,
> Visual Basic, y por supuesto desde Xailer.
Bien, en ese caso, estas usando OTRA capa por encima a traves de COM, y
desconocia su existencia, y como bien dices, entonces si que seria
posible usarlo sin mayores complicaciones.
Pero bueno, en este caso, como siempre estas ligado a una plataforma en
concreto, no digo que sea ni bueno ni malo que es otro tema, en cambio
si Harbour tuviera SOPORTE de SOAP, no tendrias ningun problema de este
tipo.
Me parecio cojonudo que , por ejemplo, que xHarbour implementara soporte
de sockets, independientemente de la plataforma, como que con Harbour ,
por ejemplo, solamente lo tienes a traves de Windows y es una contrib de
Matteo.
En fin, creo que todos al final saben lo que es exactamente el famoso
webservices
Saludos
Rafa Carmona

Por cierto, para saber más:
http://es.wikipedia.org/wiki/SOAP
http://es.wikipedia.org/wiki/CORBA
Saludos
Rafa Carmona

Para saber todavia mas
http://es.wikipedia.org/wiki/Servicios_Web
Aqui lo deja muy claro.
Nada de COM.
Nada de CORBA.
SOAP y XML en cualquier servidor. Solo puerto 80 y http.
Lo demas va de la mano de algunos fabricantes que quieren imponer su
criterio.
Saludos
Rafa
"thefull" <thefull@wanadoo.es> escribió en el mensaje
news:44157520$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> Por cierto, para saber más:
>
> http://es.wikipedia.org/wiki/SOAP
> http://es.wikipedia.org/wiki/CORBA
>
>
> Saludos
> Rafa Carmona

Lo que mas me llama la atencion de todo esto independiente de la discusion es esto:
Una tercera razón por la que los servicios Web son muy prácticos es que pueden aportar un débil acoplamiento entre una aplicación que usa el servicio Web y el propio servicio. De esta forma los cambios que cada uno realice con el tiempo no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir las aplicaciones grandes a partir de componentes distribuidos más pequeños es cada dí­a mayor.
"Rafa R.Gaona" <rrgaona@gesintur.com> escribió en el mensaje news:44167be3$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> Para saber todavia mas
> http://es.wikipedia.org/wiki/Servicios_Web
> Aqui lo deja muy claro.
> Nada de COM.
> Nada de CORBA.
> SOAP y XML en cualquier servidor. Solo puerto 80 y http.
> Lo demas va de la mano de algunos fabricantes que quieren imponer su
> criterio.
> Saludos
> Rafa
>
> "thefull" <thefull@wanadoo.es> escribió en el mensaje
> news:44157520$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
>> Por cierto, para saber más:
>>
>> http://es.wikipedia.org/wiki/SOAP
>> http://es.wikipedia.org/wiki/CORBA
>>
>>
>> Saludos
>> Rafa Carmona
>
>
--

Y en esta pagina tambien viene muy claro
http://www.desarrolloweb.com/articulos/ ... ?manual=54
Saludos
Rafa
"Rafa R.Gaona" <rrgaona@gesintur.com> escribió en el mensaje news:[email=44167cad@ozsrvnegro.ozlan.local...]44167cad@ozsrvnegro.ozlan.local...[/email]
Lo que mas me llama la atencion de todo esto independiente de la discusion es esto:
Una tercera razón por la que los servicios Web son muy prácticos es que pueden aportar un débil acoplamiento entre una aplicación que usa el servicio Web y el propio servicio. De esta forma los cambios que cada uno realice con el tiempo no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir las aplicaciones grandes a partir de componentes distribuidos más pequeños es cada dí­a mayor.
"Rafa R.Gaona" <rrgaona@gesintur.com> escribió en el mensaje news:44167be3$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
> Para saber todavia mas
> http://es.wikipedia.org/wiki/Servicios_Web
> Aqui lo deja muy claro.
> Nada de COM.
> Nada de CORBA.
> SOAP y XML en cualquier servidor. Solo puerto 80 y http.
> Lo demas va de la mano de algunos fabricantes que quieren imponer su
> criterio.
> Saludos
> Rafa
>
> "thefull" <thefull@wanadoo.es> escribió en el mensaje
> news:44157520$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
>> Por cierto, para saber más:
>>
>> http://es.wikipedia.org/wiki/SOAP
>> http://es.wikipedia.org/wiki/CORBA
>>
>>
>> Saludos
>> Rafa Carmona
>
>
--