Bases de datos en ambiente Internet

1. Bases de datos en ambiente Internet

2. 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

3. 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

4. Servidor – Base de Datos Cliente Arquitectura Cliente/Servidor • Cliente: Demanda servicios • Servidor: Provee servicios

5. Servidor – Base de Datos Cliente Arquitectura Cliente/Servidor • Interfase de usuario • Alguna lógica del negocio • Administración de datos • Lógica del negocio, en triggers, procedimientos almacenados, …

6. 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

7. 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)

8. Cliente Cliente Cliente Cliente Servidor BD Servidor BD Servidor BD Arquitectura Cliente/Servidor Conexiones: c * s

9. 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).

10. Servidor de Bases de Datos Servidor de Aplicaciones Cliente • Interfase de usuario • Administración de las transacciones • 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 Arquitectura Multitier (Distribuida)

11. 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

12. 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

13. Cliente Cliente Cliente Cliente Servidor BD Servidor BD Servidor BD Arquitectura multicapa Conexiones: c + s Servidor de Aplicaciones

14. Arquitectura multicapa Características • Impredecible el número de clientes/transacciones • Abre las aplicaciones hacia Internet/extranet

15. 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

16. 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

17. Arquitectura multicapa • Razones para pasarse a una arquitectura multicapa • Más escalable • Mayor reutilización de objetos • Listos para desarrollos Web/Inalámbricos

18. 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

19. 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

20. 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

21. 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)

22. ORB ORB IIOP C C C Java Java Java ORB NVO NVO NVO CORBA ORB (Object Request Broquer)

23. 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

24. 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

25. 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

26. Implementación Interfase onoff Interfase vs Implementación

27. onoff Interfase vs Implementación Implementación Interfase InterfaseRemota = Stub (o Proxy)

28. onoff CORBA Lenguaje de definición de la Interfase IDL (Interface Definition Language) module financiero { interface Prestamo { double calcular(in double cantidad, in long meses); }; };

29. CORBA - IIOP Método de Invocación Objeto Cliente Objeto Implementación 9. Invoca implementación 1. Invoca método Objeto Stub Skeleton 8. Unmarshals 2. Marshals 5. Dirige requerimientos 3. Envía requerimiento 7. Invoca método ORB ORB 4. Localiza ORB 6. Identifica objeto destino IIOP

30. IIOP • IIOP (Internet Inter-ORB Protocol) • IIOP define estándares para el envío de requerimientos ORB sobre protocolos de comunicaciones de bajo nivel

31. 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

32. 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

33. 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

34. 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

35. 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

36. Arquitectura ambiente Internet

37. Client Application Web Publishing JavaScript ActiveX, JavaBeans Page Applet Applet Page Transaction Server Applet Page HTTPS Web OLTP HTTPS JDBC, ODBC, Native File System Web Server HTTPS IIOP, DCOM HTML Pages RDBMS Java Relational IIOP, DCOM Component Templates, Scripts Page Sever Component SQL RDBMS Web Data Processing Arquitectura ambiente Internet

38. 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?

39. Server Rol del Servidor de Aplicaciones • Manejo eficiente de • Instanciación de componentes y ciclo de vida • Conexiones a bases de datos • Transacciones • Seguridad:

40. Experiencia Requerida Desarrolladores - Negocio Lifecycle Threads Transactions Security Desarrolladores - GUI Connections Convenciones componentes Desarrolladores - Sistema

41. 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

42. Administración del ciclo de vida de componentes • Define como los componentes son: • Instanciados • Asignados a los clientes • Destruidos • Provee suporte para instanciar pooling

43. Connection Cache JCM Caché de conección • Pools de componentes de conexiones compartidas preasignadas a servidores remotos de bases de datos

44. Administración de transacciones • Permite definir semántica transaccional de componentes como parte de la interfase de componentes

45. 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)

46. Java COM HTML IIOP/TDS C++ EAServer SQL PowerBuilder CORBA MASP Soporte para clientes y componentes

47. Soporte J2EE • EJB • Aplicaciones J2EE • Aplicaciones Web J2EE • Caché de Objetos • JavaMail • Java API para XML • Servicios Java de Autenticación y Autorización

48. Jaguar Server Librería de clases Requerimiento IIOP 9000 Requerimiento TDS 7878 Requerimiento HTTP 8080 C++ Components Package Jaguar Manager Repositorio Ambiente del EAServer

49. 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

50. Arranque del EAServer