Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 1 Tecnologías Web Jose Emilio...

1Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra)

Tecnologías Web

Jose Emilio Labra Gayo

Departamento de Informática

Universidad de Oviedo


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


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


Topologías

TransaccionalGrandes mainframes con terminales tontasBases de datos multiusuario transaccionalesEl sistema garantizaba que una unidad de trabajo era completamente

procesada (o no) sin interferenciasRelacional

Aparición de ordenadores personalesNecesidad de comunicación Creación de LANsArquitecturas cliente-servidor (Múltiples clientes – un servidor)Bases de datos relacionales (múltiples vistas de los datos)

NavegacionalWeb = Múltiples clientes y múltiples servidoresComputación obicua (PDAs, moviles, coches,...)Se requieren nuevos servicios de todo tipoActividades del cliente: navegar y descubrir serviciosArquitecturas: anillos, comunidades, peer-to-peer, ...


Arquitectura Cliente/Servidor

Protocolo HTTP se basa en la arquitectura cliente/servidor (sin estado)

ServidorProtocolo http

Visualizador

http:/1.0 200 OK<html><body>Enlace a <a href =“otro.html”>Otro</a></body></html>

http:/1.0 200 OK<html><body>Enlace a <a href =“otro.html”>Otro</a></body></html>

GET http://servidor.com/hola.html

Cliente


Arquitectura Cliente/ServidorComputación dinámica

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

Cliente Servidor Base Datos

Arquitectura de 3 capas


Arquitectura Cliente/ServidorComputació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)

Es preferible la utilización de <object> <p><OBJECT CLASSID="java:juego.class" 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

Valoración


Arquitectura cliente/servidorComputació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>


Arquitectura cliente/servidorComputació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


Arquitectura cliente/servidorComputación en servidor

Código Incrustado en HTMLEl servidor reconoce ciertas etiquetas y ejecuta el código que contienenEl servidor debe incluir un intérprete del lenguaje de programación utilizado El programa tiene acceso a componentes del servidorLenguajes habituales:

PHP: Lenguaje específico (sintaxis similar a C, sin chequeo de tipos)

ASP (Microsoft): Utiliza Visual BasicJSP (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 { . . .}


Componentes Distribuidos


Componentes DistribuidosDefiniciones

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.

RedRed


Componentes DistribuidosAntecedentes

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)


Plataformas existentesMicrosoft 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


Plataformas existentesCORBA

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


Plataformas existentesEJBs

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


Arquitectura de Componentes DistribuidosContenedor

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.


Arquitectura de Componentes Distribuidos

stub y skeletonstub: 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

stub Red Objeto Distribuido

skeleton

interfaz remota

interfaz remota



Middleware explícito

Cliente

stub Red Objeto Distribuido

skeleton

Transacciones

Persistencia

Seguridad

...

Contenedor

El Objeto distribuido se encarga de gestionar directamente los servicios del contenedor: transacciones, persistencia, seguridad, etc.

Problema: Mayor complejidad en desarrollo de objeto distribuido

interfaz remota

interfaz remota



Middleware implícito

Cliente

stub Red

Objeto Distribuido

skeleton

interfaz remota

Interceptor

Transacciones

Bases Datos

Seguridad

...

Contenedor

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.

interfaz remota



Creación de ObjetosLa 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

stub Red skeleton Interceptor

Transacciones

Bases Datos

Seguridad

...

Contenedor

Factoría

crea

Objeto Distribuido

solicitud creación

interfaz remota

interfaz remota

interfaz factoría


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.


Servicios de InfraestructuraGestió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


Servicios de InfraestructuraConcurrencia

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.


Servicios de InfraestructuraTransacciones

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


Servicios de InfraestructuraMensajerí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:

Publicador

Suscriptor

Tópico Suscriptor

Suscriptor

Publica y subscribe

Emisor Cola

ReceptorPotencial

ReceptorPotencial

Punto a Punto


Servicios de InfraestructuraPersistencia

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)


Servicios de InfraestructuraTrasparencia 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


Servicios de InfraestructuraSeguridad

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.


Componentes Distribuidos:Caso particular: Enterprise

Java Beans


