Seminario Spring Remoting

9 de Octubre de 2008
Spring Remoting
1
9 de Octubre de 2008
Qu es Spring Framework?
Nace con el objeto de reducir la complejidad en el desarrollo de aplicaciones
empresariales.
Spring es definido como un framework que se comporta a la vez como un contenedor
orientado a aspectos y con una base de inyeccin de dependencias ligero.
Ligero: Es ligero tanto en trminos de tamao como de sencillez en el desarrollo.
Dependency Injection. Los objetos declaran las dependencias con el resto de
componentes del sistema/arquitectura y es el contenedor el encargado de resolver stas.
Orientacin a aspectos: Permite separar la lgica de negocio de los servicios de
middleware: transaccionalidad, seguridad, logging, etc
Spring Remoting
2
middleware: transaccionalidad, seguridad, logging, etc
Contenedor: Contiene y gestiona el ciclo de vida de los objetos que contiene.
Framework: Es posible configurar y componer componentes complejos a partir de
componentes ms simples. Spring incorpora mucha funcionalidad de infraestructura,
permitiendo que el desarrollador se centre en la lgica de negocio.
NO PRETENDE REINVENTAR LA RUEDA. Asume que hay buenas soluciones para la capa
de persistencia (Hibernate, Ibatis, etc..) y para la capa Web (Struts, JSF, etc). Se integra
hasta con la tecnologa motivo de su gnesis (EJBs).
Mdulos Spring Framework
Spring MVC:
Implementacin alternativa a Struts. Nace como alternativa menos intrusiva facilitando la reutilizacin de
componentes y la independencia tecnolgica
Integracin con Hibernate(ORM):
Implementa el patrn DAO y aisla al desarrollador de la obtencin de la conexin con la BBDD y simplifica la etapa de
configuracin.
Los componentes DAO nicamente presentan el cdigo de persistencia mnimo (no es responsable de la obtencin y el
cierre de la conexin).
La transaccionalidad es gestionada mediante aspectos de un modo standalone. No hay necesidad de disponer de un
contenedor que de los servicios de infraestructura de un modo intrusivo. (Mdulo AOP).
Remoting:
Spring Remoting
3
Remoting:
Los componentes pueden ser invocados remotamente mediante la incorporacin de
componentes Exporter. Es decir, cualquier componente desarrollado de la capa de servicio
puede ser expuesto como un servicio remoto sin que fuese desarrollado para tal fin.
Posibilidad de invocacin mediante HTTP/RMI/SOAP/REST (XML + HTTP)/Hessian and Burlap
(RMI binario y optimizado).
Aslas al desarrollador de la complejidad tecnolgica subyacente.
Posibilidad de ejecutarse todo el cdigo fuera de contenedores especficos para la capa de
negocio. En caso de aplicacin web, nicamente es necesario un contenedor de servlets.
Mdulos Spring Framework (II)
Spring Remoting
4
Spring Framework Servicios enterprise
Presenta APIs que facilita de servicios enterprise:
JavaMail. Permite de una manera sencilla el envo de un correo, con todas las alternativas de
configuracin: SMTP seguro/no seguro.
Quartz Scheduler. Permite la planificacin de tareas con la potencia de las expresiones Cron.
Infraestructura de monitorizacin y gestin JMX (equivalente a SNMP). Permite disponer de
una infraestructura para la monitorizacin y gestin de los servicios/sistemas de las aplicaciones
desarrolladas.
Todos los fabricantes de contenedores J2EE, se han visto en la tesitura de publicar que son
Spring Remoting
5
Todos los fabricantes de contenedores J2EE, se han visto en la tesitura de publicar que son
compatibles con Spring, incluso elaborar herramientas de apoyo al desarrollo. Ejemplos:
BEA: http://e-docs.bea.com/platform/suppconfigs/configs/spring/
Oracle:
http://www.oracle.com/corporate/press/2007_may/SpringDevKit.html
IBM:
http://www.ibm.com/developerworks/websphere/library/techarticles/0706_johnsonbuck/0706_johnsonbuck.html
Dependency Injection
En un principio es conocido como el patrn Inversion Of Control (IoC).
Qu es lo que se est invirtiendo?. Martin Fowler 2004. Concluy que lo que se estaba invirtiendo era la
obtencin de dependencias. A partir de ese momento, el patrn paso a conocerse como Dependency
Injection.
Tradicionalmente, cada objeto es responsable de obtener las referencias de los objetos con los que
trabaja. Esto puede conducir a un fuerte acoplo entre componentes, as como un cdigo difcil de probar.
Con DI las dependencias son inyectadas a los objetos por una entidad externa, con lo que los componentes
nicamente declaran su dependencia con otros objetos, sin ser responsables de obtener las referencias
de los mismos.
Spring Remoting
6
La principal ventaja de DI es el desacoplo de componentes.
Se aconseja el uso de interfaces con el objeto de ocultar la implementacin de los componentes asociados,
mejorando an ms el desacoplo.
Dentro de Spring existe un componente llamado BeanFactory (contenedor) encargado de contener e
instanciar los objetos de la aplicacin, as como resolver las dependencias entre los mismos.
XmlBeanFactory es una implementacin que define los mismos, en un fichero XML.
El proceso de ir definiendo las asociaciones entre componentes siguiendo el patrn DI, es conocido como
wiring.
Exposicin de servicios remotos basados en POJOS
7 Spring Remoting
7
Introduccin
Gracias al poder de DI y al desacoplo de componentes, es posible exponer declarativamente
lgica de negocio como un servicio con invocacin remota. El desarrollador no tiene por qu
conocer las particularidades del protocolo subyacente.
Los distintos protocolos soportados son:
Servicios RMI
Servicios Hessian and Burlap (Caucho)
Innovaciones HTTP de servicios Spring
Spring Web Services (Xfire)
Spring Remoting
8
Spring Web Services (Xfire)
Exposicin servicio mediante RMI. Parte cliente
Desde el punto de vista del cliente, la programacin tradicional de un consumidor de servicios RMI
presentaba dos potenciales problemas:
Excepciones que deben ser capturadas o relanzadas: RemoteException, NotBoundException,
MalformedURLException. Ejemplo: En el caso que se indique mal la localizacin del servicio, la nica
manera de resolverlo es recompilando el cdigo involucrado en definir la URL (o reconfigurando las
propiedades del servicio). Por qu tratar este tipo de excepciones?.
EL mtodo de localizacin de un servicio RMI, normalmente incumple el principio fundamental de DI,
con lo que el objeto cliente es responsable de obtener la referencia del servicio RMI.
Con Spring, el cliente se va a comunicar con el servicio remoto mediante el uso de un proxy.
El proxy se encarga de ocultar al cliente de las particularidades del protocolo. Asimismo las
excepciones propias del protocolo las convierte en excepciones de Runtime (el cliente no trata
Spring Remoting
9
excepciones propias del protocolo las convierte en excepciones de Runtime (el cliente no trata
excepciones propias del protocolo)
Exposicin de servicio mediante RMI. Parte servidora
Pasos a realizar en una implementacin clsica:
La implementacin de los mtodos del servicio deben lanzar java.rmi.RemoteException
EL interfaz del servicio debe extender de java.rmi.Remote
Compilar los fuentes con el compilador de RMI (rmic) para producir los stubs y skeleton.
Arrancar un registro RMI
Registrar los servicios en el registro RMI
Spring te simplifica todos estos pasos de la siguiente manera:
El interfaz no es necesario que extienda de java.rmi.Remote
La implementacin del servicio es un POJO sin necesidad de lanzar excepciones java.rmi.RemoteException. Por tanto, el
Spring Remoting
10
La implementacin del servicio es un POJO sin necesidad de lanzar excepciones java.rmi.RemoteException. Por tanto, el
componente no tiene ningn cdigo asociado que le haga comportarse como un servicio RMI.
Una vez definida la implementacin e interfaz del servicio, Spring proporciona un componente RMIServiceExporter con
todo lo necesario para exponer la lgica como servicio RMI. Por defecto se intenta conectar con el registro RMI en el
puerto 1099 de la mquina local. En el caso que se quiera redefinir hay que establecer valor para las propiedades
registryHost y registryPort.
RMI presenta dos inconvenientes fundamentales:
No trabaja bien con firewalls (existe la posibilidad de tunelar el trfico RMI).
El cliente y el servidor deben ser cdigo Java
Exposicin mediante Hessian and Burlap
Ambos protocolos usan HTTP como protocolo de capa de aplicacin (modelo OSI)
Hessian lleva asociado un protocolo binario propio y con APIs para ser manejado por clientes
que no sean Java: PHP, Python, C++, C#.
Burlap, sin embargo, es un protocolo basado en tramas XML con lo que el abanico de clientes
se aumenta.
Por tanto, en el caso que haya restricciones de ancho de banda Hessian sera la solucin ms
ptima. Sin embargo, si se quiere que la comunicacin sea legible se aconseja el uso de
Burlap.
Spring Remoting
11
Burlap.
Configuracin Hessian/Burlap
Desde el punto de vista del cliente la configuracin es exactamente igual. Para el caso de Hessian se genera
el proxy mediante la clase HessianProxyFactoryBean y en el caso de Burlap con la clase
BurlapProxyFactoryBean.
Exposicin de servicio Hessian
La implementacin del servicio debe extender de HessianServlet. Los mtodos deben ser pblicos.
Sin embargo, con Spring no es necesario este paso, puesto que tiene un componente que aisla de todas las
particularidades del servicio: HessianServiceExporter.
Es necesario configurar el controlador de Hessian encargado de definir los endpoints donde los servicios
escucharan (URL HTTP).
HessianServiceExporter es configurado como un controlador Spring MVC. Por tanto es necesario definir el
DispatcherServlet, as como el manejador de URLs.
Spring Remoting
12
DispatcherServlet, as como el manejador de URLs.
De la misma manera es posible exponer lgica de negocio como WebService mediante el uso de Xfire
Exposicin de servicios mediante XFire
XFire permitir el exportar los mtodos de la lgica de negocio implementada en POJOS como un web
services. XFire permitir por tanto traducir los mensajes de entrada SOAP en invocaciones a mtodos
Java.
XFire presenta una aproximacin bottom-up donde se expone directamente como Servicio Web la API
interna de nuestra aplicacin.
Como ventaja presenta la posibilidad de abstraer al programador de los detalles de la tecnologa
subyacente.
A continuacin se ve el diagrama donde se explica el comportamiento del componente XFireExporter:
Spring Remoting
13
Declaracin de servicios Web usando anotaciones JSR- 181
El problema principal que presenta la solucin con XFireExporter es que es necesario definir el
bean de exportacin por cada bean que quieras exportar como servicio web.
Para poder usar las anotaciones con XFire es necesario incluir el soporte JAX-WS para Xfire
(dependencia de Maven).
Las anotaciones se realizan sobre la clase y el interfaz.
Por defecto, se publican todos los mtodos pblicos de la clase. Cuidado, por tanto, con
exponer mtodos de la API interna de la aplicacin.
Dentro de Spring es necesario configurar un mapeador de direcciones especfico para que el
Spring Remoting
14
Dentro de Spring es necesario configurar un mapeador de direcciones especfico para que el
DispatcherServlet interprete las anotaciones JSR-181 de los beans: JSR181HandlerMapping.
Finalmente todos aquellos beans que estn anotados respondern a la direccin:
http://<host>:<port>/<contextApp>/services/<serviceName>?wsdl
Consumiendo web services
Aunque es posible realizar la llamada al web service mediante la API de XFire:
ObjectServiceFactory y XFireProxyFactory, lo lgico es aprovechar las ventajas del patrn DI,
evitando al cliente tener que conocer las particularidades de la API.
Siguiendo la misma filosofa que en los casos anteriores, haremos uso de una factora de
Proxies que sern los encargados de implementar toda la lgica especfica del protocolo.
Existen dos proxies para poder realizar esta labor:
JaxRpcPortProxyFactoryBean. Esta implementacin es propia de Spring
XFireClientFactoryBean: Esta factora es provista dentro de Xfire.
Spring Remoting
15
Elegiremos XFire por la gestin implcita que hace de los tipos complejos, as como la sencillez
a la hora de definirlo: no es necesario definir el nombre del servicio, nombre del puerto,
namespace, puesto que l automticamente lo descubre a partir del WSDL.
Al igual que en los casos anteriores el proxy es el que se inyecta al bean cliente, con el objeto
de proporcionar una referencia al servicio de invocacin remoto.
XFireClientFactoryBean
Spring Remoting
16
Conclusiones
La exposicin de lgica de negocio como servicio mediante el uso de componentes
exportadores (aplicacin del patrn DI y uso de AOP), permite una solucin sencilla, donde no
es necesario conocer las particularidades de las tecnologas y protocolos subyacentes.
Presenta la ventaja de poder probar la lgica de negocio, puesto que se trata de un POJO.
Posibilidad de disponer de mecanismos ms ligeros que SOAP, con lo que el rendimiento
aumenta.
Posibilidad de cambio en el mtodo de exposicin, sin que se vean afectadas la parte cliente y
la parte servidora.
Spring Remoting
17
la parte servidora.
Se desarrollan ms rpidos que con Spring-WS
Tener cuidado con no exponer la API interna de la aplicacin. Quizs ser necesario el generar
componentes de la capa de servicio de ms alto nivel.
Cambios en las APIs afectan al entorno cliente (suponen un cambio en el contrato/interfaz). La
aproximacin no tiene en cuenta el contrato con el cliente.
Implementando Web Services con Spring
18 Spring Remoting
18
Aproximacin top-down (contract first)
Introduccin Spring WS
Como se ha comentado anteriormente los mecanismos de exposicin de JavaBeans como
servicio remoto, presenta la desventaja de ofrecer la API interna de la aplicacin.
Como contraposicin a este modelo se presenta un modelo de trabajo top-down, donde se
enfatiza en qu ofrece el servicio (contrato) del cmo es implementado el mismo.
Esto permite que podamos evolucionar el interfaz entre el cliente y el servidor, permitiendo
compatibilidad hacia atrs. En el modelo anterior, cambios en la API conducen a cambios en el
contrato.
Por tanto, en esta aproximacin los pasos a realizar son los siguientes:
Spring Remoting
19
Por tanto, en esta aproximacin los pasos a realizar son los siguientes:
Definir el contrato de servicio: Se definen los mensajes de entrada y salida del servicio, se
generan los esquemas XML , los cuales sern usados posteriormente en el WSDL.
Implementacin del service endpoint. Bsicamente este componente se encarga de gestionar
los mensajes de entrada y salida del servicio.
Configuracin del endpoint y de la infraestructura Spring-WS. En este paso, se generar el WSDL
usando los componentes que ofrece el framework
Definicin del contrato
Para la defnicin del contrato es necesario modelar los mensajes XML de entrada y de salida.
A partir de stos se infiere el esquema XML. Este paso evita el tener que conocer con gran
detalle las particularidades de la tecnologa Schema XML. En el ejemplo del seminario se ha
usado la herramienta Trang.
El contrato de servicio se divide en dos partes:
El contrato a nivel de datos: Se definen los mensajes de entrada y de salida del servicio.
Contrato operacional: Define las operaciones de servicio. Una operacin de servicio no tiene
por qu coincidir con un mtodo en la API de servicio.
Spring Remoting
20
por qu coincidir con un mtodo en la API de servicio.
Por tanto, el WSDL se divide en dos partes diferenciadas:
Contrato de datos: Donde se incluyen los esquemas de los mensajes de entrada y de salida:
elementos <wsdl:types> y <wsdl:message>.
Contrato de servicio: Elementos <wsdl:portType> y <wsdl:binding>.
Manejando los mensajes con Service Endpoints
Bsicamente estos componentes se encargan de gestionar los mensajes XML de entrada y de salida.
Los tipos de endpoints que Spring-WS ofrecen son muy variados.
Existe la posibilidad de trabajar con cualquier parseador XML: SAX, DOM, StAX.
Se integra con las APIs DOM4j, JDOM.
Con el objeto de abstraer al programador del tratamiento a bajo nivel del mensaje se ofrece una API: OXM (
Object-XML-Mapping) que realiza procesos de marshalling y unmarshalling de los mensajes.
OXM tiene soporte para Castor XML, JAXB v1, JAXB v2, JIBX, XmlStream (limitaciones con namespaces),
XMLBeans.
Es importante que el MessageEndpoint no se encargue de realizar directamente la lgica de negocio, sino
Spring Remoting
21
Es importante que el MessageEndpoint no se encargue de realizar directamente la lgica de negocio, sino
que se inyecte un componente encargado de realizar sta. Permite la separacin del contrato de datos del
contrato operacional.
Configuracin de Spring WS
En la configuracin de Spring es necesario definir los siguientes tipos de beans:
Mapeador de entrada (PayloadMapping). Encargado de redirigir los mensajes XML de entrada al
correspondiente endpoint (Se realiza a partir del nombre cualificado del XML (namespace +
elemento raz).
MessageEndpoint. Componente encargado de procesar los ficheros XML del servicio
(entrada/salida).
Bean lgica de negocio. Se encarga de a partir de los datos de entrada (objetos Java) invocar a la
logica de negocio y generar los datos de salida. Este objeto se inyecta al MessageEndpoint.
Spring Remoting
22
Marshaller. Encargado de realizar los procesos de marshalling y unmarshalling. En nuestro caso
se realiza usando Castor XML y apoyndose en el fichero de mapeo.
ExceptionResolver: Encargado de generar una SOAP fault a partir de las excepciones Java
producidas en la cadena de proceso.
Generador dinmico de WSDL. A partir de los esquemas XML y en funcin de una serie de
convenciones (Request y Response) genera los ficheros descriptores del servicio Web. Es
posible proporcionar WSDL de manera esttica
ExceptionResolver & Generador dinmica WSDL
Spring Remoting
23
DispatcherServlet
Finalmente es necesario configurar un DispatcherServlet especfico para poder permitir que la invocacin
de los servicios web se realice mediante el protocolo HTTP.
Spring Remoting
24
Consumicin de servicios web con Spring-WS. WebServiceTemplate
Trabajar con WebServiceTemplate. El cliente trabaja directamente con mensajes XML y es el template el encargado de
realizar las traducciones necesarias para uso del protocolo SOAP. Bsicamente este tipo de templates necesita un
componente para poder enviar el mensaje via HTTP (MessageSender) y una factora de mensajes(MessageFactory)
encargada de generar el mensaje SOAP. Existen los siguientes tipos de MessageFactory:
AxiomSOAPMessageFactory: Genera los mensajes SOAP usando la API de Axiom (Axis Object Model). Est basado en la API de
StAX y se recomienda cuando los mensajes del servicio se prevean sean de un volumen considerable
DomPoxMessageFactory: Produce XML plano y es usado para cuando no se prevea el uso de SOAP. En la versin 2 de Spring-WS
se prevee soporte para interfaces REST ().
SaajSOAPMessageFactory: Usa la API SAAJ (Soap With Attachment API). Internamente usa DOM. Cuidado con mensajes largos
Rendimiento bajo.
Igualmente existen dos tipos de MessageSender: Uno que trabaja directamente con el soporte de gestin HTTP de la JDK:
HttpURLConnectiony otro que trabaja con la librera commons-http. ste ltimo se considera ms idneo para
autenticacin HTTP y pool de conexiones HTTP.
Es posible usar las capacidades de marshalling y unmarshalling para que el cliente componga el mensaje. En este caso el
Spring Remoting
25
Es posible usar las capacidades de marshalling y unmarshalling para que el cliente componga el mensaje. En este caso el
serviceTemplate mantiene una referencia al objeto marshaller y unmarshaller.
WebServiceTemplate con soporte para marshalling
Spring Remoting
26
Consumicin de servicios web con Spring-WS. Soporte gateway
Es posible en Spring-WS evitar que el template sea inyectado. Para ello se ofrece una clase de
soporte que automticamente genera el WebServiceTemplate.
Logicamente es necesario proveer un bean definiendo el gateway con la configuracin
necesaria para que ste pueda crear el WebServiceTemplate (MessageSender, marshaller y
unmarshaller).
Spring Remoting
27
Conclusiones finales. Contract-first vs contract-last
Fragilidad. Cada vez que se cambia el interfaz Java se cambia el contrato de servicio generado.
Por tanto, es necesario mantener el contrato con el cliente aunque cambie la API.
Rendimiento: Cuando se renderiza automticamente el objeto Java en XML, puede tener una
penalizacin en el rendimiento (referencias cruzadas). En el caso de contract-first se explicita
el mensaje XML que va por el interfaz.
Reusabilidad. El esquema XML es un fichero que puede ser reusado para generar el WSDL, o
en otros esquemas.
Versionado. Al mantener desacoplado el contrato de la implementacin es posible mantener
el contrato cambiando la implementacin del servicio. Adems es posible mantener
compatibilidad hacia atrs, por ejemplo realizando transformaciones de mensajes antiguos en
Spring Remoting
28
compatibilidad hacia atrs, por ejemplo realizando transformaciones de mensajes antiguos en
el nuevo.
Soporte de protocolos HTTP/JMS e Email.
Los procesos de logging y auditora de mensajes est integrados con Log4j:
log4j.logger.org.springframework.ws.client.MessageTracing.sent=TRACE
log4j.logger.org.springframework.ws.client.MessageTracing.received=DEBUG
Incluye interceptores de validacin de los mensajes de entrada y salida.
Impedancia entre XML y objetos
Similar a la impedancia que existe en las soluciones ORM con respecto al modelo
entidad/relacin, existe problemas al convertir objetos en XML.
Extensiones XSD. Las extensiones XSD permiten restricciones en los tipos de datos. Ejemplo:
permitir tres letras mayusculas. Este tipo de extensiones no las presenta Java (nicamente
extensin de comportamiento y no de restriccin).
Tipos no soportados. Uno de los principios bsicos de la plataforma web service es la
interoperabilidad: Java, .NET, Python, Por ejemplo si desde Java se usa el tipo TreeMap,
seguramente en .NET se use el tipo System.collections.Hashtable. Por tanto, la semntica del
tipo de dato es diferente.
Spring Remoting
29
tipo de dato es diferente.
Referencias ciclicas. La forma de representar en XML referencias ciclicas es mediante
referencias. El problema es que no se puede usar validadores XML para validar esta estructura.
Hay que tener en cuenta estas consideraciones a la hora de implementar web services.
Introduccin a WS-Security
WS-Security se centra en tres grandes aspectos:
Autenticacin: Determinar el principal y comprobar qu es quien dice ser.
Firma digital: Pieza de informacin que es basada en el documento y la clave privada de
firmante. Internamente se compone de una funcin hash y una funcin de firma con la clave
privada del firmante.
Encriptacin y desencriptacin.
Consideraciones:
El uso de WS-Security lleva consigo una penalizacin importante del rendimiento con lo que se
Spring Remoting
30
El uso de WS-Security lleva consigo una penalizacin importante del rendimiento con lo que se
aconseja en algunos casos el uso de mecanismos de seguridad ms sencillos como puede ser la
los mecanismos de seguridad bsicos HTTP.
La implementacin de WS-Security para Spring dispone de soporte para Acegi Security. Es
posible reusar la configuracin existente para el soporte de WebServices.