06/03/2014 1

Contexto de la programacin
cliente / servidor
M. C. S. Gustavo Pelez C.
06/03/2014 2
Definicin de arquitectura
Una arquitectura es un conjunto de
reglas, definiciones, trminos y
modelos que se emplean para
producir un producto.
06/03/2014 3
Definicin
La arquitectura Cliente/Servidor
agrupa conjuntos de elementos que
efectan procesos distribuidos y
computo cooperativo.
06/03/2014 4
La arquitectura cliente/servidor es un
modelo para el desarrollo de sistemas de
informacin, en el que las transacciones
se dividen en procesos independientes
que cooperan entre s

para intercambiar
informacin, servicios o recursos.
06/03/2014 5
Se denomina cliente al proceso que inicia
el dilogo o solicita los recursos y
servidor, al proceso que responde a las
solicitudes.
Es el modelo de interaccin ms comn
entre aplicaciones en una red.
06/03/2014 6
Qu es el Cliente?
Conjunto de Software y Hardware que invoca
los servicios de uno o varios servidores.
Los Clientes interactan con el usuario,
usualmente en forma grfica. Frecuentemente
se comunican con procesos auxiliares que se
encargan de establecer conexin con el
servidor, enviar el pedido, recibir la respuesta,
manejar las fallas y realizar actividades de
sincronizacin y de seguridad.
06/03/2014 7
Caractersticas:
El Cliente oculta al Servidor y
la Red.
Detecta e intercepta peticiones
de otras aplicaciones y puede
redireccionarlas.
Dedicado a la cesin del
usuario ( Inicia...Termina ).
El mtodo ms comn por el
que se solicitan los servicios
es a travs de RPC (Remote
Procedure

Calls).
Funciones Comunes del
Cliente:
Mantener y procesar todo el
dialogo con el usuario.
Manejo de pantallas.
Mens e interpretacin de
comandos.
Entrada de datos y validacin.
Procesamiento de ayudas.
Recuperacin de errores.
Generacin de consultas e
informes sobre las bases de
datos.
06/03/2014 8
Qu es el Servidor?
Conjunto de Hardware y Software que responde
a los requerimientos de un cliente.
Los Servidores proporcionan un servicio al
cliente y devuelven los resultados. En algunos
casos existen procesos auxiliares que se
encargan de recibir las solicitudes del cliente,
verificar la proteccin, activar un proceso
servidor para satisfacer el pedido, recibir su
respuesta y enviarla al cliente.
06/03/2014 9
Qu es el Servidor?
Deben manejar los interbloqueos, recuperacin
ante fallas, y otros aspectos afines.
La plataforma computacional asociada con los
servidores generalmente, es ms poderosa que
la de los clientes.
Por lo que se utilizan PCs

poderosas,
estaciones de trabajo, minicomputadores

