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

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

Jesús M. Castagnetto, Ph.D.

Latinoware 2008
30 de Octubre – 1 de Noviembre, 2008

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

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

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 AOS
no implica el uso
de 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.


(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]


(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


(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.

(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>

(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.

(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.

(Ejemplo)
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.

(Ejemplo)
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/w
hy-php-uses-should-be-serious-about.html)
● Open Service Oriented Architecture
(http://www.osoa.org/display/PHP/SOA+PHP+Ho
mepage)
● Using PHP's SDO and SCA extensions
(http://www.ibm.com/developerworks/web/librar
y/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/ba
sic_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. Castagnetto
jmcastagnetto@php.net
jesus@upch.edu.pe

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

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

Ähnlich wie Construyendo una AOS con PHP: Patrones de Diseño de Servicios Web en PHP (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

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