150

SUBSECRETARÍA DE EDUCACIÓN SUPERIOR

DIRECCIÓN GENERAL DE EDUCACIÓN SUPERIOR INSTITUTO TECNOLÓGICO
TECNOLÓGICA DE OAXACA

DE OAXACA

INSTITUTO TECNOLÓGICO DE OAXACA

ING. EN SISTEMAS COMPUTACIONALES

Desarrollo de Software Orientado a Servicios.

TEMA:
Investigación 1.

HORA:
07:00-08:00/I13.
CATEDRÁTICO:
Iván Adán Cruz Jiménez.

Alumno:
Hernández Ortiz Luis Daniel.

1
Tabla de contenido
Programación asíncrona...................................................................................................................... 4
Modelos de programación asíncrona. ............................................................................................ 4
Modelo de paso de continuadores ............................................................................................. 4
Modelo de eventos ..................................................................................................................... 4
Modelo de promesas .................................................................................................................. 4
Modelo de generadores .............................................................................................................. 5
Node JS y su ejecución asíncrona .................................................................................................... 5
La asincronía de Node JS ............................................................................................................. 5
Principios Arquitectónicos de Node JS ........................................................................................ 5
Modelo de paso de continuadores (o callbacks) ............................................................................ 5
Qué es una continuación............................................................................................................. 5
Control de flujo mediante continuadores ................................................................................... 6
Librerías para continuadores ...................................................................................................... 7
Conclusiones sobre continuadores ............................................................................................. 8
Modelo de eventos ......................................................................................................................... 8
Qué es una arquitectura dirigida por eventos ............................................................................ 8
¿Qué es una API?............................................................................................................................... 10
Innovaciones con las API ........................................................................................................... 11
Breve historia de las API ............................................................................................................ 12
Las API remotas ......................................................................................................................... 12
¿Qué se ha hecho para mejorar las API? ...................................................................................... 13
Un poco de SOAP, mucho de REST ............................................................................................ 13
SOA frente a la arquitectura de microservicios ........................................................................ 14
¿Qué es un servicio web? .................................................................................................................. 15
¿Qué es SOAP? .............................................................................................................................. 15
SOAP 1.1 ........................................................................................................................................ 15
SOAP 1.2 ........................................................................................................................................ 16
JAX-WS. ......................................................................................................................................... 17
JAXB. .............................................................................................................................................. 18
JAX-RPC. ........................................................................................................................................ 19
Laravel. .............................................................................................................................................. 23
Algunas de las características:....................................................................................................... 23

2
Características Generales .............................................................................................................. 24
¿Por qué elegir Laravel? ................................................................................................................ 24
¿Cuándo utilizar Laravel? (tres puntos a destacar) ....................................................................... 24

3
Programación asíncrona.
Los lenguajes de programación asíncronos se basan en llamadas que pueden ser cumplidas ahora o
en un futuro. Es decir, las variables pueden ser llenadas o asignadas en cualquier momento de la
ejecución del programa. Una orden solo se puede ejecutar luego que se ejecuta la anterior. Esto es
muy beneficioso para el programador, debido a que no tiene que preocuparse de cuando los datos
estarán listos. El problema de estos tipos de lenguajes es que los procesos ocupan más memoria, y
son menos eficientes.

Cada instrucción se ejecutará en secuencia hasta terminar.

console.log('Primero');
console.log('Segundo');
console.log('Tercero');

Lo bueno: Programación Asíncrona La programación asíncrona resulta ventajosa ya que aumenta

el throughput soportado. Esta ventaja le está haciendo coger mucha tracción dada la demanda de
sistemas de alta escalabilidad que se requieren en Internet.

Lo malo: El principal problema de la programación asíncrona se refiere a cómo dar continuidad a

las operaciones no bloqueantes del algoritmo una vez que éstas han terminado su ejecución.

Modelos de programación asíncrona.

Modelo de paso de continuadores

Es el modelo de asincronía más utilizado dentro Node JS. Cada función recibe información acerca
de cómo debe tratar el resultado –de éxito o error– de cada operación. Requiere orden superior.

Modelo de eventos

Se utiliza una arquitectura dirigida por eventos que permite a las operaciones no bloqueantes
informar de su terminación mediante señales de éxito o fracaso. Requiere correlación para
sincronizar.

Modelo de promesas

Se razona con los valores de retorno de las operaciones no bloqueantes de manera independiente del
momento del tiempo en que dichos valores –de éxito o fallo– se obtengan.

4
Modelo de generadores

Se utilizan generadores para devolver temporalmente el control al programa llamante y retornar en

un momento posterior a la rutina restaurando el estado en el punto que se abandonó su ejecución.

Node JS y su ejecución asíncrona

La asincronía de Node JS

• Modelo no bloqueante de E/S: Node JS es un lenguaje single-thread pero que aplica

multi-threading en los procesos de entrada salida y es ahí donde se aplica el carácter no
bloqueante.

• Arquitectura dirigida por eventos: Node JS utiliza alternativamente, como veremos,

el modelo de paso de continuadores y el de eventos si bien su arquitectura general está
dirigida por un loop general de eventos.

Principios Arquitectónicos de Node JS

• La E/S es lo que más coste implica: Esta experimentalmente comprobado que

procesamiento de las operaciones de E/S es el que mayor coste implica dentro de las
arquitecturas Hw.

• Dedicar un hilo por solicitud es caro: Dedicar un hilo para enhebrar el procesamiento
de cada solicitud entrante, como hacen otras arquitecturas servidoras (Apache) resulta
demasiado caro en memoria.

• Todo en paralelo menos tu código: Como consecuencia el esquema de

