Construyendo una AOS con PHP: Patrones de Diseño de Servicios Web en PHP

Jesús M. Castagnetto M., Ph.D. - Facultad de Ciencias y Filosofía, yDirección Universitaria de Información, Universidad Peruana Cayetano Heredia

Construyendo una AOS con PHP: Patrones de Diseño de Servicios Web en PHP

Jesús M. Castagnetto, Ph.D.

Latinoware 200830 de Octubre – 1 de Noviembre, 2008

Parque Tecnológico Itaipu (PTI)Foz do Iguaçu PR/Brasil


Agenda

● ¿Qué es una Arquitectura Orientada a Servicios (AOS)?

● ¿Qué es un Patrón de Diseño?● Uso de Servicios Web en una AOS● Ejemplos de patrones usando PHP● Recomendaciones


Arquitectura Orientada a Servicios (AOS)● Un diseño arquitectural para el

desarrollo e integración de sistemas.● La funcionalidad del sistema se

organiza en función a los procesos de negocios.

● Los procesos se implementan como servicios interoperables, usando interfaces y protocolos homogéneos.


Características de una AOS

● Acoplamiento débil/laxo entre componentes.

● “Contratos de servicio” para definir interfaces.



● Intermediarios para el reuso de sistemas existentes.

● Composición de servicios mediante la coordinación de acciones.



● Los servicios tienen lógica autónoma.

● La descripción de cada servicio se puede descubrir, simplificando su uso.



● Se pueden usar entornos y componentes heterogéneos, siempre que se cumplan los estándares para la comunicación entre servicios.


... Y algo muy importante

El usar una AOSno implica el usode Servicios Web


Patrones de Diseño

“... Cada patrón describe un problema que ocurre una y otra vez en nuesto entorno, y luego describe el meollo de la solución al problema, de tal manera que puedas usar esta solución millones de veces, sin tener que hacerlo de forma exactamente igual dos veces ...”

Christopher Alexander


Patrones de Diseño

● Son soluciones generales y reusables a problemas comunes.

● Se hacen evidente en la arquitectura, al construir edificios basados en principios clave.

● En software, la idea se traduce en soluciones pragmáticas, que nos ayudan a hacer frente a problemas recurrentes.


Patrones de Diseño

● Escribir programas, es una mezcla de teoría, técnica y arte, y los patrones de diseño surgen de la experiencia.

● Las comunidades de programadores, han descrito decenas de patrones básicos y derivados.

● Aprender a usar patrones de diseño efectivamente, toma tiempo.


Patrones y Anti-patrones

● Los patrones de diseño, nos orientan hacia que debemos hacer para resolver un problema.

● Los anti-patrones nos alertan acerca de qué evitar hacer, y nos enseñan que en ocasiones, una aparente solución es un problema más grave disfrazado.


Servicios Web“... (U)n sistema de software diseñado para permitir la interacción interoperable de máquina-a-máquina en una red. Tiene una interfaz descrita en formato procesable-por-máquina ... Otros sistemas interaccionan con el Servicio Web de la manera prescrita en su descripción ... usando HTTP con serialización XML ...”

Definición del W3C


Protocolos de Servicios Web

SOAP:● Puede usar múltiples medios de

transporte: SMTP, HTTP/HTTPS, etc.● Usa XML como formato del mensaje.● Puede combinar múltiples estándares

que abarcan otras facetas: seguridad, confiabilidad, transacciones, etc.

● Es flexible, extensible, y complejo.



XML-RPC:● Usa HTTP como transporte (no es

común que use HTTPS)● Usa XML como formato del mensaje,

y describe formas de codificar datos.● Es una implementación en XML de

una llamada remota a procedimiento.● Es simple, pero inflexible.



REST:● Es más un estilo de arquitectura de

sistemas que un protocolo per se.● Es la Web, con recursos abstraídos en

URLs, y acciones en operaciones de HTTP (GET, POST, PUT, DELETE)

● Es escalable, simple, y robusto, y es algo que ya sabemos cómo hacer.


REST y AOS

● En principio una AOS puede ser (y ha sido) implementada usando diferentes tecnologías.

● Los Servicios Web con todas sus ventajas son una excelente forma de implementar una AOS.

● Y, por supuesto, REST es la forma de hacerlo bien y en forma simple.


