Bases de datos en ambiente Internet. Objetivos Conocer la arquitectura cliente/servidor Conocer la arquitectura multitier Conocer la arquitectura Internet

Bases de datos en ambiente Bases de datos en ambiente InternetInternet

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


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


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


Conexiones: c * s

Cliente Cliente Cliente Cliente

Servidor BD Servidor BD Servidor BD


• 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 Cliente Cliente Cliente

Servidor de Aplicaciones

Servidor BD Servidor BD Servidor BD


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


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


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


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


No todas las aplicaciones necesitan estar distribuidasEspecialmente si el número de usuarios es pequeñoSi no se piensa en servicios a través de la WebSi no hay código reutilizable entre aplicacionesSi la lógica del negocio no cambia o los cambios son muy esporádicos


• En aplicaciones muy grandesGeneralmente están escritas en muchos lenguajesUtilizando diferentes herramientasCon 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

ORBORB

Java

NVO

C

ORBORB

Java

NVO

C

ORBORB

IIOPIIOP

ORB (Object Request Broquer)

OMG

OMG Object Management Group

OMG provee especificaciones y estándaresNo provee software ni implementacionesDiferentes 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 proveeMayor flexibilidadMayor aperturaMayor integración

Con diferentes plataformasCon diferentes lenguajesCon 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 ClienteObjeto Cliente

Objeto StubObjeto Stub

ORBORB

1. Invoca método

2. Marshals

3. Envía requerimiento

4. Localiza ORB

5. Dirige requerimientos

ORBORB

6. Identifica objeto destino

SkeletonSkeleton

7. Invoca método

ObjetoImplementación

ObjetoImplementació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 clientes2. 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

ActiveX,JavaBeansJavaScript

WebPublishing

WebOLTPIIOP,

DCOM

HTTPSHTTPS

HTML Pages

FileSystem

Web Data Processing

IIOP, DCOM

Templates, Scripts

SQL

RDBMS

Page SeverPage Sever

JDBC, ODBC, Native

Java Relational

TransactionServerTransactionServer

RDBMSComponent

Component

Web ServerWeb Server

HTTPS

Client ApplicationClient Application

Page

Page

Page Applet

Applet

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 vidaConexiones a bases de datos– Transacciones– Seguridad:

Server

Experiencia Requerida

Lifecycle

ThreadsSecurity

Connections

Tran

sact

ions

Desarrolladores - GUI

Desarrolladores - Sistema

Desarrolladores - Negocio

Convencionescomponentes

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/TDSIIOP/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

RepositorioJaguar Manager

Requerimiento IIOP

PackageComponents

7878Requerimiento TDS

8080Requerimiento 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

no

si

Desactivación

Desactivación

Instanciación

Destrucción

Reutilización

Activación

DesactivaciónAutomá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

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 VariablesProtected:Transaction itr_trans

Componente

//Deactivate event//Release the connectionDisconnect using itr_trans;

// Activate EventIf NOT IsValid(itr_trans) then itr_trans = CREATE transactionEND IFItr_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

Cliente

n_order_itemsn_order_itemsn_order_itemsn_order_itemsn_cartn_cartn_cartn_cart

n_ordern_ordern_ordern_order add( )

add( ) placeOrder( )

Jerarquía de componentes• ¿Qué hay de común en los componentes?

n_ordern_order n_order_itemsn_order_itemsn_cartn_cart

Instance variables

Instance variables

Instance variables

ConstructorActivateDeactivateCanBePooledDestructor



Definiendo el componente ancestro

n_ordern_order n_order_itemsn_order_itemsn_cartn_cart

n_ancestorn_ancestor

Extend and Override Descendent Events As Needed

Instance variables


Caso

Jaguar

Cliente

ProductProductProductProduct

getData( )getData( )

Cliente Cliente

getData( )

ProductProductProductProductProductProductProductProduct

Objetivo: Caché de datos

Jaguar

Client

ProductProductProductProduct

getData( )getData( )

Client Client

getData( )

ServiceProductServiceProductServiceProductServiceProduct

Ambiente / Arquitectura Web

EAServer

Servidor Aplicaciones

(PD / ASP)

Browser

HTTP

DatosCorporativos

Sitio Web

HTML

API

Servidor Web

PB Web Targets

Sitios Web Estáticos

HTML HTTP

Web BrowserWeb Server

Sitios Web Dinámicos

HTML HTTP

Web BrowserServidor Web

Servidor

Bases de Datos

WebOLTP

HTML

COM

PowerBuilderCORBA

Java PowerDynamo

HTTP

IIOPIIOP

Jaguar CTS

Web Server

Enterprise Application Server

Arquitectura

Servidor de componentesServidor Web / Servidor de páginas

Base de datos1

2

34

5

6

Llamado de componentes EAServer

<HTML><TITLE>Result.stm</TITLE><BODY><H1>Loan Calculator</H1>



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

EJBby

Sun MicrosystemsBluestoneSoftware

BluestoneSoftware

SybaseSybase

BEA Systems

BEA Systems

EAServerEAServer

Sapphire/WebSapphire/Web

WebLogicWebLogic

Especificación Vendedores ServidoresEJB-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

EAServerEAServer

CORBA

EJB

Arquitectura EJB

EJB Server

EJB Container

EJB Object

Enterprise

JavaBean

DeploymentDescriptor

EJB Client

EJB Remot

eStub

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

ServidorContainer

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 ContainerEJB 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 ObjectEJB Object

EJB HomeEJB Home EJBEJB

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 CTSJaguar CTS

ClienteCliente

additem( )

create( )

CartCart

CartHomeCartHome

JNDIJNDI

Home Stub

Remote Stub

CartBeanCartBean

1

2

5

43

6

7

lookup( )

Servidores de capa media

• Apache Tomcat• BEA WebLogic• IBM WebSphere• Sun ONE• Oracle 9i AS• Sybase EAS• Jrun Macromedia

Documents

Bases de datos en ambiente Internet. Objetivos Conocer la arquitectura cliente/servidor Conocer la arquitectura multitier Conocer la arquitectura Internet