EESSTTAADDOO DDEELL AARRTTEE DDEE LLAA TTEECCNNOOLLOOGGÍÍAA DDEE WWEEBB SSEERRVVIICCEESS
TRABAJO DE GRADUACIÓN PRESENTADO POR:
EDGARDO ALBERTO ROMERO MASIS
PARA OPTAR AL GRADO DE:
INGENIERO EN CIENCIAS DE LA COMPUTACIÓN
ASESOR:
ING. JULIO ADALBERTO RIVERA PINEDA
SEPTIEMBRE DEL 2004.
SAN SALVADOR, EL SALVADOR, CENTROAMÉRICA.
RECTOR
ING. FEDERICO MIGUEL HUGUET RIVERA
SECRETARIO GENERAL
LIC. MARIO OLMOS
DECANO DE LA FACULTAD DE INGENIERÍA
ING. ERNESTO GODOFREDO GIRÓN
ASESOR DEL TRABAJO DE GRADUACIÓN
ING. JULIO ADALBERTO RIVERA PINEDA
JURADO EVALUADOR
ING. CELIA MOLINA DE HERNÁNDEZ
ING. ARNOLDO INOCENCIO RIVAS MOLINA
ING. RENÉ AMÉRICO HERNÁNDEZ
FACULTAD DE INGENIERÍA
INGENIERIA EN CIENCIAS DE LA COMPUTACIÓN
JURADO EVALUADOR DEL TRABAJO DE GRADUACIÓN
ESTADO DEL ARTE DE LA TECNOLOGÍA DE WEB SERVICES
____________________________________
ING. CELIA MOLINA DE HERNÁNDEZ
________________________________ _______________________________
ING. ARNOLDO INOCENCIO RIVAS MOLINA ING. RENÉ AMÉRICO HERNÁNDEZ
____________________________________
ING. JULIO ADALBERTO RIVERA PINEDA
DD EE DD IICC AATTOO RR IIAA ..
A Jehová Dios Todoporeso y a nuestro señor Jesucristo por haberme dado
el privilegio de coronar mi carrera, dándome fortaleza, la verdadera paz y
felicidad que tanto necesitamos los seres humanos, llenándome de
bendiciones todos los días de mi vida.
A mi padre Elio Romero Escamilla por apoyarme incondicionalmente en
todas las áreas y etapas de mí recorrido por este mundo, educándome con
disciplina y buenos principios para enfrentar en estos días el duro camino de
la vida.
A mi madre Ángela Magdalena Masis por ser la persona que me trajo a este
mundo, brindarme educación y apoyo a mis ideales, a mi hermana Karen
Zuleyma por brindarme todo el cariño de siempre.
A mis hijos Jazmín Esmeralda y Edgar Alexis ya que son mis más
preciados tesoros que amo con todo mi corazón y el motivo fundamental de
superación y lucha por seguir adelante.
A mi amigo Julio Rivera pineda y la familia Rivera Pineda, por darme
ánimos de continuar en los momentos que mas lo necesite, además de su
colaboración y coordinación en todo el desarrollo del proyecto.
Mis más sinceros agradecimientos a toda mi familia, amigos y personas
que han contribuido desinteresadamente directa o indirectamente y hecho
posible la realización de esta obra.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” i
ÍN D IC E D E C O N T E N ID O
Introducción. _________________________________________________________iii
Objetivos _____________________________________________________________ iv
Alcances _____________________________________________________________ v
Limitaciones __________________________________________________________ v
Justificación __________________________________________________________ vi
1. Historia de los web services ____________________________________________ 1
2. ¿Qué es un web service? ______________________________________________ 5
3. Características de los web services. _____________________________________ 10
4. Plataformas de desarrollo ____________________________________________ 12
5. Implementación de Web Services.______________________________________ 19
6. Lenguajes de programación. __________________________________________ 22
7. Estándares y tecnologías asociadas. ____________________________________ 31
8. Los web services y la tecnologia actual__________________________________ 57
9. Apache Web Server. ________________________________________________ 83
10. Apache Project Axis._______________________________________________ 99
11. SOAP __________________________________________________________ 126
12. XML. __________________________________________________________ 137
13. Microsoft .NET Framework ________________________________________ 157
14. ASP.NET _______________________________________________________ 186
15. Introducción a C# ________________________________________________ 199
16. Mono Project. ___________________________________________________ 233
17. PHP. __________________________________________________________ 248
18. JAVA. __________________________________________________________ 258
Conclusiones _______________________________________________________ 279
Bibliografía ________________________________________________________ 280
Glosario ___________________________________________________________ 282
Presupuesto ________________________________________________________ 286
Cronograma de actividades ____________________________________________ 287
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” ii
ÍN D IC E D E F IG U R A S
Figura 1. Web Interactiva y Web Programable......................................................................4
Figura 2. Secuencia de Flujo de Información. .......................................................................8
Figura 3. Secuencia de funcionamiento de los Web Services.................................................9
Figura 4. Ejemplo de contratación de viaje. ........................................................................11
Figura 5. Capas de estructura de Web Services...................................................................20
Figura 6. Estructura de Interacción. ....................................................................................21
Figura 7. Estándares y Tecnologías asociadas a Web Services...........................................31
Figura 8. Modelo Soap .........................................................................................................32
Figura 9. Estructura de SOAP..............................................................................................33
Figura 10. Funcionamiento UDDI .......................................................................................51
Figura 11. Representación de datos con HTML y XML.......................................................54
Figura 12. Tecnología XML .................................................................................................55
Figura 13. Aplicaciones XML...............................................................................................55
Figura 14. Servlet Engine. ..................................................................................................100
Figura 15. Application Servers...........................................................................................101
Figura 16. Modelo de implementación de servicios...........................................................107
Figura 17. Modelo de Ejecución. .......................................................................................108
Figura 18. Proceso SOAP ..................................................................................................111
Figura 19. TCP Monitor.....................................................................................................112
Figura 20. Servicios Web XML...........................................................................................157
Figura 21. NET Framework en tres partes.........................................................................166
Figura 22. .NET Framework ..............................................................................................166
Figura 23.Arquitectura de .Net Framework. ......................................................................167
Figura 24. Interfaces ..........................................................................................................168
Figura 25. Implementación de interfaces ...........................................................................168
Figura 26. Common Type System. ......................................................................................170
Figura 27. Soporte Multilenguaje de .NET ........................................................................171
Figura 28. Interoperabilidad de .NET con COM. ..............................................................173
Figura 29. Common Language Runtime.............................................................................174
Figura 30. Lo que ve un programador: Las clases unificadas...........................................177
Figura 31. Biblioteca de clases de .NET Framework.........................................................178
Figura 32. .NET Pet Shop vs Java Pet Store – Lines of Code...........................................180
Figura 33. Nile Benchmark of .NET ...................................................................................181
Figura 34. Ventaja de creación de nuevo proyecto en Visual Studio.NET. .......................211
Figura 35. Plantilla para aplicaciones de consola generada por Visual Studio.NET.......212
Figura 36. Hoja de propiedades del proyecto en Visual Studio .NET ...............................213
Figura 37. Código de región expandido.............................................................................222
Figura 38. Código de región comprimido ..........................................................................222
Figura 39. Páginas de propiedades del proyecto en Visual Studio .NET ..........................228
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” iii
IINN TTRR OO DD UU CC CC IIÓÓ NN ..
El uso de los web services en el mundo se está ampliando rápidamente, mientras que la
necesidad de la comunicación y de la interoperabilidad entre aplicaciones crece
rápidamente. Los web services proporcionan medios de la comunicación, estándares entre
diversos usos del software implicados en la presentación de información dinámica al
usuario. Para promover interoperabilidad e integración entre aplicaciones, permitir que más
operaciones sean combinadas para realizar tareas más complejas, se necesita una
arquitectura estándar.
El contenido presentado en el siguiente trabajo está enfocado en una investigación
Bibliográfica sobre las diversas tecnologías que se usan para el diseño e implementación de
web services, describir los requisitos para una arquitectura estándar de la referencia para
estos, principales características, documentación estandarizada o manuales como son los
RFC, white paper’s, protocolos y plataformas de operación, ventajas y desventajas que
presentan, estándares de lenguajes de programación etc.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” iv
OO BB JJ EE TT IIVV OO SS
Objetivo General.
♣ Desarrollar una investigación bibliográfica sobre los web services así como las
principales tecnologías de implementación de estos en la actualidad, con el fin de
mostrar su influencia en los factores tecnológicos y económicos de la sociedad.
Objetivos Específicos.
♣ Definir la arquitectura de los web services.
♣ Mostrar las diferentes alternativas que existen para la implementación de
plataformas tecnológicas de apoyo a sistemas de web services.
♣ Mostrar los lenguajes de programación mas importantes para el desarrollo de web
services incluyendo e lenguaje de marcado utilizado para la implementación de web
services.
♣ Establecer el funcionamiento y configuración de los principales protocolos de
comunicaciones utilizados en la implementación de web services (SOAP).
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” v
AA LL CC AA NN CC EE SS
♣ La investigación contempla la información mas importante sobre los web services,
si el lector necesita obtener mas detalles al respecto se proveerán citas a los
manuales o libro de referencia, por lo que en ningún momento debe ser comparado
con estos.
♣ Establecerá las principales características de las diferentes plataformas tecnológicas
para la implementación de web services.
♣ Abarcara las diferentes tecnologías considerando sus características, ventajas y
desventajas, así como también los documentos estándares sobre dicha tecnología.
LL IIMM IITTAA CC IIOO NN EE SS
♣ El Proyecto no contempla el desarrollo de software dentro del mismo, sino más bien
algunas demostraciones prácticas.
♣ La escasa documentación en español dificulta el proceso de investigación por lo que
se retomaran datos en otros idiomas generalmente inglés.
♣ Algunas tecnologías de tipo propietarias o de patentes electrónicas pueden impedir
el desarrollo de la investigación por lo que no se consideran modelos de este tipo.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” vi
JJ UU SS TT IIFF IICC AA CC IIÓÓ NN
La capacidad de desarrollo de aplicaciones distribuidas que caracteriza al modelo de los
web services es realmente sorprendente. Por ejemplo una empresa puede tener un servicio
de pago electrónico en línea y ofrecérselo a sus socios que, a su vez, pueden conectarse a él
independientemente de la plataforma que utilicen, Las empresas de alquiler de vehículos
pueden integrar sus sistemas de reserva en línea con aerolíneas y hoteles, con el fin de que
el cliente pueda reservar un auto, un vuelo y una habitación de hotel a la vez; es por esto
que se observa que el futuro está en los web services ya que forman parte de la plataforma
de negocios en Internet del mañana.
A medida que las empresas de envíos, de servicios y de pago electrónico comiencen a
ofrecer sus servicios sistemas por medio de los web services se facilitará la conexión a los
sitios de comercio electrónico que se estén creando, permitiendo así la interacción directa
entre empresas de diferentes rubros y agilizando de esta forma los procesos de negocios.
Hasta el momento nuestro país no cuenta con ninguna investigación de este tipo, con la
realización de esta se le abrirá una puerta más, a las empresas salvadoreñas de informarse y
conocer detalladamente sobre las ultimas tecnologías que se están implantando a lo largo
del globo terrestre. Además el estudio permitirá aproximarse al IOS (Internet OperatIng
System) o el Internet del futuro, logrando definir una plataforma para la incorporar los web
services al interconectarlos a los sistemas que ya posean las empresas. En el sector
educativo se obtendrá plasmar los aspectos fundamentales para desarrollar otras tesis sobre
el tema, a la vez servirá como fuente alterna de consulta para impartir clases sobre el área.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 1
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
11 .. HH IISS TTOO RR IIAA DD EE LLOO SS WW EE BB SS EE RRVV IICC EE SS
1.1 Repaso a la historia de la Informática Distribuida.
Hace años, todas las aplicaciones informáticas de importancia se llevaban a cabo mediante
grandes ordenadores. Luego aparecieron las terminales para conectarse a estos grandes
ordenadores, de forma que los usuarios pudieran utilizarlos por medio de comandos en
texto normal. Algunos años después, surgió el ordenador personal o PC, desde el cual los
usuarios podían ejecutar sus propias aplicaciones.
En los 80's, en particular en el sector de los ordenadores personales, los protocolos de
comunicación no ocupaban un lugar demasiado importante para los desarrolladores, la
dificultad consistía en que varias aplicaciones se comunicaran entre si.
En los 90's, algunas estructuras de objetos, como COM (Component Object CODEL) de
Microsoft y CORBA (Common Object Request Broker Architecture), que se comercializó
como una iniciativa entre proveedores de OMG (Grupo de Gestión de Objetos), cobraron
popularidad.
COM y CORBA eran modelos y arquitecturas diseñadas para la escritura y
encapsulamiento del código binario, componentes que eran llamados por los programadores
desde cualquier aplicación.
COM y CORBA no interoperaban fácilmente. En estos tiempos lejanos, las máquinas
informáticas independientes eran las que dominaban el mundo.
Informática distribuida a nivel de aplicación que se comunica con otra aplicación La
comunicación a bajo nivel maquina-maquina ya estaba disponible para los 90's.
1.2 La era de las redes locales.
La extensión de las redes locales a principios de los 90's, la conexión entre máquinas se
volvió una prioridad. Los proveedores y las organizaciones que ya contaban con sus propias
estructuras de modelo-objeto las ampliaron para permitir la comunicación a través de redes.
OMG estableció el IIOP (Internet Inter-ORB Protocol) como protocolo de cable
estándar de CORBA.
Microsoft introdujo el DCOM (Distributed COM) como su protocolo de cable que permitía
cruzar las fronteras entre equipos. Otro poderoso aspirante surgió con posterioridad a IIOP
y DCOM, el RMI (Remote Method Invocation) de Sun MicroSystems, utilizado por los
usuarios de Java.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 2
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
1.3 La era de Internet y la Web.
La conexión de aplicaciones mediante el uso de cualquiera de los protocolos mencionados
con anterioridad se caracteriza por un buen funcionamiento, en especial cuando dichas
aplicaciones se encuentran en la misma red local.
Con la aparición de Internet, y en particular de la Web, la red creció inmensamente, y se
volvió extremadamente distribuida y descentralizada.
Ni personas, ni empresas eran capaces de tomar la decisión sobre que sistema operativo
o entorno de programación/lenguaje, se ejecutaría en los diversos ordenadores conectados a
Internet. Esto significa que las reglas que tienen vigencia en la red local, no funcionan de
forma óptima en Internet y la Web.
La pregunta es ¿Cuáles son los retos actuales en la utilización de Internet y la Web de los
protocolos de aplicación distribuida?
Primero surgieron las Web Aisladas. Luego surgió la interoperabilidad en aplicaciones y
sitios Web por medio de los Frames (Frameset). Otra forma que se dio fue, cuando el
servidor Web actual como un cliente de otra aplicación Web y rastrea el contenido
pertinente de la página.
Posteriormente se empleo CGI (Common Gateway Interface), para la publicación de la
información (HTTP GET y POST).
Tras la aparición de XML a mediados de los noventa, los desarrolladores se encontraron
con la posibilidad de expresar una estructura de información y mensajes de forma
autodescriptiva y uniforme, lo que impulso a XML, para aplicar un formato a los mensajes
intercambiados entre sistemas. Esta técnica permite que los usuarios intercambien mensajes
de formato correcto entre sistemas de forma autodocumentada/autodescriptiva y extensible,
independientemente del sistema operativo o del entorno de lenguaje de los sistemas.
Uno de los primeros protocolos para la comunicación mediante el protocolo HTTP, que
permite llamar a procedimientos remotos sin importar el lenguaje de desarrollo o el sistema
operativo fue XML-RPC, sin embargo a pesar de ser el primero en este campo y de las
ventajas que ofrece la mayoría de proveedores optaron por su sucesor SOAP (Simple
Object Access Protocol).
El concepto de web services comenzó a tomar forma definitiva con la introducción de
SOAP como protocolo de mensajería entre ordenadores. SOAP es un protocolo de cable
sencillo basado en XML, se diseño para conexión entre ordenadores independientes de
subsistemas operativos, lenguajes de programación o modelos de objetos utilizados (e
incluso con la carencia total del modelo de objeto).
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 3
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
A pesar de que su nombre pueda parecer que requiere del uso de determinados objetos,
SOAP especifica el formato del mensaje que accede e invoca a los objetos, en vez de
especificar los objetos en si.
SOAP es un protocolo sencillo y extensible para la comunicación de ordenador, que emplea
por igual los estándares actuales de Internet: XML para el formato de mensajes, http y otros
protocolos de Internet para el transporte de mensajes.
En mayo del año 2000, el W3C (World Wide Web Consortium http://www.w3c.org/)
reconoció la propuesta de SOAP presentada de forma conjunta por un conglomerado de
empresas (Ariba Inc., CommerceOne Inc., Compaq Computer Corp., Microsoft Corp.,
Development Corp., IBM Corp, Hewlett-Packard Co., etc). Siendo desarrollado en base a
un estándar abierto.
1.4 Evolución histórica del Web.
Con el surgimiento del Internet las aplicaciones en la web partieron usando el lenguaje de
etiquetas HTML, permitían usar la web como medio para distribuir documentos estáticos,
estos se alojaban en servidores Web que usaban el protocolo de comunicación HTTP,
luego la información se desplegada por navegadores web en cualquier cliente en el mundo
que los invocara por medio de una dirección web conocida como URL, con el paso del
tiempo se observo la necesidad de generar información dinámicamente, como solución ante
esta se desarrollaron aplicaciones web, usando códigos fuente escritos en diferentes
lenguajes de programación como ASP, PHP, PERL, etc. Estos códigos fuentes se alojaban
y se ejecutaban en servidores web, estos generaban HTML en forma dinámica. Varias
tecnologías: desde CGI a Servlets.
Luego los servidores web permitieron incorporar capacidades de programación distribuida.
Pero las necesidades de los usuarios cada día son mayores hasta que se necesito integrar las
aplicaciones web con otras del mismo tipo, integrar aplicaciones entre diferentes
plataformas, lenguajes de programación, sistemas operativos, compañías, etc. como
alternativas de a tal necesidad la representación de información (como XML) y nuevos
mecanismos de transporte (como SOAP) aparecieron uniéndose para formar lo que ahora se
conoce como los web services.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 4
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Figura 1. Web Interactiva y Web Programable.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 5
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
22 .. ¿¿ QQ UU ÉÉ EE SS UU NN WW EE BB SS EE RR VV IICC EE ??
Un web service es un programa modular y autodescriptivo que se encuentra alojado dentro
de un servidor web, sus funciones pueden ser solicitadas por aplicaciones cliente que
tengan la capacidad de ejecutarlas esto se hace posible mediante el envío y recepción de
mensajes SOAP a través del protocolo de transferencias de hipertexto HTTP y el lenguaje
XML, pueden hacerlo desde cualquier red de área local que satisfaga los estándares de
Internet o desde la web, los web services se identifican en la red por una URI, cada web
service es creado para cumplir una función especifica permitiendo que los programas
escritos en lenguajes y plataformas diferentes puedan establecer comunicación entre sí de
forma estándar, es por esta razón que los web services son independientes del sistema
operativo o lenguaje de programación en que fueron creados o desarrollados, además los
web services tienen la capacidad de reutilizarse o combinarse, trabajando de forma integral
con aplicaciones ya existentes para realizar mas tareas, el funcionamiento de un web
service se define por el lenguaje Web Service Description Language WSDL y para
encontrarlos usan (UDDI), el World Wide Web Consultorium es la entidad que se encarga
de establecer los estándares que deben cumplir los web services, aplicaciones mas
complejas se desarrollan usando lenguaje XML.http://www.ietf.org/rfc/rfc2396.txt
Según el World Wide Web Consultorium, web service es un sistema software identificado
por una URI (Uniform Resource Identifiers: sintaxis Generica, IETF RFC 2396, T.
Berners-Lee, R. Fielding, L. Masinter, August 1998 vea <>.) cuyas interfaces públicos
están definidos y descritos mediante XML. Esta definición puede ser accedida por otros
sistemas software, los cuales pueden interactuar con el web service en la forma prescrita en
su definición, utilizando mensajes XML y transportados por protocolos Internet.
2.1 ¿Cómo funcionan los web services?
Los web services se construyen sobre el acoplamiento del modelo de programación web
tradicional, y lo extienden para su uso en otros tipos de aplicaciones. Existen tres
diferencias principales entre los web services y las aplicaciones web tradicionales: los web
services utilizan mensajes SOAP en lugar de mensajes MIME, los web services no son
dependientes de HTTP y los web services proporcionan metadatos que describen los
mensajes que producen y consumen.
En primer lugar, los servicios Web se comunican utilizando mensajes SOAP. SOAP
formaliza el uso de XML como un modo de pasar datos de un proceso a otro. SOAP define
un modelo de trama para el versionado y extensibilidad del protocolo, un modo de
transportar información de errores y un modo de enviar mensajes sobre HTTP. El cuerpo de
un mensaje SOAP contiene cualquier tipo de XML que una aplicación desee enviar.
El cambio de mensajes escritos con MIME a mensajes basados en XML refleja una
diferencia fundamental entre el cliente de una aplicación web tradicional (un navegador) y
el cliente de un web service.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 6
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Generalmente, los navegadores representan páginas HTML (u otros datos escritos con
MIME, como imágenes) y dejan al usuario la interpretación de la información que
visualizan. Por otra parte, los clientes de los web services normalmente necesitan
interpretar los datos que reciben y hacer algo útil con ellos; incluso pueden no tener un
interfaz de usuario. XML proporciona un modo estándar de representar y manipular datos,
y las herramientas de procesamiento XML son una lógica elección como formato de
mensajes para los web services.
Aunque SOAP autoriza el uso de XML para representar el contenido de un mensaje, no
dice nada sobre cuál debe ser ese aspecto de XML. Corresponde a los diseñadores de web
services, decidir qué debe transportar cada mensaje. En algunos casos, los mensajes pueden
contener parámetros para invocaciones a métodos. La ventaja de esta aproximación es que
resulta muy familiar.
Específicamente, la mayoría de los sistemas centrados en métodos esperan que un mensaje
contenga exactamente el número adecuado de argumentos, en el orden adecuado y con los
tipos adecuados. En algunos casos, los mensajes pueden contener información que no
represente la llamada a un método. Esta aproximación permite un acoplamiento débil; los
clientes y servidores pueden tener una mayor flexibilidad sobre el formato y contenido de
los datos que producen y consumen. Este modelo de programación es parecido al modelo
clásico Web, que no indica cómo se procesan los datos enviados en un mensaje.
La segunda diferencia principal entre los web services y las aplicaciones web tradicionales
es que los web services no son específicos de los protocolos de transporte. Aunque la
especificación SOAP únicamente define cómo enviar mensajes sobre HTTP (y eso es lo
que la amplia mayoría de los web services actuales realizan) también pueden utilizarse
otros protocolos de transporte. Es posible enviar mensajes SOAP utilizando SMTP, TCP,
un protocolo de mensajería instantánea como Jabber o cualquier otro protocolo. Aunque la
mayoría de mensajes SOAP se enviarán sobre HTTP en un futuro inmediato, la capacidad
de utilizar otros protocolos es muy importante. HTTP no se diseñó para soportar peticiones
ejecutándose durante mucho tiempo o para enviar notificaciones de eventos a clientes.
Estos aspectos se solucionan mejor utilizando otros protocolos, y con el tiempo se
dispondrá de un soporte estandarizado para ello.
Como los web services pueden comunicarse utilizando una amplia variedad de protocolos
de transporte, es necesario definir servicios de más alto nivel, como la seguridad, de un
modo centrado en mensajes y neutral respecto del transporte. Para soportarlo, el formato de
un mensaje SOAP incluye un elemento de cabecera opcional. La cabecera transporta
metadatos del mensaje; es decir, información adicional no relacionada directamente con la
información sobre el dominio del problema en el cuerpo del mensaje. Este mecanismo se
inspiró en HTTP, que utiliza cabeceras de mensaje como un modo de extender su
comportamiento básico de petición/respuesta. Definir extensiones de protocolo al nivel de
SOAP garantiza un buen entendimiento de la semántica de mensaje, independientemente
del protocolo de transporte utilizado para su entrega.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 7
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Además de ser neutral respecto del transporte, SOAP no requiere el envío de un mensaje
desde un cliente hasta un servidor en un solo “salto”. La especificación SOAP define la
noción de intermediarios, nodos por los que cruza un mensaje en su camino hacia su
destino final. Utilizando intermediarios, se puede “virtualizar” la topología de red física
para poder enviar mensajes a web services utilizando el camino y la combinación de
protocolos que resulten más apropiados. No existe ningún soporte generalizado para utilizar
intermediarios SOAP con los kits de herramientas de web services actuales, pero estará
disponible en un futuro. Sin embargo, cuando esta funcionalidad sea más convencional, se
podrá implantar web services en una amplia variedad de configuraciones de red sin tener
que modificar código de cliente ni de servidor.
La tercera diferencia principal entre los web services y las aplicaciones Web tradicionales
es que los web services son autodescriptivos; proporcionan metadatos que describen los
mensajes que producen y consumen, y la información de direccionamiento requerida para
invocarlos. Los formatos de mensaje de un web service, se definen utilizando XML
Schema (XSD). XML Schema es suficientemente flexible para describir un amplio número
de estructuras de mensajes, incluyendo modelos de contenidos abiertos con un control fino
sobre la extensibilidad, lo que resulta crítico para que los servicios sean débilmente
acoplados respecto a los datos que envían y reciben. Los comportamientos de un web
service se describen utilizando el lenguaje Web Service Description Language (WSDL),
que mapea intercambios de mensajes a operaciones agrupadas en portTypes (interfaces) y
describe cómo pueden invocarse estas operaciones utilizando enlaces de protocolos de
transporte particulares. Se Puede utilizar estas descripciones para crear software que se
comunica con un web service, tanto directa como indirectamente mediante alguna
herramienta de generación de código.
Los web services hacen referencia a la creación de una plataforma nueva y de propósito
general para construir sistemas distribuidos débilmente acoplados. En el mundo nuevo de
los web services, hay cuatro cosas que recordar:
♣ Todo se basa en un acoplamiento débil. En ello se basa el éxito de la Web y lo que
hace interesantes los web servicies.
♣ Todo se basa en XML. Cuanto más se conozca de XML mucho mejor.
♣ Se puede utilizar objetos para implementar web services, pero éstos no son el núcleo
del modelo de programación.
♣ La evolución de la plataforma continúa. Hoy se pueden construir web services
básicos en una amplia variedad de plataformas. Se sigue trabajando en web services
de más alto nivel, el uso de protocolos de transporte alternativos y otros temas
interesantes.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 8
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Secuencia de flujo de información:
1. Empresa A diseña y pone en marcha un web service.
2. La empresa hace uso de WSDL para describir el servicio.
3. A continuación registra el servicio en un repositorio UDDI o en un registro web
XML.
4. La empresa B localiza y solicita el servicio registrado al consultar los repositorios
UDDI y/o web XML.
5. El servicio o usuario cliente escribe una aplicación que realice binding del servicio
registrado utilizando SOAP (en el caso de UDDI) y/o ebXML
6. Se intercambian las empresas A y B datos y mensajes XML sobre HTTP.
Para que un web service se encuentre habilitado debe residir residen en un servidor remoto.
Los web services utilizan estándares que indican como deben ser las peticiones o
aplicaciones informáticas instaladas en otro ordenador, brindando un conjunto de
protocolos que permiten a las aplicaciones integrar su funcionalidad y sus datos a otras
aplicaciones a través de Internet.
Figura 2. Secuencia de Flujo de Información.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 9
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Secuencia del funcionamiento de los web services
1. Cliente pregunta al registro UDDI en que lugar se encuentra un web service que
realice una función determinada.
2. El registro UDDI, le indica al cliente en que servidor puede encontrar el web
service.
3. El cliente hace la petición al servidor del lenguaje necesario para interactuar con el
web service a este se le conoce como documento WSDL.
4. El servidor provee el documento WSDL necesario para interactuar con el Web
service.
5. El Cliente invoca la petición al web service usando el protocolo SOAP.
6. Web service retorna una respuesta mediante el protocolo SOAP.
Figura 3. Secuencia de funcionamiento de los Web Services.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 10
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
33 .. CC AA RR AA CC TT EE RR ÍÍSS TT IICC AA SS DD EE LLOO SS WW EE BB SS EE RR VV IICC EE SS ..
Algunas de las principales características que resaltan los web services son:
♣ Integración entre aplicaciones.
♣ Estructurados en forma de componentes de software en la red.
♣ Lenguaje y sintaxis independiente de la plataforma.
♣ Implementación mediante XML, se obtiene como resultado, que cualquier
plataforma use esta tecnología.
♣ Alta disponibilidad.
♣ Tolerancia a fallas.
♣ Escalabilidad.
♣ Buen Rendimiento (performance).
Desarrollo de aplicaciones distribuidas altamente integradas que interactúan por XML
entre los web services existentes.
Ofrecen funciones a usuarios empleando un protocolo estándar que, en casi todos los casos,
es SOAP.
Usan un lenguaje propio llamado WSDL (lenguaje de descripción de web services) que
permite describir sus interfaces con suficiente detalle, esta se proporciona normalmente en
un documento XML.
Se registran para que los futuros usuarios los encuentren fácilmente. Este registro se realiza
a través de UDDI (descripción, descubrimiento e integración universales).
3.1 ¿Para qué sirven los web services?
Los primeros web services solían ser fuentes de información que podían incorporarse
fácilmente en aplicaciones para cotizaciones, previsión del tiempo, resultados deportivos,
etc.
Por ejemplo, una hoja de cálculo de Microsoft® Excel en la que se resumiría la siguiente
información: acciones, plan de pensiones, cuentas bancarias, préstamos, etc. Si esta
información estuviera disponible a través de web services, Excel podría actualizarla
continuamente. Parte de dicha información sería gratuita y otra necesitaría que el usuario se
subscribiera al servicio. La mayor parte de esta información está disponible ahora en
Internet. Sin embargo, los web services posibilitan que sea más fácil y fiable tener acceso a
ella. Los web services permiten que los usuarios creen aplicaciones mas potentes usándolos
como elementos constituyentes, ejemplo, un usuario puede desarrollar una aplicación de
compra para obtener automáticamente de varios fabricantes información sobre precios,
permitir seleccionar un fabricante, enviar el pedido de compra y realizar un seguimiento
hasta el momento de recibir el envío.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 11
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Es posible que la aplicación del fabricante, además de exponer sus servicios en la web,
utilice los web Services para comprobar el crédito del cliente, cargar el importe del envío
en su cuenta y enviar el pedido a través de una empresa de transportes.
La tecnología de los web services proporciona la base para la integración y agregación de
aplicaciones. Desde estas especificaciones base, las empresas están generando soluciones
reales y obteniendo valor real de las mismas. Aunque se ha trabajado mucho para que los
web services sean una realidad, es necesario hacer mucho más. Actualmente los web
services tienen un gran éxito entre la gente, pero todavía hay temas sobre los que los
desarrolladores deben seguir trabajando; por ejemplo, la seguridad, gestión operacional,
transacciones, mensajería fiable, etc.
La arquitectura Global XML Web Services Architecture (GXA) permitirá que los web
services evolucionen ofreciendo un modelo consistente y de propósito general para añadir
nuevas capacidades avanzadas a los web services actuales de modo modular y extensible.
Se cree que en el futuro, algunos de los web services más impresionantes admitirán
aplicaciones que utilicen el medio web para realizar tareas que no pueden realizarse
actualmente. Por ejemplo, uno de los servicios que el proyecto Microsoft .NET My
Services admitirá es un servicio de calendario. Así, si su dentista y mecánico expusieran sus
calendarios mediante este web service, el usuario podría concertar citas en línea desde su
calendario para una limpieza dental y mantenimiento rutinario. Y es fácil imaginar los
cientos de aplicaciones que podrían diseñarse cuando se tiene el conocimiento para
programar el medio Web.
Ejemplo: Contratar un viaje.
Figura 4. Ejemplo de contratación de viaje.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 12
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
44 .. PP LL AATTAA FF OO RR MM AA SS DD EE DD EE SS AA RR RR OO LLLLOO
4.1 WebSphere de IBM (http://www.ibm.com).
IBM ofrece varias herramientas para la creación de los sistemas de web services, en lugar
de establecer un solo producto como solución, proporciona una gamma de productos entre
los cuales se destacan DB2 (usado como gestor de bases de datos), Lotus Notes
(groupware), Tivoli (gestor de bases de datos), y la aplicación en donde se percibe mas
fácilmente, WebSphere (Infraestructura de Internet). Como un ejemplo, DB2 incorpora
varios herramientas para la conversión continua de los contenidos de bases de datos entre
XML, y el servidor de dominio dentro de Lotus puede exportar algunos servicios como
web services.
WebSphere es el producto de IBM más importante en cuanto a web services se refiere.
WebSphere es una gamma de herramientas, todas ellas relacionadas por el hecho de ser
útiles para el diseño y creación de una de web services.
Entre sus componentes esta un servidor web, un servidor directorio, herramientas de
autorización de pagina web, servicios de seguridad, gestión de sesión y un amplia variedad
de herramientas para la creación de un sitio de comercio electrónico. El componente más
importante de WebSphere en relación con los web services, es el Servidor de la Aplicación
WebSphere (WebSphere Applicatton Server). Este servidor de aplicación incluye
herramientas como un marco J2EE para el desarrollo y la implementación de Enterprise
Java Beans, controladores JDBC para la conexión a bases de datos, un contenedor servlet,
un kit para desarrollo de Java, servicios de transacción y un grupo de herramientas
enfocadas especialmente al desarrollo de una aplicación basada en el modelo de web
services descritos con anterioridad.
Estas herramientas especificas para los web services incluyen bibliotecas Java para la
producción y el análisis de XML, la transmisión de mensajes SOAP, la creación de
archivos WSDL y para establecer comunicación con un Registro de! Servidor por medio de
UDDI.
El conjunto de herramientas de SOAP que incluye IBM en el Servidor de la Aplicación
WebSphere es el mismo que ofrece Apache (Servidor Web) de forma gratuita. No obstante,
como sucede en el caso del JDK que se envía con WebSphere, la versión se selecciona
cuidadosamente para asegurar la compatibilidad con el resto de WebSphere. Por esta razón,
resulta más conveniente el uso del JDK y SOAP que se incluyen en WebSphere cuando se
vayan a usar otras herramientas de WebSphere.
WebSphere incluye una herramienta llamada wsdlgen que se utiliza para generar archivos
WSDL para describir un web service. La información de un archivo WSDL incluye
descripciones operativas de las funciones que un web service es capaz de realizar, los
protocolos que se pueden utilizar para comunicarse con él y los extremos en Internet donde
se puede contactar.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 13
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Un archivo WSDL es legible, pero al tratarse de XML, pierde esta condición. Por lo tanto,
la herramienta wsdlgen es útil ya que actúa como un "asistente" que facilita la creación del
archivo WSDL.
Asimismo, en WebSphere se incluye la biblioteca Java uddi que se utiliza para la
comunicación con un Registro de Servicio UDDI. A pesar de que se puede usar un registro
UDDI privado, existe un registro UDDI, único y global, que puede utilizarse contactando
con cualquiera de los "sitios de operación" de UDDL Estos sitios de operación son web
services, y utilizan SOAP (y por lo tanto XML) para comunicarse. No obstante, UDDI es
un protocolo sofisticado, por lo que ÍBM ha implementado uddi4j, que facilita la tarea de
escribir una aplicación y se comunica con un sitio de operación para publicar y buscar web
services. A pesar de que no se requiere para UDDI, WSDL es un complemento natural de
éste al actuar como el protocolo con el que se puede describir un web service y uddi4j
agrega herramientas que ayudan en el uso de WSDL para la descripción del web service a
registrar.
4.2 e-Speak de Hewlett Packard (http://www.hp.com).
HP ha sido una de las empresas pioneras en el área de los web services incluso antes que
fueran populares, inicio ofreciendo el producto llamado e-Speak, siendo este una
plataforma abierta para el desarrollo y uso de servicios electrónicos. Un servicio electrónico
opera de forma similar a un web service, Un servicio electrónico es aquel que se encuentra
disponible en Internet y desarrolla una función específica. Se puede ubicar dinámicamente,
invocar y crear por medio de otros servicios electrónicos. e-Speak nació como un proyecto
de investigación en el año 1995 y en 1998 se inició el proyecto de software para
transformarlo en un producto. En Mayo de 1999 salió al mercado el primer producto de e-
Speak.
Desde entonces, HP cambio hacia estándares de base XML para web services como SOAP
y UDDI, ya que cuentan con una mayor aceptación por parte de ¡a industria; HP ahora tiene
un nuevo producto llamado HP Web Services Plataform, este se construyo de acuerdo a
esos estándares.
Java ha desarrollado e-Speak. por lo que sus clientes necesitan utilizar su aplicación API
Java (conocido como Interfaz E-Speak de Java, J-ESI) para la creación de servicios
electrónicos y clientes. Asimismo, cuenta con mecanismos de base XML para la interacción
con servicios e-Speak.
4.3 HP Web Services Platform.
La plataforma de web services de HP es una plataforma XML compuesta por los siguientes
componentes:
♣ Mensajería
♣ Interacción
♣ Procesamiento
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 14
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
♣ Seguridad
♣ Transacción
Mensajería
La mensajería esta formada por oyentes y buzones de entrada para la recepción de
mensajes. Un oyente es un componente estándar que se usa de base de recepción. Los
oyentes se pueden configurar para el funcionamiento en una negociación de equilibrio de
carga para la escalabilidad en algunos protocolos estándar de transporte como HTTP,
HTTPS, SMTP y FTP.
Interacción
Ayuda a la transmisión de una petición a un componente de aplicación. Este puede
utilizarse en envíos a aplicaciones (por ejemplo, peticiones SOAP RPC) como en
conversaciones de mensajes multi-nodo (por ejemplo situaciones de negocio con ebXML).
Además cuenta con un controlador de interacción que es compatible con conversaciones
entre socios de negocios. La conversación es descrita usando el protocolo WSCL (Web
Service Conversation Language). Es a este protocolo al que HP presenta como propuesta
para la estandarización de la descripción de la conversación. Ya que este describe
conversaciones de nivel empresarial y especifica documentos XML intercambiados, así
como su secuencia.
Procesamiento
Este es compatible en tres niveles de modelos de procesamiento de aplicación:
♣ Solución de alto nivel y costo, por medio de un motor de proceso de gestión/sistema
de flujo de trabajo en HP Process Manager.
♣ Solución de secuencia de comandos creada alrededor de Cocoon 2 XSP. Esta se
podría usar para desarrollar la lógica de negocios de niveles intermedios.
♣ Solución J2EE de bajo nivel bajo y menor costo, en la que la lógica empresarial se
desarrolla en una Java Bean/EJB.
Seguridad
Este componente se enfoca en los aspectos relacionados con la seguridad y cuenta con
implementaciones de los estándares de seguridad.
♣ Firma Digital XML.
♣ Especificación de gestión clave XML o XKMS (XML Key Managment
Specification).
♣ Encriptación XML.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 15
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Transacción
Se basa en los aspectos que surgen en la calidad del servicio QoS (Quality Of Service).
Para encontrar mas detalles acerca de HP Web Services Platform usted puede visitar
http://www.hp.com/go/webservices.
4.4 .NET y .NET Framework de Microsoft
(http://www.microsoft.com).
La plataforma de implementación y desarrollo de web services que ofrece Microsoft es
.NET Framework, .Net se anuncio por primera vez en Julio del 2000. La plataforma .NET
se forma en base de bloques construidos con .NET Framework. La plataforma .NET consta
de los siguientes componentes:
♣ Sistemas operativos en servidores, escritorios y dispositivos
♣ .Net Enterprises Servers
♣ .Net Building Block Services
♣ Visual Studio .Net
♣ .Net Framework
Sistemas operativos en servidores, escritorios y dispositivos.
Este nivel se conforma por los sistemas operativos de Microsoft para servidores, como el
Servidor Windows 2000, sistemas operativos para ordenadores como Windows XP,
Windows 2000 Professional o Windows ME y sistemas operativos para mecanismos como
Windows CE.
.Net Enterprises Servers.
Este nivel se compone de los servidores .Net Enterprise Servers como BizTalk 2000 Server
(EAl o Enterprise Application Integration y B2B Server), Commerce Server 2000 (servidor
de soluciones de comercio electrónico), SQL Server 2000 (servidor de base de datos),
Exchange Server 2000 (servidor de correo electrónico y colaboración), Application Server
2000 (gestión de sitios Web de alta disponibilidad y granjas de servidores). Content
Management Server 2001 (gestión de contenido Web), Host Integraron Server 2000
(conexión a sistemas de legado), Internet Securíty and Acceleration Server 2000
(cortafuegos y servidor proxy), Mobile Información Server 2001 (entrada de conexión a
aparatos móviles) o SharePoint Portal Server 2001 (gestión de documentos, búsqueda de
empresas, y motor de portal).
Para encontrar mas detalles acerca de los servidores .NET Servers usted puede visitar
http://www.microsoft.com/Servers
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 16
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
.Net Building Block Services
Es una colección de todos los web services que Microsoft espera poner a la venta. Estos
pueden utilizarse por desarrolladores como funciones típicas para la construcción de
aplicaciones que generen, evitando de este modo dedicar demasiado tiempo a diversos
aspectos que tienen en común las aplicaciones, como por ejemplo como sucede con la
autenticación o inicio de sesión. Uno de estos web services esta disponible en su anterior
edición: el servicio Passport. Éste permite acceder únicamente a través de sitios o
aplicaciones Web.
Visual Studio .Net
Es la herramienta para creación y desarrollo rápido de web services y otras aplicaciones (es
la siguiente versión del Visual Studio 6 IDE o Integrated Development Environment).
.NET Framework j
El último elemento de la plataforma .NET es el marco .NET Framework. Este es la nueva
plataforma de desarrollo por parte de Microsoft y contiene una nueva interface de
programas Windows y API, incorporando tecnologías de componentes COM+, desarrollo
Web ASP (Active Server Pages), seguridad, implementación sencilla y los protocolos que
usan los web services como SOAP, WSDL y UDDI.
Componentes de La arquitectura .NET Framework:
♣ Web services
♣ Formularios Web
♣ Formularios Windows
♣ Información y clases de XML
♣ Clases de bases
♣ Common Language Runtime (CLR)
Los web services, formularios Web y Windows conforman la primera capa de .NET
Framework, estos formularios se usan como interfaces para las aplicaciones, además los
formularios web brindan clases para diseñar y desarrollar formularios de este mismo tipo
(de base HTML operando en un navegador). Los formularios Windows brindan clases para
diseñar y desarrollar aplicaciones propias de Windows Graphical User Interface (GUI).
Ambos formularios proporcionan clases para la creación, implementación y uso de los web
services por medio de los protocolos SOAP, WSDL y UDDI.
Las clases de bases son similares que los grupos de clases en ATL (Active Template
Library) y MFC (Microsoft Foundation Clases) o algunas de las clases de base java y se
incluyen funciones entrada/salida, de seguridad, comunicaciones de red, procesamiento de
grupos.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 17
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
La información y clases XML agregan funcionalidades a las clases bases ya que
proporcionan un conjunto de clases para la manipulación y manejo de información en
XML, incluye la información guardada en bases de datos por medio de SQL Server y
ADO.NET. La compatibilidad relacionada con datos XML consiste en el acceso y
manipulación de datos XML, búsquedas con la incorporación de Xpath y transformación
de XML con XSLT.
Common Language Runtime, opera sobre del sistema operativo, realiza varias tareas como
activar objetos, recolección de basura, manejo de memoria, ejecución de código,
comprobación de seguridad de objetos, etc.
CLR permite usar todos los lenguajes que se puedan representar en Common Intermediate
Language (CIL) o lenguaje intermedio de Microsoft en el que se haya compilado el código
(esta funcionalidad es posible gracias a los tipos de datos en común como Long o Boolean).
CLR sólo opera en sistemas operativos de Windows (a pesar de que existen indicaciones de
que otras compañías han creado versiones de CIL para Linux).
4.5 Sun Microsystems y Sun ONE Studio (http://www.sun.com).
La plataforma para el desarrollo de web services por parte de Sun Microsystems es Sun
ONE (Open Network Environment), es una plataforma creada en torno a la gama del
servidor Sun-Netscape Alliance iPIanet y la nueva API XML para web services conocida
como JAX Pack.
La plataforma Sun One esta compuesta por las siguientes capas:
♣ Creación y ensamblaje del servicio: incorpora las herramientas para el desarrollo
de web services y aplicaciones. Incluye las herramientas de Forre Developer de Sun.
♣ Reparto del servicio: incluye tecnologías que ubican, conectan, agregan, presentan,
comunican, personalizan, notifican y reparten contenidos. El servidor iPIanet Portal
Server se ha creado para esta capa.
♣ Aplicaciones y web services: se diseño para la transformación de aplicaciones de
productividad de transacciones de negocios tradicionales en web services
colaborativos. Los productos de IPianet Commerce (iPIanet BuverXpert,
BillerXpert, SellerXperr, MarketMaker) son los que colaboran en esta capa.
♣ Contenedor del servicio: incluye productos que facilitan la Implementación de
web services y los pone a disposición del usuario. Esta capa incluye la Aplicación
iPIanet y los Servidores Web.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 18
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
♣ Integración del servicio: ayuda a conectar sistemas y aplicaciones actuales. Los
producios que forman pare de esta capa incluyen el Servidor de Integración iPIanet
y el iPIanet ECXpert. El servidor de integración permite el acceso a los datos y la
lógica almacenados, como SAP o incluso aplicaciones personalizadas.
♣ Identidad y política: se ocupa de los perfiles de gestión de usuarios, usuarios,
contexto, funciones y seguridad. Los producios de Gestión del Usuario iPIanet:
Servidor del Directorio iPianet, Mera-Directorio, Enrutador de Acceso al Directorio.
Administrador, Servidor de Proxy v el Sistema de certificado de Gestión iPIanet se
ocupan de esta capa.
♣ Plataforma: hace referencia a la plataforma recomendada que el sistema operativo
necesita para ejecutar estos web services. Sun recomienda la plataforma para el
sistema operativo Sun y Sun Cluster 3.0, aunque las herramientas y los productos
mencionados en las capas anteriores funcionan en la mayoría de las plataformas de
sistema operativo UNIX y Windows.
Los componentes en esta pila se basan en las tecnologías estándar XML como SOAP,
WSDL, UDDI, etc. y en el API de Java. Sun también ha definido un conjunto de API Java
para XML, ambas API orientadas hacia documentos, como JAXP, JAXB, así como las
orientadas hacia procedimientos como JAXM. JAXR y JAX-RPC. Para más detalles acerca
de Sun 0'NE consulte http://WWW.SUn. com/sunone,'.
Agrupaciones que desarrollan estándares para Web services:
♣ W3C. World Wide Web consortium Fundada en 1994 con 500 miembros Es la
principal desarrolladora de estándares para Web services.
♣ OASIS Organization of the Advancement Structured Information Standards,
avances de estándares de la información estructurada trabajan con tecnologías XML
consiste en 400 miembros que mejoran XML.
♣ IETF Internet Engineering Task Force, Fuerza de Tarea de Ingeniería en Internet.
Trabaja sobre las arquitecturas y tecnologías de Internet.
♣ ISO Internacional Organization for Standardization tiene 140 países miembros se
encarga de desarrollar estándares para mejorar el comercio internacional.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 19
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
55 .. IIMM PP LL EE MM EE NN TTAA CC IIÓÓ NN DD EE WW EE BB SS EE RR VV IICC EE SS ..
Para implementar web services se necesita:
♣ El medio físico de comunicaciones, o llamada Intranet Administrativa.
♣ Uno o más registros UDDI de web services. Tiene que existir sincronización de
servicios entre los distintos
♣ registros.
♣ La descripción del servicio mediante un documento en XML que se recoge en un
archivo WSDL (lenguaje de descripción de web services)
♣ Un protocolo de intercambio de información en un entorno distribuido, que se
soporte sobre http, SOAP (Simple Object Access Protocol).
Las dos implementaciones más extendidas del mercado son Sun ONE y Microsoft .NET que
ofrecen todo una serie de productos, para implementar web servicies.
5.1 Protocolos que permiten implementar Web Services.
Hay un convenio generalizado que manifiesta que los web servicies se invocan en Internet
por medio de protocolos estándar basados en XML. Hoy en día hay dos grandes tendencias:
XML-RPC y SOAP. A la hora de programar un web service, hay que decidir qué protocolo
usar, porque un protocolo es incompatible con el otro. De modo que si se programa un
servicio web con XML-RPC, no podrá ser invocado desde un lenguaje de programación
que trabaje con SOAP, como por ejemplo .Net de Microsoft.
Tanto SOAP (Protocolo de acceso a objetos simple, Simple Object Access Protocol) como
XML-RPC son lenguajes de mensajería basada en XML, estandarizados por el consorcio
W3C, que especifican todas las reglas necesarias para ubicar web services, integrarlos en
aplicaciones y establecer la comunicación entre ellos.
Brevemente, la diferencia entre SOAP y XML-RPC es su complejidad. XML-RPC está
diseñado para ser sencillo. SOAP por el contrario está creado con idea de dar un soporte
completo y minucioso de todo tipo de web services. La curva de aprendizaje de XML-RPC
es muy suave, por lo que un programador novato en este campo, puede conseguir resultados
satisfactorios con poco esfuerzo. Con SOAP no pasa esto, pero a cambio, se dispone de más
potencia. Por ejemplo, con XML-RPC no se puede elegir el conjunto de caracteres a utilizar
en los web services que se desarrollen. En SOAP se puede elegir entre US-ASCII, UTF-8 y
UTF-16.
Por el contrario, en favor de SOAP se puede añadir que el famoso web service de Google,
está basado enteramente en SOAP, y que el proyecto Apache, dispone ya de un módulo de
trabajo con SOAP, que se puede usar como una librería cliente para invocar servicios
SOAP disponibles en cualquier lugar o como una herramienta del lado del servidor para
implementar servicios SOAP accesibles.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 20
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
5.2 Componentes de los web services.
Los principales bloques de construcción de los web services presentan tres aspectos
paralelos:
a) Concepto de Ubicación.
b) Concepto de Descripción.
c) Concepto de Llamada.
Cada bloque consta de una serie de capas, en la figura siguiente se estudian estos bloques
como entidades.
La arquitectura Web services posee cuatro capas:
♣ Descubrimiento(Discovery) UDDI –Universal Description, Discovery &
Integration.
♣ Descripción(Description) se encarga de conocer qué hacen exactamente, y cómo se
usan mediante WSDL – Web Services Description Language.
♣ Invocación de Llamadas(Invocation) SOAP –Simple Object Access Protocol.
♣ Transporte mediante el protocolo http.
Figura 5. Capas de estructura de Web Services.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 21
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Los elementos constitutivos fundamentales de los web services son:
♣ El Servicio (web service): es la aplicación proporcionada para uso de los
solicitantes. Su implementación se lleva a cabo en una estación accesible por red.
Utiliza un lenguaje de descripción de servicios o funciones.
♣ El Proveedor de Servicios: es la plataforma responsable de proporcionar el acceso
al servicio.
♣ El Solicitante de Servicios: es quien quiere hacer uso de cierta funcionalidad. Es el
cliente el que busca y solicita el web service.
♣ El Registro de Servicios: es una base de datos que contiene descripciones de los
web services que se encuentran disponibles, donde los Proveedores publican sus
web services y los solicitantes buscan la meta información sobre los mismos.
Las operaciones básicas asociadas a los Web Services son:
1. Publicar: un servicio sólo puede ser utilizado si se da a conocer. Para ello el
proveedor lo debe registrar.
2. Descubrir: El solicitante interactúa con el registro para encontrar el servicio que
busca.
3. Enlazar: Finalmente el servicio ha de ser invocado. En la operación de enlace, el
solicitante invoca al servicio en tiempo de ejecución utilizando la meta información
que proporciona el registro.
Figura 6. Estructura de Interacción.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 22
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
66 .. LL EE NN GG UU AA JJ EE SS DD EE PP RR OO GG RR AA MM AA CC IIÓÓ NN ..
6.1 C#.
Con .NET Framework, Microsoft presenta un nuevo lenguaje llamado C#. Microsoft ha
creado y diseñado C # expresamente para el desarrollo de .NET, C# puede considerarse
como una simplificación de C++. Sus raíces sintácticas provienen de C sin embargo, se
han eliminado o simplificado muchos aspectos misteriosos, confusos y peligrosos, de C++.
Los programadores de C++ y Java no deberían tener dificultades para leer el código C#. Sin
embargo, a continuación se citan algunas de las diferencias más importantes entre la
sintaxis de C# y C++:
Sintaxis de acceso a los miembros simplificada. C++ utiliza el operador "->" para referirse
a los miembros de la clase o de la estructura cuando un objeto está asignado a la memoria
de bloque y "." para referirse a los miembros de la clase o estructura cuando el objeto está
asignado a la memoria de pila. C# siempre utiliza la sintaxis "." para referirse a los
miembros de la clase como datos y métodos. Por ejemplo:
myObj.SomeMethod( );
llama a el método SomeMethod( ) de la clase aportada por myObj.
Atributos del parámetro.
Los parámetros se pueden ser atribuir con las palabras clave ref. y out. Por defecto, si un
parámetro no tiene el atributo ref u out, se transfiere por valor. Al crear un parámetro con
ref, se transfiere por referencia. Al crear un parámetro con out, también se transfiere por
referencia, sin embargo se asume que se definirá cuando el método sea invocado. Por
ejemplo, en el método siguiente el atributo out se utiliza para indicar que el
strNewPhoneNumber se transfiere por la referencia y se asume que no es válido en la
invocación del método:
public bool CheckForSplit(string strPhoneNum, out string strNewPhoneNun);
Tipos del sistema de tipos comunes.
C# utiliza tipos compartidos que se implementan en el sistema de tipos comunes. Muchos
de estos tipos se han estructurado según palabras clave de C++ que resultan familiares. Por
ejemplo, el tipo System.Int32 del sistema de tipos comunes se corresponde con la palabra
clave de C# int y se utiliza como el tipo int de C++. Las matrices y las cadenas son
excepciones a este tipo de estructuración que tienen una sintaxis diferente a la que los
programadores de C++ están acostumbrados. Para leer el código del ejemplo, será
suficiente saber que string es un tipo de construcción interna y que las matrices deben
declararse con paréntesis detrás del tipo. Tras la declaración, la matriz se asigna y
dimensiona utilizando la palabra clave new. Por ejemplo:
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 23
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
int[ ] myArray;
myArray = new int [3] ;
Todo es un objeto.
C# permite tratarlo todo, incluidos los tipos nativos, como objetos. Hay incluso algunos
métodos que se pueden llamar en todos los tipos. ToString( ) es uno de ellos. Lo cual quiere
decir que se puede hacer lo siguiente:
int myInt = 7;
string myString = myInt.ToString ( );
6.2 Visual Studio .NET 2003.
Visual Studio.NET 2003, esta constituido por cuatro lenguajes de programación:
1. Visual Basic .NET 2003.
2. Visual C# .NET 2003.
3. Visual C++ .NET 2003.
4. Visual J# .NET 2003.
Visual Studio .NET 2003, es la herramienta de Microsoft para crear e implementar software
para la plataforma Microsoft .NET. Incluye una gama de funciones, desde modeladores
que ayudan a componer visualmente las aplicaciones empresariales hasta la
implementación de una aplicación en el más pequeño de los dispositivos. Utilizados por
compañías de todos los tamaños en el mundo entero, Visual Studio .NET y la plataforma
.NET Framework de Microsoft Windows proporcionan una herramienta, para diseñar,
desarrollar, depurar e implementar aplicaciones para Microsoft Windows® y Web.
Los programadores pueden utilizar Visual Studio .NET para:
♣ Crear aplicaciones basadas en Windows
♣ Crear aplicaciones para Pocket PC
♣ Crear aplicaciones Web
♣ Crear aplicaciones Web para dispositivos móviles.
♣ Utilizar web services XML en cualquiera de las aplicaciones mencionadas.
♣ Evitar conflictos entre archivos .DLL.
Visual Studio .NET es un entorno de desarrollo creado exclusivamente para permitir la
integración con web services. Al hacer posible que las aplicaciones compartan datos a
través de Internet, los web services permiten a los programadores ensamblar aplicaciones a
partir de código nuevo y existente, independientemente de la plataforma, el lenguaje de
programación o el modelo de objetos.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 24
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Visual Studio .NET 2003 está disponible en las siguientes ediciones:
EENNTTEERRPPRRIISSEE AARRCCHHIITTEECCTT EENNTTEERRPPRRIISSEE DDEEVVEELLOOPPEERR PPRROOFFEESSSSIIOONNAALL
Visual Studio .NET
Enterprise Architect
Proporciona la capacidad
total de Visual Studio .NET
Enterprise Developer, más
funciones adicionales para
diseñar, especificar y
comunicar arquitectura y
funcionalidad de
aplicaciones.
Visual Studio .NET
Enterprise Developer
Proporciona un entorno de
desarrollo empresarial en
equipo para crear con
aplicaciones importantes
orientadas a cualquier
dispositivo y que se integren
en cualquier plataforma.
Visual Studio .NET
Professional.
Permite a los
programadores crear
aplicaciones para
Windows, Web,
dispositivos Web móviles,
Pocket PC y otros
dispositivos incrustados
que utilizan .NET
Compact Framework.
Visual Studio .NET 2003 permite la creación y el uso de web services para crear e integrar
aplicaciones empresariales en cualquier plataforma o dispositivo. Además incluye versiones
para programadores de Windows Server 2003, SQL Server, Microsoft Exchange Server,
Microsoft Commerce Server y Microsoft Host Integration Server, facilitando la creación y
prueba de aplicaciones antes de implementarlas.
WSDK es un componente, que se incluye con Visual Studio .NET 2003, este permite a los
programadores crear aplicaciones utilizando web services, proporcionando compatibilidad
con varios aspectos principales de web services, entre ellos:
♣ Seguridad basada en mensajes (WS-Security).
♣ Enrutamiento e independencia de la topología de red (WS-Routing).
♣ Archivos adjuntos en mensajes SOAP (WS-Attatchments).
Visual C++ .NET 2003 ofrece la máxima capacidad, rendimiento, control y flexibilidad
para crear aplicaciones que aprovechen Windows directamente. La nueva compatibilidad
con el diseñador de formularios Windows Forms ofrece a los programadores de C++ una
productividad sin precedentes al crear completas aplicaciones basadas en Windows. Con la
programación basada en atributos y el servidor ATL, una extensión de las bibliotecas ATL,
puede utilizar la sintaxis de C++ para crear aplicaciones Web ISAPI. Además, los
programadores de C++ pueden orientar sus aplicaciones a Windows .NET Framework
utilizando las Extensiones administradas para Visual C++.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 25
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
En Visual Studio .NET 2003, los programadores que utilicen Visual C++ notarán también
que la métrica principal para medir la portabilidad del código, compatibilidad con
ANSI/ISO, se ha mejorado notablemente. El estándar ANSI/ISO C++ es el estándar
generalmente aceptado para el lenguaje C++ y todos los proveedores de compiladores de
C++ miden la compatibilidad con este estándar.
Visual C# .NET 2003 proporciona un lenguaje moderno e innovador, ideal para construir
componentes orientados a objetos y marcos de trabajo empresariales. Basado en el estándar
ECMA C#, Visual C# .NET ofrece mayor productividad a los programadores de C y C++.
Gracias a la compatibilidad de primera clase con componentes que incluyen propiedades,
métodos, indicadores, atributos, control de versiones y eventos, Visual C# .NET 2003
proporciona una base sólida para crear aplicaciones .NET.
Visual J# .NET 2003 es una herramienta de desarrollo para aquellos programadores de Java
que deseen crear aplicaciones y servicios en Windows .NET Framework. Visual J# .NET
2003 se suma a más de 20 lenguajes anunciados anteriormente con su capacidad de orientar
aplicaciones a Windows .NET Framework y servicios Web XML de primera clase.
Visual Basic .NET 2003.
Es ideal para programadores de Visual Basic 6.0, por usar sintaxis bastante similar, así
como para programadores nuevos en el entorno de desarrollo de Microsoft .NET, Visual
Basic .NET 2003 brinda diseñadores visuales, y un entorno de desarrollo integrado (IDE).
Permite a los programadores utilizar web services que se ejecuten en cualquier plataforma y
crearlos al igual que cualquier clase en Visual Basic 6.0.
Posee interoperabilidad COM integrada a Windows .NET Framework, los programadores
pueden seguir utilizando la mayor parte de los componentes que han usado durante años.
La interoperabilidad COM proporciona comunicación bidireccional entre las aplicaciones
escritas con Visual Basic 6.0 y las escritas con Visual Basic .NET, sin necesidad de escribir
de nuevo el código. Visual Basic 6.0 y Visual Basic .NET pueden residir sin problemas en
el mismo equipo, lo que facilita la transición.
Visual C#.NET 2003.
Es una herramienta y un lenguaje de programación que permite generar software conectado
a .NET para Microsoft Windows®, Web y una amplia gama de servicios. Usa sintaxis
similar a la de C++, y un entorno de desarrollo integrado (IDE) capaz de crear soluciones
informáticas para una varias plataformas y dispositivos.
Visual C#.NET está basado en C++ y resulta muy familiar a los programadores que han
trabajado con C++ y Java. Es un lenguaje de programación intuitivo orientado a objetos que
ofrece un sistema de tipos unificados, código "no seguro" que permite un control al
programador y construcciones de lenguaje fáciles de entender para la mayoría de los
programadores. Usa comentarios en formato XML, los programadores de C# pueden
elaborar documentación sobre el código fuente.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 26
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Posee un modelo de herencia que permite a los programadores volver a utilizar el código de
cualquier lenguaje de programación compatible con .NET.
Visual C#.NET 2003, permite crear web services que integren procesos empresariales y los
pongan a disposición de aplicaciones que se ejecuten en cualquier plataforma. Se puede
incorporar fácilmente cualquier número de web services, que estén catalogados y
disponibles en cualquier directorio UDDI (integración, descubrimiento y descripción
universal) independiente.
Visual C++ .NET 2003
Microsoft Visual C++ .NET 2003 permite crear aplicaciones basadas en Microsoft
Windows® y conectadas a Microsoft .NET, aplicaciones Web dinámicas y web services
mediante el lenguaje de programación C++.
Este entorno de desarrollo incluye compiladores con compatibilidad a las normas ISO,
implementación de bibliotecas STL (Standard Template Library), biblioteca ATL (Active
Template Library) estándar, bibliotecas MFC (Microsoft Foundation Class) y un entorno de
desarrollo integrado que permite editar y depurar el código fuente.
Algunas de las funciones de Visual C++ .NET 2003:
♣ Capacidad de utilizar y ampliar Microsoft Windows .NET Framework.
♣ Diseñadores visuales para crear Formularios Windows y componentes.
♣ Depurador y varios compiladores de la industria que ofrecen opciones para la
generación de código en plataformas de 32 y 64 bits.
Se puede incorporar funciones de Windows .NET Framework, incluida la recolección de
elementos no utilizados, los atributos y los subprocesos, en aplicaciones de C++. Visual
C++ ofrece una función exclusiva que le permite llamar a código de C++ y componentes de
ActiveX® utilizando la tecnología de interoperabilidad en .NET.
El compilador de Visual C++ .NET 2003 es compatible con la definición del lenguaje C++
de ISO y permite crear fuentes de bibliotecas y código de C++. Entre las nuevas
características, destacan varias funciones de plantillas definidas por la norma ISO, tales
como Partial Template Specialization (Especialización parcial de plantillas) y Partial
Ordering of Function (Ordenamiento parcial de funciones). Estas funciones permiten
escribir menos código y reciclable. Las bibliotecas de C++, incluidas Loki, Boost y Blitz,
son compilables con Visual C++ .NET 2003, proporcionando a los programadores de
Visual C++ la capacidad de incorporar estas fuentes a sus aplicaciones.
Visual C++ posibilita incorporar las funciones nuevas a las aplicaciones mediante
bibliotecas. Visual C++ ofrece una variedad de bibliotecas, como por ejemplo:
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 27
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
- Implementación STL totalmente compatible con las normas ISO (que proporciona
algoritmos y clases de contenedores genéricos).
- ATL y MFC (ahora actualizadas para Windows XP y Windows Server 2003).
- Servidor ATL (que permite web services y contenido Web dinámico no
administrado).
- La plataforma Windows .NET Framework está completamente habilitada para los
programadores de Visual C++, que pueden utilizar y expandir con esta biblioteca a
partir de fuentes de C++.
Visual J# .NET 2003.
Es una herramienta para programadores que usen lenguaje Java y que desean crear
aplicaciones y web services en Microsoft Windows .NET Framework. Está dirigido a la
versión 1.1 de Windows .NET Framework, está integrado con Visual Studio .NET 2003 y
proporciona compatibilidad adicional para generar aplicaciones Web para dispositivos
móviles.
Algunos aspectos que Visual J# .NET 2003 proporciona a los programadores de Java:
Una forma fácil de aprovechar las ventajas de Windows .NET Framework, como por
ejemplo, la compatibilidad nativa con los web services.
a) Capacidad de crear una variedad de aplicaciones utilizando un modelo de
programación unificado. Visual J# .NET 2003 permite generar aplicaciones basadas
en Microsoft Windows®, aplicaciones Web e incluso aplicaciones Web para
dispositivos móviles que se pueden implementar de forma dinámica en más de 200
tipos de dispositivos móviles.
b) Oportunidad para los clientes de Microsoft Visual J++® y otros programadores de
Java de aprovechar la inversión actual en conocimientos y código, así como el uso
completo del entorno de desarrollo de Microsoft tanto ahora como en el futuro.
Visual J# .NET 2003 incluye tecnología que permite a los usuarios migrar sus aplicaciones
Java a Windows .NET Framework. Las aplicaciones existentes creadas mediante Visual
J++ pueden modificarse fácilmente para ejecutarse en Windows .NET Framework,
interactuar con otros lenguajes y aplicaciones conectados a Microsoft .NET e incorporar
funcionalidad .NET, como por ejemplo, ASP.NET, ADO.NET y Formularios Windows.
También es posible utilizar Visual J# .NET 2003 para generar aplicaciones conectadas a
.NET totalmente nuevas.
Visual J# .NET 2003 incluye herramientas para actualizar automáticamente y convertir los
proyectos y soluciones existentes de Visual J++ 6.0 al formato de Visual Studio .NET
2003. Estas herramientas garantizan a los programadores actuales de Visual J++ 6.0 una
transición sencilla a Visual J# .NET 2003 y la creación de aplicaciones y componentes
conectados a .NET.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 28
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Visual J# .NET 2003 no es una herramienta diseñada para crear aplicaciones que se puedan
ejecutar en una máquina Java virtual. Las aplicaciones y servicios generados con Visual J#
.NET 2003 sólo se podrán ejecutar en Windows .NET Framework y no en una máquina
Java virtual. Microsoft ha diseñado y creado Visual J# .NET 2003 de forma independiente.
Esta herramienta no ha sido certificada ni aprobada por Sun Microsystems, Inc.
6.3 Sun ONE Studio 5, Standard Edition
Sun ONE Studio 5, Standard Edition es la siguiente versión de la familia de productos Sun
ONE Studio for Java. Ha sido creado como el entorno de desarrollo de la pila de productos
Sun ONE, específicamente para Sun ONE Application Server y los desarrolladores
encargados de la creación de aplicaciones y web services en n-niveles. Contiene un entorno
de desarrollo integrado (IDE) potente e intuitivo para Java, proporciona un conjunto de
funciones y características que permiten el desarrollo de software desde aplicaciones de
escritorio hasta aplicaciones empresariales basadas en estándares y web services.
Características:
♣ Preconfigurado con Sun ONE Application Server 7; menores ciclos iterativos de
desarrollo gracias a herramientas integradas, Respuesta y rendimiento mejorados
significativamente.
♣ Centrado en Java 2 Platform, Enterprise JavaBean 2.0 Workshop; rápido desarrollo
de J2EE 1.3 Enterprise Applications.
♣ Desarrollo, prueba y publicación de web services.
♣ Acceso a bases de datos con desarrollo de JDBC simplificado.
♣ Compatibilidad con XML; creación y depuración de documentos XML, XML
Schema y DTD utilizando las herramientas integradas.
♣ Interoperabilidad para el Desarrollo Orientado de Objetos JNDI/CORBA/RMI
(provee módulos opcionales, actualizables desde el centro de Actualizaciones de la
compañía).
♣ Configuración de compatibilidad sin fisuras con web services ampliados para el Sun
ONE Application Server 7.
♣ Servidor web de registro UDDI.
♣ Compatibilidad completa con JAX-RPC, incluidos: encabezados, archivos adjuntos,
sesiones de filtro dinámico de paquetes y seguridad.
♣ Integración inalámbrica mejorada para dispositivos con SOAP activado.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 29
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
♣ Módulo de interfaz de compatibilidad integrado para permitir la resolución y
notificación de problemas eficaz.
♣ Nuevas funciones y características de Netbeans 3.4 1
♣ Cómodo acceso a la información del servicio técnico gracias al nuevo módulo Bug
Submitter
Sun ONE Web Services Platform Developer Edition.
Sun™ ONE Web Services Platform Developer Edition proporciona un entorno de prueba y
desarrollo de web services integrados para crear pruebas de concepto que se integren en
varios sistemas de información. El producto proporciona herramientas integradas y
servidores de software intermedio y aprovecha los estándares más recientes de Java, XML
y web services. Las herramientas de Sun ONE Web Services Platform Developer Edition se
han creado sobre la plataforma NetBeans para maximizar la productividad de los
desarrolladores. La salida de estas herramientas se puede desplegar en diferentes servidores
Sun ONE que permiten que los negocios simulen fácilmente un entorno de producción para
una comercialización rápida.
Características:
♣ Integrated Installer permite una instalación optimizada para los desarrolladores de
toda la plataforma de web services.
♣ Desarrolla, ensambla y despliega aplicaciones de web services basados en
componentes y estándares Java 2 Platform, Enterprise Edition (J2EE™) para Sun
ONE Application Server y otras plataformas líderes en el mercado. Compatible con
el desarrollo para la especificación J2EE 1.3-
♣ Sun ONE Application Framework (JATO) facilita el proceso de desarrollo de
aplicaciones Web, que son seguras, escalables y mantenibles. Se trata de una
infraestructura de aplicaciones Web Java™ 2 Platform, Enterprise Edition (J2EE™)
dirigido al desarrollo de aplicaciones Web de empresa.
♣ Sun ONE Connector Builder; permite integrar los sistemas de información de
empresa existentes, en una infraestructura de web services, resulta más fácil
realizar la migración de las organizaciones de TI a una arquitectura basada en
servicios-
♣ Sun ONE Portlet Builder permite el desarrollo de portales de empresa
personalizados-
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 30
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
♣ Sun ONE Portal Server proporciona una solución de portal activado para
identidades para gestionar y administrar usuarios, normas y servicios de
abastecimiento, además de proporcionar un inicio de sesión único, administración
delegada y web services-
♣ Sun ONE Integration Server EAI Edition proporciona integración de Sun ONE para
web services a través de mensajería SOAP, que puede exportar una definición de
servicio por WSDL a UDDI u otros clientes SOAP-
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 31
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
77 .. EE SS TT ÁÁ NN DD AA RR EE SS YY TTEE CC NN OO LLOO GG ÍÍAA SS AA SS OO CC IIAA DD AA SS ..
Figura 7. Estándares y Tecnologías asociadas a Web Services.
Los web services, se basan en los siguientes estándares de Internet:
1. SOAP
2. WSDL
3. UDDI
4. XML
7.1 SOAP (Simple Object access Protocol).
Es el protocolo de comunicaciones que usan los web services. Define los mecanismos por
los cuales un web service, es invocado y cómo devuelve los datos. Los clientes SOAP
llaman a los servidores SOAP, pasando objetos en formato XML. SOAP es un estándar
definido por W3C y creado a partir de un grupo de trabajo integrado por varias
asociaciones. Se encarga de indicar como deben ser los mensajes que circulan entre las
distintas aplicaciones, se construyo para facilitar la llamada a funciones remotas.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 32
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Figura 8. Modelo Soap
SOAP como protocolo de mensajería entre ordenadores.
SOAP es un protocolo de cable sencillo basado en XML, se diseño para conexión entre
ordenadores independientes de subsistemas operativos, lenguajes de programación o
modelos de objetos utilizados (e incluso con la carencia total del modelo de objeto). A
pesar de que su nombre pueda parecer que requiere del uso de determinados objetos, SOAP
especifica el formato del mensaje que accede e invoca a los objetos, en vez de especificar
los objetos en si.
SOAP es extensible para la comunicación de ordenador, que emplea por igual los
estándares actuales de Internet: XML para el formato de mensajes, http y otros protocolos
de Internet para el transporte de mensajes.
SOAP especifica el formato del mensaje de la comunicación entre ordenadores. Los
Mensajes de SOAP son básicamente transmisiones de dirección única emisor-receptor.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 33
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Sobre de SOAP
Encabezamiento de
SOAP
Cuerpo de SOAP
Figura 9. Estructura de SOAP.
En mayo del año 2000, el W3C (World Wide Web Consortium http://www.w3c.org/)
reconoció la propuesta de SOAP presentada de forma conjunta por un conglomerado de
empresas (Ari a Inc., CommerceOne Inc., Compaq Computer Corp., Micro$oft Corp.,
Development Corp., IBM Corp, Hewlett-Packard Co., etc). Siendo desarrollado en base a
un estándar abierto.
Ventajas de SOAP:
♣ Fácil de implementar y usar.
♣ Utiliza los mismos estándares de la web: HTTP para la
♣ comunicación, protocolos de autenticación y
♣ encriptación.
♣ Atraviesa “firewalls” y routers ya que piensan que es
♣ una comunicación HTTP.
♣ Tanto los datos como las funciones se describen en
♣ XML.
♣ No depende del sistema operativo y procesador
♣ Describe un estándar WSDL que define los objetos y métodos disponibles a través
de
♣ páginas XML disponibles en la web.
♣ Se puede implementar en casi cualquier lenguaje de programación.
♣ Dos formatos de mensajes:
♣ Un mensaje que se envía desde la aplicación cliente a la aplicación servidor. Y un
mensaje que se envía desde la aplicación servidor a la aplicación cliente.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 34
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
♣ SOAP provee un mecanismo independiente del protocolo, que se use para la
comunicación, para asociar el encabezado al cuerpo del mensaje: a esto se le
conoce como “envelope”.
♣ SOAP no impone ninguna restricción acerca de cómo debe formatearse el cuerpo
del mensaje.
Funcionamiento de SOAP.
En principio una petición/respuesta de SOAP puede usar cualquier protocolo de transporte
(HTTP, SMTP, etc.). Las cabeceras difieren de protocolo a protocolo, pero el contenido de
SOAP es el mismo. La petición de SOAP en XML consiste de tres partes:
1. Envelope - El sobre de SOAP define un marco de referencia general para expresar
que es lo que contiene el mensaje, quién debe recibirlo, y si es opcional u
obligatorio.
2. Codificación - Las reglas de codificación de SOAP definen un mecanismo de
estandarización que puede ser utilizado para intercambiar instancias de tipos de
datos definidos por la aplicación.
3. Estándar - La representación RPC de SOAP define una convención que puede ser
utilizada para representar los llamados y respuestas de procedimientos remotos.
Un mensaje SOAP/HTTP es aceptado típicamente por un Java servlet que se ejecuta en el
servidor web Apache (Tomcat). En su momento el servlet revisa si hay alguna petición de
SOAP y la transfiere al motor SOAP de Apache. El motor analiza el contenido de texto de
XML y utiliza la dirección destino del servicio Web para buscar e invocar el servicio y
brindar el resultado.
La respuesta SOAP/HTTP se devuelve como un documento XML dentro de una respuesta
HTTP. El documento XML está estructurado como cualquier respuesta HTTP excepto que
el Cuerpo contiene incrustado el resultado del método ejecutado.
Dado que SOAP utiliza XML para codificar mensajes, es relativamente sencillo procesar
los mensajes en cada paso del proceso. Además, la facilidad de depuración de mensajes
SOAP permite la convergencia rápida de las diversas implementaciones de SOAP, la cual
es importante en la interoperabilidad a gran escala.
Internet fue diseñada para que múltiples sistemas se pudiesen comunicarse entre si. Lo ideal
es que una aplicación pueda usar componentes de otras aplicaciones, e incluso
desarrollados en otros lenguajes. Eso se consigue actualmente mediante CORBA y DCOM.
No obstante un desarrollo con estos estándares no es fácil de lograr y, sobre todo, la
comunicación entre módulos situados remotamente no suele funcionar. El más típico es que
haya un cortafuego por el medio. Entonces el tráfico de este tipo no puede pasar. Como
SOAP trabaja sobre HTTP, este problema se minimiza: HTTP es un protocolo opera muy
bien con los "cortafuegos".
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 35
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Para asegurarse que la comunicación SOAP sea segura se debe utilizar el protocolo HTTPS
en lugar de HTTP, de ésta manera SSL nos brinda su protección. Se puede resumir que
SOAP es un protocolo ligero, simple y extensible. Se usa para comunicación entre
aplicaciones dentro y fuera de la misma red. SOAP está diseñado para comunicarse vía
HTTP, es decir a través del puerto 80 lo que facilita su tránsito. El estándar no está ligado a
ninguna tecnología de componentes propietarios ni lenguaje de programación específico. El
formato está basado en XML y coordinado por W3C. La mayoría de las plataformas ya
disponen de implementaciones de SOAP.
Mensajes SOAP.
Un mensaje SOAP es un documento XML que consta de los siguientes elementos:
♣ Envelope (sobre) que define el contenido del mensaje.
♣ Header (cabecera) que es opcional y que contiene meta información referente al
mensaje.
♣ Body (cuerpo) que contiene la información de la llamada y de la respuesta.
Ejemplo de mensaje SOAP petición:
84-4553-3334-2X
Ejemplo de mensaje SOAP respuesta:
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 36
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
Catalogar materiales especiales
Marta de Juanes
7.2 WSDL (Web Service Definition Language).
Describe la interfaz externa de un web service y cómo utilizarlo. Se puede definir un
archivo WSDL como un documento XML que describe un conjunto de mensajes SOAP y
la forma en que éstos interactúan.
Puesto que la notación que utiliza WSDL es XML significa que es un idioma de
programación neutral, basado en estándares (W3C) y que puede utilizarse desde una gran
variedad de plataformas y lenguajes.
Además de describir el contenido WSDL define todos los elementos necesarios para utilizar
el servicio (interfaz, lugar en el que está disponible, protocolo de comunicaciones...), El
Lenguaje de Descripción de web services (WSDL) es el equivalente de un resumen en
XML, describiendo los web services, donde se ubican, y cómo se pueden invocar.
Especificación XML para la formación del documento de descripción de un web service.
Identifica los métodos, funciones y parámetros necesarios para invocar un determinado
servicio. Así, un usuario puede crear una aplicación cliente que comunica con el web
service.
Para que un cliente se pueda enlazar o comunicar con un web servicie es necesario algo
más que la definición formal del interfaz. Se deben especificar toda una serie de
metainformaciones del servicio: dirección de red, los protocolos, los requisitos de
seguridad, etc. WDSL (Web Services Definition Language) cumple con estas necesidades.
Al igual que para cualquier componente de un modelo de computación distribuida ,se
necesita un lenguaje de definición del interfaz (IDL). WSDL establece todos los
requerimientos necesarios. WSDL proporciona solo descripciones funcionales del servicio
(detalles de enlace, prototipo, protocolo).
WDSL describe lo siguiente:
♣ Información de interfaz que describe todas las funciones públicamente accesibles.
♣ Información de los tipos de datos para todos los mensajes de petición y respuesta.
♣ Información acerca del protocolo de transporte a utilizar.
♣ Información para localizar un servicio específico Representa un contrato entre el
peticionario del servicio y el servicio proveedor.
♣ El cliente puede localizar un servicio web y llamar a alguna de sus funciones.
Universidad Don Bosco
“Estado del Arte de la Tecnología de Web Services” 37
Fa
cu
lta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
F
ac
ul
ta
d
de
In
ge
ni
er
ía
El lenguaje de descripción de web services WSDL es un lenguaje XML que contiene
información acerca de la interfaz, semántica, y administración de una llamada a un web
service.
Una vez se encuentre desarrollado el web service, se publica su descripción y se construye
un enlazamiento o puntero en un depósito UDDI (Universal Description, Discovery and
Integration) para que los usuarios potenciales lo puedan utilizar.
Cuando alguien piensa en utilizar este web service, solicitan el archivo WSDL para conocer
la ubicación del servicio, llamado de funciones, y cómo acceder al web service. Luego
utilizan la información en el archivo WSDL para construir una petición SOAP (Simple
Object Access Protocol) y enviarla hacia el proveedor de servicio.
Una de las ideas principales detrás de los web services, es que las aplicaciones futuras
estarán conformadas de una colección de servicios habilitados en la red. Mientras haya dos
servicios equivalentes que se anuncien a la red de una forma estandarizada, en teoría un
cliente podría seleccionar uno de ellos en base a criterios establecidos de antemano como
precio o rendimiento.
Los documentos WSDL consisten de siguientes elementos:
Definitions - El elemento contiene la definición de uno o más servicios. En la
mayoría de los casos, un archivo WSDL define un servicio únicamente. Seguido de la
etiqueta de definición se encontrarán declaraciones de algunos atributos. Dentro de la
etiqueta las siguientes secciones conceptuales:
♣ y , describe qué operaciones provee el servicio.
♣ , describe cómo se invocan las operaciones.
♣ , describe dónde se ubica el servicio.
♣ , cualquier elemento WSDL puede incluir información del servicio
para el usuario.
Resumiendo, WSDL es equivalente a la URL en los servicios XML-RPC. Es la dirección
de Internet donde hay que invocar el método o el proceso.
El WSDL es un borrador (no está completamente aprobado por el W3C), aunque ya se usa
en fase de explotación de forma extensiva.
El WSDL aunque actualmente no está completamente aprob