comportamiento de Node JS se puede resumir en aquellas partes del proceso de la petición
que merezca la pena paralelizar (E/S) se ejecutarán de forma no bloqueante mientras que el
resto ejecuta en un esquema single-thread.

Modelo de paso de continuadores (o callbacks)

Qué es una continuación

El modelo nativo que utiliza Node JS en sus APIs para dar soporte a la programación asíncrona es
el de paso de continuadores. Cada operación no bloqueante recibe una función como último
parámetro que incluye la lógica de continuación que debe ser invocada tras la finalización de la
misma tanto para procesar los resultados en caso de éxito como para tratar los fallos en caso de
error.

La función de continuación permite indicar a la operación bloqueante como debe proceder después
de finalizada la operación,

5
Control de flujo mediante continuadores
Secuenciamiento

La manera de proceder dentro de este modelo para establecer flujos de ejecución secuenciales exige
ir encadenando cada función subsiguiente como continuación de la anterior donde se procesarán los
resultados tanto en caso de éxito como de fracaso. Esto conduce a una diagonalización del código
que se ha dado en llamar pirámide del infierno (callback hell), por su falta de manejabilidad práctica
en cuanto crece mínimamente el número de encadenamientos secuenciales.

Paralelización

La paralelización –ejecución asíncrona– de las operaciones no bloqueantes es inmediata ya que su

mera invocación ejecuta en segundo plano por definición. Para convertir en no bloqueantes las
operaciones bloqueantes, se requiere un pequeño proceso de encapsulación funcional que lance la
operación en segundo plano.

6
Sincronización

La sincronización de funciones de continuación requiere encadenar al final de cada

secuencia paralela una función de terminación que aplique cierta lógica sólo una vez que se
compruebe que todas las ramas paralelas han terminado. Para implementar esta
comprobación se utilizan esquemas basados en contadores.

Librerías para continuadores

• Async: es tal vez la librería más conocida y ampliamente utilizada para la programación
asíncrona basada en continuadores. Ofrece métodos de control de flujo variados para
funciones no bloqueantes.

• Join: es una implementación del método de sincronización que hemos comentado

anteriormente y resulta similar al que puede encontrarse en otros lenguajes como C que
opera con threads. También puede usarse en promesas, aunque su uso resulta menos
relevante.

7
 • Fn.js: es una excelente librería que implementa distintos métodos de gestión funcional. Su
aplicabilidad práctica en este contexto está relacionada con las capacidades que expone para
generar funciones no bloqueantes y aplicar currificación.

Conclusiones sobre continuadores

Lo bueno: La programación asíncrona basada en continuadores puede ser una buena opción para
situaciones en que la lógica de control de flujo es muy sencilla. Tal suele ser el caso de programas
en Node JS que permiten definir una respuesta no bloqueante a peticiones entrantes.

• Sencillo para esquemas solicitud / respuesta

• Alineado con los esquemas de programación funcional
• Fácil de entender como mecanismo conceptual

Lo malo: No obstante, cuando la lógica de control resulta mínimamente elaborada el proceso de

razonamiento sobre el programa se complica lo cual redunda en un código con lógica funcional
distribuida y difícil de leer, entender y mantener.

• Complejidad en la definición de una lógica de control de flujo elaborada

• Difícil establecer mecanismos de sincronización
• La lógica de control queda distribuida entre cada rama no bloqueante
• Difícil de seguir, leer y mantener a medida que crece el código

Modelo de eventos
Qué es una arquitectura dirigida por eventos

Un evento es la señalización de un acontecimiento relevante dentro del ecosistema de negocio.

Anatómicamente están formados, típicamente, por un tipo, una marca de tiempo y un conjunto de
datos que caracteriza el contexto en el que se produjo el evento. Las arquitecturas de eventos (EDA)
proporcionan un mecanismo de comunicación entre clientes y proveedores en relación 1:N y con
desacoplamiento nominal. Una de sus muchas aplicaciones es en los problemas de procesamiento
asíncrono de datos.

Arquitectura centralizada

En las arquitecturas centralizadas dirigidas por eventos existe un mediador central –bus de
comunicaciones– que se encarga de hacer efectivo el proceso de registro de los clientes
escuchadores y de lanzar las notificaciones bajo demanda de los proveedores a los mismos. Este
mecanismo permite una cardinalidad N:N. Este esquema se conoce bajo el nombre de patrón
PUB/SUB.

8
Arquitectura distribuida

En las arquitecturas distribuidas dirigidas por eventos cada proveedor es responsable de

gestionar la suscripción de sus clientes y de enviar las notificaciones cuando se produce un
evento. El mecanismo de comunicación también es desacoplado nominalmente, pero la
cardinalidad típicamente es de 1:N entre el proveedor y los clientes. Este esquema se
corresponde con el patrón observador-observable o event emitters en jerga Node JS.

9
¿Qué es una API?
Una API es un conjunto de definiciones y protocolos que se utiliza para desarrollar e
integrar el software de las aplicaciones. API significa interfaz de programación de
aplicaciones.

Las API permiten que sus productos y servicios se comuniquen con otros, sin necesidad de
saber cómo están implementados. Esto simplifica el desarrollo de las aplicaciones y permite
ahorrar tiempo y dinero. Las API le otorgan flexibilidad; simplifican el diseño, la
administración y el uso de las aplicaciones, y proporcionan oportunidades de innovación, lo
cual es ideal al momento de diseñar herramientas y productos nuevos (o de gestionar los
actuales).

A veces, las API se consideran como contratos, con documentación que representa un
acuerdo entre las partes: si una de las partes envía una solicitud remota con cierta estructura
en particular, esa misma estructura determinará cómo responderá el software de la otra
parte.