o
sistemas mainframe.
Deben manejar servicios como administracin
de la red, mensajes, control y administracin de
la entrada al sistema ("login"), auditora y
recuperacin y contabilidad.
06/03/2014 10
Tipos de Servidores:
Servidor de Archivos (FTP, Novell).
Servidor de Bases de Datos (SQL,
CBASE, ORACLE, INFORMIX).
Servidor de Comunicaciones.
Servidor de Impresin.
Servidor de Terminal.
Servidor de Aplicaciones (Windows NT,
Novell).
06/03/2014 11
Funciones de los Servidores
Acceso, almacenamiento y organizacin de datos.
Actualizacin de datos almacenados.
Administracin de recursos compartidos.
Ejecucin de toda la lgica para procesar una
transaccin.
Procesamiento comn de elementos del servidor (Datos,
capacidad de CPU, almacenamiento en disco,
capacidad de impresin, manejo de memoria y
comunicacin).
Gestin de perifricos compartidos.
Control de accesos concurrentes a bases de datos
compartidas.
Enlaces de comunicaciones con otras redes de rea
local o extensa
06/03/2014 12
Arquitectura Cliente-Servidor
En el mundo de TCP/IP las
comunicaciones entre computadoras se
rigen bsicamente por lo que se llama
modelo Cliente-Servidor, ste es un
modelo que intenta proveer usabilidad,
flexibilidad, interoperabilidad y
escalabilidad en las comunicaciones.
06/03/2014 13
Arquitectura Cliente-Servidor
El trmino Cliente/Servidor fue usado por
primera vez en 1980 para referirse a PCs en
red.
Este modelo empez a ser aceptado a finales
de los 80s. Su funcionamiento es sencillo: se
tiene una mquina cliente, que requiere un
servicio de una mquina servidor, y ste realiza
la funcin para la que est programado (hay que
notar que no tienen que tratarse de mquinas
diferentes; es decir, una computadora por s
sola puede ser ambos cliente y servidor
dependiendo del software de configuracin ).
06/03/2014 14
El Modelo Cliente-Servidor
Desde el punto de vista funcional, se
puede definir la computacin
Cliente/Servidor como una arquitectura
distribuida que permite a los usuarios
finales obtener acceso a la informacin en
forma transparente an en entornos
multiplataforma.
06/03/2014 15
El Modelo Cliente-Servidor
En el modelo cliente servidor, el cliente
enva un mensaje solicitando un
determinado servicio a un servidor (hace
una peticin), y este enva uno o varios
mensajes con la respuesta (provee el
servicio) (Ver Figura 1).
06/03/2014 16
Arquitectura Cliente - Servidor
Figura 1
06/03/2014 17
El Modelo Cliente-Servidor
En un sistema distribuido cada mquina
puede cumplir el rol de servidor para
algunas tareas y el rol de cliente para
otras.
La idea es tratar a una computadora como
un instrumento, que por s sola pueda
realizar muchas tareas, pero con la
consideracin de que realice aquellas que
son ms adecuadas a sus caractersticas
06/03/2014 18
La aplicacin de este concepto tanto a clientes
como servidores se entiende que la forma ms
estndar de aplicacin y uso de sistemas
Cliente/Servidor es mediante la explotacin de
las PCs a travs de interfaces grficas de
usuario; mientras que la administracin de datos
y su seguridad e integridad se deja a cargo de
computadoras centrales tipo mainframe.
La mayora del trabajo pesado se hace en el
proceso llamado servidor y el o los procesos
cliente slo se ocupan de la interaccin con el
usuario.
06/03/2014 19
En otras palabras la arquitectura
Cliente/Servidor es una extensin de
programacin modular en la que la base
fundamental es separar una gran pieza de
software en mdulos con el fin de hacer ms
fcil el desarrollo y mejorar su mantenimiento
06/03/2014 20
Caractersticas Funcionales
Esta arquitectura se puede clasificar en
cinco niveles, segn las funciones que
asumen el cliente y el servidor.
06/03/2014 21
Primer nivel el cliente
Asume parte de las funciones de presentacin de la
aplicacin, ya que siguen existiendo programas en el
servidor, dedicados a esta tarea.
Esta distribucin se realiza mediante el uso de
productos para el "maquillaje" de las pantallas del
mainframe. Esta tcnica no exige el cambio en las
aplicaciones orientadas a terminales, pero dificulta su
mantenimiento.
El servidor ejecuta todos los procesos y almacena la
totalidad de los datos. En este caso se dice que hay una
presentacin distribuida o embellecimiento.
06/03/2014 22
Segundo nivel, la aplicacin
Est