Anatomía de un patrón de diseño

Generalmente se describen usando:● Un nombre descriptivo.● Una descripción corta que incluye la

intención (el objetivo del mismo y la razón de su uso) y su aplicabilidad (el contexto de uso).

● Las consecuencias de su uso.● Descripción de cómo implementarlo.


Patrones a discutir

● Búsqueda asincrónica(Asynchronous query)

● Servicios de fachada(Facade services)

● Envoltura para lo anticuado(Legacy wrapper)


Búsqueda asincrónica

Intención:● Permitir que se puedan realizar

búsquedas o procesos de larga duración, sin impactar en forma negativa en el funcionamiento de quienes usen el servicio.

● Tratar de reducir el problema de agotamiento de tiempo y bloqueo de recursos.



Consecuencias:● No hay un tiempo precisamente

determinado para obtener la respuesta.

● El cliente del servicio tiene que implementar la lógica de reintentar obtener la respuesta, hasta que ésta se encuentre disponible.



Implementación:● El cliente envía un pedido de

búsqueda al proveedor del servicio, el cual lo pone en una cola de proceso, y retorna un ID del pedido.

● Un proceso secundario ejecuta el pedido en cola, y al terminar, pone la respuesta en otra cola de mensajes.



Implementación: (cont.)● El cliente le pide la respuesta al

servicio. Si el servicio no la encuentra en la cola, le dice al cliente que regrese luego, de otro modo la saca de la cola de mensajes, y la entrega al cliente.


Búsqueda asincrónica (Ejemplo)● Vamos a generar un reporte de notas

para alumnos y cursos.● Usaremos REST para definir las URLs

de búsqueda:● http://[dominio]/notas/curso/[CURSOID]● http://[dominio]/notas/cursos/[CURSOLISTA]● http://[dominio]/notas/alumno/[ALUMID]● http://[dominio]/notas/alumnos/[ALUMLISTA]


Búsqueda asincrónica (Ejemplo)● Y definiremos:

● CURSOID:Identificador del curso, ej. Q0415

● CURSOLISTA:Lista de cursos, ej. M0101,B0203

● ALUMNID:Identificador del alumno, ej. 65782

● ALUMNOLISTA:Lista de alumnos, ej. 34291,78239,12033


Búsqueda asincrónica (Ejemplo)● La estructura del URL nos da el tipo

general de acción, los límites de la búsqueda y sus parámetros:

/notas/alumno/05644

● De esta manera el URL es único y explícito.

● Para nuestro ejemplo asumimos que usaremos sólo HTTP GET.


Búsqueda asincrónica (Ejemplo)● Al llamar una URL, el cliente recibe

un identificador de búsqueda en XML:➔ http://.../notas/alumno/30462

<notas><id>12345678901234567890<id><query>/alumno/30462</query><result/>

</notas>


Búsqueda asincrónica (Ejemplo)● El servicio lo envía a ser procesado

en una cola, y de ahí en adelante, el cliente se encargará de pedir el resultado usando el URL apropiado.

● Hay dos opciones de diseño:● Un servicio de resultados general, que sólo

use el ID para obtener la información.● Uno específico al servicio inicial, usando una

variante del URL original.


Búsqueda asincrónica (Ejemplo)

Usando un procesador genérico:➔ http://.../resultados/[RESULTID]● Nos permite unificar resultados de

varios servicios, y no multiplicar innecesariamente los recursos.

● Pero, perdemos el contexto del servicio original, lo cual puede ser confuso para los usuarios.



Usando una variante del URL original:➔ http://.../notas/resultado/[RESULTID]● Nos permite conservar el contexto de

la interacción, añadiendo sólo una nueva acción dentro del servicio.

● Podemos evitar duplicación de código delegando responsabilidades a un servicio interno.



El código que implemente el patrón no es complicado, se necesita:● Código que implemente la recepción

de búsquedas, y puesta en cola.● Código para obtener la búsqueda de

la cola, ejecutarla, y luego poner los resultados en cola.

● Código para obtener los resultados.


Servicios de fachada

Intención● Permitir un acceso simplificado a un

sistema con una interfaz compleja.● Combinar en una, varias operaciones

relacionadas en la API existente.● Reducir el número de parámetros.● Aislar cambios del sistema interno, y