Debido a que simplifican la forma en que los desarrolladores integran los elementos de las
aplicaciones nuevas en una arquitectura actual, las API permiten la colaboración entre el
equipo comercial y el de TI. Las necesidades comerciales suelen cambiar rápidamente en
respuesta a los mercados digitales en constante cambio, donde la competencia puede
modificar un sector entero con una aplicación nueva. Para seguir siendo competitivos, es
importante admitir la implementación y el desarrollo rápidos de servicios innovadores. El
desarrollo de aplicaciones nativas de la nube es una forma identificable de aumentar la
velocidad de desarrollo y se basa en la conexión de una arquitectura de aplicaciones de
microservicios a través de las API.

Las API son un medio simplificado para conectar su propia infraestructura a través del
desarrollo de aplicaciones nativas de la nube, pero también le permiten compartir sus datos
con clientes y otros usuarios externos. Las API públicas representan un valor comercial
único porque simplifican y amplían la forma en que se conecta con sus partners y, además,
pueden rentabilizar sus datos (un ejemplo conocido es la API de Google Maps).

10
En resumen, las API le permiten habilitar el acceso a sus recursos y, al mismo tiempo,
mantener la seguridad y el control. Cómo habilitar el acceso y a quiénes depende de usted.
La seguridad de las API tiene que ver con que se gestionen bien. Para conectarse a las API
y crear aplicaciones que utilicen los datos o las funciones que estas ofrecen, se puede
utilizar una plataforma de integración distribuida que conecte todos los elementos,
incluidos los sistemas heredados y el Internet de las cosas (IoT).

Existen tres enfoques respecto a las políticas de las versiones de las API.

Privado De partners Público

Las API solo se pueden
usar internamente, así que
las empresas tienen un
mayor control sobre ellas.
Esto le da a las empresas un
mayor control sobre sus
API.
Las API se comparten con
partners empresariales
específicos, lo cual puede
ofrecer flujos de ingresos
adicionales, sin
comprometer la calidad.
Esto puede proporcionar
flujos de ingreso
adicionales, sin
comprometer la calidad.
Todos tienen acceso a las
API, así que otras empresas
pueden desarrollar API que
interactúen con las de usted
y así convertirse en una
fuente de innovaciones.
Esto permite que terceros
desarrollen aplicaciones que
interactúan con su API, y
puede ser un recurso para
innovar.

Innovaciones con las API

El acceso de los partners o el público a sus API permite:

• Crear nuevos canales de ingresos o ampliar los existentes.

• Expandir el alcance de su marca.
• Facilitar la innovación abierta o lograr mayor eficiencia, gracias al desarrollo y la
colaboración externos.

Suena maravilloso, ¿no? ¿Pero cómo lo logran las API?

Volvamos al ejemplo de la empresa distribuidora de libros.

Supongamos que uno de los partners de la empresa desarrolla una aplicación que ayuda a
las personas a encontrar libros en los estantes de cierta librería. Esta experiencia mejorada
atrae más compradores a la librería (que es cliente de la distribuidora) y expande un canal
de ingresos existente.

Es posible que un tercero use una API pública para desarrollar una aplicación que permita a
las personas comprar libros directamente de la distribuidora, en lugar de hacerlo en una

11
tienda, lo cual abre un nuevo canal de ingresos para la distribuidora de libros. Esto abre un
nuevo canal de ingresos para la distribuidora de libros.

Las API compartidas, ya sea con los partners elegidos o con todo el mundo, tienen efectos
positivos. Mientras más se asocie con otros gracias a las API, mayor difusión obtendrá su
marca, independientemente de los esfuerzos publicitarios de la empresa. Si usted utiliza una
API pública, por ejemplo, para dar acceso a la tecnología a todo el mundo, alienta a los
desarrolladores a crear un ecosistema de aplicaciones en torno a su API. Mientras más
personas usen su tecnología, más personas estarán dispuestas a hacer negocios con usted.

Hacer pública la tecnología da resultados novedosos e inesperados que a veces alteran

sectores completos. Estos resultados, a veces, alteran sectores completos. En el caso de
nuestra distribuidora de libros, las nuevas empresas (un servicio de préstamo de libros, por
ejemplo) pueden cambiar la manera en que comercializa sus servicios. Los partners y las
API públicas le permiten aprovechar los esfuerzos creativos de una comunidad más grande
que su equipo de desarrolladores internos. Las nuevas ideas surgen de todas partes, y las
empresas deben ser conscientes de los cambios en su mercado y estar listas para actuar en
consecuencia. Las API son de gran ayuda.

Breve historia de las API

Las API surgieron los primeros días de la informática, mucho antes que la computadora
personal. En esa época, una API normalmente se usaba como biblioteca para los sistemas
operativos. Casi siempre estaban habilitadas localmente en los sistemas en los que
operaban, aunque a veces pasaban mensajes entre las computadoras centrales. Después de
casi 30 años, las API se expandieron más allá de los entornos locales. A principios del año
2000, ya eran una tecnología importante para la integración remota de datos.

Las API remotas

Las API remotas están diseñadas para interactuar en una red de comunicaciones. Por
"remoto" nos referimos a que los recursos que administran las API están, de alguna manera,
fuera de la computadora que solicita alguno de dichos recursos. Debido a que la red de
comunicaciones más usada es Internet, la mayoría de las API están diseñadas de acuerdo
con los estándares web. No todas las API remotas son API web, pero se puede suponer que
las API web son remotas.

Las API web normalmente usan HTTP para solicitar mensajes y proporcionar una
definición de la estructura de los mensajes de respuesta. Por lo general, estos mensajes de
respuesta toman la forma de un archivo XML o JSON, que son los formatos preferidos
porque presentan los datos en una manera fácil de manejar para otras aplicaciones.