soportada directamente por el
servidor, excepto la presentacin que es
totalmente remota y reside en el cliente.
Los terminales del cliente soportan la
captura de datos, incluyendo una
validacin parcial de los mismos y una
presentacin de las consultas.
En este caso se dice que hay una
presentacin remota.
06/03/2014 23
Tercer nivel
La lgica de los procesos se divide entre los
distintos componentes del cliente y del servidor.
El diseador de la aplicacin debe definir los
servicios y las interfaces del sistema de
informacin, de forma que los papeles de cliente
y servidor sean intercambiables, excepto en el
control de los datos, que es responsabilidad
exclusiva del servidor.
En este tipo de situaciones se dice que hay un
proceso distribuido o cooperativo.
06/03/2014 24
Cuarto nivel
El cliente realiza tanto las funciones de
presentacin como los procesos.
Por su parte, el servidor almacena y
gestiona los datos que permanecen en
una base de datos centralizada.
En esta situacin se dice que hay una
gestin de datos remota.
06/03/2014 25
Quinto nivel
El reparto de tareas es como en el nivel anterior,
el gestor de base de datos divide sus
componentes entre el cliente y el servidor.
Las interfaces entre ambos, estn dentro de las
funciones del gestor de datos y, por lo tanto, no
tienen impacto en el desarrollo de las
aplicaciones.
En este nivel ocurre lo que se conoce como
bases de datos distribuidas.
06/03/2014 26
Caractersticas Lgicas
Una de las principales aportaciones de esta
arquitectura a los sistemas de informacin, es la
interfaz grfica de usuario. Gracias a ella se
dispone de un manejo ms fcil e intuitivo de las
aplicaciones mediante el uso de un dispositivo
tipo ratn.
En esta arquitectura los datos se presentan,
editan y validan en la parte de la aplicacin
cliente.
06/03/2014 27
En cuanto a los datos, cabe sealar que
en la arquitectura cliente / servidor se
evitan las duplicidades (copias y
comparaciones de datos), teniendo
siempre una imagen nica y correcta de
los mismos, disponible en lnea para su
uso inmediato.
06/03/2014 28
Todo esto tiene como fin que el usuario de
un sistema de informacin soportado por
una arquitectura cliente / servidor, trabaje
desde su estacin de trabajo con distintos
datos y aplicaciones, sin importarle dnde
estn o dnde se ejecuta cada uno de
ellos.
06/03/2014 29
Arquitecturas de desarrollo
Una arquitectura orientada a servicio, es un esquema de
tecnologa de informacin o estrategia en la cual las
aplicaciones cuentan con servicios disponibles en una
red tal como la World Wide Web (WWW).
06/03/2014 30
Arquitecturas de desarrollo
Implementar una arquitectura orientada a
servicios puede involucrar desarrollar
aplicaciones que usan servicios, quedando las
aplicaciones disponibles como servicios tal
que otras aplicaciones puedan usar estos
servicios ambos.
Un servicio provee una funcin especfica,
tpicamente una funcin de administracin, tal
como analizar un historial crediticio de
individuos o procesar una orden de compra.
06/03/2014 31
Arquitecturas de desarrollo
Un servicio puede proveer una funcin nica
discreta, tal como convertir un tipo de moneda
en otra, o ejecutar un conjunto de funciones
administrativas relacionadas, tal como
manipular varias operaciones en un sistema
de reservaciones de una lnea area.
06/03/2014 32
El concepto de SOA no es nuevo. Las
arquitecturas orientadas a servicios han sido
usadas por aos. Lo qu distingue una SOA de
otras arquitecturas es que est dbilmente
acoplada. Dbilmente acoplada significa que el
cliente de un servicio es esencialmente
independiente del otro servicio.
Arquitecturas de desarrollo
06/03/2014 33
La forma como un cliente (que puede ser otro
servicio) se comunica con los servicios no
depende de la implementacin del servicio.
Significativamente resulta que el cliente no tiene
que conocer mucho acerca del servicio para
usarlo.
Por ejemplo el cliente no necesita conocer en
que lenguaje est codificado el servicio o en qu
plataforma corre.
Arquitecturas de desarrollo
06/03/2014 34
Arquitecturas de desarrollo
06/03/2014 35
Arquitecturas de desarrollo
06/03/2014 36
Arquitecturas de desarrollo
Evolucin de la arquitectura de los
Sistemas Informticos
Datos
C/S 2 capas
Sistemas monolticos
C/S 3 capas
BD
Negocio
Presentacin
Negocio
Presentacin
Datos
Negocio
Datos
Negocio
Presentacin
06/03/2014 37
Arquitecturas de desarrollo
Arquitectura basada en
componentes
Componente de software:
Unidad de composicin que posee un conjunto
de interfaces y un conjunto de requisitos y que
puede desarrollarse e incorporarse a otro sistema
compuesto por otros componentes de forma
independiente en tiempo y espacio.
06/03/2014 38
Arquitecturas de desarrollo
Sistema basado en componentes
Conjunto de mecanismos y herramientas que
permiten la creacin e interconexin de
componentes de software, junto con una
coleccin de servicios para facilitar la labor de
los componentes que residen y se ejecutan en
l.
06/03/2014 39
Arquitecturas de desarrollo
Modelos basados en componentes
CORBA (Common Object Request Broker Architecture)
COM (Component Object Model)
DCOM COM distribuido
J ava RMI (Remote Method Invocation)
J avaBeans
J ava RPC (Remote Procedure Call)
06/03/2014 40
Arquitecturas de desarrollo
Arquitecturas orientadas a Servicios
(SOA)
Los componentes no resuelven el problema de la
interoperabilidad, para ello surgen las arquitecturas
basadas en servicios.
06/03/2014 41
Arquitecturas orientadas a
Servicios (SOA Service-Oriented
Architecture).
Servicios Web: Son componentes de software reusables
y dbilmente acoplados que encapsulan su
funcionalidad en una forma semntica y que adems
estn distribuidos y accesibles a travs de protocolos
estndares de Internet.
Son independientes del lenguaje de programacin
Son independientes de la plataforma
Usan estndares de Internet
06/03/2014 42
Protocolos de comunicacin:
XML: (eXtensible Markup Language)
Describe informacin que se intercambia.
SOAP: (Simple Object Access Protocolo)
Servicio de mensajera.
WSDL: (Web Services Descripcin Language)
Describe funcionalidades y donde se localiza en internet
un Web Service.
UDDI: (Universal Description Dicovery and Integration)
Mecanismo para publicar y descubrir servicios Web.
06/03/2014 43
Funcionamiento de los Servicios Web
06/03/2014 44
Caractersticas de SOA
1. Bajo acoplamiento
2. Request/Response (Solicitud/respuesta)
3. Sncrono (Este es un problema)
06/03/2014 45
Arquitectura EDA (Event-Driven
Architecture)
1. Desacoplado
2. Publicacin-subscricin
3. Asncrono
06/03/2014 46
Arquitectura ESB (Enterprise
Service Bus)
1. Orquestacin
2. Administracin y monitorizacin
3. Seguridad
4. Confiabilidad, escalabilidad y disponibilidad
06/03/2014 47
Arquitecturas de desarrollo
06/03/2014 48
Arquitecturas de desarrollo
Cada arquitectura
necesitar uno o
varios servicios de
Internet para
funcionar.
Los servicios
pueden ser desde
los mas sencillos
hasta los ms
complejos:
Sistemas operativos
Servidor de Directorios
Servidor de Base de datos
Servidor Web
Servidor de Correo
Servidor de Aplicacin
Servidor de UDDI
Servidor DNS
Servidor de transferencia
de archivos
Servidor de Noticias
06/03/2014 49
Propuestas Open Sources y
Licenciadas
Para cada servicio de los mencionados
anteriormente existen propuestas en el
mercado donde van desde las de cdigo
abierto (Open Sources) las cuales se
distribuyen de manera gratuita y
normalmente bajo la licencia GPL
(General Public License)
06/03/2014 50
Propuestas Open Sources y
Licenciadas
Existen empresas que han creado sus
productos desde cero o basados en las de
cdigo abierto en cuanto a funcionalidad y
caractersticas. Algunas de estas
empresas se encuentran IBM, Microsoft,
HP, BEA Logic, Sun, Oracle, etc. Donde el
uso de sus productos esta regido por una
licencia propietaria.
06/03/2014 51
Propuestas Open Sources y
Licenciadas
Productos de Cdigo Abierto tenemos a:
GNU Linux
Open LDAP
Postgresql
Apache
Sendmail
Tomcat
Axis
Bind
J ava Web Services Developer Pack
06/03/2014 52
Propuestas Open Sources y
Licenciadas
Productos de Cdigo Licenciado tenemos a:
Windows 2003 Server
HP-UX
Active Directory de Microsoft
SQL Server
IIS (Internet Information Server)
Exchange Server
Oracle Application Server 10g
WebSphere Application Server
DNS de Windows 2003 Server
06/03/2014 53
Modelo de objetos distribuidos
Objetivo: Extender el paradigma de orientacin a objetos
al desarrollo de sistemas distribuidos
Modelo RPC se ajusta bien a arquitecturas 2-tier
2 papeles bien diferenciados
cliente: realiza peticiones
servidor: recibe peticiones
La lgica de aplicacin est en el cliente o en el servidor
Difcil extender RPCs en desarrollo arquitecturas 3-tier

