Download ambiente_internet
Document related concepts
no text concepts found
Transcript
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 Servidor – Base de Datos Cliente • Cliente: Demanda servicios • Servidor: Provee servicios Arquitectura Cliente/Servidor Servidor – Base de Datos Cliente • • Interfase de usuario Alguna lógica del negocio • • 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 Cliente Cliente Servidor BD Servidor BD Cliente Cliente Servidor BD Conexiones: c * s 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) Servidor de Aplicaciones Cliente Interfase de usuario Administración de las transacciones Servidor de Bases de Datos Lógica del negocio Caché Administración de las transacciones Transparencia en la localización de los datos Balance de carga Administración de los 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 Cliente Cliente Cliente Cliente Servidor de Aplicaciones Servidor BD Servidor BD Servidor BD Conexiones: c + s 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 C Java NVO C NVO ORB IIOP ORB ORB Java C NVO 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 Implementación Interfase Interfase vs Implementación 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); }; }; CORBA - IIOP Método de Invocación Objeto Implementación Objeto Cliente 9. Invoca implementación 1. Invoca método 2. Marshals Objeto Stub 3. Envía requerimiento Skeleton 5. Dirige requerimientos ORB 8. Unmarshals 7. Invoca método ORB 4. Localiza ORB 6. Identifica objeto destino 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 Client Application JavaScript Applet Page Page Applet ActiveX, JavaBeans Applet Page Web Publishing HTTPS HTTPS File System Web Server HTTPS Web OLTP IIOP, DCOM HTML Pages Templates, Scripts Page Sever IIOP, DCOM Transaction Server JDBC, ODBC, Native SQL RDBMS Web Data Processing RDBMS Component Component Java Relational 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: Experiencia Requerida Desarrolladores - Negocio Lifecycle Desarrolladores - GUI Convenciones componentes Desarrolladores - Sistema 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 Java COM HTML IIOP/TDS EAServer SQL PowerBuilder MASP CORBA 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 Librería de clases Requerimiento IIOP 9000 Requerimiento TDS 7878 Requerimiento HTTP 8080 Package Jaguar Manager Repositorio Components 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 / modelosespecíficos de servicios del servidor de aplicaciones – Usadas para implementar servicios de componentes PowerBuilder Ciclo de vida de los componentes Instanciación Ocioso Activación Asignado al Cliente Reutilización Método Ejecutado Desactivación Automática si Desactivación no Primitiva Desactivación Grupo Soporte no Destrucción 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 IIOP Connection Cache Connection Cache 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 Componente //Instance Variables Protected: Transaction 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 //Deactivate event //Release the connection Disconnect using itr_trans; 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 Cliente Jaguar n_order n_order_items add( ) add( ) n_cart placeOrder( ) Jerarquía de componentes • ¿Qué hay de común en los componentes? Instance variables n_cart Instance variables n_order Constructor Activate Deactivate CanBePooled Destructor Instance variables n_order_items Constructor Activate Deactivate CanBePooled Destructor Constructor Activate Deactivate CanBePooled Destructor Definiendo el componente ancestro Instance variables n_ancestor n_cart n_order Constructor Activate Deactivate CanBePooled Destructor n_order_items Extend and Override Descendent Events As Needed Caso Cliente Jaguar Cliente getData( ) getData( ) Cliente getData( ) Product Product Product Objetivo: Caché de datos Client Jaguar getData( ) ServiceProduct Client Client getData( ) getData( ) Product Ambiente / Arquitectura Web HTTP Browser Servidor Web API Servidor Aplicaciones (PD / ASP) PB Web Targets EAServer Sitio Web HTML Datos Corporativos Sitios Web Estáticos HTML Web Browser HTTP Web Server Sitios Web Dinámicos Servidor HTML Web Browser HTTP Servidor Web Bases de Datos WebOLTP Enterprise Application Server Java HTML COM Web Server PowerDynamo HTTP IIOP PowerBuilder CORBA Jaguar CTS Arquitectura Base de datos 1 3 6 2 4 5 Servidor Web / Servidor de páginas Servidor de componentes 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 Especificación Sybase EAServer Bluestone Software Sapphire/Web BEA Systems Vendedores WebLogic 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 EAServer EJB CORBA Arquitectura EJB EJB Server EJB Client EJB Home Interface EJB Container EJB Home Stub Deployment Descriptor EJB Home Enterprise JavaBean EJB Remot e Stub EJB Object EJB Remote Interface *Shaded Blue is developer-created 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 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 EJB Container Remote Stub EJB Object Home Stub 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 Cliente 1 lookup( ) JNDI Jaguar CTS 3 2 Home Stub create( ) CartHome 4 CartBean 5 6 Remote Stub additem( ) 7 Cart Servidores de capa media • • • • • • • Apache Tomcat BEA WebLogic IBM WebSphere Sun ONE Oracle 9i AS Sybase EAS Jrun Macromedia