You are on page 1of 12

SERVICIOS Y

MODELOS DE
MIDDLEWARE

DEFINICIN
El Middleware es el elemento clave de la integracin del
sistema distribuido, aporta todos los elementos para
conseguir transparencia. Elimina la complejidad en:

El desarrollo.
Obtener servicios de datos y de proceso de forma
transparente.
Obtener transparencia en el transportista
La administracin del sistema.
La localizacin de los elementos en la plataforma.

LA VISIN DEL SISTEMA DEL


DISEADOR

COMPONENTES BSICOS DEL


MIDDLEWARE
APIs de alto nivel para la peticin de forma
transparente de los servicios.

Mecanismos bsicos
del Middleware, que
se deben encontrar
en todos los modelos

Un
mecanismo de
implementacin e
integracin de los servicios construidos en el
Middleware.
Herramientas para referenciar, catalogar,
gestionar y localizar los recursos en la
plataforma.
Facilidades de gestin distribuida.
La plataforma del transportista.
Si estamos en un modelo de objetos
distribuidos, los recursos de gestin de estos
objetos OO.

SERVICIOS BSICOS
PROPORCIONADOS POR
MIDDLEWARE
5.1.1. Acceso a recursos: Presentacin, Impresin, Datos, Comunicaciones.

5.1.2. Servicios de comunicacin entre programas: RPC, Memoria compartida


(casi no se usa ya).

SERVICIOS DE
DESARROLLO

5.1.3. Servicios de Distribucin: Referencia y catalogacin de recursos y


componentes, Arranque de recursos Localizacin. Gestor de transacciones.
Fecha y Hora.

5.1.4. Gestor de Objetos Distribuidos (Object Request Brokers ORBs): Si el


Middleware tiene un modelo de objetos distribuidos.

5.1.5. Servicios de administracin del sistema: Servicios de referencia y


catalogacin de recursos (Naming and Directory Services).
Seguridad, autentificacin de usuarios y proteccin de acceso a recursos
(Security Services).
Algoritmos y protocolos de comunicacin,etc.

Modelo de
DeBower&Dolgi
MODELOS DE MIDDLEWARE
cer (1992)
Modelo de King (1992)
El modelo est claramente pensado para
proponer un Middleware que hiciera transparente
los protocolos de red que hacan del transportista
algo no estndar y difcil de gestionar en aquella
poca.

King propona un modelo mucho ms general y


cercano a lo que uno espera hoy da del
Middleware.
Propona una capa de servicios de alto nivel con
RPC, SQL y MOM que se apoyaba en el concepto
de sesin (se pide un enlace con el servicio, se
usa y despus se cierra). Las sesiones se
apoyaban sobre una capa de transporte que hacia
transparente la red y los datos.

MODELOS DE MIDDLEWARE
Modelo de Dolgicer (1994)

Open Distribuited Application


Model (ODAM-1996

Servicios de alto nivel: RPC, DATABASE Access,


MOM, ORB
Gestor de transacciones
Correo independiente de la heterogeneidad de la
plataforma.
ste se considera el primer modelo completo y
se habla ya nicamente de un Middleware que
transporta mensajes de forma transparente a la
plataforma.

Propuesto por IBM.


Posee una gran similitud con el modelo del 94 de
Dolgicer.
Su aportacin es crear una capa, los gestores,
que se sita por debajo del Middleware, con una
propuesta de servicios de DSM.

WINDOWS OPEN SERVICES


ARCHITECTURE (WOSA)
Mediante APIs proporcionadas por Windows, se
ataca un sistema estndar de empalme de
servicios. Se pierde la organizacin de los servicios
por capas proporcionados por los modelos
anteriormente citados.
Una utilizacin de este modelo fue crucial es el
desarrollo de aplicaciones distribuidas.
Para poder conectar a cualquier motor de base de
datos, Microsoft propuso una capa por debajo del
Windows Service Provider Interface para enlazar con
bases de datos relacionales.
Se cre como una extensin de SQL, un estndar ya
consolidado. Cualquier motor de bases de datos que
proporcionara una conversin de sus APIs nativas a
esa capa podra ser atacado desde un programa
Windows.
Haba nacido Open Database Connectivity (ODBC).
El acceso trasparente a las bases de datos era una
realidad.

U
O
S
E
b
e
tl
O
il
rj
b
e
vi
d
tji
o
e
a
c 2.
d
si
c
d
o
e
t
R
e
s
A
d
e
p
q
e
O
D
u
li
O
U
S
E
S
b
e
c
b
e
tl
M
a
s
O
il
rjj
e
c
ti
b
e
v
B
tt(iji
d
C

o
r
o
e
a
c
n
o
(i
d
s
c
O
m
k
d
o
e
t(
m
A
b
e
R
e
s
p
o
rj
A
d
e
p
n
e
p
q
e
li
F
c
O
D
u
li
a
c
t
S
b
e
c
S
a
c

COMMON REQUEST BROKER


ARCHITECTURE (CORBA)
Object Management Architecture (OMA).

Soporta entornos heterogneos y


distribuidos combinando proceso
distribuido y orientado a objetos.
Proporciona un mtodo estndar
para crear, preservar, localizar y
comunicar objetos y distribuidos por
la plataforma.

COMMON REQUEST BROKER ARCHITECTURE


(CORBA)

Estructura del ORB

Cliente:
Utilizar la interface proporcionada
por el Dynamic Invocation y el IDL
Stub del servidor (objeto) al cual
pide el servicio, para algunas
funciones utilizar directamente el
ORB Interface.
Servidor, implementado en un objeto:
Recibe la peticin a travs de una
llamada generada desde el IDL
Skeleton,
mientras
procesa
la
peticin, el Servidor puede utilizar el
ORB Interface o el Object Adapter.
La definicin de los interfaces de los
objetos puede realizarse de dos
maneras:
Estticamente, a travs de un
lenguaje de definicin de interfaces
denominado Interface Definition
Language (IDL).
Dinmicamente, aprovechando un
servicio del Interface Repository.

MODELO ESTANDAR DEL


MIDDLEWARE
La idea del
Middleware
estndar se
completa con un
ideal: una
semntica y una
sintaxis nicas
para cada
servicio.
Todo el

EL MODELO REAL DEL


MIDDLEWARE
Se debe sustituir el Middleware
de la instalacin por el estndar,;
si el contenido semntico y
sintctico del nuevo Middleware
no coincida con el del usuario que
va a sustituir.
Existen dos formas:
Sustituir en bloque, cosa que
muchas veces no es factible,
no solo por la carga de
trabajo, sino por la
distribucin de la plataforma.
Encapsular el nuevo
Middleware con llamadas con
la sintaxis y la semntica
antiguas y usar esta nueva
implementacin a travs de
una compilacin masiva.

You might also like