http://www.help400.com/asp/scripts/nwart.asp?Num=141&Pag=10&Tip=T
¿Qué son realmente los Servicios Web?
Evaluación del auténtico potencial que se esconde tras la publicidad
Si creyéramos a pie juntillas toda la publicidad que inunda el sector de las tecnologías de la información, ahora mismo todo hombre, mujer y niño del planeta estarían concentrados desarrollando servicios web. La exageración ha llegado a tal punto que una importante emisora de televisión está preparando un reality show basado en los servicios web. Con el título provisional de "Supervivientes: Servicios Web", esta serie enfrenta a dos equipos de programadores que viven juntos en una isla desierta que deben llevar a cabo una serie de complejos juegos de programación.
Vale, lo del programa de televisión es mentira, pero está claro que hay mucho de exageración sobre el asunto de los servicios web. ¿A quién creer? Hay profesionales del mundo de la informática que ven los servicios web como una tecnología innovadora que transformará la forma de desarrollar y desplegar las aplicaciones de las generaciones futuras. Y hay otros que ven los servicios web simplemente como un cuento chino del software que apenas hará impacto en el mundo del desarrollo de aplicaciones.
Al final, la única forma de evaluar el impacto de los servicios web es averiguar quién está desarrollando y desplegando actualmente servicios web en el sector de la informática o piensa hacerlo en breve. Para este fin, la firma de investigación Gartner llevó a cabo dos encuestas en febrero de 2003 para medir la fuerza motriz de los servicios web ahora y en el futuro.
La primera encuesta tuvo como objetivo 50 empresas estadounidenses con ingresos anuales de más de 500 millones de dólares. Por conveniencia, en este artículo la llamaremos "Encuesta 50". Aunque el grupo de encuestados era relativamente pequeño, el tamaño de las empresas en que se centra da una buena idea de lo que las grandes corporaciones piensan sobre los servicios web.
La segunda encuesta se hizo a más de 100 empresas estadounidenses que tienen más de 1.000 empleados y que planean desplegar servicios web en un plazo de 12 a 24 meses. A ésta la llamaremos "Encuesta 100". Obviamente, este grupo de encuestados está sesgado puesto que pretenden desplegar servicios web; aún así, la encuesta revela datos muy interesantes.
Fíjese que ambos estudios se centran en los Estados Unidos. En realidad, en otros países tienen otros niveles de interés por los servicios web y ritmos de despliegue diferentes. Por lo tanto, deberá ser cuidadoso a la hora de extrapolar los resultados de las encuestas en el mercado mundial.
Servicios web por su nombre
La primera complicación que uno se suele encontrar cuando investiga los proyectos de servicios web es que cada uno tiene una interpretación distinta de lo que son los "servicios web". Por ejemplo, algunas personas ven los servicios web simplemente como la preparación de las aplicaciones para poder utilizar XML. Para otros, se trata de poner unas cuantas importaciones y exportaciones de XML delante de un viejo programa escrito en RPG del iSeries y voilà, ya tenemos servicios web.
La definición más habitual de servicios web en el sector (y la que adoptaremos aquí) es la que dice que para que una aplicación pueda calificarse como un componente de servicios web debe utilizar una o varias de las tecnologías siguientes: Protocolo simple de acceso a objetos (SOAP o Simple Object Access Protocol), Lenguaje de descripción de servicios web (WSDL o Web Services Description Language) y Descripción, descubrimiento e integración universales (UDDI o Universal Description, Discovery and Integration). El uso de XML está implícito en todos esos estándares.
Esta idea de igualar a XML con los servicios web aparece claramente en las dos encuestas de Gartner. En la "Encuesta 50", el 86% de los encuestados respondieron que en sus proyectos de servicios web se utilizaba XML, pero sólo el 31% señaló que se utilizaba SOAP, el 14% UDDI y menos del 10% WDSL.
En la "Encuesta 100" (que, como ya hemos mencionado, se basa en empresas que dicen tener en marcha proyectos de servicios web), los resultados son parecidos. Aquí, el 75% de los encuestados indica que utiliza XML, pero sólo el 31% dice que usa SOAP. En el caso tanto de WSDL como UDDI los porcentajes que se obtienen son menores.
La conclusión es que el énfasis puesto por el sector en XML como espina dorsal de los servicios web ha desdibujado la definición de servicios web en las mentes de muchos informáticos. Las organizaciones pueden creer que están metidas de lleno en proyectos de servicios web, pero si hemos de ser rigurosos, lo cierto es que no es así.
Tapar huecos con servicios web
El plan maestro de los servicios web consiste en ofrecer un marco para desplegar tanto aplicaciones dentro de una empresa (intraempresa) como aplicaciones que abarcan varias empresas (interempresas). La aplicación desplegada puede estar constituida por nuevos componentes de software escritos siguiendo los estándares de los servicios web y por componentes de software antiguos adaptados a los servicios web.
De acuerdo con la "Encuesta 100", el 54% de los encuestados prevén utilizar los servicios web para integrar aplicaciones tanto dentro de la empresa (intraempresa) como con socios o clientes (interempresas) en el plazo de 12 meses. Durante el mismo tiempo, el 39% prevé utilizar los servicios web solamente dentro de la empresa. Cuando el periodo se alarga a 24 meses, el porcentaje de utilización interempresas aumenta al 65% y el porcentaje de utilización intraempresas baja al 23%.
La "Encuesta 50" muestra un panorama algo diferente. El 48% de los encuestados están interesados en un uso intraempresa y el 41% interempresas. La diferencia no es demasiado sorprendente puesto que los encuestados en la "Encuesta 100" están dedicándose activamente a desarrollar proyectos de servicios web, mientras que los de la "Encuesta 50" no necesariamente tienen el mismo nivel de implicación.
Los resultados sugieren que las empresas primero desplegarán los servicios web para resolver la integración interna de las aplicaciones y las necesidades de aplicaciones nuevas y que más tarde los extenderán fuera de la empresa. Esto es válido tanto para los proyectos intraempresa de la "Encuesta 100" como para los de la "Encuesta 50", en la que se muestra un interés mucho mayor por los proyectos intraempresa.
El factor del proveedor
En la visión que se tiene de los servicios web, los componentes de las aplicaciones pueden interconectarse sea cual sea el lenguaje en que se hayan escrito o la plataforma en que se ejecuten. Sin embargo, la realidad es que los servicios web están implementados en plataformas, servidores de aplicaciones, lenguajes e incluso productos de bases de datos concretos. Por ejemplo, .NET de Microsoft tiene sus raíces en la plataforma Windows, mientras que J2EE tiene propensión por Unix (en honor a la verdad, J2EE puede ejecutarse en Windows y en otras plataformas, pero la mayoría de las implementaciones son para Unix o Linux).
¿Cuáles son las arquitecturas y productos dominantes en el mercado? En la "Encuesta 50", el 48% de los encuestados señalaba que J2EE iba a ser su arquitectura principal para los servicios web y el 39% apuntaba a .NET (el 13% restante no lo sabía). Sin embargo, observe que a los encuestados sólo se les permitía escoger su arquitectura "principal". De modo que las empresas que prevén desplegar ambas arquitecturas estaban limitadas a dar una sola respuesta.
La "Encuesta 100" revela más cosas sobre el despliegue de varias arquitecturas ya que permite a los encuestados seleccionar múltiples respuestas. Aunque dicha encuesta no hace la pregunta sobre la arquitectura, si que lo hace sobre los servidores de aplicaciones que se están utilizando actualmente para los proyectos de servicios web y los que están previstos instalar. En este estudio, algo más del 50% de los encuestados responde que .NET de Microsoft será el servidor de aplicaciones para los proyectos actuales y futuros.
Aunque .NET obtiene muy buenos resultados, los de los servidores de aplicaciones J2EE tampoco son malos. En el caso de los proyectos de servicios web actuales, Apache, 9iAS de Oracle y WebSphere Application Server de IBM obtienen cada uno entre el 20% y el 25%. Cuando se trata de los proyectos futuros, .NET obtiene el mismo resultado, pero Apache, 9iAS de Oracle y WebSphere Application Server de IBM suben hasta el 25%-30%.
Observe también que la competición entre los proveedores acaba de empezar; es demasiado pronto para declarar ganadores y perdedores. Por lo tanto, las empresas deben potenciar las relaciones con sus proveedores o asegurarse de que un nuevo acuerdo de colaboración ofrece la mejor adaptación tecnológica posible y que es financieramente viable (es decir, que la recuperación de la inversión es a corto plazo). La encuesta también indica que las empresas deben estar preparadas para desplegar ambas arquitecturas, J2EE y .NET; hoy por hoy no hay una arquitectura todo-en-uno.
Quedarse con lo que nos interesa
Los resultados de cualquier encuesta siempre deben valorarse con cautela y debemos someterlos a nuestro propio punto de vista. Sin embargo, las encuestas permiten tomarle el pulso al sector de forma razonable y pueden utilizarse como norma para ver cómo se compara nuestra empresa con las demás. En términos de esa comparación, estas son las cuestiones que hay que hacerse para comparar nuestra empresa con la media.
1. Los servicios web no se han entendido bien. ¿Cuál es la definición de servicios web que se utiliza en su trabajo y cómo se compara con las definiciones del sector?
2. XML es una piedra angular del futuro. Tanto si utiliza XML en un contexto de servicios web "real" como si no, XML está emergiendo sin duda como una importante interfaz para la integración de aplicaciones. ¿Cuál es el nivel de conocimiento de XML que se tiene en su organización y qué proyectos orientados hacia XML se han iniciado o se prevé iniciar?
3. Empezar internamente y luego hacerlo externamente. Si su empresa ha iniciado algún proyecto de servicios web o únicamente de XML, ¿estos proyectos se aplican interna o externamente? Los estudios demuestran que la mayoría de las empresas empiezan internamente, para ganar experiencia, y luego amplían el ámbito de sus despliegues.
4. Sea receptivo a las opciones del proveedor. En muchos casos, las empresas no son capaces de estandarizarse en una sola arquitectura de servicios web o en un solo servidor de aplicaciones. ¿Cuáles son sus proveedores de plataformas estratégicos? ¿Cuáles son sus proveedores de servidores de aplicaciones estratégicos? Las respuestas a estas preguntas le indicarán con toda probabilidad cuáles son las arquitecturas y productos más importantes para usted.
¿Por qué no ahora?
Si su empresa está preparando sus aplicaciones para que puedan utilizar XML o está poniendo en marcha proyectos de servicios web de gran alcance, obviamente trabaja en una gran compañía. Si no, puede que trabaje en una empresa que tiene una posición más conservadora sobre las nuevas tecnologías o que alguien del departamento de informática se ha dormido en los laureles. En este caso, puede que éste sea un buen momento para hacer una llamada de advertencia. Los servicios web interempresa están creciendo y, tarde o temprano, se cruzarán en el camino de su empresa. ¿Para qué esperar si puede empezar a prepararse ya?
Sean Chandler es un consultor con más de 20 años de experiencia real. Conoce un buen número de sistemas: iSeries, Windows, NetWare, OpenVMS, Unix y Linux. Además, está más familiarizado de lo que quisiera con los entornos de middleware y de servidores de aplicaciones.
Servicios Web con ILE-RPG y SOAP
alex martinez
Wed, 24 Mar 2004 01:56:50 -0800
Hola a todos:
Despues de leer el artículo publicado en help400 el mes pasado sobre los
servicios web
http://www.help400.com/asp/scripts/nwart.asp?Num=141&Pag=10&Tip=T, me
preguntaba si era posible desarrollar un cliente de servicio web, utilizando
ÚNICAMENTE ILE-RPG.
Buscando con Google vi que hay cientos de servicios web y que incluso Google
tiene su propio servicio web que permite mediante mensajes SOAP (basado en
XML) realizar consultas desde nuestros programas en nuestro lenguaje de
programacion preferido.
Me descargé los ejemplos que proporciona Google y por supuesto, entre estos
no se incluía ninguno en ILE-RPG. Así que decidí desarrollar un programa de
un servicio web en RPG.
Para ello es necesario la libreria de Scott Klement
y crear una cuenta en Google para obtener una clave de licencia (todo
gratis). http://www.google.com/apis/
La libreria HTTPLIB de Scott Klement proporciona toda la comunicacion con
Sockets entre sistemas y porporciona funciones para los métodos GET y POST
de HTTP, ya que SOAP realiza su comunicacion a traves de HTTP.
La clave que proporciona Google permite la identificacion de nuestras
peticiones y nos limita a realizar hasta 1000 consultas diarias.
Si estais interesados podeis descargar los fuentes que he dejado en mi web.
Tomado de:
Web Services con ILE-RPG
Implementar un servicio web en i5 (System i o AS400 de toda la vida) con V5R4 consiste en:
* Un programa ILE-RPG de cálculo de costes de envio (descargar y compilar el programa ILE-RPG del archivo shipcost.zip adjunto).
* Convertir nuestro programa RPG en un Web service con un asistente de 8 pasos, que se completa habitualmente en ménos de 1 minuto.
* Realizar pruebas con Web Services Explorer, tambien integrado en i5.
No requiere ninguna herramienta para PC; únicamente un navegador.
Instrucciones para instalar libreria de Sockets
Tomado de:
http://www.scottklement.com/httpapi/httpapi_savf.html
_______________________________________________________________________________
Otra fuente interesante:
CONSUMIR UN WEB SERVICE DESDE UN PROGRAMA RPG/400
Hace
unos días me encargaron un proyecto en una entidad donde el 100 % de su
software en producción está desarrollado con Genexus, en la plataforma
AS/400 V5R4M00 procesando programas generados en RPG nativo. El proyecto
implicaba conectarse desde un programa RPG a un web service externo,
obtener datos de validación, confirmar la operación en el web service
actualizando su base de datos externa y finalmente registrar los datos
en la base de datos Iseries.
Genexus
no soporta ese tipo de operaciones en la plataforma AS/400, por lo que
tuve que buscar alternativas a mano, aunque Google no fue de demasiada
ayuda, ya que no hay demasiada experiencia sobre este tema. Supongo que
se considera un poco pasado de moda el RPG/400.
RPG
es bastante áspero para comunicarse con otras plataformas on-line,
salvo cuando fija las reglas. No me servía APPC (me pareció demasiado
complicado organizar eso), ni tampoco el ODBC porque las transacciones
se originaban en el ambiente nativo. Si el caso hubiera sido el inverso
(generar transacciones que afecten la base de datos nativa) la solución
era trivial. Una opción razonable era usar las DTAQ, que pueden ser
accedidas desde ambiente nativo y Windows, pero me complicó tener una
cantidad no definida de usuarios concurrentes. El indexado de las DTAQ
es limitado. Por otra parte, me obligaba a tener un servidor adicional
activo para poder interactuar con el web service externo en ambiente PC,
con los problemas que esto conlleva (de mantenimiento y control sobre
todo).
Buscando
por la red, encontré una biblioteca OpenSource para administrar sockets
y generar HTTP desde RPG/400, de un gordito llamado Scott Klement
(http://www.scottklement.com/), bajé todo lo que hay en el sitio y me
puse a estudiar. No soy un experto en ILE RPG ni mucho menos,hace
muuuucho tiempo que no programo manualmente, así que me costó bastante
el tema.
Para
preparar el escenario, creé un Web Service en mi localhost con Genexus X
WEB muy simple, solamente recibe un tipo y número de documento y
devuelve el nombre del cliente desde una base de datos MySQL. Hice un
work panel cliente en genexus 9.0 WIN para probar el funcionamiento
desde otra pc y todo funcionó sin problemas. Para ver bien el Web
Service bajé un software llamado SOAPUI (open source) de
http://www.soapui.org/ que permite testear y observar Web Services que
es bastante bueno.
Usando
su LIBHTTP/QRPGLESRC/EXAMPLE18 como modelo,empecé a meter mano. Primer
problema, hay que armar el XML de envío a mano y para eso me fue útil la
estructura del Soapui. Segundo problema, el mensaje que se recibe es
XML y tuve que parsearlo a mano. (Prueba y error) * n veces más no pude
hacer que funcionara con mi web service el parsing del modelo.
Dándole
vueltas al tema me topé con un sitio (Isockets.com) de Bob Cozzi, que
tiene una biblioteca de rutinas que manejan los sockets del AS/400. Bajé
la biblioteca, la instalé en mi equipo y empecé a probar. En definitiva
me pareció mucho más fácil de usar y una ayuda bastante más detallada.
Para la versión V5R4M0 es imprescindible tener aplicadas algunas PTF’s,
principalmente la MF40520 (importante porque el source sí se cobra).
El
proceso de comunicación, partiendo del modelo que hay en la biblioteca,
fue bastante simple. Igualmente hay que armar a mano el xml de envío
(para eso usé SoapUI). En teoría el HttpParse se encarga de desarmar el
xml de recepción pero no logré hacerlo funcionar, al igual que el
XML_INTO del ILE RPG. Me parece que alguno de los datos adicionales (el
namespace u otro) que el web service generado por Genexus envía no son
entendibles por el XML-INTO o por el DAX. Tampoco me puse a averiguar
demasiado porque usando %SUBST y %SCAN en un minuto se “pela” el xml,
dejando en variables los datos reales que quiero.
También
hay herramientas en
http://www.tools400.de/English/Freeware/WSDL2RPG/wsdl2rpg.html, pero ya
tenía el asado listo, así que simplemente lo miré un poco. Parece bueno
pero son solo las herramientas sin demasiados ejemplos de uso.
En
resumen, los programas RPG de la aplicación hechos en Genexus llaman
con parámetros a un pequeño programa de comunicaciones también ILE RPG,
que mediante HTTP accede al web service y devuelve los datos
solicitados. No es necesario usar absolutamente nada de los servidores
locales, salvo el browser ni hacer programas java. Creo que quedó una solución elegante.
El
tema que me queda pendiente es el SSL, porque los tipos del web service
externo usan un certificado propio (no Verisign ni los comunes) y me
obligan a configurar mi AS/400 para manejar certificados digitales. Aún
no lo pude probar pero parece ser alguito complicado. Si les toca lo
mismo, vean el manual de Security Digital Certificate Manager de IBM
como para empezar.
Algo de bibliografía para buscar, si lo necesitan es:
No hay comentarios:
Publicar un comentario