Plataformas existentesEJBs

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


Tipos de Beans

EnterpriseBean

EntityBeanSessionBean MessageDrivenBean

Stateless Stateful CMP BMP


Beans de SesiónSessionBean

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


Beans de EntidadEntityBean

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


Beans Manejados por MensajesMessageDrivenBean

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


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

Servdor Aplicaciones (Contenedor)

EJBMDB

EJBSesión

EJBSesión

EJBSesión

EJBEntidad

EJBEntidad

JSP

Servlet

AplicaciónApplet

ClienteCORBA

ClienteMensaje

ClienteHTML

SocioNegocio

Firewall

SOAPWSDLUDDI

Mensaje

IIOP

RMI-IIOP

RMI-IIOP

Servidor Web


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

stub Red skeleton Interceptor

Transacciones

Bases Datos

Seguridad

...

Contenedor

Factoría

crea

Objeto Distribuido

solicitud creación

interfaz remota

interfaz remota

interfaz factoría


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

stub Red skeleton EJBObject

Transacciones

Bases Datos

Seguridad

...

Contenedor

HomeObject

crea

EnterpriseBean

solicitud creación

interfaz remota

interfaz remota

interfaz Home


Partes de un EJBEnterprise 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)


Partes de un EJBEJB 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


Transacciones

Bases Datos

Seguridad

...

Contenedor

HomeObject

crea

EnterpriseBean

solicitud creación

interfaz remota

interfaz remota

interfaz Home


Partes de un EJBInterfaz 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


Partes de un EJBObjeto 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


Transacciones

Bases Datos

Seguridad

...

Contenedor

HomeObject

crea

EnterpriseBean

solicitud creación

interfaz remota

interfaz remota

interfaz Home


Partes de un EJBInterfaz 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


Transacciones

Bases Datos

Seguridad

...

Contenedor

HomeObject

crea

EnterpriseBean

solicitud creación

interfaz remota

interfaz remota

interfaz Home


Partes de un EJBInterfaces 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


Partes de un EJBDescriptores 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


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


Transacciones

Bases Datos

Seguridad

...

Contenedor

HomeObject

crea

EnterpriseBean

solicitud creación

interfaz remota

interfaz remota

interfaz Home


Ejemplo de EJB de SesiónInterfaz 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

Necesario para que el

contenedor implemente el

EJBObject


Ejemplo de EJB de SesiónInterfaz Home

public interface SumaHome extends EJBHome { Suma create() throws javax.ejb.CreateException,java.rmi.RemoteException;}

Necesario para que el

contenedor implemente el

EJBHome

Método que se invocará al crear

el EJB


Ejemplo de EJB de SesiónObjeto de Negocio

public class SumaBean implements SessionBean {

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); }

}

Implementación del método

Bean de sesión

Métodos que controlan el ciclo de vida (en este caso, no hacen

nada)


Ejemplo de EJB de SesiónDescriptor 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> <session> <ejb-name>ejbSuma</ejb-name> <home>com.suma.ejbSuma.SumaHome</home> <remote>com.suma.ejbSuma.Suma</remote> <ejb-class>com.suma.ejbSuma.SumaBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> . . .

Declara las clases e

interfaces del EJB

Delega la gestión

transaccionalal contenedor

Indica que es sin estado


Ejemplo de EJB de SesiónDescriptor de Despliegue (y 2)

<assembly-descriptor> <security-role><role-name>everyone</role-name></security-role> <method-permission> <role-name>everyone</role-name> <method> <ejb-name>ejbSuma</ejb-name><method-name>*</method-name> </method> </method-permission> <container-transaction> <method> <ejb-name>ejbSuma</ejb-name><method-name>*</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor></ejb-jar>

Especifica política de seguridad (todo el mundo puede invocar todos los

métodos)

Especifica política de transacciones (el contenedor

de crear una transacción si no existe)


Ejemplo de EJB de SesiónCódigo Cliente

import com.suma.ejbSuma.SumaHome;

