Download ambiente_internet

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