Bases de datos en ambiente Internet

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 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 Servidor de Aplicaciones 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 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 Java NVO C ORB Java NVO C ORB Java NVO C ORB 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 on off Implementación Interfase

Interfase vs Implementación on off 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); }; }; on off

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

ActiveX, JavaBeansJavaScript Web Publishing Web OLTP IIOP, DCOM HTTPS HTML Pages File System Web Data Processing IIOP, DCOM Templates, Scripts SQL RDBMS Page Sever JDBC, ODBC, Native Java Relational Transaction Server Transaction Server RDBMS Component Web Server HTTPS Client Application Page 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: 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 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/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 Repositorio Jaguar Manager Requerimiento IIOP Package Components 7878 Requerimiento TDS 8080 Requerimiento 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

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 PowerBuilder

Ciclo de vida de los componentes Ocioso Asignado al Cliente Método Ejecutado no si Desactivación Instanciación Destrucción Reutilización Activación Desactivación Automá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.

Administración de conexiones 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 //Instance Variables Protected: Transaction itr_trans Componente //Deactivate event //Release the connection Disconnect using itr_trans; // 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 Jaguar Clienten_order_itemsn_order_items n_cartn_cart n_ordern_order add( ) placeOrder( )

Jerarquía de componentes ¿Qué hay de común en los componentes? n_ordern_order_itemsn_cart Instance variables Constructor Activate Deactivate CanBePooled Destructor Constructor Activate Deactivate CanBePooled Destructor Constructor Activate Deactivate CanBePooled Destructor

Definiendo el componente ancestro n_ordern_order_itemsn_cart n_ancestor Extend and Override Descendent Events As Needed Instance variables Constructor Activate Deactivate CanBePooled Destructor

Caso Jaguar ClienteProductProduct getData( ) Cliente getData( ) ProductProduct ProductProduct

Objetivo: Caché de datos Jaguar Client ProductProduct getData( ) Client getData( ) ServiceProductServiceProduct

Ambiente / Arquitectura Web EAServer Servidor Aplicaciones (PD / ASP) Browser HTTP Datos Corporativos Sitio Web HTML API Servidor Web PB Web Targets

Sitios Web Estáticos HTML HTTP Web Browser Web Server

Sitios Web Dinámicos HTML HTTP Web Browser Servidor Web Servidor Bases de Datos

WebOLTP HTML COM PowerBuilder CORBA Java PowerDynamo HTTP IIOP Jaguar CTS Web Server Enterprise Application Server

Arquitectura Servidor de componentesServidor Web / Servidor de páginas Base de datos

Llamado de componentes EAServer Result.stm Loan Calculator <!--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); -->

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 VendedoresServidores 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 EAServer CORBA EJB

Arquitectura EJB EJB Server EJB Container EJB Object Enterprise JavaBean Deployment Descriptor EJB Client EJB Remot e Stub 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 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 lookup( )

Servidores de capa media Apache Tomcat BEA WebLogic IBM WebSphere Sun ONE Oracle 9i AS Sybase EAS Jrun Macromedia