public class hazSuma { public static void main(String[] args) { try {

Context jndiContext = new InitialContext();Object ref = jndiContext.lookup("Suma");SumaHome home = (SumaHome)

PortableRemoteObject.narrow(ref,SumaHome.class); Suma s = home.create();System.out.println("2 + 3 = " + s.suma(2,3));} catch (Exception e) { System.out.println("Exception: " + e);

}}

Buscar objeto Home en JNDI

Convertir referencia a objeto Home

Crear objeto EJB a partir del Home

Invocar método


EJBsValoració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


EJBsValoració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...


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


Servicios Web


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

AntecedentesIntercambio de XML


Servicios WebPosible 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

ServicioWeb

Petición

RespuestaInternetInternet

URL


Servicios WebFactores que influyeron en su

apariciónComputació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


Servicios WebObjetivos

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


Servicios WebPrincipales 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)

Programas accesibles en Internet que esponen su funcionalidad recibiendo/enviando mensajes SOAP a través de HTTP(s) y describen su interfaz en WSDL

Otra definición


HTTPHTTP

Servicios WebPrincipales Vocabularios

UDDIUDDI

regist

ra

regist

ra

publica W

SDL

publica W

SDL

petición SOAP (XML)petición SOAP (XML)

respuesta SOAP (XML)respuesta SOAP (XML)ImplementaciónImplementación

servicio Webservicio Web

encuentra

encuentra

obtiene WSDL

obtiene WSDL

ConsumidorConsumidorservicio Webservicio Web


XSLTXSLT

HTMLHTML

Dispositivo delDispositivo delClienteCliente

Servicio WebServicio Web

Base DatosBase Datos

SOAPSOAPXMLXML XSLTXSLT WMLWML

XSLTXSLT

VoiceXMLVoiceXML

Servicios WebArquitectura de Aplicaciones


SOAPSOAP

SOAPSOAPSOAPSOAP

SOAPSOAP

InternetInternet

Conversión deConversión deMonedasMonedas

FacturaciónFacturación

Gestión deGestión deUsuariosUsuarios

SOAPSOAPXMLXML

AplicaciónAplicacióndel usuariodel usuario

Servicios WebArquitectura de Aplicaciones


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

SOAPEvolución


EnvelopeEnvelope

BodyBody

HeaderHeader

Header KeyHeader Key

Header KeyHeader Key

SOAPFormato


<?xml version=‘1.0’ ?><soap:Envelope xmlns:soap=‘http://www.w3.org/2001/12/soap-envelope’ xmlns:p =‘http://www.mafia.it/pizzas’>

</soap:Envelope>

<soap:Header> <p:prioridad> urgente </p:prioridad> <p:origen>[email protected]</p:origen> </soap:Header>

Cabecera Cabecera

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

Contenido Contenido

SOAPEjemplo


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

SOAPFormato general


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

SOAPHeader


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 XMLfaultactor: URI del nodo que causó el error

SOAPFault


<?xml version=‘1.0’ ?><soap:Envelope xmlns:soap=‘http://www.w3.org/2001/12/soap-envelope’>

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

SOAPFault


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

SOAPCodificación


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

Tipos básicosTipos básicos

SOAPCodificación


<Pizza xmlns=‘cualquier_URI’> <código>234</código> <nombre>Barbacoa</nombre></Pizza>

struct Pizza { int código; string nombre;};

EstructurasEstructuras

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

ArraysArrays

SOAPCodificación


Arrays parcialesArrays parciales

<pizzas xsi:type=‘soap:Array’ soap:arrayType=‘p:Pizzas[10]’ soap:offset=‘[4]’> <pizza> <código>234</código> <nombre>Barbacoa</nombre> </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> <nombre>Barbacoa</nombre> </pizza> <pizza soap:position=‘5’ ><código>237</código> <nombre>Barbacoa</nombre> </pizza></pizzas>

5º y 6º 5º y 6º elementoelemento

2º y 5º 2º y 5º elementoelemento

SOAPCodificación


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>

SOAPEjemplo con HTTP


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>

SOAPEjemplo de respuesta


WSDL (Web Services Description Language)Describe:

Qué puede hacer el servicioDónde resideCómo invocarlo

Vocabulario basado en capasEs 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

WSDLEvolución


WSDLEstructura del documento

service