12
¿Qué se ha hecho para mejorar las API?

A medida que las API han evolucionado en las ahora generalizadas API web, se han
realizado muchos esfuerzos para simplificar su diseño y facilitar su implementación.

Un poco de SOAP, mucho de REST

A medida que se han difundido las API, se desarrolló una especificación de protocolo para
permitir la estandarización del intercambio de información; se llama Protocolo de Acceso a
Objetos Simples, más conocido como SOAP. Las API diseñadas con SOAP usan XML
para el formato de sus mensajes y reciben solicitudes a través de HTTP o SMTP. Con
SOAP, es más fácil que las aplicaciones que funcionan en entornos distintos o están escritas
en diferentes lenguajes compartan información.

Otra especificación es la Transferencia de Estado Representacional (REST). Las API web

que funcionan con las limitaciones de arquitectura REST se llaman API de RESTful. La
diferencia entre REST y SOAP es básica: SOAP es un protocolo, mientras que REST es un
estilo de arquitectura. Esto significa que no hay ningún estándar oficial para las API web de
RESTful. Tal como se define en la tesis de Roy Fielding, “Architectural Styles and the
Design of Network-based Software Architectures”, las API son RESTful siempre que
cumplan con las 6 limitaciones principales de un sistema RESTful:

• Arquitectura cliente-servidor: la arquitectura REST está compuesta por clientes,

servidores y recursos, y administra las solicitudes con HTTP.
• Sin estado: el contenido de los clientes no se almacena en el servidor entre las
solicitudes, sino que la información sobre el estado de la sesión se queda en el
cliente. En su lugar, la información sobre el estado de la sesión está en posesión del
cliente.
• Capacidad de caché: el almacenamiento en caché puede eliminar la necesidad de
algunas interacciones cliente-servidor.
• Sistema en capas: las interacciones cliente-servidor pueden estar mediadas por
capas adicionales, que pueden ofrecer otras funciones, como el equilibrio de carga,
los cachés compartidos o la seguridad. Estas capas pueden ofrecer funcionalidades
adicionales, como equilibrio de carga, cachés compartidos o seguridad.
• Código de demanda (opcional): los servidores pueden extender las funciones de
un cliente transfiriendo código ejecutable.
• Interfaz uniforme: esta limitación es fundamental para el diseño de las API de
RESTful e incluye 4 aspectos:
o Identificación de recursos en las solicitudes: los recursos se identifican en
las solicitudes y se separan de las representaciones que se devuelven al
cliente.
o Administración de recursos mediante representaciones: los clientes
reciben archivos que representan los recursos. Estas representaciones deben
tener la información suficiente como para poder ser modificadas o
eliminadas.

13
 o Mensajes autodescriptivos: cada mensaje que se devuelve al cliente
contiene la información suficiente para describir cómo debe procesar la
información.
o Hipermedios es el motor del estado de la aplicación: después de acceder a
un recurso, el cliente REST debe ser capaz de descubrir mediante
hipervínculos todas las otras acciones que están disponibles actualmente.

Estas limitaciones pueden parecer demasiadas, pero son mucho más sencillas que un
protocolo definido previamente. Por eso, las API de RESTful son cada vez más frecuentes
que las de SOAP.

En los últimos años, la especificación de OpenAPI se ha convertido en un estándar común

para definir las API de REST. OpenAPI establece una forma independiente del lenguaje
para que los desarrolladores diseñen interfaces API de REST, que permite a los usuarios
entenderlas con el mínimo esfuerzo.

SOA frente a la arquitectura de microservicios

Los dos enfoques de arquitectura que más se utilizan para las API remotas son la
arquitectura orientada al servicio (SOA) y la arquitectura de microservicios. La SOA es el
más antiguo de los dos, y comenzó como una mejora de las aplicaciones monolíticas. En
lugar de usar una sola aplicación que haga todo, se pueden usar varias aplicaciones que
proporcionen diferentes funciones y que no tengan conexión directa, todo gracias a un
patrón de integración, como un bus de servicios empresariales (ESB).

Aunque en muchos aspectos la SOA es más sencilla que una arquitectura monolítica,
conlleva un riesgo de cambios en cascada en todo el entorno si las interacciones de los
componentes no se comprenden claramente. Esta complejidad adicional vuelve a presentar
algunos de los problemas que la SOA pretendía solucionar.

Las arquitecturas de microservicios se parecen a los patrones SOA en que los servicios son
especializados y no tienen conexión directa. Pero, además, descomponen las arquitecturas
tradicionales en partes más pequeñas. Los servicios de la arquitectura de microservicios
usan un marco de mensajería común, como las API de RESTful. Utilizan API de RESTful
para comunicarse entre sí, sin necesidad de operaciones complejas de conversión de datos
ni capas de integración adicionales. Usar las API de RESTful permite e incluso fomenta
una distribución más rápida de nuevas funciones y actualizaciones. Cada servicio es
independiente. Un servicio se puede reemplazar, mejorar o abandonar, sin afectar los demás
servicios de la arquitectura. Esta arquitectura liviana optimiza los recursos distribuidos o en
la nube y admite la escalabilidad dinámica de los servicios individuales.

14
¿Qué es un servicio web?
Los servicios web son aplicaciones autónomas modulares que se pueden describir, publicar,
localizar e invocar a través de una red.

El World Wide Web Consortium (W3C) define un servicio web como un sistema de
software designado para dar soporte a la interacción de máquina a máquina interoperativa a
través de una red.