o
n-tier
Componentes del sistema pueden actuar a la vez como clientes
y servidores
En n-tier

la lgica de aplicacin se divide en componentes
modulares reutilizables

se ajustan mejor a un modelo
orientado a objetos.
06/03/2014 54
Finalidad: Disear e implementar sistemas
distribuidos que se estructuren como
colecciones de componentes modulares
(objetos) que puedan ser manejados fcilmente
y organizados en capas para ocultar la
complejidad del diseo.
Posibilidad de invocar y pasar como argumento
diferentes comportamientos
Posibilidad de aplicar patrones de diseo orientados
a objetos en la implementacin del sistema
distribuido
Modelo de objetos distribuidos
2
06/03/2014 55
Idea base: Extender el concepto RPC para su uso en un
modelo de computacin distribuida orientado a objetos
Un objeto es una entidad identificable de forma nica en todo el
sistema
Objetos encapsulan los recursos disponibles en el
sistema distribuido
Estado: representado por los atributos del objeto
Comportamiento: representado por los mtodos del objeto
La particin de la aplicacin y su distribucin se basa
en el uso de esos objetos
La comunicacin se lleva a cabo mediante la invocacin
de los mtodos de esos objetos
Modelo de objetos distribuidos
3
06/03/2014 56
Aspectos claves
(1) Definicin interfaces vs. implementacin mtodos
remotos
Interfaz remoto: define el comportamiento del objeto
remoto
Conjunto de definiciones de mtodos accesibles por los dems
objetos del sistema
Separacin entre definicin del interfaz remoto e
implementacin del comportamiento
Alternativas:
1. Mismo lenguaje para definicin e implementacin (ej.: J ava
RMI)
2. Uso de un IDL (interface

definition

languaje) independiente
del lenguaje de implementacin (ej.: CORBA)
Generacin automtica de elementos complementarios
a partir de la definicin del interfaz (stubs

(1)
, cdigo de
partida para las implementaciones)
(1) Un stub puede simular el comportamiento de cdigo existente (tal como un procedimiento en una mquina remota) o ser el sustituto
temporal para un cdigo an no desarrollado.
06/03/2014 57
(2) Referencias a objetos remotos (referencia remota)
Objetos remotos residen en la mquina que los crea
Es donde almacenan su estado (atributos)
Es donde ejecutan su comportamiento (mtodos)
En los procesos cliente se manejan referencias remotas a esos objetos
Determinan de forma unvoca la ubicacin de un objeto en el sistema distribuido
puntero

