Date post: | 01-Jan-2016 |
Category: |
Documents |
Upload: | carlos-davis-rivera-pena |
View: | 7 times |
Download: | 0 times |
Objetivos
• Conocer la arquitectura cliente/servidor• Conocer la arquitectura multitier• Conocer la arquitectura Internet con bases de datos• Conocer las generalidades de un servidor de
aplicaciones• Conocer servidores de aplicaciones que se ofrecen
en el mercado
Características deseables de un sistema de información
• Infraestructura modular• Infraestructura versátil • Facilidad de uso
– Usuarios aprenden a manipular la herramienta disponible• Interoperabilidad
– Dos o más sistemas o componentes intercambian información de manera sencilla
• Escalabilidad– Facilidad de modificar y adaptar un sistema a las necesidades del problema
para el cual fue diseñado• Flexibilidad
– Capacidad de modificar un sistema para solucionar un problema para el cual no fue diseñado inicialmente
Arquitectura Cliente/Servidor
• Cliente: Demanda servicios• Servidor: Provee servicios
Cliente
Servidor – Base de Datos
Arquitectura Cliente/Servidor
• Interfase de usuario• Alguna lógica del negocio
Cliente
Servidor – Base de Datos
• Administración de datos• Lógica del negocio, en triggers,
procedimientos almacenados, …
Arquitectura Cliente/Servidor
• Arquitectura de dos niveles (two tier)• Mantenimiento no particionado del código• Al hacer cambios hay que volver a comprobar• Hay que administrar las máquinas de los clientes• Los cambios en aplicaciones hay que volverlos a distribuir
a todos los clientes• Hay que administrar el rendimiento• El hardware debe soportar el software requerido por los
aplicativos
Arquitectura Cliente/Servidor
• Control no centralizado• Difícil implementar seguridad• Cuellos de botella en los servidores de Bases de
datos• Se tienen muchas conexiones• La lógica del negocio se encuentra en la base de
datos (escrita en lenguaje propietario)
Arquitectura Cliente/Servidor
Conexiones: c * s
Cliente Cliente Cliente Cliente
Servidor BD Servidor BD Servidor BD
Arquitectura Cliente/Servidor
• En trabajo en grupo/departamental• Se controla el número de clientes y así el número
de transacciones• Hay que controlar la(s) plataforma(s).
Arquitectura Multitier (Distribuida)
Cliente
Interfase de usuario Administración de las
transacciones
Administración de los datos
Servidor de Aplicaciones
Lógica del negocio Caché Administración de las
transacciones Transparencia en la
localización de los datos Balance de carga
Servidor de Bases de Datos
Ventajas de la arquitectura multicapa
• Cliente más liviano• Menos administración en el cliente• Lógica encapsulada• Mejor rendimiento• Escalabilidad• Consistencia, control y seguridad• Reusabilidad de componentes existentes• Listo para usar la Web
Desventajas de la arquitectura multicapa
• Hay que cambiar los hábitos de programación• Curva de aprendizaje• Más tiempo en diseño y tiempo de desarrollo
iniciales • Más puntos posibles de fallas
Arquitectura multicapa
Conexiones: c + s
Cliente Cliente Cliente Cliente
Servidor de Aplicaciones
Servidor BD Servidor BD Servidor BD
Arquitectura multicapa
Características• Impredecible el número de clientes/transacciones• Abre las aplicaciones hacia Internet/extranet
Arquitectura multicapa
Principios de la arquitectura Multitier• Encapsula o “particiona” la lógica del negocio en objetos.• Mueve o “distribuye” los objetos del negocio a una
máquina dedicada• Da acceso o permite alojar a los objetos en un servidor de
aplicaciones
El servidor de aplicaciones recibe requerimientos de procesamiento de los clientes. El servidor dirige los requerimientos a los objetos del negocio para su procesamiento
Arquitectura multicapa
Ejemplos• Lógica de negocio: aprobación de préstamos,
autorización de tarjeta de crédito• Datos en caché: estados, partes/productos• Servicios para recursos especializados: vía hacia
un computador servidor tipo mainframe o hacia un servidor de fax, servicios inalámbricos de la vida real
Arquitectura multicapa
• Razones para pasarse a una arquitectura multicapa– Más escalable– Mayor reutilización de objetos– Listos para desarrollos Web/Inalámbricos
Arquitectura multicapa
No todas las aplicaciones necesitan estar distribuidasEspecialmente si el número de usuarios es pequeñoSi no se piensa en servicios a través de la WebSi no hay código reutilizable entre aplicacionesSi la lógica del negocio no cambia o los cambios son muy esporádicos
Arquitectura multicapa
• En aplicaciones muy grandesGeneralmente están escritas en muchos lenguajesUtilizando diferentes herramientasCon clientes heterogéneos (incluyendo aplicaciones HTML basadas en la Web)Máquinas de los clientes heterogéneas
Allí se necesita arquitectura distribuida. En estos casos no se pueden administrar fácilmente las aplicaciones en un ambiente típico de dos niveles
CORBA
• CORBA: Common Object Request Broker Architecture• Arquitectura estándar para objetos distribuidos
– Desarrollada por OMG (Object Management Group)– Establecida en 1989– Incluye más de 800 compañías (IBM, SUN, Oracle, Sybase, ...)– No incluye a Microsoft
• DCOM compite con CORBA
• Independiente de proveedor• Separa la interfase de la implementación
CORBA
• Componentes CORBA típicamente aceptados en los servidores de aplicaciones– CORBA-Java– Objetos no visuales (NVA, Non-Visual Objects)– CORBA C++ / C– ActiveX– EJB (Enterprise Java Beans)
OMG
OMG Object Management Group
OMG provee especificaciones y estándaresNo provee software ni implementacionesDiferentes proveedores implementan las especificaciones
Una ventaja de CORBA es que para escribir software que inter-opere con otro software vía un objeto, solamente se necesita conocer la interfase para ese software, no se necesita conocer detalles de la implementación
La separación de la interfase y la implementación es lo que hace que CORBA sea independiente del lenguaje
CORBA
CORBA permite la comunicación desde cualquier lenguaje hacia cualquier otro lenguaje sobre cualquier plataforma
• Plataformas Soportadas :– Independiente de la plataforma
• Lenguajes/Componentes Soportados :– Independiente de lenguaje
CORBA
CORBA no se debe presentar como si tuviera siempre la mejor solución
CORBA proveeMayor flexibilidadMayor aperturaMayor integración
Con diferentes plataformasCon diferentes lenguajesCon diferentes herramientas
CORBA
Lenguaje de definición de la Interfase IDL (Interface Definition Language)
module financiero {
interface Prestamo {double calcular(in double cantidad,
in long meses); };
};
on
off
CORBA - IIOP Método de Invocación
Objeto ClienteObjeto Cliente
Objeto StubObjeto Stub
ORBORB
1. Invoca método
2. Marshals
3. Envía requerimiento
4. Localiza ORB
5. Dirige requerimientos
ORBORB
6. Identifica objeto destino
SkeletonSkeleton
7. Invoca método
ObjetoImplementación
ObjetoImplementación
9. Invoca implementación
8. Unmarshals
IIOP
IIOP
• IIOP (Internet Inter-ORB Protocol) • IIOP define estándares para el envío de
requerimientos ORB sobre protocolos de comunicaciones de bajo nivel
CORBA - Stubs
• Objetos locales proxy• Marshal los métodos de invocación• Delega la invocación de métodos al objeto remoto de
implementación• Provee transparencia de localización• Implementa la misma interfase como la deseada del
objeto remoto• Implementa métodos IDL definidos en el lenguaje de
programación del cliente
ORB (Object Request Broker)
• Maneja todas las comunicaciones entre objetos en un sistema de objetos distribuidos:1. Acepta requerimientos de los clientes2. Localiza y activa los objetos a. Identifica la máquina que ejecuta el objeto servidor
b. Pregunta por el ORB de la máquina para una conexión al servidor
3. Enruta el requerimiento y recibe las respuestas
CORBA - Skeleton
• Implementa el mecanismo por medio del cual el requerimiento que va al servidor puede ser unmarshaled y dirigido al método correcto
• Pega el objeto de implementación al runtime ORB• Unmarshals los argumentos del método• Envía métodos a la instancia del objeto
implementado• También conocido como la clase base de
implementación
Implementación
• Define el comportamiento de todas las operaciones y atributos que soporta la interfase
• Creada usando un lenguaje de programación o un modelo de componentes tales como Java, C, C++, or ActiveX
Servidor
• Programa que contiene la implementación de uno o más tipos de objetos
• Provee un ambiente para alojar componentes• Instancia objetos CORBA• Aplica seguridad• Maneja:
– Transacciones– Fallas– Balanceo de carga
Arquitectura ambiente Internet
ActiveX,JavaBeansJavaScript
WebPublishing
WebOLTPIIOP,
DCOM
HTTPSHTTPS
HTML Pages
FileSystem
Web Data Processing
IIOP, DCOM
Templates, Scripts
SQL
RDBMS
Page SeverPage Sever
JDBC, ODBC, Native
Java Relational
TransactionServerTransactionServer
RDBMSComponent
Component
Web ServerWeb Server
HTTPS
Client ApplicationClient Application
Page
Page
Page Applet
Applet
Applet
Arquitectura distribuida
• ¿Cuántas instancias de un componente se pueden tener?
• ¿Cuántas conexiones a bases de datos se pueden tener?
• ¿Cómo se pueden manejar transacciones entre varios componentes?
• ¿Quién puede acceder al servidor?
Rol del Servidor de Aplicaciones
• Manejo eficiente de Instanciación de componentes y ciclo de vidaConexiones a bases de datos– Transacciones– Seguridad:
Server
Experiencia Requerida
Lifecycle
ThreadsSecurity
Connections
Tran
sact
ions
Desarrolladores - GUI
Desarrolladores - Sistema
Desarrolladores - Negocio
Convencionescomponentes
Rol del CTS
• CTS (Component Transaction Server)• Provee un marco para desarrollo de lógica en la capa media,
de aplicaciones basadas en componentes distribuidas• Provee soporte para:
– Administración del ciclo de vida de componentes– Caché de conexiones– Administración de transacciones– Seguridad
Administración del ciclo de vida de componentes
• Define como los componentes son:– Instanciados– Asignados a los clientes– Destruidos
• Provee suporte para instanciar pooling
Caché de conección
• Pools de componentes de conexiones compartidas preasignadas a servidores remotos de bases de datos
Connection Cache
Administración de transacciones
• Permite definir semántica transaccional de componentes como parte de la interfase de componentes
Administración de seguridad
• Incluida, basada en roles para autenticación y autorización de usuarios
• Autenticación de usuarios cuando la aplicación cliente crea un stub
• Lista de control de acceso para cada componente, la cual determina qué usuarios pueden invocar un componente
• Soportan certificados digitales• Soportan SSL (Secure Socket Layer)
Soporte para clientes y componentes
HTML
COM
PowerBuilder
CORBA
Java
IIOP/TDSIIOP/TDS
MASP
SQL EAServer
Soporte J2EE
• EJB• Aplicaciones J2EE• Aplicaciones Web J2EE• Caché de Objetos• JavaMail• Java API para XML• Servicios Java de Autenticación y Autorización
Ambiente del EAServer
Jaguar Server
9000
RepositorioJaguar Manager
Requerimiento IIOP
PackageComponents
7878Requerimiento TDS
8080Requerimiento HTTP
Librería de clases
Servidor EAServer
• Provee un ambiente de ejecución por componentes• Maneja requerimientos de clientes• Instancia componentes• Maneja seguridad, transacciones, caché de
conexiones, balance de carga y fallas• Definido usando Jaguar Manager
Componentes en el EAServer
• La definición de un componente consiste de:– Métodos firmados– Modelo de componentes– Suporte de transacciones– Nombres de clases Java o librerías ejecutables que
implementan componentes (DLL, …)
Package en el EAServer
• Grupo de componentes relacionadas• Colección de componentes que trabajan juntas para
proveer algún aspecto de la lógica de las aplicaciones
• Define un “límite de verdad” dentro del cual los componentes se pueden comunicar fácilmente
• Unidad de distribución, agrupando recursos de aplicaciones para facilitar su distribución y administración
Repositorio en el EAServer
• El repositorio del EAServer contiene:
– Información de configuración del servidor de aplicaciones
– Metadatos para paquetes de aplicaciones, componentes y métodos
• EAServer utiliza el repositorio para encontrar e invocar componentes
Librerías de clases / Máquinas virtuales
• Jaguar provee un conjunto de Librerías de clases / Máquinas virtuales
– Librerías de clases / Máquinas virtuales para cada lenguaje / modelo soportado
• Las Librerías de clases / Máquinas virtuales son:
– Implementaciones de lenguaje / modelos-específicos de servicios del servidor de aplicaciones
– Usadas para implementar servicios de componentes
PowerBuilder
Ciclo de vida de los componentes
Ocioso
Asignado al Cliente
Método Ejecutado
no
no
si
Desactivación
Desactivación
Instanciación
Destrucción
Reutilización
Activación
DesactivaciónAutomática Grupo
Soporte
Primitiva
Componentes – Estrategias de diseño• Stateful.
– Persistente. La instancia permanece asignada al cliente entre llamadas a métodos.
– La instancia puede guardar información del estado.– El desarrollador es responsable de iniciar el evento Deactivate.– La instancia no puede ser utilizada por otros clientes mientras no
sea liberada del cliente asignado.• Stateless.
– No persistente. El evento Deactivate se ejecuta automáticamente después de cada llamada a métodos.
– Para cada llamada a método no se puede asumir qué instancia será asignada al cliente.
– El desarrollador es responsable de inicializar la instancia.
Stateful vs Stateless
Stateful La instancia se asigna
al cliente por periodos largos.
El servidor maneja más instancias.
Las instancias son reutilizadas con menos frecuencia.
El servidor requiere más recursos limitando la escalabilidad.
Stateless La instancia es
asignada al cliente por periodos cortos.
El servidor maneja menos instancias.
Las instancias son reutilizadas con mayor frecuencia.
El servidor requiere menos recursos.
Connection Cache
• Pool de conexiones disponibles a una base de datos específica
• Todas las conexiones en un caché comparten:– User ID y password– Base de datos– Librería de conectividad
Ventajas de Connection Cache
• Da rendimiento– Elimina la sobrecarga asociada con el requerimiento y fijación de
una conexión• Proporciona escalabilidad
– Permite al servidor de aplicaciones atender cientos de clientes usando sólo unas pocas conexiones a la base de datos
• Control sobre el número de conexiones a la base de datos– Establece un número máximo de conexiones en un ambiente de
carga impredecible
Conexión a una base de datos
//Instance VariablesProtected:Transaction itr_trans
Componente
//Deactivate event//Release the connectionDisconnect using itr_trans;
// Activate EventIf NOT IsValid(itr_trans) then itr_trans = CREATE transactionEND IFItr_trans.dbms = “ODBC”Itr_trans.DBParm =&“UseContextObject=‘Yes’,CacheName=‘EASDemoDB’”CONNECT USING itr_trans;If itr_trans.sqlcode <> 0 THEN … process error
Transacción
• Secuencia de sentencias SQL que se comportan como una unidad lógica de trabajo
– Cada sentencia SQL ejecuta una parte del trabajo total– Todas las sentencias SQL deben terminar de manera
exitosa para que la tarea termine– Si cualquier sentencia falla, todas las sentencias
anteriores se deshacen
Objetivo
Jaguar
Cliente
n_order_itemsn_order_itemsn_order_itemsn_order_itemsn_cartn_cartn_cartn_cart
n_ordern_ordern_ordern_order add( )
add( ) placeOrder( )
Jerarquía de componentes• ¿Qué hay de común en los componentes?
n_ordern_order n_order_itemsn_order_itemsn_cartn_cart
Instance variables
Instance variables
Instance variables
ConstructorActivateDeactivateCanBePooledDestructor
ConstructorActivateDeactivateCanBePooledDestructor
ConstructorActivateDeactivateCanBePooledDestructor
Definiendo el componente ancestro
n_ordern_order n_order_itemsn_order_itemsn_cartn_cart
n_ancestorn_ancestor
Extend and Override Descendent Events As Needed
Instance variables
ConstructorActivateDeactivateCanBePooledDestructor
Caso
Jaguar
Cliente
ProductProductProductProduct
getData( )getData( )
Cliente Cliente
getData( )
ProductProductProductProductProductProductProductProduct
Objetivo: Caché de datos
Jaguar
Client
ProductProductProductProduct
getData( )getData( )
Client Client
getData( )
ServiceProductServiceProductServiceProductServiceProduct
Ambiente / Arquitectura Web
EAServer
Servidor Aplicaciones
(PD / ASP)
Browser
HTTP
DatosCorporativos
Sitio Web
HTML
API
Servidor Web
PB Web Targets
WebOLTP
HTML
COM
PowerBuilderCORBA
Java PowerDynamo
HTTP
IIOPIIOP
Jaguar CTS
Web Server
Enterprise Application Server
Llamado de componentes EAServer
<HTML><TITLE>Result.stm</TITLE><BODY><H1>Loan Calculator</H1>
<!--script
/* Initialize the Java stub */
var loan = java.CreateComponent("finance/n_loan", "iiop://localhost:9000", "jagadmin", "");
/* Invoke the Jaguar component method */
var payment = loan.of_calculate(document.value.amount, document.value.months);
/* Process the results of the method call */
document.WriteLn("Your monthly payment is: "+payment);
-->
</BODY></HTML>
Enterprise JavaBeans
• Especificación del lado servidor del modelo de componentes Java• Escritas por Sun Microsystems con apoyo de muchas compañías (Sybase, IBM,
Oracle, BEA, …)• Vendedores implementan la especificación
EJBby
Sun MicrosystemsBluestoneSoftware
BluestoneSoftware
SybaseSybase
BEA Systems
BEA Systems
EAServerEAServer
Sapphire/WebSapphire/Web
WebLogicWebLogic
Especificación Vendedores ServidoresEJB-Compliant
EJB y EAServer
• EAServer implementa la arquitectura EJB sobre CORBA• EJB provee un estándar para el modelo de componentes Java del lado servidor• CORBA provee interoperabilidad con componentes que no son componentes EJB
EAServerEAServer
CORBA
EJB
Arquitectura EJB
EJB Server
EJB Container
EJB Object
Enterprise
JavaBean
DeploymentDescriptor
EJB Client
EJB Remot
eStub
EJB Home Stub
EJB Home Interface
EJB Remote
Interface *Shaded Blue is developer-created
EJB Home
Servidor EJB
• Proceso de alto nivel que contiene el EJB container• Puede tener múltiples containers• Provee disponibilidad JNDI servicio de nombres y servicio
de transacciones• Ejemplos de servidores EJB:
– Servidores de bases de datos– Servidores de aplicaciones– Servidores de capa media– EAServer es un servidor EJB
EJB Container
• Intercepta todas las llamadas a los Bean para dar el servicio requerido por el componente EJB basado en propiedades declarativas (in deployment descriptor)
• Puede tener uno o muchos Enterprise JavaBeans• EAServer es el EJB Container más el EJB Server
ServidorContainer
EJB
EJB Cliente
• Provee la interfase lógica de usuario en la máquina cliente• Hace llamadas a componentes remotos EJB en un
servidor• No se comunica directamente con los componentes EJB• Interactúa con objetos del lado servidor:
– EJB Home – EJB Object
EJB ContainerEJB Container
EJB Home Stub
• Usado por el cliente para crear, encontrar y quitar instancias EJB• Retorna referencia del objeto EJB al cliente, como un stub remoto• El cliente usa el objeto EJB para acceder a los métodos del Bean
Home Stub
Remote Stub EJB ObjectEJB Object
EJB HomeEJB Home EJBEJB
EJB Remote Stub
• Provee la interfase al Enterprise JavaBean– Contiene los métodos sin la implementación– Llamadas dirigidas al objeto EJB se dirigen al Bean vía
el container• El cliente interactúa con EJB Remote Object stub
como si el Bean fuera local
Tipos EJB
• Sesión Bean:– Administra el flujo de trabajo– Transiente– Procesos del negocio (proceso
de pagos, reservas, …)– Dura una simple sesión– Transaccional, pero no
recuperable si falla– Stateful o stateless– Debe manejar persistencia– No tiene llave primaria
• Entidad Bean– Representa objeto de datos (filas
en una taba de base de datos)– Persistente– Sustantivo (cliente, producto,
empaque, orden, ...)– Alrededor de señal– Transicional, recuperable en fallas– Inherentemente stateful– Administrado Bean o container – Tiene llave primaria
Proceso de Aceso EJB
Jaguar CTSJaguar CTS
ClienteCliente
additem( )
create( )
CartCart
CartHomeCartHome
JNDIJNDI
Home Stub
Remote Stub
CartBeanCartBean
1
2
5
43
6
7
lookup( )