Un servicio web realiza una tarea específica o un conjunto de tareas, y se describe mediante
una descripción de servicio en una notación XML estándar llamada WSDL (Web Services
Description Language). La descripción de servicio proporciona todos los detalles
necesarios para interactuar con el servicio, incluidos los formatos de mensaje (que detallan
las operaciones), los protocolos de transporte y la ubicación.

Otros sistemas utilizan mensajes SOAP para interactuar con el servicio web, normalmente
utilizando HTTP con una serialización XML conjuntamente con otros estándares
relacionados con la web.

La interfaz WSDL oculta los detalles de cómo se implementa el servicio, y el servicio se

puede utilizar independientemente de la plataforma de hardware o software en la que se
implementa e independientemente del lenguaje de programación en el que está escrito.

Las aplicaciones basadas en servicios web son implementaciones en todas las tecnologías,
con acoplamientos flexibles y orientadas a componentes. Los servicios web se pueden
utilizar individualmente o junto con otros servicios web, para llevar a cabo una agregación
completa o una transacción empresarial.

¿Qué es SOAP?
SOAP es una especificación para el intercambio de información estructurada en un entorno
distribuido y descentralizado. Como tal, representa la principal forma de comunicación entre los
tres actores clave de una arquitectura orientada a los servicios (SOA): el proveedor de servicios, el
solicitante de servicios y el intermediario de servicios. El principal objetivo de su diseño es ser
simple y ampliable. Se utiliza un mensaje SOAP para solicitar un servicio web.

SOAP 1.1
Varias compañías, entre las que se encontraban IBM® y Lotus, entregaron SOAP a W3C (World
Wide Web Consortium) como la base del Grupo de trabajo de protocolo XML (Extensible Markup
Language). Este protocolo está formado por tres partes:

• Un sobre que define una infraestructura para describir el contenido del mensaje e
instrucciones de proceso.
• Un conjunto de reglas de codificación para expresar instancias de tipos de datos
definidos por la aplicación.
• Un convenio para representar llamadas de procedimiento remoto y respuestas.

15
SOAP 1.1 es un transporte independiente del protocolo y se puede utilizar en combinación
con otros protocolos. En los servicios web que se desarrollan y se implementan con
WebSphere Application Server, se utiliza SOAP en combinación con HTTP, la
infraestructura de extensiones HTTP, y Java™ Message Service (JMS). SOAP también es
independiente del sistema operativo y no está vinculada con ningún lenguaje de
programación ni tecnología de componentes.

Siempre que el cliente pueda emitir mensajes XML, no importa qué tecnología se utiliza
para implementar el cliente. De igual forma, el servicio se puede implementar en cualquier
lenguaje, siempre que el servicio pueda procesar mensajes SOAP. Asimismo, el cliente y el
servidor pueden residir en cualquier plataforma adecuada.

SOAP 1.2
La especificación SOAP 1.2 también es una recomendación W3C, y WebSphere
Application Server sigue los estándares que se describen en SOAP 1.2. La especificación
SOAP 1.2 tiene tres partes, además de algunas confirmaciones y una colección de pruebas:

• Parte 0: Principal
• Parte 1: Infraestructura de mensajería
• Parte 2: Adjuntos
• Aserciones de especificación y colección de pruebas.

SOAP 1.2 proporciona una definición más específica del modelo de proceso SOAP que
suprime muchas de las ambigüedades que pueden generar problemas de interoperatividad
cuando no existen perfiles WS-I (Web Services-Interoperability). SOAP 1.2 disminuye la
posibilidad de que existan problemas de interoperatividad con las implementaciones de
SOAP 1.2 entre distintos proveedores.

Algunos de los cambios más importantes en la especificación SOAP 1.2 son:

• La posibilidad de definir oficialmente otros protocolos de transporte distintos del

protocolo HTTP, siempre que los proveedores se ajusten a la infraestructura de
enlaces definida en SOAP 1.2. Aunque HTTP es ubicuo, no es tan seguro como
transporte como TCP/IP, MQ, etc.
• El hecho de que SOAP 1.2 se basa en el conjunto de información XML (Infoset
XML). El conjunto de información proporciona un modo de describir el documento
XML utilizando el esquema XSD, pero no necesariamente serializa el documento
utilizando la serialización XML 1.0. SOAP 1.1 se basa en la serialización XML 1.0.
El conjunto de información permite utilizar de forma más fácil otros formatos de
serialización como el formato de protocolo binario. Puede utilizar un formato de
protocolo binario para mermar el mensaje a un formato más compacto, en el que la
información de codificación verbosa puede que no sea necesaria.

El estándar JAX-WS (Java API for XML Web Services) introduce la posibilidad de dar
soporte a SOAP 1.1 y SOAP 1.2.

16
Consulte las diferencias en la información de versiones de SOAP para ver las diferencias
adicionales entre SOAP 1.1 y SOAP 1.2.

Para obtener una lista completa de los estándares y las especificaciones a los que se da
soporte, consulte las especificaciones y la documentación de la API de los servicios Web.

JAX-WS.

JAX-WS (Java™ API for XML-Based Web Services) es la siguiente generación del
modelo de programación de servicios web que complementa la infraestructura que
proporciona el modelo de programación JAX-RPC (Java API for XML-based RPC). Con
JAX-WS, se simplifica el desarrollo de servicios web y clientes con una mayor
independencia de la plataforma para las aplicaciones Java mediante el uso de anotaciones
Java y proxies dinámicos.

JAX-WS es un modelo de programación que simplifica el desarrollo de aplicaciones