que referencia un objeto distribuido residente en otra mquina
Informacin tpica asociada a una referencia remota
Direccin IP de la mquina donde reside el objeto remoto
No. de puerto de escucha asignado por el sistema de objetos
Identificador nico del objeto (nico dentro de la mquina que lo crea)
Normalmente su contenido no es accesible directamente
Gestionado por los stub

de los clientes y por el servicio de binding
Uso de las referencias remotas
En la invocacin remota de los mtodos exportados por el objeto remoto
Como argumento que se pasa en una invocacin a otro objeto
Aspectos claves
2
06/03/2014 58
(3) Invocacin transparente de mtodos remotos
Modelos de invocacin
Invocacin esttica: la interfaz del objeto remoto es conocida en tiempo de
compilacin
Basado en la generacin/uso de representantes (stubs

y skeleton)
Cliente invoca el stub

correspondiente, que gestiona la invocacin real del objeto
remoto
Invocacin dinmica: la interfaz del objeto remoto no es conocida en tiempo de
compilacin
Requiere una serie de pasos previos para descubrir el interfaz
Paso de parmetros
Para tipos bsicos: paso por valor (copia-restauracin)
Para objetos locales: paso por valor de objetos serializados (copia-restauracin)
1. Serializar: convertir objeto en una cadena de bytes
2. Transferir copia serializada del objeto
3. Deserializar: reconstruir el objeto en la mquina de destino
Para objetos remotos: paso de referencias remotas
Aspectos claves
3
06/03/2014 59
Ubicacin de objetos remotos (binding)
Necesidad de mecanismos para obtener referencias remotas
binding

esttico: en tiempo de compilacin
La ubicacin del objeto remoto es fija y conocida a priori
El compilador genera directamente la referencia remota
binding

dinmico: en tiempo de ejecucin
El objeto remoto tiene asociado un nombre
La referencia remota se recupera de un servidor de nombres
binding

dinmico uso de servicios de nombres
Mantiene una B.D. con pares (nombre objeto, referencia remota)
Funciones bsicas:
registrar pares nombre-referencia (bind())
localizar referencia asociada a un nombre (lookup())
Nombres pueden ser
transparentes a la ubicacin
no transparentes a la ubicacin
Espacio de nombres puede ser
plano
jerrquico (en rbol)
Aspectos claves
3
06/03/2014 60
Gua Breve de Servicios
Web
06/03/2014 61
Qu son los Servicios Web?
Existen mltiples definiciones sobre lo que son los
Servicios Web, lo que muestra su complejidad a la hora
de dar una adecuada definicin que englobe todo lo que
son e implican. Una posible sera hablar de ellos como
un conjunto de aplicaciones o de tecnologas con
capacidad para interoperar en la Web.
Estas aplicaciones o tecnologas intercambian datos
entre s con el objetivo de ofrecer unos servicios. Los
proveedores ofrecen sus servicios como procedimientos
remotos y los usuarios solicitan un servicio llamando a
estos procedimientos a travs de la Web.
06/03/2014 62
Para qu sirven?
Estos servicios proporcionan mecanismos de
comunicacin estndares entre diferentes
aplicaciones, que interactan entre s para
presentar informacin dinmica al usuario. Para
proporcionar interoperabilidad y extensibilidad
entre estas aplicaciones, y que al mismo tiempo
sea posible su combinacin para realizar
operaciones complejas, es necesaria una
arquitectura de referencia estndar.
06/03/2014 63
Cmo funcionan?
El siguiente grfico muestra cmo
interacta un conjunto de Servicios Web:
Figura 1 -

