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 distribuidas
Especialmente si el número de usuarios es pequeño
Si no se piensa en servicios a través de la Web
Si no hay código reutilizable entre aplicaciones
Si la lógica del negocio no cambia o los cambios son muy esporádicos
Arquitectura multicapa
En aplicaciones muy grandes
Generalmente están escritas en muchos lenguajes
Utilizando diferentes herramientas
Con 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)
CORBA
(Gp:) Java
(Gp:) NVO
(Gp:) C
(Gp:) ORB
(Gp:) Java
(Gp:) NVO
(Gp:) C
(Gp:) ORB
(Gp:) Java
(Gp:) NVO
(Gp:) C
(Gp:) ORB
(Gp:) IIOP
ORB (Object Request Broquer)
OMG
OMG Object Management Group
OMG provee especificaciones y estándares
No provee software ni implementaciones
Diferentes 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 provee
Mayor flexibilidad
Mayor apertura
Mayor integración
Con diferentes plataformas
Con diferentes lenguajes
Con diferentes herramientas
Interfase vs Implementación
(Gp:) onoff
(Gp:) Implementación
(Gp:) Interfase
Interfase vs Implementación
(Gp:) onoff
Implementación
Interfase
Interfase Remota = Stub (o Proxy)
CORBA
Lenguaje de definición de la Interfase IDL (Interface Definition Language)
module financiero {
interface Prestamo { double calcular(in double cantidad, in long meses); };
};
(Gp:) onoff
CORBA – IIOP Método de Invocación
Objeto Cliente
Objeto Stub
ORB
1. Invoca método
2. Marshals
3. Envía requerimiento
4. Localiza ORB
5. Dirige requerimientos
ORB
6. Identifica objeto destino
Skeleton
7. Invoca método
Objeto
Implementació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 clientes
2. 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
Arquitectura ambiente Internet
(Gp:) ActiveX,
JavaBeans
(Gp:)
JavaScript
(Gp:) Web
Publishing
(Gp:) Web
OLTP
(Gp:) IIOP, DCOM
(Gp:) HTTPS
(Gp:) HTTPS
(Gp:) HTML Pages
(Gp:) File
System
(Gp:) Web Data Processing
(Gp:) IIOP, DCOM
(Gp:) Templates, Scripts
(Gp:) SQL
(Gp:) RDBMS
(Gp:) Page Sever
(Gp:) JDBC, ODBC, Native
(Gp:) Java Relational
(Gp:) Transaction
Server
(Gp:) RDBMS
(Gp:) Component
(Gp:) Component
(Gp:) Web Server
(Gp:) HTTPS
(Gp:) Client Application
(Gp:) Page
(Gp:) Page
(Gp:) Page
(Gp:) Applet
(Gp:) Applet
(Gp:) 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 vida
Conexiones a bases de datos
Transacciones
Seguridad:
(Gp:) Server
Experiencia Requerida
Lifecycle
Threads
Security
Connections
Transactions
Desarrolladores – GUI
Desarrolladores – Sistema
Desarrolladores – Negocio
Convenciones
componentes
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
(Gp:) JCM
(Gp:) 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
(Gp:) HTML
(Gp:) COM
(Gp:) PowerBuilder
(Gp:) CORBA
(Gp:) Java
(Gp:) IIOP/TDS
(Gp:) MASP
(Gp:) SQL
(Gp:) EAServer
(Gp:) C++
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
(Gp:)
(Gp:) Jaguar Server
(Gp:) 9000
(Gp:) Repositorio
(Gp:) Jaguar Manager
(Gp:) Requerimiento IIOP
(Gp:) Package
(Gp:) Components
(Gp:) 7878
(Gp:) Requerimiento TDS
(Gp:) 8080
(Gp:) Requerimiento HTTP
(Gp:)
(Gp:) Librería de clases
(Gp:) C++
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
Arranque del EAServer
Conexión al EAServer – Jaguar Manager
Jaguar Manager
Server Log
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
(Gp:) C++
(Gp:) C
(Gp:) PowerBuilder
Ciclo de vida de los componentes
(Gp:) Ocioso
(Gp:) Asignado al Cliente
(Gp:) Método Ejecutado
(Gp:) no
(Gp:) no
(Gp:) si
(Gp:) Desactivación
(Gp:) Desactivación
(Gp:) Instanciación
(Gp:) Destrucción
(Gp:) Reutilización
(Gp:) Activación
(Gp:) Desactivación
Automática
(Gp:) Grupo
Soporte
(Gp:) 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.
Administración de conexiones
Connection Manager
Connection Cache
Connection Cache
IIOP
Administrador de conexiones
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
(Gp:) //Instance Variables
Protected:
Transaction itr_trans
(Gp:) Componente
(Gp:) //Deactivate event
//Release the connection
Disconnect using itr_trans;
(Gp:) // Activate Event
If NOT IsValid(itr_trans) then
itr_trans = CREATE transaction
END IF
Itr_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
(Gp:) Jaguar
(Gp:) Cliente
(Gp:) n_order_items
(Gp:) n_cart
(Gp:) n_order
(Gp:) add( )
(Gp:) add( )
(Gp:) placeOrder( )
Jerarquía de componentes
¿Qué hay de común en los componentes?
n_order
n_order_items
n_cart
Instance variables
Instance variables
Instance variables
Constructor
Activate
Deactivate
CanBePooled
Destructor
Constructor
Activate
Deactivate
CanBePooled
Destructor
Constructor
Activate
Deactivate
CanBePooled
Destructor
Definiendo el componente ancestro
(Gp:) n_order
(Gp:) n_order_items
(Gp:) n_cart
(Gp:) n_ancestor
(Gp:) Extend and Override Descendent Events As Needed
(Gp:) Instance variables
(Gp:) Constructor
Activate
Deactivate
CanBePooled
Destructor
Caso
(Gp:) Jaguar
(Gp:) Cliente
(Gp:) Product
(Gp:) getData( )
(Gp:) getData( )
(Gp:) Cliente
(Gp:) Cliente
(Gp:) getData( )
(Gp:) Product
(Gp:) Product
Objetivo: Caché de datos
(Gp:) Jaguar
(Gp:) Client
(Gp:) Product
(Gp:) getData( )
(Gp:) getData( )
(Gp:) Client
(Gp:) Client
(Gp:) getData( )
(Gp:) ServiceProduct
Ambiente / Arquitectura Web
(Gp:) EAServer
(Gp:) Servidor Aplicaciones
(PD / ASP)
(Gp:) Browser
(Gp:) HTTP
(Gp:) Datos
Corporativos
(Gp:) Sitio Web
(Gp:) HTML
(Gp:) API
(Gp:) Servidor Web
(Gp:) PB
Web Targets
Sitios Web Estáticos
(Gp:) HTML
(Gp:) HTTP
(Gp:) Web Browser
(Gp:) Web Server
Sitios Web Dinámicos
(Gp:) HTML
(Gp:) HTTP
(Gp:) Web Browser
(Gp:) Servidor Web
(Gp:) Servidor
(Gp:) Bases de Datos
WebOLTP
(Gp:) HTML
(Gp:) COM
(Gp:) PowerBuilder
(Gp:) CORBA
(Gp:) Java
(Gp:) PowerDynamo
(Gp:) HTTP
(Gp:) IIOP
(Gp:) Jaguar CTS
(Gp:) Web Server
(Gp:) Enterprise Application Server
Arquitectura
Servidor de componentes
Servidor Web / Servidor de páginas
Base de datos
1
(Gp:) 2
(Gp:) 3
(Gp:) 4
(Gp:) 5
(Gp:) 6
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
EJB
by
Sun Microsystems
Bluestone
Software
Sybase
BEA
Systems
EAServer
Sapphire/Web
WebLogic
Especificación
Vendedores
Servidores
EJB-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
(Gp:) EAServer
(Gp:) CORBA
(Gp:) EJB
Arquitectura EJB
(Gp:) EJB Server
(Gp:) EJB Container
(Gp:) EJB Object
(Gp:) Enterprise
JavaBean
(Gp:) Deployment
Descriptor
(Gp:) EJB Client
(Gp:) EJB Remote
Stub
(Gp:) EJB Home
Stub
(Gp:) EJB Home
Interface
(Gp:) EJB Remote
Interface
(Gp:) *Shaded Blue is developer-created
(Gp:) 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
Servidor
Container
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 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 Object
EJB Home
EJB
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 CTS
Cliente
additem( )
create( )
Cart
CartHome
JNDI
Home Stub
Remote Stub
CartBean
1
2
5
4
3
6
7
lookup( )
Servidores de capa media
Apache Tomcat
BEA WebLogic
IBM WebSphere
Sun ONE
Oracle 9i AS
Sybase EAS
Jrun Macromedia
 Página anterior | Volver al principio del trabajo | Página siguiente  |