mediante el soporte de un modelo basado en anotaciones estándar para desarrollar clientes
y aplicaciones de servicio web. La tecnología JAX-WS se alinea estratégicamente con las
tendencias actuales del sector hacia un modelo de mensajería más centrado en los
documentos y sustituye el modelo de programación de llamada a procedimiento remoto tal
como se define en JAX-RPC. Aunque el modelo de programación JAX-RPC y las
aplicaciones siguen recibiendo soporte en este producto, JAX-RPC tiene limitaciones y no
da soporte a varios servicios complejos centrados en los documentos. JAX-WS es el
modelo de programación estratégico para desarrollar servicios web, además de ser una
parte necesaria de Java Platform, Enterprise Edition 6 (Java EE 6). JAX-WS también se
conoce como JSR 224.

La especificación JAX-WS 2.2 sustituye e incluye funciones de la especificación JAX-WS

2.1. JAX-WS 2.2 añade soporte del lado cliente para utilizar anotaciones relacionadas con
WebServiceFeature como @MTOM, @Addressing y las anotaciones @RespectBinding.
JAX-WS 2.1 anteriormente ha agregado soporte para estas anotaciones en el servidor.
También existe ahora la posibilidad de habilitar y configurar el soporte de WS-Addressing
en un cliente o servicio añadiendo aserciones WS-Policy en el documento WSDL. Además,
los servicios web para la especificación Java EE 1.3 introducen soporte para estas
anotaciones relacionadas con WebServiceFeature, así como soporte para utilizar los
elementos del descriptor de despliegue para configurar estas características tanto en el
cliente como en el servidor. JAX-WS 2.2 exige Java Architecture for XML Binding
(JAXB) Versión 2.2 para el enlace de datos.

La implementación del estándar de programación JAX-WS proporciona las siguientes

mejoras para desarrollar clientes y servicios web:

• Independencia de plataforma ampliada para aplicaciones Java.

Con las API de JAX-WS el desarrollo de los servicios y los clientes web se
simplifica con una independencia de plataforma ampliada para aplicaciones Java.

17
 JAX-WS aprovecha el mecanismo de proxy dinámico para proporcionar un modelo
de delegación formal con un proveedor conectable. Esto constituye una mejora
respecto a JAX-RPC, que se basa en la generación de objetos stub específicos del
proveedor para la invocación.

• Anotaciones

JAX-WS proporciona el soporte para anotar clases Java con metadatos para indicar
que la clase Java es un servicio web. JAX-WS da soporte al uso de anotaciones
basándose en la especificación del recurso de metadatos del lenguaje de
programación Java (JSR 175), la especificación de metadatos de servicios web para
la plataforma Java (JSR 181) y las anotaciones definidas por la especificación JAX-
WS 2.2. Utilizando las anotaciones del origen Java y la clase Java se simplifica el
desarrollo de los servicios web. Utilice las anotaciones para definir la información
que se suele especificar en los archivos del descriptor de despliegue, los archivos
WSDL o en la correlación de metadatos de archivos XML y WSDL con los
artefactos de origen.

JAXB.

JAXB (Java™ Architecture for XML Binding) es una tecnología Java que proporciona una
forma fácil y cómoda de correlacionar clases Java y esquemas XML para simplificar el
desarrollo de servicios web. JAXB aprovecha la flexibilidad de los datos XML neutros de
plataforma en las aplicaciones Java para enlazar esquemas XML con aplicaciones Java sin
necesidad de un conocimiento experto en programación XML. JAXB proporciona la
herramienta de compilador de esquemas xjc y la herramienta de generador de esquemas
schemagen para transformar entre el esquema XML y las clases Java.

JAXB es una tecnología de enlace de XML a Java que da soporte a la transformación entre
objetos de esquema y objetos Java, así como entre documentos de instancia XML e
instancias de objetos Java. JAXB está formado por una interfaz de programación de
aplicaciones (API) de tiempo de ejecución y las herramientas correspondientes que
simplifican el acceso a los documentos XML. JAXB también permite crear documentos
XML que cumplen el esquema XML y lo validan. JAX-WS (Java API for XML-Based
Web Services) utiliza la API y las herramientas JAXB como tecnología de enlace para las
correlaciones entre los objetos Java y los documentos XML. Las herramientas JAX-WS se
basan en las herramientas JAXB para el enlace de datos predeterminado en las
correlaciones de dos direcciones entre objetos Java y documentos XML.

Esta versión del servidor de aplicaciones admite la especificación JAXB 2.2. JAX-WS 2.2
requiere JAXB 2.2 para el enlace de datos. JAXB 2.2 proporciona mejoras menores en sus
anotaciones para mejorar la generación de esquemas y la integración con JAX-WS.

JAXB proporciona la herramienta de compilador de esquemas xjc, la herramienta de

generador de esquemas schemagen y una infraestructura de tiempo de ejecución. Puede
utilizar la herramienta de compilador de esquemas xjc para empezar con una definición de

18
esquema XML (XSD) para crear un conjunto de JavaBeans que se correlacionen con los
elementos y los tipos definidos en el esquema XSD. También puede empezar con un
conjunto de JavaBeans y utilizar la herramienta de generador de esquemas schemagen para
crear el esquema XML. Una vez exista la correlación entre el esquema XML y las clases
Java, los documentos de instancia XML pueden convertirse en y desde objetos Java
mediante el uso de la API de tiempo de ejecución de enlace JAXB. Puede acceder a los
datos almacenados en los documentos XML sin necesidad de conocer la estructura de
datos. A continuación, puede utilizar las clases Java resultantes para ensamblar una
aplicación de servicios web.

Los artefactos y las clases anotadas JAXB contienen toda la información que necesita la
API de tiempo de ejecución JAXB para procesar los documentos de instancia XML. La
API de tiempo de ejecución JAXB da soporte a la ordenación de objetos JAXB en XML y
la desordenación del documento XML en instancias de clases JAXB. De manera opcional,
puede utilizar JAXB para proporcionar una validación XML que obligue a los documentos
XML entrantes y salientes a cumplir las restricciones XML definidas con el esquema XML.

