Diseño de la Capa de Negocio

Aplicaciones Distribuidas

2

Motivación

•  Motivación: •  Implantar un modelo UML (diagramas de clases y

colaboraciones) de una aplicación empresarial.

•  Solución:è Enterprise JavaBeans •  Implantar los objetos de negocio con distintas posibilidades

de persistencia. •  Implantar la lógica de negocio (controladores cdu) como

objetos distribuidos y transaccionales. •  Eficiencia en la gestión de recursos. •  Seguridad. •  ... •  è Modelo de programación complejo

3

Guías básicas de diseño

•  Implantar los objetos de negocio y sus relaciones como componentes Entidad: •  Persistencia: •  BMP: manejar almacenamiento XML, LDAP, ... •  CMP 1.x: integración con otro sistema de información. •  CMP 2.x: propósito general.

•  En general, definir interfaces locales. •  Sólo accesibles para los controladores de cdu.

•  Utilizar un modelo transaccional “required”: •  Integración con la operación transaccional del cdu.

•  Implantar los controladores de cdu como componentes Sesión: •  Decidir entre un controlador con estado (stateful) o sin estado

(stateless). •  Modelo transaccional “required”.

4

Ejemplo de Colaboración

pedidos : ControladorPedidos

Cliente pedidoActual : Pedido

l1 : LineaPedido

p1 : Producto l2 : LineaPedido

totalAPagar( )getTotal( )

getSubtotal( )precio( )

getSubtotal( )

CapaPresentación

SesiónStateful

Entidades

5

Patrones – Factoría de Homes

•  Problema: •  Necesidad de uso objetos Home: crear una Pedido, conectar una

Línea de Pedido con un Producto, ...

•  Acceso local o remoto al objeto Home a través de JNDI:

•  Solución: •  Utilizar una factoría (singleton) de objetos Home que mantenga una

caché de referencias: EJBHomeFactory

!Context ctxInicio = new InitialContext();!!

!// Obtiene una referencia local al Home!!Object obj = entorno.resolve(“Producto");!!ProductoLocalHome productoHome = (ProductoLocalHome) obj;!

ProductoLocalHome productoHome = !!!(ProductoLocalHome) EJBHomeFactory.getInstance().getHome(“Producto”)!

!

Patrones – Value Object

6

•  Motivación: •  Necesitamos la información de un objeto de negocio.

•  Alternativa 1: •  Devolver una referencia remota al objeto

•  Inconvenientes: •  Múltiples invocaciones remotas.

Cliente : Productopedidos : GestorPedidos

getNombre( )

getPrecio( )

...Acceso remoto RMI/IIOP

getInfoProducto( )

Patrones – Value Object

7

•  Alternativa 2: •  Construir un objeto de datos (Value Object) que sea devuelto por

valor (serializable).

•  Ventajas: •  Una sola invocación remota para obtener los datos.

Cliente producto: ProductoVO

: Producto producto : ProductoVO

pedidos : GestorPedidos

getNombre( )

getPrecio( )

...

getInfoProducto(id)getVO( )

Servidor EJB Capa de Presentación

new( )return producto

8

Patrones – Value Object

•  Consecuencias:

•  Introducir los métodos getVO y setVO (actualizaciones) en todos los objetos de negocio.

•  Problemas:

•  Distintos cdu pueden necesitar una pequeña parte de la información de un objeto de negocio.

•  Necesitamos información de varios objetos de negocio (submodelo):

•  Ejemplo: información de un pedido

•  Objeto pedido, sus líneas de pedido y de los productos.

•  à Custom Value Object

•  è El controlador se encarga de componer el objeto:

•  Un VO puede estar compuesto de otros VOs.

•  Ejemplo: PedidoVO contiene una colección de LineaPedidoVO

9

Patrones – Custom Value Object Cliente pedidos :

GestorPedidos miPedido : Pedido lp1 :

LineaPedido lp1VO : LineaPedidoVO p1 : Producto pedidoVO :

PedidoVO infoPedido( )

getLineasVenta( )

new( ) getTotal( ) setTotal( )

getProducto( )

getNombre( ) precio( )

getSubTotal( )

setNombreProducto( ) setPrecioProducto( )

setSubTotal( )

setLineasPedidoVO( ) return pedidoVO

Compone la colección de Líneas de Pedido VO

new( )

10

Patrones – Iterador

•  Motivación: •  Devolver una colección de objetos de negocio de un

modo eficiente.

•  Solución: •  Implementar un iterador distribuido.

•  Obtendrá una colección de objetos de negocio sobre los que iterar.

•  Irá devolviendo sus VO asociados según vayan siendo necesarios.

•  Implementado como un objeto de tipo sesión.

11

Patrones – Iterador

it : IteradorRem oto

Cliente pedidos : GestorPedidos

: ProductoHome

p1 : Producto p2 : Producto

getProductos( )col = findAll( )

new(col)

return it

next(n)

previous(n)

getVO( )

getVO( )return colVO

Compone la colección de los siguientes "n" VO

SessionStateful

"create" del Home

12

Patrones – Business Delegate

•  Motivación:

•  El modelo puede estar implementado con diferentes tecnologías: DAO, RMI, CORBA, EJB

•  Independizar Presentación del Modelo.

•  Solución: è Patrón Bussiness Delegate

•  Interface Java con las operaciones cdu •  GestorPedidosDelegate

•  Implementado por una clase que hace de proxy (delegate) •  Obtiene el controlador del modelo.

•  Delega todas sus operaciones en él.

•  Factoría de Delegates.

13

Patrones – Service Locator

•  Problema: •  Los delegados se crean continuamente: por sesión y cdu.

•  Un delegado obtiene el controlador EJB a través de JNDI y de su interface home

•  El acceso JNDI es costoso.

•  Solución: è Patrón Service Locator •  Proporciona referencias a los objetos Home de los controladores.

•  Se encarga de los detalles de acceso (propiedades JNDI)

•  Mantiene una caché de referencias.

•  è Similar a la factoría de homes, pero en la capa de presentación.

•  Propósito general: objetos distribuidos, EJB, colas JMS, ...