1
Download componentes distribuidos - Departamento de Informática
Document related concepts
no text concepts found
Transcript
Tecnologías Web
Jose Emilio Labra Gayo
Departamento de Informática
Universidad de Oviedo
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
1
Esquema de la exposición
1.-Lenguaje XML
Definición y Vocabularios
2.-Arquitecturas Web
Cliente-servidor
Componentes distribuidos
Servicios Web
Otras arquitecturas: Agentes, P2P, etc.
3.-Web Semántica
Descripción de recursos
Ontologías
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
2
Internet
(60-80) Origen militar
Protocolos de comunicación (TCP/IP)
Seguridad ante ataques (múltiples servidores)
(80 – 95) Implantación académica
Protocolos de intercambio de información (FTP, SMTP, HTTP, ...)
Enorme biblioteca con material hipermedia
(95 – 00) Acceso comercial
Posibilidad de negocio Dinero!!
Boom comercial
La red es un ordenador gigante para hacer negocios
(00-) Crisis de las punto com
Historias de fracasos Lecciones aprendidas
Revisión de las arquitecturas tradicionales
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
3
Topologías
Transaccional
Grandes mainframes con terminales tontas
Bases de datos multiusuario transaccionales
El sistema garantizaba que una unidad de trabajo era completamente
procesada (o no) sin interferencias
Relacional
Aparición de ordenadores personales
Necesidad de comunicación Creación de LANs
Arquitecturas cliente-servidor (Múltiples clientes – un servidor)
Bases de datos relacionales (múltiples vistas de los datos)
Navegacional
Web = Múltiples clientes y múltiples servidores
Computación obicua (PDAs, moviles, coches,...)
Se requieren nuevos servicios de todo tipo
Actividades del cliente: navegar y descubrir servicios
Arquitecturas: anillos, comunidades, peer-to-peer, ...
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
4
Arquitectura Cliente/Servidor
Protocolo HTTP se basa en la arquitectura cliente/servidor (sin estado)
Cliente
Protocolo
http
Servidor
Visualizador
GET http://servidor.com/hola.html
http:/1.0 200 OK
<html>
<body>
Enlace a
<a href =“otro.html”>Otro</a>
</body>
</html>
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
5
Arquitectura Cliente/Servidor
Computación dinámica
Cliente
Servidor
Base Datos
Computación dinámica: La información se computa en el momento en que se
solicita (normalmente a partir de una base de datos)
Ejemplos: Información meteorológica, bursátil, estado de carreteras, etc.
Ventajas:
Flexibilidad: La información se adapta a las características del cliente
Eficiencia: No es necesario tener almacenada toda la información
Posibilidades
Computación en cliente
Computación en servidor
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
6
Arquitectura Cliente/Servidor
Computación en cliente
Etiqueta <object> permite incluir elementos computacionales
El visualizador reconoce el tipo de elemento y lo ejecuta
Sólo funciona con ciertos tipos de visualizadores (necesidad de plug-ins)
<p><OBJECT CLASSID=”juego.py" CODETYPE="application/x-python"
TITLE=”Juego lógico">
</OBJECT></p>
Applets = código Java compilado (Java utiliza la máquina virtual JVM)
Muchos visualizadores incluyen la JVM
La etiqueta <applet> no se recomienda en HTML 4.0 (deprecated)
<p><OBJECT CLASSID="java:juego.class"
Es preferible la utilización de <object>
Valoración
CODETYPE="application/java"
WIDTH=400 HEIGHT=250>
</OBJECT></p>
Menor carga computacional en el servidor
Menor carga en la red
Dependencia capacidades del cliente
Problema de seguridad para el cliente
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
7
Arquitectura cliente/servidor
Computación en cliente
La etiqueta <script> permite incluir guiones (programas interpretados por el
visualizador)
DHTML (Dynamic HTML): los programas pueden tener acceso a características del
visualizador
Lenguajes interpretados: JavaScript, VBScript, etc.
<p><SCRIPT type=“text/javascript”>
function onImg(name) { . . . }
function offImg(name) { . . . }
</SCRIPT>
</p>
Se pueden combinar con los eventos de navegación y con los formularios
Aplicaciones habituales: Modificar la presentación, validar entradas, etc.
<li><a href="About.html"
onMouseOver='onImg("About")'
onMouseOut ='offImg("About")'>
<img width="200" height="23” src="Images/About.gif"></a></li>
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
8
Arquitectura cliente/servidor
Computación en servidor
CGI (Common Gateway Interface)
Cuando el servidor reconoce que el fichero es un CGI, en lugar de transferir su
contenido, lo ejecuta como si fuese un programa y transmite al cliente los
resultados de la ejecución (salida estándar)
Al programa se le pasan parámetros con un formato determinado
CGI = Especificación formato E/S de dichos programas
Ejecución en servidor Transparencia para el cliente
El cliente sólo ve los resultados
Independencia del lenguaje de programación (C, Perl, Java, ...)
Lenguajes interpretados: Mediante llamada al intérprete. #! perl ...
#!/usr/bin/perl
código Perl que devuelve HTML
El programa CGI se arranca, se ejecuta, devuelve el resultado y acaba
Poco eficiente para ejecuciones repetidas
No mantiene el estado (se recurre a la utilización de cookies)
FastCGI utiliza un hilo por cada proceso
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
9
Arquitectura cliente/servidor
Computación en servidor
Código Incrustado en HTML
El servidor reconoce ciertas etiquetas y ejecuta el código que contienen
El servidor debe incluir un intérprete del lenguaje de programación utilizado
El programa tiene acceso a componentes del servidor
Lenguajes habituales:
PHP: Lenguaje específico (sintaxis similar a C, sin chequeo de tipos)
ASP (Microsoft): Utiliza Visual Basic
JSP (Sun): Utiliza lenguaje Java
<html><body>
<h1><?php . . . ?></h1>
...
</body></html>
Servlets: Programas Java compilados que se ejecutan en la JVM del servidor
Dependen del lenguaje Java
Disponibles en plataformas Java (compatibilidad?)
public class MiServlet extends GenericServlet {
public void service (ServletRequest rqt, ServletResponse rs)
throws ServletException, IOException {
...
}
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
10
Componentes Distribuidos
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
11
Componentes Distribuidos
Definiciones
Un componente software en una unidad de software independiente con
una interfaz explícita que puede utilizarse para componer aplicaciones
Un componente puede considerarse como una colección de objetos.
Un sistema de componentes distribuidos es un sistema de
componentes que pueden estar ejecutándose en diferentes máquinas.
Red
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
12
Componentes Distribuidos
Antecedentes
RPC (Remote Procedure Call): Permite la invocación a procedimientos
remotos
Concepto de Marshalling/Unmarshalling: Conversión de parámetros en
las llamadas
RMI (Remote Method Invocation): Permite la invocación a métodos de
objetos que residen en diferentes máquinas virtuales
Concepto de serialización/deserialización de objetos
Recolección de basura remota
Sistemas de Transacciones Distribuidos:
CICS (1977, IBM), TUXEDO (BEA)
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
13
Plataformas existentes
Microsoft COM y .NET
COM (1993) fue uno de los primeros modelos de componentes populares
DCOM (1995) = Componentes distribuidos mediante RPC
COM+ (2000) nueva generación con soporte transaccional
.NET Framework (2002) proporciona:
- Lenguaje intermedio común (CLR)
- Programación en Cliente (ASP.NET)
- Componentes de negocios (.NET Enterprise services)
- Bases de datos (ADO.NET)
- Servicios Web
- etc.
Similar a plataforma Java, aunque promueve la independencia del
Lenguaje (VB, C++, C#, etc.) e incluso de plataforma (Mono en Linux)
Prog. Declarativa mediante atributos vs Descriptor de despliegue
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
14
Plataformas existentes
CORBA
CORBA (Common Object Request Broker Architecture) fue desarrollado por
el OMG (Object Management Group) en 1989
Independencia de Lenguaje y de Plataforma
ORB (Object Request Broker): Intermediario de petición de objetos
Proporciona transparencia entre clientes e implementaciones
IDL (Interface Definition Language)
Lenguaje propio para definir interfaces
Conversiones desde/hacia otros lenguajes (C++, Java, etc.)
Numerosos servicios soportados: Nombres, comunicaciones asíncronas,
transacciones, concurrencia y seguridad
Reciente extensión para soportar componentes no muy utilizada
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
15
Plataformas existentes
EJBs
Sun Microsystems desarrolló un modelo de componentes distribuidos en
1997 denominado Enterprise Java Beans (EJBs)
Inspirados en CORBA, pero específico para Java
Arquitectura basada en un contenedor (servidor de aplicaciones) que ofrece
servicios de infraestructura: Persistencia, Concurrencia, Transacciones,
Seguridad, etc.
Posteriormente, se describirá en más detalle...
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
16
Arquitectura de Componentes Distribuidos
Contenedor
El contenedor o servidor de aplicaciones se encarga de proporcionar
servicios de infraestructura
La especificación de servicios puede ser:
Programática: Se ofrece acceso a APIs de servicios
Ejemplo: JDBC, JTA, JNDI, JMS, etc.
Declarativa: Mediante los descriptores de despliegue se definen
diversas políticas como la seguridad, las transacciones
El contenedor puede gestionar otros servicios:
Ciclo de vida de componentes, pool de recursos, servicios de
nombres, clustering, etc.
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
17
Arquitectura de Componentes Distribuidos
stub y skeleton
stub: Objeto que se forma en el cliente y se encarga de la comunicación
con el objeto remoto (patrón proxy)
skeleton: Objeto del lado del servidor que se comunica con el stub y el
objeto distribuido (patrón adapter)
Ventaja: Liberar al cliente y al objeto distribuido de tareas de
comunicación. Incluso pueden generarse automáticamente
Cliente
interfaz
remota
stub
Red
skeleton
Objeto
Distribuido
interfaz
remota
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
18
Arquitectura de Componentes Distribuidos
Middleware explícito
El Objeto distribuido se encarga de gestionar directamente los servicios del
contenedor: transacciones, persistencia, seguridad, etc.
Problema: Mayor complejidad en desarrollo de objeto distribuido
Contenedor
Cliente
Transacciones
interfaz
remota
stub
Red
skeleton
Objeto
Distribuido
interfaz
remota
Persistencia
Seguridad
...
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
19
Arquitectura de Componentes Distribuidos
Middleware implícito
Se utiliza un objeto interceptor que se encarga de gestionar servicios del
contenedor y llamar al objeto distribuido cuando sea necesario.
Ventaja: Libera al objeto distribuido de dichas tareas. Posibilidad de
creación automática del interceptor.
Contenedor
Cliente
Transacciones
interfaz
remota
stub
Red
Bases Datos
skeleton
Interceptor
interfaz
remota
Seguridad
Objeto
Distribuido
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
...
20
Arquitectura de Componentes Distribuidos
Creación de Objetos
La creación, eliminación y búsqueda de objetos distribuidos se realiza
mediante un objeto dedicado exclusivamente a dicha tarea (patrón
Factoría)
Cliente
Factoría
interfaz
factoría
interfaz
remota
stub
Contenedor
solicitud creación
Red
Transacciones
crea
Bases Datos
skeleton
Interceptor
interfaz
remota
Seguridad
Objeto
Distribuido
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
...
21
Servicios de Infraestructura
El contenedor se encarga de los servicios de infraestructura:
- Gestión de recursos
- Concurrencia
- Transacciones
- Mensajería Asíncrona
- Nombres
- Seguridad
etc.
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
22
Servicios de Infraestructura
Gestión de Recursos
Problema de Escalabilidad: Mantener eficiencia cuando el número de
clientes aumenta
Acciones:
Pooling de recursos: permite reutilizar varios recursos para diferentes
propósitos
Pooling de instancias: Los mismos Objetos son utilizados
por diferentes peticiones (evita la creación de nuevos objetos
para cada petición)
Gestión de Pasivación/Activación: Almacenar valores de un objeto en
memoria secundaria o recuperarlos.
Balance de carga: Distribuir peticiones a elementos con menor carga
Clustering: Utilizar varios servidores de aplicaciones
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
23
Servicios de Infraestructura
Concurrencia
La programación concurrente requiere técnicas de programación
avanzadas: bloqueos, recursos compartidos, sincronización, etc.
El contenedor puede realizar la gestión de la concurrencia, liberando al
desarrollador (limita creación explícita de hilos)
Aspectos:
Código Reentrante: Código que puede ser compartido por varios
procesos.
El mantenimiento de estado de objetos limita posibilidades.
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
24
Servicios de Infraestructura
Transacciones
Una transacción es un conjunto de tareas que se ejecutan como una
unidad
Propiedades ACID
(A)tomicidad: El trabajo se realiza en su totalidad o no se realiza
(C)onsistencia: Se mantiene la coherencia de los datos (aunque se
produzcan fallos)
(I)solation (Aislamiento): Cada transacción es autónoma y no depende
de otras
(D)urabilidad: Los resultados permanecen aunque haya fallos
Ejemplo: Comprar billete = Reservar plaza + Pagar
Interrupción comunicación tras la reserva...
Protocolo de consumación en 2 fases
Ejemplo: Viaje combinado (varios proveedores y fallo del último...)
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
25
Servicios de Infraestructura
Mensajería
MOM (Message Oriented Middleware) = Capa que se encarga de la
comunicación mediante mensajes
Acoplamiento fuerte: El emisor realiza una petición y queda a la espera de
la respuesta.
Problema: Fallo en comunicación o en receptor?
Acomplamiento débil: El emisor envía un mensaje y continúa trabajando
2 modelos:
Publica y subscribe
Punto a Punto
Suscriptor
Publicador
Tópico
Suscriptor
Receptor
Potencial
Emisor
Cola
Suscriptor
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
Receptor
Potencial
26
Servicios de Infraestructura
Persistencia
Persistencia consiste en el almacenamiento en memoria secundaria del
estado de los objetos
El contenedor puede encargarse de gestionar dicho almacenamiento
Aspectos:
Conversión modelo OO a modelo relacional
Consultas de datos
Rendimiento
En EJBs los beans de entidad son objetos con persistencia. 2
posibilidades:
Bean Managed Persistence (BMP)
Container Managed Persistence (CMP)
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
27
Servicios de Infraestructura
Trasparencia de Localización
El contenedor se encarga de la localización física del objeto distribuido
El cliente accede a través de un nombre lógico que el contenedor
resuelve.
La dirección exacta sólo es conocida por el contenedor
Facilita escalabilidad (ejemplo: clustering)
En EJBs, se utiliza JNDI para localizar/asociar nombres a recursos.
JNDI es un API común que permite la coexistencia de varios servicios
de directorios
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
28
Servicios de Infraestructura
Seguridad
Retos de seguridad:
1. Integridad: Garantizar que los documentos o mensajes, y sus
componentes no han sido alterados
2. Autentificación: Garantizar que una entidad (persona o sistema) es
quien dice que es.
3. Autorización: Determinar los privilegios asociados a una entidad
4. Confidencialidad: Garantizar que elementos no autorizados no pueden
acceder a documentos, mensajes o sus componentes
5. No repudiación: Prohibir que una entidad niegue haber recibido o
enviado un mensaje
En EJBs, el contenedor facilita gestión de autorización de forma
declarativa mediante roles.
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
29
Componentes Distribuidos:
Caso particular: Enterprise Java Beans
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
30
Plataformas existentes
EJBs
Desarrollados por Sun Microsystems como modelo de componentes de
negocio en servidor para Java
Se definen como:
Una especificación + Un conjunto de interfaces
Evolución:
EJB 1.0 (1997) Beans de sesión
EJB 1.1 (1999) Beans de entidad
EJB 2.0 (2001) Beans manejados por mensajes
EJB 2.1 (2003) Soporte para Servicios Web
EJB 3.0 (borrador) Meta-datos para facilitar desarrollo declarativo
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
31
Tipos de Beans
EnterpriseBean
Stateless
EntityBean
MessageDrivenBean
SessionBean
Stateful
CMP
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
BMP
32
Beans de Sesión
SessionBean
Los Beans de Sesión describen procesos de negocio
Ejemplos: ConsultarTarifa, ReservaViaje, etc.
2 tipos:
Sin estado: no almacenan información entre peticiones
Los beans sin estado facilitan la gestión de recursos del
contenedor (mayor rendimiento)
Con estado: permiten conversaciones de un cliente
Requieren serialización/deserialización de valores
Estado conversacional: el estado sólo se almacena durante
una sesión del cliente
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
33
Beans de Entidad
EntityBean
Los Beans de entidad describen elementos del dominio
Característica: Persistencia (son almacenables)
Ejemplos: Cliente, Avión, Aeropuerto, etc.
Aspectos:
Necesario declarar una clave primaria (puede ser objeto compuesto)
Conversión automática modelo OO a modelo Relacional
Manejo de Persistencia: Contenedor vs Componente
Incluye lenguaje de consultas EJB-QL similar a SQL
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
34
Beans Manejados por Mensajes
MessageDrivenBean
Describen procesos de negocio que son accedidos asíncronamente
Se subscriben y reaccionan a determinados eventos
Facilitan la integración de sistemas ya existentes
Ejemplos: ReservaViaje
No se declaran interfaces ya que sólo reaccionan a un método:
onMessage()
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
35
Interacción entre tipos de EJBs
Es posible invocar a Beans de sesión o a Beans manejados por mensajes
(MDBs) pero no a Beans de entidad
Firewall
Cliente
HTML
Servidor Web
Servdor Aplicaciones (Contenedor)
JSP
RMI-IIOP
Socio
Negocio
Servlet
SOAP
WSDL
UDDI
Aplicación
Applet
Cliente
CORBA
Cliente
Mensaje
EJB
Sesión
EJB
Entidad
EJB
Sesión
EJB
Entidad
EJB
MDB
EJB
Sesión
RMI-IIOP
IIOP
Mensaje
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
36
Partes de un EJB
Enterprise Bean: Objeto distribuido propiamente dicho
EJBObject: Interceptor
Objeto Home: Objeto Factoría
Interfaz Remote: Interfaz del Enterprise Bean (también puede ser local)
Interfaz Home: Interfaz del Objeto Home
Descriptor de Despliegue: Especificación declarativa del componente
Cliente
Contenedor
solicitud creación
Factoría
interfaz
factoría
interfaz
remota
stub
Red
Transacciones
crea
Bases Datos
Interceptor
skeleton
interfaz
remota
Seguridad
Objeto
Distribuido
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
...
37
Partes de un EJB
Enterprise Bean: Objeto distribuido propiamente dicho
EJBObject: Interceptor
Objeto Home: Objeto Factoría
Interfaz Remote: Interfaz del Enterprise Bean (también puede ser local)
Interfaz Home: Interfaz del Objeto Home
Descriptor de Despliegue: Especificación declarativa del componente
Cliente
Contenedor
solicitud creación
HomeObject
interfaz
Home
interfaz
remota
stub
Red
Transacciones
crea
Bases Datos
EJBObject
skeleton
interfaz
remota
Seguridad
Enterprise
Bean
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
...
38
Partes de un EJB
Enterprise Bean
El Bean de negocio (EnterpriseBean) es el objeto distribuido propiamente
dicho
Debe implementar la interfaz serializable así como la interfaz que
corresponda a su tipo:
SessionBean, MessageDrivenBean ó EntityBean
Implementa los métodos que se definan en la interfaz remota (métodos
públicos para los clientes) y en la interfaz Home (métodos de creación,
destrucción y búsqueda)
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
39
Partes de un EJB
EJB Object
El Objeto EJB (EJBObject) intercepta las invocaciones al EJB y gestiona los
servicios implícitos del contenedor
Forma parte del contenedor de EJBs y es generado automáticamente
Cliente
Contenedor
solicitud creación
HomeObject
interfaz
Home
interfaz
remota
stub
Red
Transacciones
crea
Bases Datos
EJBObject
skeleton
interfaz
remota
Seguridad
Enterprise
Bean
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
...
40
Partes de un EJB
Interfaz del Componente
Interfaz remota del componente = contrato entre cliente y Bean de negocio
Debe extender la interfaz javax.ejb.EJBObject
Se publican los métodos que se quieran invocar desde el cliente
La interfaz será implementada por
- Bean de negocio (implementado por el desarrollador)
- EJBObject (generado automáticamente por contenedor)
La interfaz remota es obligatoria en beans de sesión y de entidad
También puede definirse una interfaz local que se utiliza cuando el bean
se invoca de forma no remota
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
41
Partes de un EJB
Objeto Home
El objeto Home es la factoría para la obtención de referencias a EJBs (Patrón
Factory)
La factoría es la responsable de instanciar, buscar y destruir los objetos
Los objetos Home son autogenerados y forman parte del contenedor. El
desarrollador especifica solamente la interfaz Home
Cliente
Contenedor
solicitud creación
HomeObject
interfaz
Home
interfaz
remota
stub
Red
Transacciones
crea
Bases Datos
EJBObject
skeleton
interfaz
remota
Seguridad
Enterprise
Bean
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
...
42
Partes de un EJB
Interfaz Home
Para generar los objetos Home, el desarrollador debe aportar una interfaz
java que extienda la interfaz javax.ejb.EJBHome
En esta interfaz se definen los métodos para crear,destruir y localizar
EJBs
Cliente
Contenedor
solicitud creación
HomeObject
interfaz
Home
interfaz
remota
stub
Red
Transacciones
crea
Bases Datos
EJBObject
skeleton
interfaz
remota
Seguridad
Enterprise
Bean
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
...
43
Partes de un EJB
Interfaces Locales
Permiten invocar al EJB como si se tratara de un objeto local.
Solventan el problema de la sobrecarga cuando el EJB se ejecuta en la
propia máquina del cliente.
El Objeto Local realiza las tareas de middleware que le corresponderían al
EJB Object, y luego le cede el control al bean de negocio.
De esta forman, se evitan las tareas propias a la invocación remota
(stubs, serialización, etc.).
Son opcionales
Extienden la interfaz javax.ejb.EJBLocalObject y su factoría
javax.ejb.EJBLocalHome
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
44
Partes de un EJB
Descriptores de Despliegue
Especifica las propiedades y servicios del EJB de forma declarativa
(sintaxis XML)
Describe cómo ha de ser desplegado el EJB en el contenedor, y cómo ha
de ser manejado:
Ciclo de vida
Sistema de persistencia
Control de transacciones
Servicios de seguridad.
Es un fichero XML: ejb-jar.xml
Habrá uno por paquete de despliegue (fichero jar) y puede declarar varios
EJBs de distintos tipos
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
45
En resumen...
Pasos para crear un EJB
El desarrollador debe definir:
- interfaz del componente (remota y/o local)
- interfaz Home (remota y/o local)
- Clase de negocio y clave primaria (para beans de entidad)
- Descriptor de Despliegue (parte declarativa,en XML)
Cliente
Contenedor
solicitud creación
HomeObject
interfaz
Home
interfaz
remota
stub
Red
Transacciones
crea
Bases Datos
EJBObject
skeleton
interfaz
remota
Seguridad
Enterprise
Bean
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
...
46
Necesario para
que el
contenedor
implemente el
EJBObject
Ejemplo de EJB de Sesión
Interfaz del Componente
public interface Suma extends EJBObject {
public int suma(int a, int b) throws java.rmi.RemoteException;
}
Método que
va a ser
invocado
Necesario para
todos los
métodos de
objetos
distribuidos
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
47
Necesario para
que el
contenedor
implemente el
EJBHome
Ejemplo de EJB de Sesión
Interfaz Home
public interface SumaHome extends EJBHome {
Suma create()
throws javax.ejb.CreateException,java.rmi.RemoteException;
}
Método que se
invocará al crear
el EJB
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
48
Ejemplo de EJB de Sesión
Objeto de Negocio
public class SumaBean implements SessionBean {
Bean de sesión
public void ejbActivate() throws EJBException, RemoteException { }
public void ejbPassivate() throws EJBException, RemoteException { }
public void ejbRemove() throws EJBException, RemoteException { }
public void setSessionContext(SessionContext arg0) throws EJBException,
RemoteException { }
public void ejbCreate() throws javax.ejb.CreateException { }
public int suma(int a, int b) { return (a+b); }
Métodos que
controlan el ciclo
de vida (en este
caso, no hacen
nada)
}
Implementación
del método
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
49
Ejemplo de EJB de Sesión
Descriptor de Despliegue (1)
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<ejb-jar>
<enterprise-beans>
Declara las
<session>
clases e
<ejb-name>ejbSuma</ejb-name>
interfaces del
<home>com.suma.ejbSuma.SumaHome</home>
EJB
<remote>com.suma.ejbSuma.Suma</remote>
<ejb-class>com.suma.ejbSuma.SumaBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
Indica que es sin
</session>
estado
</enterprise-beans>
Delega la
...
gestión
transaccional
al contenedor
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
50
Ejemplo de EJB de Sesión
Descriptor de Despliegue (y 2)
<assembly-descriptor>
<security-role><role-name>everyone</role-name></security-role>
<method-permission>
Especifica política de
<role-name>everyone</role-name>
seguridad (todo el mundo
puede invocar todos los
<method>
métodos)
<ejb-name>ejbSuma</ejb-name><method-name>*</method-name>
</method>
</method-permission>
Especifica política de
transacciones (el contenedor
<container-transaction>
de crear una transacción si no
<method>
existe)
<ejb-name>ejbSuma</ejb-name><method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
51
Ejemplo de EJB de Sesión
Código Cliente
import com.suma.ejbSuma.SumaHome;
public class hazSuma {
public static void main(String[] args) {
Buscar objeto Home en
JNDI
try {
Context jndiContext = new InitialContext();
Object ref = jndiContext.lookup("Suma");
Convertir referencia a
SumaHome home = (SumaHome)
objeto Home
PortableRemoteObject.narrow(ref,SumaHome.class);
Suma s = home.create();
System.out.println("2 + 3 = " + s.suma(2,3));
Crear objeto EJB a partir
} catch (Exception e) {
del Home
System.out.println("Exception: " + e);
}
Invocar método
}
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
52
EJBs
Valoración
Facilita el desarrollo de aplicaciones Web liberando al programador de la
gestión de tareas complicadas: gestión de recursos, transacciones,
seguridad, etc.
Favorece una mayor separación entre lógica de negocio y presentación
Gran penetración en el mercado: numerosas implementaciones
comerciales y libres
Permite la integración entre tecnologías de última generación y
tecnologías ya existentes (legacy systems)
Soporte a la escalabilidad del sistema desde el principio
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
53
EJBs
Valoración
Múltiples capas intermedias
Puede perjudicar depuración y rendimiento
Tecnología en movimiento, necesidad de consolidación de algunas
especificaciones
No todas las aplicaciones requieren EJBs. Ejemplos:
- Aplicaciones basadas únicamente en interfaz de usuario accediendo
a base de datos (sin lógica de negocio)
- Aplicaciones muy simples (prototipos), en algunos casos puede ser
como matar pulgas a cañonazos...
- Limitaciones de EJBs, se requiere utilización de código nativo o
programación multi-hilo
- Se utilizan otras tecnologías alternativas: .NET o CORBA...
Programación declarativa mediante lenguajes no convencionales:
vocabularios XML, lenguaje EJB-QL, etc...
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
54
Bibliografía
Libros:
Mastering EJBs de Ed Roman
EJB Design Patterns de Floyd Marinescu
Enterprise Java Beans de Richard Monson-Haefel
URLS:
java.sun.com/products/ejb/ Especificaciones y otros documentos
www.theserverside.com: Documentos y Forums
www.jguru.com EJB FAQ
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
55
Servicios Web
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
56
Antecedentes
Intercambio de XML
XML-RPC
Adapta RPC para envío de mensajes en formato XML
Semilla de SOAP
XMOP (XML Metadata Object Persistence)
Protocolo de interacción de objetos
ebXML (electronic business XML)
Proyecto más ambicioso
Intercambio de mensajes, gestión y recuperación de errores,
calidad de servicio, seguridad, etc.
Reciente acuerdo para adoptar SOAP como parte de su
infraestructura
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
57
Servicios Web
Posible definición
Aplicaciones auto-contenidas, auto-descritas que
pueden ser publicadas, localizadas e invocadas a
través de la Web
Una vez desarrolladas, otras aplicaciones (y otros
servicios Web) pueden descubrirlas e invocar el
servicio dado
Petición
Internet
Servicio
Web
Respuesta
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
URL
58
Servicios Web
Factores que influyeron en su aparición
Computación Distribuida: RPC, CORBA, RMI, DCOM
Sistemas fuertemente acoplados
Integración de aplicaciones: EAI (Enterprise Application
Integration)
Reacción frente a sistemas ERP monolíticos
Aparición de XML
Adopción por principales industrias
XML-RPC
Necesidad de intercambios B2B
Sistemas de integración EDI, RosettaNet, ebXML
Comercio electrónico y burbuja de Internet
Necesidad de nuevas fórmulas
Microsoft vs. Java
Compatibilidad
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
59
Servicios Web
Objetivos
Independencia del lenguaje y de la plataforma
Separación de especificación de la implementación
Interoperabilidad
Utilización de estándares: XML, SOAP, WSDL, UDDI...
Acoplamiento débil: Sistemas basados en mensajes
Interacciones síncronas y asíncronas
A través de Internet
Sin control centralizado
Utilización de Protocolos establecidos
Consideraciones de seguridad
Modularidad y Reusabilidad de servicios
Escalabilidad: Aplicaciones uno-a-uno frente a uno-a-muchos
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
60
Servicios Web
Principales Vocabularios
Protocolo de transporte
HTTP/HTTPs (principalmente)
Codificación de datos y mensajes
SOAP (Simple Object Access Protocol)
Descripción del servicio
WSDL (Web Service Description Language)
Búsqueda y localización de servicios
UDDI (Universal Discovery, Description and Integration)
Otra definición
Programas accesibles en Internet que esponen su funcionalidad
recibiendo/enviando mensajes SOAP a través de HTTP(s) y describen su
interfaz en WSDL
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
61
Servicios Web
Principales Vocabularios
UDDI
HTTP
petición SOAP (XML)
Implementación
servicio Web
respuesta SOAP (XML)
Consumidor
servicio Web
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
62
Servicios Web
Arquitectura de Aplicaciones
Dispositivo del
Cliente
Base Datos
HTML
XML
XSLT
WML
SOAP
Servicio Web
VoiceXML
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
63
Servicios Web
Arquitectura de Aplicaciones
Facturación
SOAP
SOAP
XML
Internet
SOAP
SOAP
Gestión de
Usuarios
Aplicación
del usuario
SOAP
Conversión de
Monedas
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
64
SOAP
Evolución
SOAP: Define el formato de los mensajes
SOAP = Simple Object Access Protocol
Aunque tiene poco de objetos...
Evolución
Desarrollado a partir de XML-RPC
SOAP 1.0 (1999), 1.1 (2000), 1.2 (2002)
Participación inicial de Microsoft
Adopción posterior de IBM, Sun, etc.
Aceptación industrial
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
65
SOAP
Formato
Envelope
Header
Header Key
Header Key
Body
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
66
SOAP
Ejemplo
<?xml version=‘1.0’ ?>
<soap:Envelope xmlns:soap=‘http://www.w3.org/2001/12/soap-envelope’
xmlns:p =‘http://www.mafia.it/pizzas’>
<soap:Header>
<p:prioridad> urgente </p:prioridad>
<p:origen>[email protected]</p:origen>
</soap:Header>
<soap:Body>
<p:encargo>
<p:pizza nombre=‘Margarita’>
<p:tamaño>familiar</p:tamaño>
<p:comentario>con mucho queso</p:comentario>
</p:pizza>
</p:encargo>
</soap:Body>
</soap:Envelope>
Cabecera
Contenido
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
67
SOAP
Formato general
SOAP especifica el formato de mensajes
Es independiente del protocolo de transporte
Aunque se define un enlace (binding) con HTTP
envelope: Pueden especificarse datos globales
(codificación, espacios de nombres, etc.)
Contiene: header (opcional) + body (obligatorio)
body contiene datos en formato XML
header contiene meta-información
Extensiones obligatorias/opcionales
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
68
SOAP
Header
header incluye información sobre el mensaje
Facilita futuras extensiones
Seguridad, transacciones, etc.
Información procesable por intermediarios
Atributos pre-definidos
mustUnderstand (true/false)
Si el elemento no puede procesar dicha información devuelve
un error
actor
Indica qué nodo debe procesar la información
Si no aparece, debe procesarla el nodo receptor final
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
69
SOAP
Fault
fault: Formato predefinido de mensajes de error
Se incluye el elemento fault en el cuerpo
Subelementos predefinidos
faultcode: Código del error
Predefinidos: VersionMismatch,
MustUnderstand, DTDNotSupported,
DataEncodingUnknown, Sender, Receiver
faultstring: Explicación legible por personas
detail: Información específica de la aplicación
Puede contener elementos XML
faultactor: URI del nodo que causó el error
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
70
SOAP
Fault
<?xml version=‘1.0’ ?>
<soap:Envelope xmlns:soap=‘http://www.w3.org/2001/12/soap-envelope’>
<soap:Body>
<soap:Fault>
<faultcode>soap:Receiver’</faultcode>
<faultstring>Error al procesar</faultstring>
<detail>
<p:detalles xmlns:p=‘http://www.mafia.it/pizzas’>
<mensaje>La pizza Barbacoa no puede llevar
tanto queso</mensaje>
</p:detalles>
</detail>
</p:pizza>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
71
SOAP
Codificación
Atributo encodingStyle define reglas de codificación
Algunos tipos básicos predefinidos
Enteros, cadenas, flotantes
Contiene reglas específicas para:
Estructuras
Arrays
Referencias
Se complementa con XML Schemas
Pueden definirse otros sistemas de codificación
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
72
SOAP
Codificación
Tipos básicos
<?xml version=‘1.0’ ?>
<soap:Envelope xmlns:soap=‘http://www.w3.org/2001/12/soap-envelope’
xmlns:xsi=“http://www.w3.org/2001/XMLSchema”
encodingStyle=‘http://www.w3.org/2001/12/soap-encoding’>
<soap:Body>
<p:pizza>
<p:código xsi:type=‘soap:int’>234</p:comida>
<p:tamaño xsi:type =‘soap:string’>familiar</p:tamaño>
</p:pizza>
</soap:Body>
</soap:Envelope>
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
73
SOAP
Codificación
Estructuras
struct Pizza {
int código;
string nombre;
};
<Pizza xmlns=‘cualquier_URI’>
<código>234</código>
<nombre>Barbacoa</nombre>
</Pizza>
Arrays
<pizzas xsi:type=‘soap:Array’ soap:arrayType=‘p:Pizzas[2]’>
<pizza> <código>234</código>
<nombre>Barbacoa</nombre>
</pizza>
<pizza><código>237</código>
<nombre>Barbacoa</nombre>
</pizza>
</pizzas>
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
74
SOAP
Codificación
Arrays parciales
<pizzas xsi:type=‘soap:Array’ soap:arrayType=‘p:Pizzas[10]’
soap:offset=‘[4]’>
5º y 6º
<pizza> <código>234</código>
<nombre>Barbacoa</nombre>
elemento
</pizza>
<pizza><código>237</código>
<nombre>Barbacoa</nombre>
</pizza>
</pizzas>
<pizzas xsi:type=‘soap:Array’ soap:arrayType=‘p:Pizzas[10]’>
<pizza soap:position=‘2’> <código>234</código>
2º y 5º
<nombre>Barbacoa</nombre>
</pizza>
elemento
<pizza soap:position=‘5’ ><código>237</código>
<nombre>Barbacoa</nombre>
</pizza>
</pizzas>
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
75
SOAP
Ejemplo con HTTP
POST /Suma/Service1.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: longitod del mensaje
SOAPAction: "http://tempuri.org/suma"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<suma xmlns="http://tempuri.org/">
<a>3</a>
<b>2</b>
</suma>
</soap:Body>
</soap:Envelope>
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
76
SOAP
Ejemplo de respuesta
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: longitud del mensaje
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<sumaResponse xmlns="http://tempuri.org/">
<sumaResult>5</sumaResult>
</sumaResponse>
</soap:Body>
</soap:Envelope>
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
77
WSDL
Evolución
WSDL (Web Services Description Language)
Describe:
Qué puede hacer el servicio
Dónde reside
Cómo invocarlo
Vocabulario basado en capas
Es posible concentrarse en una capa cada vez
Evolución: Iniciativa conjunta de Ariba, IBM y Microsoft
(2001) Propuesto a W3C como recomendación (WSDL 1.1)
(2003) En desarrollo WSDL 2.0
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
78
WSDL
Estructura del documento
definitions
types
Tipos de datos usados en los mensajes (XML Schema)
message
Definición abstracta de los datos transmitidos.
portType
Conjunto de operaciones abstractas
binding
Protocolo concreto y especificaciones de los
formatos de las operaciones del mensaje
Especifica una dirección para el enlace definiendo
un único punto de destino
port
service
Colección de puntos de destino
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
79
WSDL
Ejemplo
<?xml version="1.0" encoding="utf-8" ?>
<definitions xmlns:s=. . .
<types>
<s:schema
<s:element name="suma">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="a" type="s:int" />
<s:element minOccurs="1" maxOccurs="1" name="b" type="s:int" />
</s:sequence>
</s:complexType>
</s:element>
...
<message name="sumaSoapIn">
<part name="parameters" element="s0:suma" />
</message>
...
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
80
WSDL
Ejemplo
...
<portType name="ServicioSumaSoap">
<operation name="suma">
<input message="s0:sumaSoapIn" />
<output message="s0:sumaSoapOut" />
</operation>
</portType>
...
<binding name="ServicioSumaSoap" type="s0:ServicioSumaSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<operation name="suma">
<soap:operation soapAction="http://tempuri.org/suma" style="document" />
<input> <soap:body use="literal" /> </input>
<output> <soap:body use="literal" /> </output>
</operation>
</binding>
<service name="ServicioSuma">
<port name="ServicioSumaSoap" binding="s0:ServicioSumaSoap">
<soap:address location="http://localhost/Suma/Service1.asmx" />
</port>
</service>
</definitions>
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
81
UDDI
Definición
UDDI (Universal Discovery, Description and Integration)
Consorcio formado por IBM, Hp, Sun, Microsoft, Oracle, etc.
UDDI 1.0 (2000) Fundación del registro
UDDI 2.0 (2001) Alineación con estándares y taxonomía de servicios
más flexible
UDDI 3.0 (2002) Interacción de implementaciones públicas y privadas
2 partes
Descripción de negocios
Páginas blancas (información de contacto)
“
amarillas (información de la industria)
“
verdes (información técnica y
especificaciones)
Registro de servicios
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
82
UDDI
Definición
Provider: Información sobre la
entidad que ofrece el servicio
tModel: Descripciones de
especificaciones de servicios
0…n
Service: Información
descriptiva sobre una familia
particular de ofertas
0…n
Binding contiene referencias
a tModels. Estas referencias
declaran las especificaciones
del interfaz
0…n
Binding: Información técnica
sobre un punto de entrada a un
servicio
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
83
UDDI
Funcionamiento
1.
El desarrollador construye un
servicio para convertir
monedas
servicio Web
conversión
2.
5.
El usuario construye una
aplicación que consuma el
servicio Web directamente
SOAP
El desarrollador registra y
clasifica el servicio Web
Servicios
UDDI
3.
El usuario pregunta a UDDI por
servicios de conversión
4.
El usuario determina el servicio
de conversión más apropiado
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
84
Utilización de un Servicio Web
Ejemplos
Consltar listados de servicios Web
www.xmethods.net
www.bindingpoint.com
Pueden
ejecutarse
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
85
Utilización de servicios Web
Ejemplos: Google
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
86
Utilización de servicios Web
Ejemplos: Amazon
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
87
Implementación de Servicios Web
Posibilidades
Java
APIs de Sun: JAXRPC, JAXM, SAAJ,
Librerías de Apache: Axis
Microsoft .NET
ASP.NET para C#, VBasic, etc.
MS SOAP Toolkit
Otros:
SOAP::Lite (Perl), NuSOAP (PHP), Axis (C++)
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
88
Implementación de Servicios Web
APIs de Java
SAAJ (SOAP with Attachments API for Java)
Tratar mensajes SOAP como objetos Java
JAX-RPC (Java API for XML based RPC)
Modelo de programación
Conversión WSDL/XML Java
Manejo de SOAP y SOAP con Attachments
API para cliente: WSDL, Invocación y proxy dinámico
JWSDL
Acceso a descripciones WSDL
JAXR (Java API for XML Registries)
Acceso a registros de servicios Web (UDDI)
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
89
Implementación de Servicios Web
Apache Axis
Sucesor de Apache SOAP (software abierto)
Soporta JAX-RPC y SAAJ
Arquitectura flexible y extensible
Necesita servidor de aplicaciones (por ejemplo Tomcat)
Validar la instalación:
http://localhost:8080/axis
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
90
Implementación de Servicios Web
Creación de un Cliente
WSDL
Descripción
del servicio
adaptador
WSDL2Java
stubs
clases Java
generadas
javac
cliente
código
cliente
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
91
Implementación de servicios Web
Creación de un cliente
1.- Acceder a WSDL
http://petra.euitio.uniovi.es/~labra/ws/suma.php?wsdl
Almacenar como suma.wsdl
2.-Generar stubs
> java org.apache.axis.wsdl.WSDL2Java -p suma suma.wsdl
3.- Comprobar clases generadas
> ls suma/*.java
ServicioSuma.java
ServicioSumaBindingStub.java
ServicioSumaLocator.java
ServicioSumaPortType.java
4.- Compilar clases generadas
> javac suma/*.java
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
92
Implementación de servicios Web
Creación de un cliente
ClienteSuma.java
import suma.*;
public class ClienteSuma {
public static void main(String[ ] args) throws Exception {
try {
ServicioSumaLocator loc = new ServicioSumaLocator();
ServicioSumaPortType p = loc.getServicioSumaPort();
System.out.println("2 + 3 = " + p.suma(2,3));
} catch (Exception e) {
System.err.println("Excepción: " + e);
}
}
}
4.- Compilar cliente
> javac CienteSuma.java
5.-Ejecutar cliente
> java ClienteSuma
2+3=5
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
93
Implementación de un servicio Web
Creación de un cliente
Ejercicio: Consultar temperatura del aeropuerto de Avilés...
http://live.capescience.com/wsdl/GlobalWeather.wsdl
ClienteTemp.java
public class ClienteTemp {
public static void main(String args[]) throws Exception {
try {
GlobalWeather_ServiceLocator loc = new GlobalWeather_ServiceLocator();
GlobalWeather_Port s = loc.getGlobalWeather();
System.out.println("Temperatura en Aeropuerto de Asturias: " +
s.getWeatherReport("LEAS").getTemperature().getString());
} catch (Exception e) {
System.err.println("Excepción: " + e);
}
}
}
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
94
Implementación de Servicios Web
Creación de un Servicio Web
Método simple: JWS
Suma.jws
public class Suma {
public int suma(int a, int b) {
return a + b;
}
}
Almacenar en:
<TOMCAT>\webapps\axis\Suma.jws
http://localhost:8080/axis/Suma.jws
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
95
Implementación de Servicios Web
Creación de un Servicio Web
Utilizar JWS tiene sus limitaciones
Debe disponerse del código fuente
Los errores aparecen en tiempo de ejecución
La clase no puede tener package
Sólo se pueden transferir datos simples
No se puede configurar el servicio
Método riguroso: WSDD (Web Service Deployment Descriptor)
Permite desplegar (deploy) y quitar (undeploy) servicios
Pueden utilizarse servicios compilados
Control de las Conversiones de tipos
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
96
Implementación de Servicios Web
Creación de un Servicio Web
ServSuma.java
package ServSuma;
public class ServSuma {
public int suma(int a, int b){
return (a + b);
}
}
1.- Compilar servicio
> javac ServSuma.java
2.-Copiar ServSuma.class a
<TOMCAT>/webapps/WEB-INF/classes/ServSuma/ServSuma.class
También puede dejarse un .jar en WEB-INF/lib
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
97
Implementación de Servicios Web
Creación de un Servicio Web
deploy.wsdd
<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="ServSuma" provider="java:RPC">
<parameter name="className" value="ServSuma.ServSuma"/>
<parameter name="allowedMethods" value="*"/>
</service>
</deployment>
3.- Desplegar servicio
> java org.apache.axis.client.AdminClient deploy.wsdd
Processing file deploy.wsdd
<Admin>Done processing</Admin>
Puede ser necesario reiniciar servidor
4.- Acceder a
http://localhost:8080/axis/services/ServSuma
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
98
Implementación de Servicios Web
Otras características de Axis
Invocación dinámica
Dynamic Invocation Interface
Invocación mediante Proxy
Conversión Java2WSDL
Permite generar WSDL a partir de clases/interfaces
Java
Generación de ficheros WSDD para deploy/undeploy
Seguridad
Otros protocolos de transporte
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
99
Interoperabilidad
Acceso desde .NET a servicio en Java
1.- Acceso a WSDL y creación de Stubs (o proxys)
> wsdl http://localhost:8080/axis/services/ServSuma?wsdl
...
Writing file 'C:\usr\labra\cursos\XMLInnova\WebServ\ClienteNet\ServSumaService.cs'.
En algunas versiones es necesario editar ServSumaService.cs y modificar
this.URL para que incluya el puerto 8080
2.- Compilación de proxys
> csc /t: library ServSumaService.cs
using System;
3.- Creación de cliente
cliente.cs
4.- Compilación de cliente
public class ClienteSumaNet {
public static void Main() {
ServSumaService srv = new ServSumaService();
Console.WriteLine("2 + 3 = {0}", srv.suma(2,3));
}}
> csc cliente.cs /reference:ServSumaService.cs
5.- Ejecución
> cliente
2+3=5
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
100
Interoperabilidad
Servicios Web en .NET
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
101
Interoperabilidad
Servicios Web en .NET
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
102
Interoperabilidad
Servicios Web en .NET
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
103
Interoperabilidad
Servicios Web en PHP
suma.php
<?php
include "nusoap.php";
$namespace = "http://petra.euitio.uniovi.es/~labra/ws/suma.php?wsdl";
$servidor = new soap_server;
$servidor -> configureWSDL ("ServicioSuma", $namespace,
"http://petra.euitio.uniovi.es/~labra/ws/suma.php");
$servidor -> wsdl -> schemaTargetNamespace = $namespace;
$servidor -> register ('suma', array ('a' => 'xsd:float', 'b' => 'xsd:float'),
array ('return' => 'xsd:float'),
'http://petra.euitio.uniovi.es/~labra/ws/suma.php', '', '', '', '' );
$servidor -> service ($HTTP_RAW_POST_DATA);
function suma ($a, $b) {
if (!$a || !$b) {
return new soap_fault ("Client", "", "Se necesitan dos argumentos");
}
if ((gettype ($a) != "integer" && gettype ($a) != "double") ||
(gettype ($b) != "integer" && gettype ($b) != "double")) {
return new soap_fault ("Client", "", "El tipo debe ser entero o real");
}
return $a + $b;
}
?>
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
104
Arquitecturas Orientadas a Servicios
Definición
SOA = Service Oriented Architectures
Construcción de aplicaciones partiendo de interfaces, con el objetivo de
desarrollar agentes débilmente acoplados que se comunican entre sí.
Ejemplo
Un tocadiscos es un servicio...
...le pasamos un disco y suena música
En POO se encapsulan datos y procesos
...el disco incluiría su tocadiscos...
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
105
Arquitecturas Orientadas a Servicios
Modelo tradicional
Datos
IVA
Algoritmos
IVA
Algoritmos
Envío
Aplicación
Integrada
Compilación
Aplicación
Tiempo de
construcción
Fuente
datos
datos
envío
Tiempo de
configuración
Tiempo de
ejecución
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
106
Arquitecturas Orientadas a Servicios
Modelo Orientado a Servicios
servicio
cálculo
IVA
Aplicación
Compilación
Aplicación
Integrada
servicio
gastos
envío
Tiempo de
construcción
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
Tiempo de
ejecución
107
Arquitecturas Orientadas a Servicios
Principales características
Importancia de las interfaces
Descripción rigurosa de interfaces (legibles por máquinas)
Recomendación: Partir de WSDL + XML Schema
Modelos débilmente acoplados
Sistemas de comunicación asíncrona
Estilo documento vs. estilo RPC
Colas de mensajes
Ej. Solicitar un libro
Interoperabilidad
Independencia de lenguajes y plataformas
Adaptación de arquitecturas ya existentes
Utilización de estándares
Modelo REST vs SOAP
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
108
Servicios Web
Retos
Gestión de servicios Web
WSDM - Web Services Distribution Management
Agregación de servicios
Ejemplo. Reserva de avión + hotel
Evolución de los servicios
Cambio de la Interfaz
Modelización de procesos de negocios
BPEL - Business Process Execution Language
Contratos, facturación
¿Quién gana dinero? ¿Qué pasa cuando algo
falla?
Seguridad y fiabilidad
XML Security
Calidad de servicios
Tiempos de respuesta, soporte, monitorización, etc.
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
109
Servicios Web
Mitos...
Web para ordenadores?
... no confundir con Web semántica
Nueva arquitectura?
...en realidad, usan arquitecturas ya existentes
Obligarán a cambiar de plataformas?
... es posible incorporar sistemas heredados
Lengua universal para las aplicaciones?
...no proporcionan semántica, sólo una sintaxis común
Nuevo modelo de negocios?
...el negocio es el servicio, no la forma en que se suministra
Ventaja competitiva?
...peligro de adoptar tecnología inmadura.
Enlace automático a socios desconocidos?
...modelo de negocio no desarrollado
Estándares bien definidos?
...algunos se están desarrollando y otros ni siquiera se han
desarrollado
Es lo mismo que .NET?
...Independiente de plataforma...
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
110
Más información
www.wsindex.org
Información de servicios Web y Web semántica
www.searchwebservices.com
Portal de servicios Web orientado a empresas
www.webservices.org
Sobre servicios Web
www.xmethods.net
Lista de servicios Web
www.soapware.org
Portal sobre SOAP
www.w3c.org/2002/ws
Especificaciones relacionadas con servicios Web
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
111
Otras Arquitecturas:
Agentes
Sistemas Colaborativos
Peer-to-peer
Grid computing
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
112
Sistemas de Agentes
Código móvil: Aplicaciones globales que pueden intercambiar unidades
activas de comportamiento (computaciones), no simplemente datos.
Modelos:
Evaluación remota: Código que se envía a un ordenador remoto para
que lo ejecute
Código bajo demanda: Código que se va obteniendo y ejecutando a
medida que se necesita (JIT)
Agentes móviles: Procesos que pueden suspender su ejecución y
migrar a otro ordenador en el que continúan la ejecución
Movilidad débil: El código se mueve a otro entorno, se enlaza y se
ejecuta (no se transmite el estado).
Movilidad fuerte: Un hilo puede mover su código y estado de la
ejecución a un sitio diferente y continuar la ejecución al llegar
Movilidad total: Se mueve el estado completo, incluidas las pilas de
ejecución de todos los hilos migración transparente
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
113
Sistemas de Agentes: Características
El agente es un programa y necesita un entorno de ejecución (servidor que
suministra recursos)
Autonomía: El código se ejecuta independientemente del usuario que lo
crea
Orientación a un objetivo (goal oriented): El código persigue un objetivo y
para ello puede actuar sobre el entorno en el que se ejecuta
Reactividad: El agente siente los cambios en el entorno y actúa de acuerdo
a ellos
Adaptatividad/aprendizaje: El agente actúa de acuerdo a su experiencia
Autocontenido: El agente posee todos los datos que necesita para
ejecutarse y migrar
Coordinación: Los agentes pueden coordinarse entre sí para realizar una
actividad compleja
Desconexión: El agente puede seguir ejecutándose aunque el usuario (o
dueño) esté desconectado
Puede decidir dormir, y reestablecer conexión periódicamente
El usuario puede traer de vuelta al agente cuando lo desea
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
114
Sistemas de Agentes: Tecnologías
Tecnologías Java
Mole,
Concordia,
Mobile Objects and Agents
Voyager
IBM Aglets
Agent Communication Language (ACL)
Vocabulario
KIF (Knowledge Interchange Language)
KQML (Knowledge Query Manipulation Language)
Diversas arquitecturas:
InteRRAP, GRATE, ADEPT
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
115
Sistemas de Agentes: Valoración
Ventajas
Los agentes pueden reducir el tráfico en la red
No se requiere que el usuario esté conectado para que la computación
se ejecute
Pueden utilizarse como intermediarios (proxy)
Los computadores de los usuarios no requieren gran capacidad
(posible aplicación: PDAs)
Desventajas
Dependencia de la red, no siempre se reduce el tráfico
Se requiere independencia de plataforma Código no optimizado
Seguridad Requiere chequeo de código antes de ejecución
Tolerancia a Fallos, ¿y si el servidor que ejecuta el código se cae?
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
116
Sistemas Colaborativos
La Web nació como una tecnología colaborativa
Visualización / Creación de contenidos
Ejemplo: Amaya
Protocolo HTTP
Sistemas de Edición compartida: Sistemas Wiki, Weblogs, Blogs
Mensajería Instantánea: Jabber
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
117
Sistemas peer-to-peer
Sistemas de intercambio de información y/o servicios entre nodos de una
red con la misma capacidad o papel.
Los ordenadores se intercambian el papel de cliente/servidor
Aplicaciones:
música (Napster, Soul seek),
Vídeos y otros archivos (Kazaa)
Mensajes personales (ICQ)
Ciclos computacionales
SETI@home: Search for extraterrestiral Intelligence
BOINC: Berkeley Open Infraestructure for Network Computing
Colecciones de documentos (LOCKSS), etc.
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
118
Sistemas peer-to-peer
Topologías
Servidor de Directorios Centralizado (sistemas híbridos)
Algunos nodos tienen carácter especial (servidores de directorio)
Ejemplos: Napster, Pointerra, OpenNap
Problemas:
Punto simple de fallo (si el servidor de directorio falla, la aplicación p2p
falla). Soluciones mediante granjas de servidores.
Cuello de botella (gran base de datos si hay muchos usuarios)
Problemas de copyright: Si los servidores pertenecen a una compañía, ésta
puede tener problemas legales.
peers
Servidor directorios
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
119
Sistemas peer-to-peer
Topologías
Directorio Descentralizado (super-peer)
Se utilizan líderes de grupo (super-peers)
Los super-peers están a su vez conectados entre sí como peers
Se requiere uno (o más) nodos de arranque
Asignan los líderes de grupo
Los peers están enlazados virtualmente
Ejemplos: KaZaA/FastTrack
Problemas:
Protocolos complejos
Falta de simetría
Problemas si fallan los super-peers
Posibles cuellos de botella
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
120
Sistemas peer-to-peer
Topologías
Sistemas peer-to-peer puros:
Todos los nodos tienen la misma capacidad
Sistema de Inundación de preguntas (query flooding):
Las peticiones se transmiten a los nodos vecinos y éstos a su vez
a otros nodos.
Problemas de escalabilidad
Ejemplos:
GNUTella
Freenet: Sistemas Intercambio seguro y anónimo
Se intenta proteger la identidad de la información
pregunta
unirse
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
121
Computación Colaborativa
Grid Computing, Cluster Computing
Orígenes = Enlazar supercomputadores dispersos geográficamente
Infraestructura que facilita intercambio de computaciones
Comparación con red eléctrica = Disponibilidad global de ciclos de
computación
Varias posibilidades:
Cluster Computing: Sistemas homogéneos
Grid Computing: Sistemas heterogéneos y dinámicos
Fuerte soporte industrial: Oracle, Sun, IBM, etc.
Ejemplos:
Distributed.net - Retos computacionales, ej. descifrado de códigos
SETI@Home - Search for extraterrestrial Intelligence
grid.org
Lucha contra el cáncer
globus.org Infraestructura para grid computing
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
122
Sistemas de Edición colaborativa
Wikis
Wikis = Portales que facilitan la edición colaborativa de contenido
wiki wiki = significa rápido en hawaiano
Facilitan la edición rápida de contenido por parte de los usuarios
Varios ejemplos:
wikipedia, nupedia,
etc...
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
123
Otros Sistemas Colaborativos
Trabajo en Grupo
Software de trabajo en Grupo: Groupware
Desarrollo de proyectos: eGroupWare, phpGroupware,
Desarrollo de software: Sourceforge, bugzilla, CVS, Subversion, etc.
Protocolos de Edición distribuida: WebDAV
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
124
Otros Sistemas Colaborativos
Weblogs
Sistemas de registro: Weblogs, Blogs, etc.
Ejemplo de aplicación: http://allconsuming.net/
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
125
Otros Sistemas Colaborativos
Mensajería Instantánea, chatbots
Sistemas de mensajería instantánea
Jabber = Protocolo de Mensajería instantánea sin servidores
centralizados
ChatBots = Robots que conversan automáticamente.
Ejemplo: ALICE
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
126
Más información
Servicios Web
Portal sobre SOAP www.soapware.org
Lista de servicios Web www.xmethods.com
Sobre servicios Web www.webservices.org
Especificaciones relacionadas con servicios Web www.w3c.org/2002/ws
Varios artículos comparando ventajas e inconvenientes de XML y servicios Web
www.zapthink.com
Páginas con información sobre agentes:
Agents 101: agents.umbc.edu/introduction/
AgentLand: www.agentland.com
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
127
Más Información
Peer-to-Peer y Grid Computing
Workshop on Peer-to-peer
http://www.lri.fr/~fci/GP2PC-04.htm
Peer-to-Peer Working Group
www.p2pwg.org
SETI@home
http://setiathome.ssl.berkeley.edu
Distributed.net, Project RC5
www.distributed.net/rc5
Global Grid Forum
www.gridforum.org
Grid Computing Info Centre
www.gridcomputing.com
Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)
128
