Bases de datos en ambiente internet
Download
1 / 87

Bases de datos en ambiente Internet - PowerPoint PPT Presentation


  • 172 Views
  • Updated On :

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

Related searches for Bases de datos en ambiente Internet

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Bases de datos en ambiente Internet' - malvina


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Objetivos l.jpg
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 l.jpg
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 l.jpg

Servidor – Base de Datos

Cliente

Arquitectura Cliente/Servidor

  • Cliente: Demanda servicios

  • Servidor: Provee servicios


Arquitectura cliente servidor5 l.jpg

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, …


Arquitectura cliente servidor6 l.jpg
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 servidor7 l.jpg
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 servidor8 l.jpg

Cliente

Cliente

Cliente

Cliente

Servidor BD

Servidor BD

Servidor BD

Arquitectura Cliente/Servidor

Conexiones: c * s


Arquitectura cliente servidor9 l.jpg
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 l.jpg

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)


Ventajas de la arquitectura multicapa l.jpg
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 l.jpg
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 l.jpg

Cliente

Cliente

Cliente

Cliente

Servidor BD

Servidor BD

Servidor BD

Arquitectura multicapa

Conexiones: c + s

Servidor de Aplicaciones


Arquitectura multicapa14 l.jpg
Arquitectura multicapa

Características

  • Impredecible el número de clientes/transacciones

  • Abre las aplicaciones hacia Internet/extranet


Arquitectura multicapa15 l.jpg
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 multicapa16 l.jpg
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 multicapa17 l.jpg
Arquitectura multicapa

  • Razones para pasarse a una arquitectura multicapa

    • Más escalable

    • Mayor reutilización de objetos

    • Listos para desarrollos Web/Inalámbricos


Arquitectura multicapa18 l.jpg
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 multicapa19 l.jpg
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 l.jpg
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


Corba21 l.jpg
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)


Corba22 l.jpg

ORB

ORB

IIOP

C

C

C

Java

Java

Java

ORB

NVO

NVO

NVO

CORBA

ORB (Object Request Broquer)


Slide23 l.jpg
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


Corba24 l.jpg
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


Corba25 l.jpg
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 l.jpg

Implementación

Interfase

onoff

Interfase vs Implementación


Interfase vs implementaci n27 l.jpg

onoff

Interfase vs Implementación

Implementación

Interfase

InterfaseRemota = Stub (o Proxy)


Corba28 l.jpg

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); };

};


Corba iiop m todo de invocaci n l.jpg
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


Slide30 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 internet37 l.jpg

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


Arquitectura distribuida l.jpg
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 l.jpg

Server

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 l.jpg
Experiencia Requerida

Desarrolladores - Negocio

Lifecycle

Threads

Transactions

Security

Desarrolladores - GUI

Connections

Convenciones

componentes

Desarrolladores - Sistema


Rol del cts l.jpg
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 l.jpg
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 l.jpg

Connection Cache

JCM

Caché de conección

  • Pools de componentes de conexiones compartidas preasignadas a servidores remotos de bases de datos


Administraci n de transacciones l.jpg
Administración de transacciones

  • Permite definir semántica transaccional de componentes como parte de la interfase de componentes


Administraci n de seguridad l.jpg
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 l.jpg

Java

COM

HTML

IIOP/TDS

C++

EAServer

SQL

PowerBuilder

CORBA

MASP

Soporte para clientes y componentes


Soporte j2ee l.jpg
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 l.jpg

Jaguar Server

Librería de clases

Requerimiento IIOP

9000

Requerimiento TDS

7878

Requerimiento HTTP

8080

C++

Components

Package

Jaguar Manager

Repositorio

Ambiente del EAServer


Servidor easerver l.jpg
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



Conexi n al easerver jaguar manager l.jpg
Conexión al EAServer - Jaguar Manager




Componentes en el easerver l.jpg
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 l.jpg
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 l.jpg
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 l.jpg

C

C++

PowerBuilder

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


Ciclo de vida de los componentes l.jpg

