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 siguiente |