JAXB es la tecnología de enlace de datos predeterminado que utiliza la API Java para las
herramientas de servicios web XML (JAX-WS) y la implementación en este producto.
Puede desarrollar objetos JAXB para su uso en las aplicaciones JAX-WS.

También puede utilizar JAXB independientemente de JAX-WS cuando desee aprovechar la

tecnología de enlace de datos XML para manipular XML en las aplicaciones Java.

JAX-RPC.

La especificación Java API for XML-based RPC (JAX-RPC) permite desarrollar clientes
de servicios web y servicios web interoperativos y portátiles basados en SOAP. JAX-RPC
1.1 proporciona API básicas para el desarrollo y el despliegue de servicios web en una
plataforma Java™ y es una parte de la plataforma de servicios web para Java EE (Java
Platform, Enterprise Edition). La plataforma Java EE permite desarrollar servicios web
portátiles.

19
WebSphere Application Server implementa estándares JAX-RPC 1.1.

El estándar JAX-RPC cubre el modelo de programación y los enlaces para la utilización de

WSDL (Web Services Description Language) para servicios web en lenguaje Java. JAX-
RPC simplifica el desarrollo de servicios web al protegerle de la complejidad subyacente de
la comunicación SOAP.

En la superficie, JAX-RPC parece otra creación de instancias de RMI (Remote Method

Invocation). Básicamente, JAX-RPC permite a los clientes acceder a un servicio web como
si el servicio web fuera un objeto local correlacionado con el espacio de direcciones del
cliente, aunque el proveedor del servicio web se encuentre en otra parte del mundo. JAX-
RPC se ejecuta utilizando el protocolo SOAP basado en XML, que se ejecuta normalmente
encima de HTTP.

JAX-RPC define las correlaciones entre los tipos de puerto WSDL y las interfaces Java, así
como entre el lenguaje Java y los tipos de esquema XML (Extensible Markup Language).

Se puede crear un servicio web de JAX-RPC a partir de una implementación de JavaBeans

o de enterprise bean. Puede especificar los procedimientos remotos definiendo métodos
remotos en una interfaz Java. Sólo necesita codificar una o varias clases que implementen
los métodos. Las demás clases y los otros artefactos se generan mediante las herramientas
del proveedor del servicio web.
La definición de interfaz en JAX-RPC debe seguir unas reglas concretas:

• La interfaz debe ampliar java.rmi.Remote, como RMI.

• Los métodos deben crear java.rmi.RemoteException.
• Los parámetros de método no pueden ser referencias remotas.
• El parámetro de método debe ser uno de los parámetros soportados por la
especificación JAX-RPC. En la siguiente lista se proporcionan ejemplos de los
parámetros de método que están soportados. Si desea ver una lista completa de los
parámetros de método, consulte la especificación JAX-RPC.
o Tipos primitivos: boolean, byte, double, float, short,
int y long
o Envoltura de objeto de tipos primitivos: java.lang.Boolean,
java.lang.Byte, java.lang.Double, java.lang.Float,
java.lang.Integer, java.lang.Long, java.lang.Short
o java.lang.String
o java.lang.BigDecimal
o java.lang.BigInteger
o java.lang.Calendar
o java.lang.Date
• Los métodos pueden tomar objetos de valor formados por un compuesto de los tres
tipos anteriores, además de objetos de valor agregado.

Un cliente crea un stub e invoca métodos en él. El stub actúa como un proxy para el
servicio web. Desde el punto de vista del código del cliente, parece una invocación de un

20
método local. No obstante, cada invocación de método se organiza en el servidor remoto.
La organización incluye la codificación de la invocación de método en XML, tal como se
prescribe en el protocolo SOAP.

Estas son las interfaces y las clases clave que se necesitan para escribir servicios web y
clientes de servicios web:

• Interfaz de servicio: Una fábrica de invocación dinámica o de objetos stub y objetos

de proxy que se utilizan para invocar métodos.
• Clase ServiceFactory: Una fábrica de servicios.
• loadService

El método loadService se proporciona en WebSphere Application Server

Versión 6.0 para generar el localizador de servicios que necesita la implementación
de JAX-RPC. Si recuerda, en las versiones anteriores no existía ninguna forma
específica de adquirir el localizador de servicios generado. Para clientes gestionados
ha utilizado un método JNDI para obtener el localizador de servicios y para clientes
no gestionados, tuvo que crear instancias del localizador de servicios específico de
IBM, ServiceLocator service=new ServiceLocator(...);, el cual
no se puede migrar. Los parámetros loadService son:

owsdlDocumentLocation: un URL para la ubicación de documentos

WSDL para el servicio o null.
o serviceName: un nombre cualificado para el servicio
o properties: un conjunto de propiedades específicas de la
implementación que permiten ubicar la clase de implementación de servicios
generada.
• isUserInRole

El método isUserInRole devuelve un valor booleano que indica si el usuario

autenticado de la invocación de método actual en la instancia de punto final se
incluye en el rol lógico especificado.

o role: el parámetro role es una serie que especifica el nombre del rol.
• Servicio
• Interfaz de llamada: se utiliza para la invocación dinámica
• Interfaz de stubs: interfaz base de objetos stub