Los servicios Web en Funcionamiento
06/03/2014 64
Aplicacin Servicio Web
Segn el ejemplo del grfico, un usuario
(que juega el papel de cliente dentro de
los Servicios Web), a travs de una
aplicacin, solicita informacin sobre un
viaje que desea realizar haciendo una
peticin a una agencia de viajes que
ofrece sus servicios a travs de Internet.
06/03/2014 65
Aplicacin Servicio Web
La agencia de viajes ofrecer a su cliente
(usuario) la informacin requerida. Para
proporcionar al cliente la informacin que
necesita, esta agencia de viajes solicita a
su vez informacin a otros recursos (otros
Servicios Web) en relacin con el hotel y
la compaa area.
06/03/2014 66
Aplicacin Servicio Web
La agencia de viajes obtendr informacin
de estos recursos, lo que la convierte a su
vez en cliente de esos otros Servicios
Web que le van a proporcionar la
informacin solicitada sobre el hotel y la
lnea area. Por ltimo, el usuario
realizar el pago del viaje a travs de la
agencia de viajes que servir de
intermediario entre el usuario y el servicio
Web que gestionar el pago.
06/03/2014 67
Aplicacin Servicio Web
En todo este proceso intervienen una
serie de tecnologas que hacen posible
esta circulacin de informacin.
Por un lado, estara SOAP (Protocolo
Simple de Acceso a Objetos). Se trata de
un protocolo basado en XML, que permite
la interaccin entre varios dispositivos y
que tiene la capacidad de transmitir
informacin compleja.
06/03/2014 68
Aplicacin Servicio Web
Los datos pueden ser transmitidos a
travs de HTTP , SMTP , etc. SOAP
especifica el formato de los mensajes. El
mensaje SOAP est compuesto por un
envelope (sobre), cuya estructura est
formada por los siguientes elementos:
header (cabecera) y body (cuerpo).
06/03/2014 69
Estructura de los mensajes
SOAP
06/03/2014 70
SOAP
Para optimizar el rendimiento de las
aplicaciones basadas en Servicios Web,
se han desarrollado tecnologas
complementarias a SOAP, que agilizan el
envo de los mensajes (MTOM) y los
recursos que se transmiten en esos
mensajes (SOAP-RRSHB).
06/03/2014 71
Lenguaje de Descripcin de
Servicios Web
Por otro lado, WSDL (Lenguaje de Descripcin
de Servicios Web), permite que un servicio y un
cliente establezcan un acuerdo en lo que se
refiere a los detalles de transporte de mensajes
y su contenido, a travs de un documento
procesable por dispositivos. WSDL representa
una especie de contrato entre el proveedor y el
que solicita.
WSDL especifica la sintaxis y los mecanismos
de intercambio de mensajes.
06/03/2014 72
Aplicacin Servicios Web
Durante la evolucin de las necesidades
de las aplicaciones basadas en Servicios
Web de las grandes organizaciones, se
han desarrollado mecanismos que
permiten enriquecer las descripciones de
las operaciones que realizan sus servicios
mediante anotaciones semnticas y con
directivas que definen el comportamiento.
06/03/2014 73
Aplicacin Servicios Web
Esto permitira encontrar los Servicios
Web que mejor se adapten a los objetivos
deseados. Adems, ante la complejidad
de los procesos de las grandes
aplicaciones empresariales, existe una
tecnologa que permite una definicin de
estos procesos mediante la composicin
de varios Servicios Web individuales, lo
que se conoce como coreografa.
06/03/2014 74
Servicios Web
Son componentes de software reusables y
dbilmente acoplados que encapsulan su
funcionalidad en una forma semntica y que
adems estn distribuidos y accesibles a travs
de protocolos estndares de Internet.
Son independientes del lenguaje de programacin
Son independientes de la plataforma
Usan estndares de Internet
06/03/2014 75
Funcionamiento de los Servicios
Web
06/03/2014 76
Protocolos de comunicacin
XML: (eXtensible Markup Language)
Describe informacin que se intercambia.
SOAP: (Simple Object Access Protocolo)
Servicio de mensajera.
WSDL: (Web Services Descripcin Language)
Describe funcionalidades y donde se localiza en
internet un Web Service.
UDDI: (Universal Description Dicovery and Integration)
Mecanismo para publicar y descubrir servicios Web.
06/03/2014 77
Ejemplo 1-3
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reserva xmlns:m="http://empresaviajes.ejemplo.org/reserva"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:referencia>
uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d </m:referencia>
<m:fechaYHora>2001-11-29T13:20:00.000-05:00</m:fechaYHora>
</m:reserva>
<n:pasajero xmlns:n="http://miempresa.ejemplo.com/empleados"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:nombre>Pepe Ejemplo</n:nombre>
</n:pasajero>
</env:Header>
06/03/2014 78
Ejemplo 2-3
<env:Body>
<p:itinerario
xmlns:p="http://empresaviajes.ejemplo.org/reserva/viaje">
<p:ida>
<p:salida>Nueva York</p:salida>
<p:llegada>Los Angeles</p:llegada>
<p:fechaSalida>2001-12-14</p:fechasalida>
<p:horaSalida>ltima hora de la tarde</p:horaSalida>
<p:preferenciaAsiento>pasillo</p:preferenciaAsiento>
</p:ida>
06/03/2014 79
Ejemplo 3-3
<p:vuelta>
<p:salida>Los Angeles</p:salida> <p:llegada>Nueva
York</p:llegada> <p:fechaSalida>2001-12-
20</p:fechaSalida> <p:horaSalida>media-
maana</p:horaSalida> <p:preferenciaAsiento/>
</p:vuelta> </p:itinerario>
<q:alojamiento
xmlns:q="http://empresaviajes.example.org/reserva/hotel
es"> <q:preferencia>ninguna</q:preferencia>
</q:alojamiento>
</env:Body>
</env:Envelope>
06/03/2014 80
Introduccin al Editor WSDL
WTP 1.5.1
06/03/2014 81
WSDL
Web Services Description Language - es un lenguaje
basado en XML para describir servicios Web y cmo
acceder a ellos (protocolo vinculante, formato de los
mensajes, etc.)
Permite separar la descripcin de la funcionalidad
abstracta que ofrece un servicio de los detalles
concretos de su descripcin como "cmo" o "dnde" se
ofrece esa funcionalidad.
El editor WSDL es una potente herramienta que permite
crear y editar archivos WSDL grficamente, y la
automatizacin de la mayor parte de las tareas
relacionadas con estos procesos.
06/03/2014 82
Ejemplo: creacin de un archivo
WSDL
Permite crear un archivo WSDL para un
servicio web simple que llamaremos
"InternationalTime".
Este servicio Web recibe como parmetro
un lugar compuesto por el nombre de una
ciudad y el nombre de un pas, y devuelve
su tiempo actual.
06/03/2014 83
Para empezar a
crear el archivo
WSDL, abra el
men Archivo y
seleccione Nuevo
- otro - XML -
WSDL.
Ejemplo: creacin de un archivo
WSDL
06/03/2014 84
Nos pedir que escriba el
nombre del archivo que se
crear. Para el ejemplo se va
nombrar el archiv o
"InternationalTime.wsdl".
Despus dar clic en el botn
Siguiente para ir a la pgina
siguiente.
Aceptar los valores
predeterminados en la pgina
Opciones de WSDL.
Debe tener un aspecto como
el siguiente: (figura)
Ejemplo: creacin de un archivo
WSDL
06/03/2014 85
Dar clic en el botn Finalizar para cerrar el
cuadro de dilogo. Se crear
automticamente un esqueleto WSDL,
que nos da un punto de partida excelente
para describir nuestro servicio Web. El
esqueleto debe tener el siguiente aspecto:
Ejemplo: creacin de un archivo
WSDL
06/03/2014 86
Se da el nombre de la operacin de
servicio Web a "getInternationalTime".
Para ello, basta con hacer doble clic
sobre el ttulo de la operacin y escribir
el nuevo nombre, como se muestra a
continuacin.
Ejemplo: creacin de un archivo
WSDL
06/03/2014 87
A continuacin vamos a especificar los
formatos de entrada y de salida de este
servicio. Para ello, pulsaremos primero en
la flecha que aparece junto a la operacin
de entrada:
Ejemplo: creacin de un archivo
WSDL
06/03/2014 88
Se abrir un editor en lnea de esquema:
una nueva pestaa aparecer en la parte
superior del editor indicando as:
Ejemplo: creacin de un archivo
WSDL
06/03/2014 89
En el editor de esquemas en lnea, se establece el tipo
de elemento a conseguir InternationalTimeRequest. En
este caso particular, dado que el parmetro de entrada
es un lugar compuesto por el nombre de una ciudad y el
nombre de un pas, se va a crear un nuevo tipo complejo
dando clic derecho en el elemento
InternationalTimeRequest y seleccionando Set Tipo -
Nuevo.
En el cuadro de dilogo Nuevo Tipo seleccionar tipo
complejo y colocar el nombre a "Location". A
continuacin aadir los elementos "Country" y "City" de
tipo String y establezcer el atributo tipo en "All".
Ejemplo: creacin de un archivo
WSDL
06/03/2014 90
Una vez terminado, el elemento de
ubicacin debe tener el siguiente aspecto.
Ejemplo: creacin de un archivo
WSDL
06/03/2014 91
Volver a la pantalla principal del editor
WSDL dando clic en su ficha
correspondiente:
Ejemplo: creacin de un archivo
WSDL
06/03/2014 92
Paso siguiente, fijar el formato de la salida de la misma
manera que se hizo para la entrada. Empezar dando clic
en la flecha que aparece junto a la salida de la siguiente
manera.
El editor en lnea de esquema se abrir. En ella, se
establece el tipo del elemento
getInternationalTimeResponse dando clic derecho y
seleccionando Set Tipo - Usuarios.
Puesto que el servicio web devuelve el tiempo de un
lugar determinado, se elige a partir del momento de lista
Tipo y dar clic en Aceptar y guardar los cambios
realizados en el archivo WSDL.
En este punto no necesitaremos ms al editor de
esquemas en lnea, as que lo cerramos.
Ejemplo: creacin de un archivo
WSDL
06/03/2014 93
Terminado! desde la
pantalla principal del
editor WSDL se
puede dar clic en la
ficha "Fuente",
situado en la parte
inferior de la pantalla
para ver el cdigo
XML que se ha
generado
automticamente.
Ejemplo: creacin de un archivo
WSDL
06/03/2014 94
Por ltimo hay que
verificar que el
archivo WSDL es
vlido. Para hacer
esto, dar clic en el
archivo y seleccionar
Validar.
Ejemplo: creacin de un archivo
WSDL
06/03/2014 95
En caso de que haya algn problema con
el contenido del archivo, stos aparecern
en la ventana de Problemas.
Si la ventana de problemas no es visible
en la mesa de trabajo (workbench), se
puede mostrar al seleccionar en el men
principal: Ventana - Show - Vista -
Problemas
Ejemplo: creacin de un archivo
WSDL
06/03/2014 96
Comunicacin entre componentes
Existen diversas dificultades tcnicas a la hora
de llevar a la prctica las arquitecturas
orientadas a servicios. Entre stas estn la
comunicacin entre las distintas capas y
componentes que constituyen la aplicacin, la
gestin de peticiones y el balanceado de carga
entre servidores cuando un mismo componente
reside en varios de ellos (para aplicaciones muy
grandes con muchos clientes), la gestin de
transacciones entre componentes y algunas
otras cosas ms.
06/03/2014 97
Comunicacin entre componentes
Existe la posibilidad de escribir un protocolo de
comunicaciones propio que se ocupe de todas
estas cuestiones, pero por supuesto se trata de
una opcin muy poco realista dada la
complejidad que conllevara. Para responder a
estas necesidades de los programadores,
diversos fabricantes y asociaciones de la
industria crearon servicios y protocolos
especficos orientados a la interaccin
distribuida de componentes. Aunque existe una
gran variedad, de todos ellos los ms
importantes sin duda son:
06/03/2014 98
DCOM (Distributed

Common

Object

Model),
la propuesta de Microsoft, ligada a sus sistemas
Windows. Se trata de algo ms que un protocolo
de invocacin remota de procedimientos (RPC)
ya que su ltima encarnacin, COM+, incluye
servicios avanzados para balanceado de carga,
gestin de transacciones o llamadas
asncronas. Los parmetros son transmitidos a
travs de la red mediante un formato binario
propio llamado NDR (Network Data
Representation).
06/03/2014 99
RMI (Remote Method

Invocation),
Es la metodologa de llamada a
procedimientos remotos de J ava. No se
centra en la definicin de interfaces para
compatibilidad binaria de componentes ni
en otros conceptos avanzados, y se basa
en la existencia de un cliente y un servidor
que actan de intermediarios entre los
componentes que se quieren comunicar.
Es una tecnologa bastante simple, que es
fcil de utilizar para aplicaciones bsicas.
06/03/2014 100
CORBA (Common

Object

Request

Broker Architecture).
Se trata de una serie de convenciones que describen
cmo deben comunicarse entre s los distintos
componentes, cmo se deben transferir los datos de las
llamadas y sus resultados o cmo se describen las
interfaces de programacin de los componentes para
que los dems sepan cmo utilizarlos. Fue desarrollado
por el OMG (Object

Management Group) en la segunda
mitad de la dcada de los '90, y es el modelo que ms
xito ha tenido en el mundo UNIX. Su mtodo de
empaquetado y transmisin de datos a travs de la red
se llama CDR (Common

Data representation). Existen
diversas implementaciones de distintos fabricantes.
Estos