definitions

Tipos de datos usados en los mensajes (XML Schema)

message

types

portType

binding

port

Definición abstracta de los datos transmitidos.

Conjunto de operaciones abstractas

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

Colección de puntos de destino


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

WSDLEjemplo


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

WSDLEjemplo


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

flexibleUDDI 3.0 (2002) Interacción de implementaciones públicas y privadas

2 partesDescripció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

UDDIDefinición


Provider: Información sobre la entidad que ofrece el servicio

0…n

Service: Información descriptiva sobre una familia particular de ofertas

0…n

Binding: Información técnica sobre un punto de entrada a un servicio

tModel: Descripciones de especificaciones de servicios

BindingBinding contiene referencias contiene referencias a a tModelstModels. Estas referencias . Estas referencias declaran las especificaciones declaran las especificaciones del interfazdel interfaz

0…n

UDDIDefinición


Servicios Servicios UDDIUDDI

2.2. El desarrollador registra y El desarrollador registra y clasifica el servicio Webclasifica el servicio Web

2.2. El desarrollador registra y El desarrollador registra y clasifica el servicio Webclasifica el servicio Web

3.3. El usuario pregunta a UDDI por El usuario pregunta a UDDI por servicios de conversiónservicios de conversión

3.3. El usuario pregunta a UDDI por El usuario pregunta a UDDI por servicios de conversiónservicios de conversión

4.4. El usuario determina el servicio El usuario determina el servicio de conversión más apropiadode conversión más apropiado

4.4. El usuario determina el servicio El usuario determina el servicio de conversión más apropiadode conversión más apropiado

5.5. El usuario construye una El usuario construye una aplicación que consuma el aplicación que consuma el servicio Web directamenteservicio Web directamente

5.5. El usuario construye una El usuario construye una aplicación que consuma el aplicación que consuma el servicio Web directamenteservicio Web directamente

SOAPSOAP

1.1. El desarrollador construye un El desarrollador construye un servicio para convertir servicio para convertir monedasmonedas

1.1. El desarrollador construye un El desarrollador construye un servicio para convertir servicio para convertir monedasmonedas

servicio Web servicio Web conversiónconversión

UDDIFuncionamiento


Utilización de un Servicio WebEjemplos

Consltar listados de servicios Web

www.xmethods.net

www.bindingpoint.com

Puedenejecutarse


Utilización de servicios WebEjemplos: Google


Utilización de servicios WebEjemplos: Amazon


JavaAPIs de Sun: JAXRPC, JAXM, SAAJ, Librerías de Apache: Axis

Microsoft .NETASP.NET para C#, VBasic, etc.MS SOAP Toolkit

Otros:SOAP::Lite (Perl), NuSOAP (PHP), Axis (C++)

Implementación de Servicios Web

Posibilidades



APIs de JavaSAAJ (SOAP with Attachments API for Java)

Tratar mensajes SOAP como objetos JavaJAX-RPC (Java API for XML based RPC)

Modelo de programaciónConversión WSDL/XML JavaManejo de SOAP y SOAP con AttachmentsAPI 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)



Apache AxisSucesor 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



Creación de un Cliente

WSDL

Descripcióndel servicio

adaptador stubs

clases Javageneradas

WSDL2Java

códigocliente

javac cliente


Implementación de servicios WebCreación de un cliente

http://petra.euitio.uniovi.es/~labra/ws/suma.php?wsdl

1.- Acceder a WSDL

> java org.apache.axis.wsdl.WSDL2Java -p suma suma.wsdl

2.-Generar stubs

Almacenar como suma.wsdl

3.- Comprobar clases generadas

