Universidad Nacional de San Antonio Abad del
Cusco
Departamento Académico de Informática
Iván Medrano Valencia
2005
Introducción
Cuando se necesitaron SI que se
fueran ajustando a las necesidades
de la empresa, la única solución
que podían aportar los primeros
sistemas, debido en gran parte al
elevado costo del hardware, era
una configuración en la que un
único equipo gestionaba toda la
información.
Los distintos puntos en los que se
requería el acceso a esa
información eran conectados al
gran mainframe
Introducción (2)
Todo el código del programa y los datos
residian en el computador central. Esto
hacía que para empresas relativamente
grandes, el SI sea muy grande y
complejo, difícil de mantener.
El sistema quedaba muy poco
escalable, porque todos los terminales
se conectaban a un mismo computador,
lo que hacía que al ir añadiendo más
terminales, el servicio de las peticiones
se hacía mas lento.
Introducción (3)
Ampliaciones tan básicas como la
inclusión de un segundo mainframe,
llevaron a que surgieran preguntas
bastante importantes y que no
estaban resueltas hasta ese
momento. ¿cómo reorganizar la
aplicación monolítica existente si
ahora se tiene dos mainframe?,
¿cómo se redistribuyen los datos
de estas aplicaciones?, ¿cómo se
logra que ambos computadores
trabajen juntos y se distribuyan
el trabajo para aprovechar
realmente ambas capacidades de
trabajo?.
Introducción (4)
De otro lado, en la parte de los
usuarios, equipos cada vez más
potentes podían ser instalados, lo
que lleva a la pregunta razonable
¿cómo se puede conseguir que
la capacidad de procesamiento
de los computadores de los
usuarios sea aportada a la del
sistema global?
En definitiva ¿cómo distribuir la
funcionalidad los datos y los
recursos del SÍ de la empresa
de una forma que sea
escalable y flexible?
Introducción (5)
La capacidad de procesamiento de las
computadoras actuales, dotadas de
conexiones a redes y de SO modernos
hacen que surjan nuevas preguntas,
tales como:
¿Cómo conseguir sistemas abiertos
(en el sentido de que permitan la
inclusión
de
herramientas
y
subsistemas de terceros de forma
sencilla) que permitan integrar los
sistemas
de
la
empresa
(posiblemente
en
diferentes
tecnologías)?
Introducción (6)
¿cómo aprovechar los recursos
proporcionados por las computadoras y
los sistemas operativos de red, incluso
en sistemas heterogéneos con distintas
plataformas hardware y diferente
sistemas operativos?
¿Cómo conseguir que la aplicación
distribuya la funcionalidad entre todos
los equipos de manera que maximice la
productividad, capacidad de
procesamiento y utilización de recursos
y que ala vez permita un diseño
modular, reutilizable, basado en
objetos, portable, independiente de la
plataforma, etc?
¿Cómo integrar el sistema informático
de la empresa con Internet?
Cliente / Servidor
Servidor
Cliente
La respuesta a las preguntas anteriores vino a
través de la inclusión del modelo
cliente/servidor que separa la funcionalidad de
una aplicación en torno a dos roles muy bien
definidos: cliente y servidor.
De modo abstracto, el servidor ofrece una
serie de servicios que pueden ser utilizados por
los clientes para completar la funcionalidad de
la aplicación.
Una interacción básica cliente/servidor
implica a un cliente que inicia una petición de
algún servicio a un servidor, posiblemente
incluyendo algunos parámetros que modifiquen
el
comportamiento
del
servidor.
El servidor entonces realiza la función
especificada por el cliente, devolviendo los
posibles resultados que el servicio genera.
Middleware
Los clientes y servidores se implementan como procesos que están
ejecutando en máquinas conectadas a una red. La infraestructura
que se encarga de conectar de alguna manera los procesos
cliente/servidor es llamada Middleware. El término middleware
engloba a todos los elementos que hacen posible esta
comunicación, desde las líneas físicas de comunicación hasta los
protocolos de alto nivel. El soporte estándar del desarrollo de
aplicaciones distribuidas es Internet (e intranet a nivel de
empresas).
MIDDLEWARE
SERVIDOR
CLIENTE
Unidades funcionales de una
aplicación:
Típicamente una aplicación
consta de:
• Una presentación, ya
sea en base a un GUI o
mediante una terminal de
caracteres, que implemente
la interacción con el usuario
y realiza ciertas
comprobaciones
sencillas(validez de fechas,
etc.)
Unidades funcionales de una
aplicación:
•Una lógica de negocio o funcionalidad, que
implementa la funcionalidad de la aplicación. Esta lógica
de negocio se encarga de realizar todos los procesos
que son requeridos por el sistema de información.
Lógica del
negocio.
Acceso a datos
Servidor
Unidades funcionales de una
aplicación:
 Una lógica de datos, que establece como los