desacoplar el uso externo.



Consecuencias● Si bien simplifica el uso de una

interfaz, puede llevar a complejidad en la lógica de implementación.

● Puede haber más de una forma de combinar interfaces, y no todas pueden ser óptimas.

● Impacta el rendimiento del servicio.



Implementación● Una capa que implementa el API del

servicio que será visto por los clientes externos.

● Código específico que use las librerías o sistemas internos (con todas sus condiciones) para que se pueda cumplir la API simplificada del servicio.


Envoltura para lo anticuado

Intención● Permitir el acceso a un sistema

anticuado (legacy), a través de una tecnología o protocolo nuevo.

● Integrar sistemas heterogéneos existentes, dentro de una nueva arquitectura, sin necesidad de rehacer la funcionalidad.



Consecuencias● La “envoltura” tiene que encargarse

de posibles trasformaciones de datos, para que el sistema anticuado pueda funcionar correctamente.

● Aumenta la vida útil del sistema anticuado, pero eso puede convertirse en un defecto grave en la evolución futura de la arquitectura.



Implementación● Una capa que exponga la API del

sistema anticuado usando REST.● Rutinas de transformación de datos

de entrada y salida, para que funcionen con el sistema anticuado.

● Código para manejar los errores originados en el sistema anticuado.


¿Cómo hacemos el código?

● Podemos hacerlo “a mano”, implementando mapeos apropiados, y lógica de redirección.

O

● Podemos usar librerías que hagan el manejo rutinario y concentrarnos en la funcionalidad a proveer.


Tonic (tonic.sf.net)


Konstrukt (www.konstrukt.dk)


WSO2 WSF/PHP (wso2.org/projects/wsf/php)


WSO2 WSF/PHP

● Un proyecto de WSO2: herramientas y librerías para Servicios Web.

● Soporte para SOAP y WSDL, y una serie de estándares WS-*.

● Interoperable con otras implementaciones de SOAP.

● Soporte para REST, incluyendo mapeo específico de URIs.


Ideas finales

● Es posible hacer una AOS simple usando REST, y diseñándola bien.

● Los patrones comunes de diseño no son tan complicados, pero su implementación sí puede serla.

● Si entendemos el uso de REST y de patrones de diseño, podemos escribirlo en PHP (o cualquier otro lenguaje de programación).


Más información: Patrones

● Portland Pattern Repository:http://c2.com/cgi/wiki?PortlandPatternRepository

➔ Lean también el resto del sitio de Ward Cunninhgam (http://c2.com/)

● “Design Patterns: Elements of Reusable Object-Oriented Software” por Erich Gamma, Richard Helm, Ralph Johnson, y John Vlissides (ISBN: 0-201-63361-2)

● “The Timeless Way of Building” por Christopher Alexander (ISBN: 0195024028)


Más información: PHP, Servicios Web y AOS● Do REST in PHP - PHP RESTful Data Services

(http://www.dimuthu.org/blog/2008/09/18/do-rest-in-php-php-restful-data-services/)

● Why PHP Users should be Serious about SOA? (http://phpwebservices.blogspot.com/2008/01/why-php-uses-should-be-serious-about.html)

● Open Service Oriented Architecture (http://www.osoa.org/display/PHP/SOA+PHP+Homepage)

● Using PHP's SDO and SCA extensions (http://www.ibm.com/developerworks/web/library/ws-soa-scasdo/)


Más información: SOA, REST

● “RESTful Web Services” por Leonard Richardson y Sam Ruby (ISBN: 0-596-52926-0)

● “Basic SOA using REST” (http://www.webreference.com/programming/basic_soa/)

● SOA Pattern Catalog (http://www.soaprpc.com/patterns/soa_pattern_catalog.html)

● SOA Patterns (http://www.soapatterns.org/)


¡Gracias/Obrigado!

A los organizadores del evento por la invitación y el entusiasmo.

A todos ustedes por soportar mi “bla, bla, bla...”, sin dormirse.

Jesús M. [email protected]

[email protected]

Construyendo una AOS con PHP: Patrones de Diseño de Servicios Web en PHP

Technology

Transcript of Construyendo una AOS con PHP: Patrones de Diseño de Servicios Web en PHP