> ls suma/*.javaServicioSuma.java ServicioSumaLocator.javaServicioSumaBindingStub.java ServicioSumaPortType.java

4.- Compilar clases generadas

> javac suma/*.java


Implementación de servicios WebCreación de un cliente

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 ClienteSuma2 + 3 = 5

ClienteSuma.java


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

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); } }}

ClienteTemp.java



Creación de un Servicio WebMétodo simple: JWS

public class Suma { public int suma(int a, int b) { return a + b; }}

Suma.jws

Almacenar en: <TOMCAT>\webapps\axis\Suma.jws

http://localhost:8080/axis/Suma.jws



Creación de un Servicio WebUtilizar 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



Creación de un Servicio Web

1.- Compilar servicio

> javac ServSuma.java

package ServSuma;

public class ServSuma { public int suma(int a, int b){ return (a + b); }}

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



Creación de un Servicio Web

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

deploy.wsdd

3.- Desplegar servicio

> java org.apache.axis.client.AdminClient deploy.wsddProcessing file deploy.wsdd<Admin>Done processing</Admin>

Puede ser necesario reiniciar servidor

4.- Acceder a http://localhost:8080/axis/services/ServSuma



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


InteroperabilidadAcceso desde .NET a servicio en

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

3.- Creación de cliente using System;

public class ClienteSumaNet { public static void Main() { ServSumaService srv = new ServSumaService(); Console.WriteLine("2 + 3 = {0}", srv.suma(2,3));}}

cliente.cs

> csc cliente.cs /reference:ServSumaService.cs

4.- Compilación de cliente

> cliente2 + 3 = 5

5.- Ejecución


InteroperabilidadServicios Web en .NET


InteroperabilidadServicios Web en 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; }?>

suma.php


Arquitecturas Orientadas a Servicios

DefiniciónSOA = Service Oriented Architectures

Un tocadiscos es un servicio......le pasamos un disco y suena música

Ejemplo

Construcción de aplicaciones partiendo de interfaces, con el objetivo de desarrollar agentes débilmente acoplados que se comunican entre sí.

En POO se encapsulan datos y procesos...el disco incluiría su tocadiscos...



Modelo tradicional

AlgoritmosIVA

AlgoritmosEnvío

Aplicación

Compilación

DatosIVA

AplicaciónIntegrada

Fuentedatos

datosenvío

Tiempo de construcción

Tiempo de configuración

Tiempo de ejecución



Modelo Orientado a Servicios

Aplicación Compilación

servicio cálculo

IVA

AplicaciónIntegrada

Tiempo de construcción

Tiempo de ejecución

servicio gastos envío



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 mensajesEj. Solicitar un libro

Interoperabilidad

Independencia de lenguajes y plataformas

Adaptación de arquitecturas ya existentes

Utilización de estándares

Modelo REST vs SOAP


Servicios WebRetos

Gestión de servicios Web

WSDM - Web Services Distribution Management

Agregación de servicios

Ejemplo. Reserva de avión + hotelEvolución de los servicios

Cambio de la InterfazModelizació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.


Servicios WebMitos...

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


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


Otras Arquitecturas:Agentes

Sistemas ColaborativosPeer-to-peer

Grid computing


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


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 experienciaAutocontenido: El agente posee todos los datos que necesita para

ejecutarse y migrarCoordinación: Los agentes pueden coordinarse entre sí para realizar una

actividad complejaDesconexión: El agente puede seguir ejecutándose aunque el usuario (o

dueño) esté desconectadoPuede decidir dormir, y reestablecer conexión periódicamenteEl usuario puede traer de vuelta al agente cuando lo desea


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


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?


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


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.


Sistemas peer-to-peerTopologías

Servidor de Directorios Centralizado (sistemas híbridos)Algunos nodos tienen carácter especial (servidores de directorio)Ejemplos: Napster, Pointerra, OpenNapProblemas:

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.

1.informar/actualizar



3. transferencia2. preguntar

peers

Servidor directorios



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



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

unirse

pregunta


Computación ColaborativaGrid Computing, Cluster

ComputingOrí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


Sistemas de Edición colaborativaWikis

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


Otros Sistemas ColaborativosTrabajo 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


Otros Sistemas ColaborativosWeblogs

Sistemas de registro: Weblogs, Blogs, etc.

Ejemplo de aplicación: http://allconsuming.net/


Otros Sistemas ColaborativosMensajerí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


Más informaciónServicios 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


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) 1 Tecnologías Web Jose Emilio...

Documents

Transcript of Curso Doctorado:Universidad Pontificia de Salamanca (Jose E. Labra) 1 Tecnologías Web Jose Emilio...