Instanciación

Ocioso

Activación

Asignado al Cliente

Reutilización

Método Ejecutado

si

Desactivación

Automática

Grupo

Soporte

Desactivación

no

Destrucción

no

Primitiva

Desactivación

Ciclo de vida de los componentes


Componentes estrategias de dise o l.jpg
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 l.jpg
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 l.jpg
Administración de conexiones

IIOP

Connection Cache

Connection Manager

Connection Cache

Administrador de conexiones


Connection cache l.jpg
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 l.jpg
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 l.jpg

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;

Conexión a una base de datos


Transacci n l.jpg
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 l.jpg

Cliente

add( )

n_order

Jaguar

n_cart

add( )

placeOrder( )

n_order_items

Objetivo


Jerarqu a de componentes l.jpg
Jerarquía de componentes

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

Instance variables

Instance variables

Instance variables

n_cart

n_order

n_order_items

Constructor

Activate

Deactivate

CanBePooled

Destructor

Constructor

Activate

Deactivate

CanBePooled

Destructor

Constructor

Activate

Deactivate

CanBePooled

Destructor


Definiendo el componente ancestro l.jpg

Constructor

Activate

Deactivate

CanBePooled

Destructor

Instance variables

n_ancestor

n_cart

n_order

n_order_items

Extend and Override Descendent Events As Needed

Definiendo el componente ancestro


Slide69 l.jpg

Cliente

Cliente

Cliente

getData( )

getData( )

getData( )

Product

Jaguar

Product

Product

Caso


Objetivo cach de datos l.jpg

Client

Client

Client

getData( )

getData( )

getData( )

Jaguar

ServiceProduct

Product

Objetivo: Caché de datos


Ambiente arquitectura web l.jpg

HTTP

Servidor Web

Sitio Web

API

Browser

Servidor Aplicaciones

(PD / ASP)

HTML

PB

Web Targets

Datos

Corporativos

EAServer

Ambiente / Arquitectura Web


Sitios web est ticos l.jpg

HTTP

HTML

Web Browser

Web Server

Sitios Web Estáticos


Sitios web din micos l.jpg

Servidor

HTTP

HTML

Web Browser

Servidor Web

Bases de Datos

Sitios Web Dinámicos


Weboltp l.jpg

Enterprise Application Server

Java

COM

PowerDynamo

Web Server

HTML

HTTP

IIOP

PowerBuilder

CORBA

Jaguar CTS

WebOLTP


Arquitectura l.jpg

3

6

4

2

5

Arquitectura

Base de datos

1

Servidor Web / Servidor de páginas

Servidor de componentes


Llamado de componentes easerver l.jpg
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 l.jpg
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

Sybase

EAServer

EJB

by

Sun Microsystems

Bluestone

Software

Sapphire/Web

BEA

Systems

WebLogic

Vendedores

Servidores

EJB-Compliant

Especificación


Ejb y easerver l.jpg

EAServer

EJB

CORBA

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


Arquitectura ejb l.jpg

EJB Server

EJB Home

Interface

EJB Client

EJB Container

EJB Home

Stub

Deployment

Descriptor

EJB Home

Enterprise

JavaBean

EJB Remote

Stub

EJB Object

EJB Remote

Interface

*Shaded Blue is developer-created

Arquitectura EJB


Servidor ejb l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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

EJB Object

Remote Stub

EJB Home

EJB

Home Stub


Ejb remote stub l.jpg
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 l.jpg

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

Tipos EJB


Proceso de aceso ejb l.jpg
Proceso de Aceso EJB

Cliente

JNDI

lookup( )

1

Jaguar CTS

create( )

3

4

Home Stub

CartHome

2

CartBean

additem( )

6

Remote Stub

Cart

5

7


Servidores de capa media l.jpg
Servidores de capa media

  • Apache Tomcat

  • BEA WebLogic

  • IBM WebSphere

  • Sun ONE

  • Oracle 9i AS

  • Sybase EAS

  • Jrun Macromedia