datos de la aplicación son estructurados, ya sea a
través de bases de datos SQL, o a través de
archivos de disco.
Base de
Datos
Clasificación de las
aplicaciones
Cada unidad funcional se puede distribuir en un
procesador especifico para gestionarla.
Tomando como base la manera en que la funcionalidad
se distribuye, las aplicaciones de pueden clasificar en:
•Aplicaciones
•Aplicaciones
•Aplicaciones
•Aplicaciones
de
de
de
de
1
2
3
n
nivel (1 tier) o monolíticos
niveles (2 tier)
niveles (3 tier)
niveles (n tier) o distribuidos
Aplicaciones de 1 nivel
Son aquellas en las que todas las unidades
funcionales de la aplicaciones son
gestionadas en un solo computador.
Interfaz con el usuario
Lógica del negocio
Lógica de datos
Aplicaciones de 2 niveles
Fueron el primer paso en el desarrollo de aplicaciones
Cliente/servidor. Típicamente, la lógica de presentación,
la de negocio y la de datos quedaban en la parte Cliente,
dejando a los servidores encargados solo de guardar los
datos, es decir, como servidores de bases de datos. Esta
organización
Cliente
Presentación
Lógica del negocio
Acceso a datos
Servidor
Lógica de
datos
Aplicaciones de 3 niveles
Aquí, el cliente se encarga de mantener el interfaz gráfico del
usuario mientras que existen una serie de componentes intermedios
en el sistema que se encargan de implementar la lógica de la
aplicación. Finalmente hay un ultimo nivel que se encarga de la lógica
de datos, típicamente SGBDs. En el momento en el que los
componentes de este último nivel se conviertan en clientes de otros
componentes, se convierte en una estructura multinivel o distribuido.
Presentación o interfaz
con el usuario
Lógica del
negocio
Lógica de datos
Sistema de Información
Distribuido
Son el último paso en el modelo cliente/servidor. En vez de
diferenciar entre las distintas partes de la aplicación, los
sistemas distribuidos ofrecen toda la funcionalidad en forma
de objetos. No existen los roles explícitos de cliente y
servidor, sino que toda la funcionalidad esta ahí para ser
utilizada. Los procesos que componen la aplicación y que se
están ejecutando en las distintas máquinas de la red son
clientes y servidor y cooperan para conseguir la
funcionalidad total de la aplicación. Esto da una máxima
flexibilidad.
Sistema de Información
Distribuido (2)
En general, un sistema distribuido es un sistema cliente/servidor
multinivel con un número potencialmente grande de entidades
que pueden desempeñar roles de clientes y servidores según sus
necesidades. El hecho de ofrecer una serie de servicios en forma
de objetos hace que el diseño y desarrollo de haga en base a
interfaces bien definidos que facilitan y apoyan la modularidad y
reutilización, a la vez que permiten un diseño mucho mas flexible.
Modelo de Objetos
Distribuidos
Cada proceso contiene un conjunto de objetos,
algunos de los cuales pueden recibir tanto
invocaciones locales como remotas, mientras que los
otros objetos pueden recibir invocaciones locales. Los
dos conceptos fundamentales siguientes son el
corazón del modelo de objetos distribuidos.


Interfaz remota
Espedifica cuales de sus métodos pueden invocarse
remotamente
Referencia de objeto remoto
Otros objetos pueden invocar los métodos de un objeto
remoto si tienen acceso a su referencia
Modelo de Objetos
Distribuidos
A
Los objetos involucrados en una cadena de invocaciones
relacionadas
pueden
estar
ubicados
en
procesos
o
computadores diferentes. Cuando una invocación cruza los
límites de un proceso o computador, se emplea invocación
remota, y la referencia remota al objeto se hace disponible
para hacer posible la RMI.
C
A
B
E
F
D
Invocación remota
Invocación Local
Teconologías de objetos
distribuidos
Java RMI
CORBA
.NET
ICE (Internet Communication Engine)
RMI: Introducción
RMI -> Remote Method Invocation
Diseñado para trabajar con objetos remotos
RMI integra un modelo de objetos distribuido
en Java ( Distributed Object Programming)
Diseñado específicamente para el entorno
Java
Objetivos de Java Rmi
Semántica similar para objetos locales y
remotos
Llamadas de retorno del servidor al cliente
Integración natural del modelo distribuido en
el modelo Java
Preservar la seguridad y seguridad
proporcionadas por el entorno de ejecución
Java
Cliente
Java
Network
Esquema de componentes
RMI Registry
Objeto
Remoto
Stub
Skeleton
(Descargado de la JVM remota)
JVM Cliente
JVM Remota
Qué es CORBA? (surge OMG)
Finales años 80: se vislumbran cambios
importantes en la computación:
Http
Ethernet
Html
ATM
Internet
Pthreads
UDP
TCP
C++
Sockets
Java
RPC
Qué es CORBA? (surge OMG)
Grandes compañías intentan conseguir el mercado
Microsoft
HP
Sun
IBM
Oracle
Abril de 1989: se
funda
la
Object
Management
Group
(800 empresas)
Qué es CORBA?: 1º factor clave
Interface Definition Languaje (IDL)
C++
Smalltalk
Java
Implementación
oculta por un
interfaz
OLE
(Visual Basic,
Delphi, Builder)
Ada
Cobol, C, etc.
Vista de
servicios
mediante
interfaz
los
el
Qué es CORBA?: 2º factor clave
Internet Inter-Object Protocol (IIOP)
Smalltalk
Java
Sistema
de
Objetos
distribuido
Corba Software Bus: ORB
C++
Interface
definition
Language
Cobol
C
Protocolo de
Comunicaciones
: IIOP
Qué es CORBA?: 3º factor clave
Corba Services
CORBA Services
Naming
Events
Transactions
Security
Smalltalk
Java
Naming
Trader
Notifications
Persistence
Concurrency
Corba Software Bus: ORB
Query
Licensing
(más otros de
C++
Cobol
Security
menor
importancia)
IDL estándar
para los
El núcleo CORBA.
Objeto
Implementación
Cliente
Control
Control
Interfaz
DII
Interface
Repository
Stubs
IDL
ORB
Skeleton
IDL
Object Request Broker
DSI
OA
Implementation
Repository
Descargar

Universidad Nacional de San Antonio Abad del Cusco