Si utiliza un stub para acceder al proveedor de servicios web, la mayoría de los detalles de
la API JAX-RPC están ocultos. El cliente crear una ServiceFactory
(java.xml.rpc.ServiceFactory). El cliente crea una instancia de un servicio
(java.xml.rpc.Service) a partir de la ServiceFactory. El servicio es un objeto de
fábrica que crea el puerto. El puerto es la interfaz de punto final de servicio remoto con el
servicio web. En el caso de DII, el objeto de servicio se utiliza para crear los objetos de
llamada, que se pueden configurar para que llamen a los métodos en el puerto del servicio
web.

21
Desarrollo web.
Desarrollo web significa construir y mantener sitios web; es el trabajo que tiene lugar en un
segundo plano y que permite que una web tenga una apariencia impecable, un funcionamiento
rápido y un buen desempeño para permitir la mejor experiencia de usuario.

Pero, ¿cómo lograrlo?

Los desarrolladores web lo hacen a través de diversos lenguajes de programación. El

lenguaje que usan en cada momento depende del tipo de tarea que están haciendo. El
desarrollo web se divide, de forma general, en Frontend (la parte cliente) y Backend (la
parte servidor).

Frontend, Backend o Full-stack, ¿quién es quién?

Un desarrollador Frontend se encarga de la composición, diseño e interactividad usando

HTML, CSS y JavaScript. El desarrollador Frontend toma una idea y la convierte en
realidad. Lo que ves y lo que usas, como por ejemplo el aspecto visual del sitio web, los
menús desplegables y el texto, son creados por el desarrollador Frontend, que escribe una
serie de programas para dar estructura, forma e interactividad a estos elementos. Estos
programas se ejecutan después a través de un navegador.

El desarrollador Backend se encarga de lo que no se ve, es decir, dónde se almacenan los

datos. Sin datos no hay Frontend. El Backend consiste en el servidor que acoge la web, una
aplicación para ejecutarlo y una base de datos. El desarrollador Backend utiliza programas
de computación para asegurar que el servidor, la aplicación y la base de datos tengan un
desempeño regular conjunto. Además, analiza qué necesita la empresa y proporciona
soluciones de programación eficientes. Para hacer este increíble trabajo, utiliza una serie de
lenguajes del lado del servidor, como PHP, Ruby, Python y Java.

El desarrollador Full-stack está a cargo tanto del Frontend como del Backend, y necesita
saber cómo funciona la web a todos los niveles para determinar cómo se van a coordinar la
parte cliente y la parte servidor. Para alcanzar este nivel de experiencia hace falta más
tiempo, claro, puesto que hay más que aprender.

22
Laravel.
Laravel, el “framework PHP para artesanos” según dicta su slogan. Laravel es un
framework PHP de código abierto que intenta aprovechar las ventajas de otros
Frameworks y desarrollar con las últimas versiones de PHP (entre otras muchas cosas
que aporta como framework).
Su filosofía es desarrollar código PHP de forma elegante y simple basado en un modelo
MVC(Modelo-Vista-Controlador).
El objetivo de Laravel es el de ser un framework que permita el uso de una sintaxis refinada
y expresiva para crear código de forma sencilla, evitando el «código espagueti» y
permitiendo multitud de funcionalidades. Aprovecha todo lo bueno de otros frameworks y
utiliza las características de las últimas versiones de PHP.

La mayor parte de su estructura está formada por dependencias, especialmente de Symfony,

lo que implica que el desarrollo de Laravel dependa también del desarrollo de sus
dependencias.

Algunas de las características:

• Blade: Blade es un sistema de plantillas para crear vistas en Laravel. Este permite
extender plantillas creadas y secciones en otras vistas en las cuales también
tendremos accesibles las variables y con posibilidad de utilizar código PHP en ellas,
además, ligado al uso de bootstrap u otro famework HTML generará resultados
optimizados a los diferentes dispositivos (Móviles, Tablets, PC’s, etc..).
• Eloquent: Eloquent es el ORM que incluye Laravel para manejar de una forma
fácil y sencilla los procesos correspondientes al manejo de bases de datos en nuestro
proyecto. Transforma las consultas SQL a un sistema MVC lo que no permite
procesar consultas SQL directamente y así protegernos de la inyección SQL.
• Routing: Laravel proporciona un sistema de organización y gestión de rutas que
nos permite controlar de manera exhaustiva las rutas de nuestro sistema.
• Middlewares: Son una especie de controladores que se ejecutan antes y después de
una petición al servidor, lo que nos permite insertar múltiples controles,
validaciones o procesos en estos puntos del flujo de la aplicación.
• Comunidad y documentación: Un gran punto a destacar de este framework es la
gran comunidad y documentación que existe, una comunidad de profesionales
activa que aporta conocimiento y funcionalidades, además de testear nuevas
versiones y detectar fallos del framework, lo que le da seguridad al framework. Y
una documentación muy completa y de calidad pensada para los propios
desarrolladores.

23
Características Generales

• Sistema de ruteo, también RESTful

• Blade, Motor de plantillas
• Peticiones Fluent
• Eloquent ORM
• Basado en Composer
• Soporte para el caché
• Soporte para MVC
• Usa componentes de Symfony
• Adopta las especificaciones PSR-2 y PSR-4

¿Por qué elegir Laravel?

La potencia de Laravel radica en su integración, escalabilidad y facilidad de

mantenimiento respecto a otros desarrollos en lenguajes 100% nativos y por lo tanto es
una opción más que a tener en cuenta a la hora de decidir usar este framework en nuestros
desarrollos.

¿Cuándo utilizar Laravel? (tres puntos a destacar)

• Los CMS no cubren nuestras necesidades como aplicación web.

• Necesitamos de un desarrollo a medida ágil, seguro y con una fácil escalabilidad y
mantenimiento.
• Si además de necesitar una solución web, esta tiene que estar integrada con otras
aplicaciones (Google, servicios de mailing, ERP’s, etc.).

24