Resumen Parcial.docx

1. Glosario de trminos de Java. IMPORTANTE SABER DIFERENCIAR QUE ES CADA COSA PARA ENTENDER MEJOR TODO

EJB: es una arquitectura del lado del servidor, basada en componentes y orientada a transacciones, para la construccin de aplicaciones empresariales. Es una plataforma para la construccin de aplicaciones de negocios escalables, portables y reutilizables, usando Java. BASICAMENTE ES UN COMPONENTE, ME PARECE QUE ES MEJOR DECIR ESO. SOLAMENTE HAY 3 TIPOS, SESSION, ENTITY, MESSAGE DRIVEN

El modelo EJB solo puede ejecutarse sobre un contenedor, con lo cual los componentes deben respetar una interface determinada. Siempre el acceso de los clientes a un componente es a travs de un contenedor y un componente no puede acceder directamente a otro, solo puede hacerlo a travs del contenedor. Esto le da la caracterstica de indireccin.

Contenedor: en l estarn los diferentes tipos de Beans. El contenedor es una especie de sistema operativo para los EJB. Proporciona una capa adicional de servicios: Manejo de transacciones: apertura y cierre de transacciones asociadas a las llamadas a los mtodos del bean. Seguridad: comprobacin de permisos de acceso a los mtodos del bean. Concurrencia: llamada simultnea a un mismo bean desde mltiples clientes. Servicios de red: comunicacin entre el cliente y el bean en mquinas distintas. Gestin de recursos: gestin automtica de mltiples recursos, como colas de mensajes, bases de datos o fuentes de datos en aplicaciones heredadas que no han sido traducidas a nuevos lenguajes/entornos y siguen usndose en la empresa. Persistencia: sincronizacin entre los datos del bean y tablas de una base de datos. Gestin de mensajes: manejo de Java Message Service (JMS). Escalabilidad: posibilidad de constituir clusters de servidores de aplicaciones con mltiples hosts para poder dar respuesta a aumentos repentinos de carga de la aplicacin con slo aadir hosts adicionales. Adaptacin en tiempo de despliegue: posibilidad de modificacin de todas estas caractersticas en el momento del despliegue del bean.

Session Bean: ES UN EJB DIRECTAMENTE son una tecnologa EJB que permite encapsular procesos de negocio. Estn compuestos por una o ms interfaces y una clase de implementacin. Un cliente puede acceder solamente a los mtodos definidos en las interfaces implementadas por el Bean. Puede ser invocado de forma remota (@Remote) o local (@Local), estas annotations se ponen en la interfaz. Pueden ser Stateless o Stateful. Tienen 4 mtodos callback (@PreDestroy, @PostConstruct, @PrePassivate, @PostActivate) y poseen las siguientes caractersticas: Vida corta, si el servidor falla la sesin se pierde No manejan persistencia No es compartido entre clientes Pueden actualizar y crear entidades, estas ltimas son persistentes. Un cliente (WEB como JSP o servlet y un cliente aplicacin standalone) interacta con un session bean a travs de la invocacin de sus mtodos (esta invocacin se llama sesin). Un componente session bean es un POJO anotado.

Message-Driven Bean: son un tipo de EJB, que sirve para consumir de manera fcil y rpida mensajes JMS. No pueden ser invocados por un cliente, son Stateless, son asincrnicos, se invocan a travs de mensajes (onMessage(Message m)), no hay valor de retorno y las excepciones no se propagan al cliente. Los MDB pueden llamar a otros Beans. Se suscriben a un topic o una queue y se activan al recibir un mensaje dirigido a dicho topic o queue.

Entity Bean: representan datos persistentes. Encapsulan objetos del lado del servidor que almacenan datos.

Sincronicos Cualquier entidad del modelo de dominio Se guardan en una BD, con un identificador El estado queda en la BD, por lo que sobreviven una cada del contenedor. Se implementan con una clase Java comn. Se debe agregar metadata de cmo persistir el estado interno del objeto en un modelo relacional (mapping). No estn asociados a un usuario en particular (como los Session Beans). Se comparten entre varios usuarios. Existen independientemente de cualquier usuario. Soportan un lenguaje de consultas para buscar una o varias instancias en particular.

EAR: es un formato de archivo utilizado por Java EE para el empaquetado de uno o ms mdulos en un solo archivo para que el deploy de los diferentes mdulos en un servidor de aplicaciones ocurra simultneamente y de manera coherente. Tambin contiene archivos XML llamados descriptores de despliegue que describen cmo implementar los mdulos.

JBoss: es un servidor de aplicaciones (descrito al final de todo).

JNDI: es un servicio de nombres que permite a un componente localizar otros componentes o recursos . Habilita a las aplicaciones para acceder mltiples servicios de nombres y de directorios. Por ejemplo servicios como LDAP, NDS, DNS, y NIS. Ofrece los mtodos de: Asociar un nombre con un objeto (binding) Buscar un objeto (lookup). El uso de JNDI en aplicaciones Java EE permite almacenar o consultar cualquier objeto de java: acceso a sistemas y aplicaciones Legado.

Entity Manager: es una interfaz asociada a un PersistenceContext, el cual es inyectado generalmente en los Session Beans que actuarn de controladores. A travs del Entity Manager, se puede persistir, remover, attachear, desattachear, mergear una entidad, hacer queries, etc.

2. Qu entiende por Componente? IMPORTANTE

Un componente es una pieza de software que se inserta en un contenedor especfico. Es una forma de agrupar implementaciones de objetos en una sola entidad (la cual puede ser ensamblada dentro de un sistema ms grande). Tiene las siguientes caractersticas: Es accedida slo va interfaces. Es construida para su customizacin, composicin y colaboracin con otros componentes. Tiene un tamao adecuado para su reuso, reemplazo y mantenimiento. Su tamao tambin permite su distribucin, deployment y soporte. Es entregado dentro de un paquete self-contained.

Es conveniente el desarrollo basado en componentes por los siguientes motivos: Mejor manejo de la complejidad. Reduce tiempo de entrega. Incrementa productividad. Permite el desarrollo paralelo y distribuido. Reduce costos de mantenimiento. Permite usar el mejor de su clase.

3. Describa el ciclo de vida de cada tipo de Session Beans. IMPORTANTE

Stateful mantiene el estado conversacional con el cliente (por ejemplo, carrito de compras). Un SB Stateful tiene tres estados: Does not exist: la instancia del bean simplemente no existe. Ready: la instancia del bean est atada a un cliente en particular y comprometido en una conversacin. Passive: la instancia est en modo pasivo para conservar el recurso.

1. Create: el ciclo de vida comienza cuando el cliente obtiene una referencia a un SB stateful.2. Dependency Injection, si hay.3. PostConstruct callback, si hay. Despus de esto, el SB est listo para que el cliente invoque sus mtodos de negocio (es decir, pasa a estado Ready).

Cuando el SB est en Ready, el contenedor EJB puede desactivarlo, o hacerlo pasivo, moviendo el SB de memoria a un mtodo de almacenamiento secundario. Antes de hacer esto, el EJB invoca al mtodo @PrePassivate, si es que hay alguno. Cuando un cliente ejecuta un mtodo y el SB est en Passive, el EJB activa el SB y despus ejecuta el mtodo anotado @PostActivate, si es que hay uno, y luego pasa a estado Ready.Cuando el cliente invoca el mtodo anotado @Remove, el contenedor EJB ejecuta el @PreDestroy, si hay uno, y despus la instancia del SB est lista para ser eliminada.

Stateless no mantiene el estado conversacional con el cliente. Las variables del SB solamente pueden contener un estado especfico del cliente por la duracin de la invocacin. El EJB tiene un pool de instancias, cuando el cliente ejecuta un mtodo, se asigna una instancia del pool, y luego de usarse, es retornada al mismo.Solamente pueden implementar un web service, no otro tipo de Enterprise Beans.Un SB Stateless tiene dos estados: Does not exist. Ready.

Las etapas son:1. Dependency Injection, si hay (el Create ya fue realizado por el EJB, que mantiene el pool de SBs Stateless).2. PostConstruct callback, si hay.3. Al final del ciclo de vida, se llama al mtodo PreDestroy, si hay. Y despus la instancia de SB est lista para ser eliminada.

4. Implemente un Session Bean cuyo objetivo es eliminar un producto. Tambin implemente el mtodo public void eliminarProducto (int productoId). LO IMPORTANTE SON LAS ANNOTATIONS, DESPUES LOS METODOS PUEDEN VARIAR, PERO SE SACA

@Statelesspublic class AdminProductoBean implements AdminProducto {@PersistenceContext(unit = unit-admin) // Inyectamos el EntityManager, no hace falta inicializarlo.private EntityManager em;

@Overridepublic void eliminarProducto(int productoId){Producto p = (Producto)em.find(Producto.class, productoId);em.remove(p);}}

5. Al Session Bean del punto anterior, agregue funcionalidad para imprimir en el stack trace un texto se elimina instancia y se crea instancia, cada vez que se elimina y se crea una instancia del Session Bean.

@PreDestroypublic void onEliminarInstancia(){System.out.println(Se elimina instancia);}

@PostConstructpublic void onCrearInstancia(){System.out.println(Se crea instancia);}

6. Indique estructura de carpetas de una aplicacin JEE. Indique descriptores de deploy e informacin que contiene. Indique cmo se empaqueta una aplicacin JEE y cmo se despliega en el JBoss Application Server. SI TOMA ESTO TIENE QUE SER TAL CUAL ESTA ACA!

Estructura de carpetas:

ProyectoEJB. ejbModule. Beans. DAO. Entities.SE Interfaces. ... META-INF. Persistence.xml. jboss-webservices.xml ejb-jar.xml ProyectoEAR. EarContent. META-INF. application.xml ProyectoEJB.jar. ProyectoClienteWeb.war ProyectoClienteWeb. WebContent. css. js. adminProducto.jsp. error.jsp. detalle.jsp. WEB-INF. web.xml.

Descriptores:

Persistence.xml: especifica el DataSource y las unidades de persistencia. jboss-webservices.xml: provee configuraciones adicionales para deployear web services (ya sea en un EJB o endpoints empaquetados en un WAR), como puertos, URLs, mtodo de autenticacin, ubicacin del WDSL, etc. application.xml: describe los mdulos que van a estar includos en el EAR. web.xml: describe componentes web, mapeos, archivos iniciales, etc. ejb-jar.xml: describe los beans y sus caractersticas (nombre, nombre para mostrar, tipo de session (stateful o stateless), tipo de transaccin).

Cmo se empaqueta una aplicacin JEE y se despliega en un JBoss Application Server:

Primero deben empaquetarse los EJB (haciendo click derecho => Export, y eligiendo el nombre y la carpeta EarContent del EAR de destino). Esto va a crear un archivo .JAR (por ejemplo AdministradorProductosEJB.jar). Para empaquetar el EAR, hay que crear el archivo descriptor application.xml (en META-INF) y luego hacer click derecho => Export => EAR File y especificar la carpeta deployments del JBoss. De manera ms sencilla, se puede hacer click derecho => Run As (elegir JBoss) y de esta forma se har el empaquetado y el deploy de manera automtica.

7. Indique cmo es el diseo de su trabajo prctico. Indique Session Beans, Entities y patrones utilizados, tanto en el cliente como en el servidor.

Tenemos las siguientes Entity Beans: DespachoEntity LogEntity ModuloEntity MonitoreoEntity MonitoreoOrdenDespachoEntity MonitoreoVentaEntity OrdenDespachoEntity ProductoEntity VentaEntity VentaItemEntity

Tenemos los siguientes Session Beans: LogBean. MonitoreoBean. VentaBean. DespachoBean. OrdenDespachoBean.ESTO ESTA BUENO PARA ENTENDER QUE ES CADA PATRONDesde el cliente, utilizamos el patrn Facade, el cual consiste en simplificarle la integracin al cliente, a travs de exponer una capa extra con un mtodo que se encargar de realizar las llamadas internas correspondientes. Para el punto 3 (Recepcin de cambio de estado de despachos (Entregas)), tenemos que realizar internamente diferentes acciones: registrar la orden de cambio de estado, cambiar el estado de la orden de despacho, cambiar el estado de la venta para marcarla como entregada. Introduciendo el patrn Facade, el cliente solo llama a CambioEstadoDespacho con los parmetros correspondientes, en lugar de hacer tres llamadas, con las dificultades y complicaciones que podran traer (qu pasa si una se ejecuta bien y otra no?). De esta forma, manejamos todo como una transaccin.

En la parte web, utilizamos un patrn de arquitectura MVC, para tener separada la vista, del modelo y del controlador.

Del lado del servidor, usamos un patrn Business Delegate. Se llaman a los mtodos que exponemos en este Bean y de ah llamamos a los otros Beans correspondientes. Por ejemplo, si necesitamos traer el listado de ventas, llamamos al mtodo obtenerVentas() del Business Delegate, el cual va a llamar al Bean correspondiente, loguear si hay errores, y realizar cualquier otro tipo de accin que sea necesaria. Si el logueo o una de estas acciones cambia, no cambia la firma del mtodo del Business Delegate, por lo tanto, quien lo consuma tampoco deber cambiar nada.

8. Indique archivos descriptores y de configuracin necesarios para utilizar JPA en una aplicacin JEE. Indique qu informacin contiene cada uno y en qu carpetas deben ubicarse.

Persistence.xml: este descriptor estar ubicado dentro de la carpeta META-INF. Los Entity Beans pueden estar en el mismo JAR que los Sessions Beans o en un JAR separado. Este descriptor contendr lo siguiente: Nombre lgico de la unidad de persistencia (opcional). JNDI Name de Datasource (definido en standalone.xml). XMLs de mapeo para aumentar/reemplazar las anotaciones (opcional). Opciones de configuracin especficas de la BD (opcional).

standalone.xml: hay que agregar a este archivo, ubicado en JBOSS_HOME/standalone/configurations/, el Data Source correspondiente a la DB a utilizar, con elemento del tag . Se especificar la URL de conexin, usuario, password, y qu driver se utilizar. Por eso tambin hay que agregar el driver dentro del tag , en el cual se especificar qu mdulo usar (vara dependiendo de si es SQL Server, Oracle, MySQL, etc.).

modules.xml: ubicado en JBOSS_HOME\modules (por ejemplo JBOSS_HOME\modules\com\microsoft\sqlserver\main), se agrega el .JAR que corresponda (por ejemplo, sqljdbc4.jar) y el archivo modules.xml propiamente dicho, en el cual se especificar el nombre, los resources (sqljdbc4.jar en este caso), y otros mdulos que sean dependencias.

9. Indique el impacto (en cdigo, archivos de configuracin, descriptores y archivos de deploy) de cambiar el motor de base de datos de una aplicacin JEE existente que utiliza JPA.

La idea de utilizar JPA es abstraernos del motor de base de datos que estamos usando (es decir, de una tecnologa especfica), para as poder cambiar el mismo sin tener que tocar el cdigo. Si cambiamos de motor de base de datos, deberamos conseguir el nuevo mdulo y agregarlo a la carpeta JBOSS_HOME\modules. Si cambia el Data Source, tocaremos el archivo standalone.xml. Si cambia el nombre del Data Source, tendremos que tocar el archivo persistence.xml.

10. Indique el mapeo JPA para persistir una Factura con sus Items. Debe tener en cuenta que al eliminar la factura, se deben eliminar sus tems.

@Entity@Table(name=Factura)public class FacturaEntity{@GeneratedValue@Id@Column(name=facturaId)private int facturaId;

@Column(name=fecha)private Date fecha;

@OneToMany(cascade=CascadeType.REMOVE, mappedBy=factura)@JoinColumn(name=facturaId)private List items;

// Getters y setters.}

@Entity@Table(name=Item)public class ItemEntity{@GeneratedValue@Id@Column(name=itemId)private int itemId;

@ManyToOne@JoinColumn(name=productoId)private ProductoEntity producto;

@ManyToOne@JoinColumn(name=facturaId)private FacturaEntity factura;

private int cantidad;private float precio;

// Getters y setters.}

@Entity@Table(name=Producto)public class ProductoEntity{@GeneratedValue@Id@Column(name=productoId)private int productoId;

private int stock;private String descripcion;

// Getters y setters.}

11. Implemente el mtodo que elimina facturas a partir de una fecha: public void eliminarFacturasPorFecha (Date fecha).

public void eliminarFacturasPorFecha(Date fecha){em.createQuery(DELETE FROM FacturaEntity FE WHERE fe.fecha = :fecha).setParameters(fecha, fecha).executeUpdate();}

12. Describa 3 mtodos de integracin. Indique ventajas y desventajas de cada uno. IMPORTANTE

Web Services SOAP: es un standard para comunicaciones basado en XML. Usa diferentes protocolos (HTTP, SMTP). Al usar HTTP, es fcil pasar proxies y firewalls sin problemas. Es muy verbose, es decir, tiene muchas palabras, por lo que es ms lento que otras soluciones. Usa WSDL para proveer el contrato o interfaz del web service.Pros: Desacoplado del lenguaje, plataforma y transporte. Diseado para soportar ambientes distribuidos de procesamiento. Manejo de errores por defecto. Extensibilidad.Contras: Conceptualmente ms dificiles, ms pesados que REST. Ms verboso. Dificil de desarrollar y de testear, se necesitan herramientas extras.

Web Services REST: es una alternativa liviana, simple, pero potente. Usa HTTP para transportar, y se suele usar JSON en vez de XML, hacindolo mucho ms sencillo de leer y ms liviano. Usa los verbos de HTTP (PUT, GET, POST, DELETE) para realizar las acciones. Por ejemplo, para traer un usuario por id: http://mysite.com/users/5 (GET).Pros: Desacoplado del lenguaje y plataforma. Ms fcil de desarrollar que SOAP. Es fcil de entender y no se necesitan herramientas extra. Es conciso, no se necesitan capas de mensajera extra. Ms cercano en diseo y funcionamiento a lo que es Web. Ms liviano.

Cons: Asume comunicacin punto a punto, no apto para ambientes distribudos de procesamiento en dnde hay multiples intermediarios. Falta de standards, falta de soporte para seguridad, encriptacin, haciendo ms complicado el desarrollo de requerimientos complejos. Est totalmente atado al modelo de transporte HTTP.

Mensajera (JMS): es una forma de comunicacin asincrnica entre componentes, utilizando mensajes, en el cual el emisor y el receptor estn desacoplados. El receptor puede no estar activo cuando el emisor enva el mensaje. Hay dos formas de comunicar en JMS: Punto a punto: los mensajes se envan a colas. El Receptor consume mensajes de la cola a medida que llegan. Un mensaje es consumido slo por un Receptor. En una misma Cola pueden recibir varios Receptores. El Emisor generalmente no sabe quien va a consumir el mensaje finalmente. Publicacin y suscripcin: los mensajes se publican en tpicos. Cada mensaje publicado se entrega a todos los Suscriptores de ese Tpico. Para garantizar la entrega, un Tpico se puede configurar como durable. Los Suscriptores pueden recibir mensajes que fueron publicados mientras estaban inactivos.

Pros: Llamadas asincrnicas. Un componente puede llamar a otro sin tener que esperar por una respuesta inmediata. El tiempo total de ejecucin del Emisor no tiene que incluir el tiempo de ejecucin del Receptor. Mejor uso de recursos Menos tiempo de ejecucin por componente. Menos uso de memoria y servicios. Reduce las dependencias entre componentes Un componente no tiene que conocer la identidad ni la ubicacin fsica de otro para poder ejecutarlo. Puedo cambiar la identidad, ubicacin fsica e implementacin interna de un componente sin necesidad de recompilar a sus clientes. Permite que una aplicacin siga funcionando an con algn componente fuera de lnea. Los mensajes quedan en el destino y pueden ser procesados ms tardeContras: Ms complicado de codificar que una llamada comn sincrnica. Ms cdigo para enviar un mensaje. Ms cdigo para consumir un mensaje. Ms configuracin. Configuracin de Destinos. Autenticacin para enviar y recibir. Persistencia de mensajes. Recibir respuestas asincrnicas es complicado. Mecanismo de enviar y olvidar (fire and forget). No hay validacin en tiempo de compilacin del contenido del mensaje. Un mensaje puede contener cualquier tipo de objeto. Contrato explcito vs contrato implcito entre lo que pone el Emisor en el mensaje y lo que saca el Receptor.

13. Ud. est realizando una integracin de aplicaciones. En dicho proceso, recibe un XML con la informacin de un listado de productos. Indique cmo validara dicho XML y qu utilizara para procesarlo programticamente. De un ejemplo.

Para validar un XML, se lo puede comparar contra un XSD, que define no solamente la estructura (especificando los elementos, la cantidad de los mismos, el orden, etc.), sino los tipos de datos.

Por ejemplo, un XSD para validar el listado de productos, podra ser el siguiente:

Para parsear programticamente un XML, utilizamos alguna librera como XStream para poder parsear XML y para poder convertir de objetos a XML:

public List parseProductosFromXML(String xml){List productos = (List)xstream.fromXML(xml);return productos;}

14. JMS: indique participantes de la integracin. Indique qu tipos de mensajera conoce, caractersticas y un ejemplo de cundo utilizar cada uno. IMPORTANTE

Hay tres participantes en JMS: emisor, receptor, y el broker.

Hay dos tipos de mensajera: Punto a punto: los mensajes se envan a colas. Lo usamos cuando necesitamos que el mensaje sea procesado por un solo receptor, y cuando es importante que el mensaje sea procesado si o si. Por ejemplo, podramos usar este modelo cuando tenemos que crear un mensaje con los datos de un paciente para que se atienda en algn hospital la siguiente semana. El hospital que procese el mensaje desde la cola, ser el que recibir al paciente. El Receptor consume mensajes de la cola a medida que llegan. Un mensaje es consumido slo por un Receptor. En una misma Cola pueden recibir varios Receptores. El Emisor generalmente no sabe quien va a consumir el mensaje finalmente. Publicacin y suscripcin: los mensajes se publican en tpicos. Lo usamos cuando enviamos informacin a muchos suscriptores, y no importa si estn activos o no. Por ejemplo, somos un corredor de bolsa y queremos mandarles a nuestros clientes sobre una oportunidad para comprar acciones. Los que estn activos, lo recibirn, y los que no, se lo perdern. Cada mensaje publicado se entrega a todos los Suscriptores de ese Tpico. Para garantizar la entrega, un Tpico se puede configurar como durable. Los Suscriptores pueden recibir mensajes que fueron publicados mientras estaban inactivos.

15. JMS: indique cmo se consume un mensaje utilizando JEE5, suponiendo que la informacin del mensaje es texto XML. REPASAR TOTALMENTE IMPORTANTE

En nuestro MDB (Message-Driven Bean), el cual va a tener inyectada la cola que va a procesar a travs de la annotation @MessageDriven, vamos a tener un mtodo llamado onMessage, que es ejecutado por el contenedor al recibir un mensaje. All podremos consumir el mensaje y realizar las acciones que necesitemos, como llamar a otros Beans.Hay un pool de MDBs, los cuales son Stateless. El procesamiento de los mensajes es asincrnico, y los clientes no conocen ni interactan con el MDB, desacoplndolos totalmente. No hay valores de retorno ni las excepciones se propagan al cliente.El ciclo de vida es controlado completamente por el contenedor.

El cuerpo del mensaje puede ser de diferentes tipos (todos sub-interfaces de javax.jms.Message): TextMessage: un objeto String (ej: XML). MapMessage: tabla de clave/valor. ObjectMessage: una clase Java Serializable.

Ejemplo de MDB: IMPORTANTISIMO, ME LO TOMO

@MessageDriven( activationConfig = { @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/log") }, mappedName = "queue/log")

public class LogMDB implements MessageListener {@Overridepublic void onMessage(Message message) {TextMessage textMessage = (TextMessage) message; try { Producto p = (Producto)xstream.fromXML(message.getText());System.out.println(Producto: + p.getNombre()); } catch (JMSException e) { e.printStackTrace(); } }}

16. JMS: indique cmo se configura una cola JMS, utilizando JBoss como broker de mensajera. REPASAR TOTALMENTE

Hay que agregar la configuracin de la cola en standalone-full.xml, luego configurar el JBoss para que use ese archivo, y darle Run al JBoss. La cola debera estar configurada y lista para recibir mensajes.

Debe aadirse el siguiente cdigo dentro del elemento :

17. Qu es un Servidor de Aplicaciones? IMPORTANTE

Es un conjunto estandarizado de frameworks y servidores sobre los cuales construir aplicaciones empresariales. Es la capa central donde se ejecuta la lgica de la aplicacin (mantenida independientemente de los clientes y las bases de datos).Proveen los siguientes servicios: Concurrencia Coordinacin de transacciones Seguridad Administracin de recursos (ej. BDs) Distribucin entre distintos servidores Comunicacin entre distintas partes del sistema distribuido Naming.

La lgica de negocios de una aplicacin debe ser escrita y deployada dentro de un servidor de aplicaciones. El servidor de aplicaciones provee un conjunto de servicios, disponibles para la aplicacin, y define las interfaces para accederlos. Provee tambin capacidades para deployar una aplicacin. Sugiere un modelo de programacin para instalar el software (Modelo de componentes).

18. Ejemplo de carrito de compras. IMPORTANTISIMO, NO SOLO PORQUE SUELE TOMAR CARRITO DE COMPRAS, SINO PORQUE ES UN EJEMPLO DE UN SESSION BEAN STATEFUL

@Remotepublic interface Cart { public void initialize(String person) throws BookException; public void initialize(String person, String id) throws BookException; public void addBook(String title); public void removeBook(String title) throws BookException; public List getContents(); public void remove();}

@Statefulpublic class CartBean implements Cart {//Variables del stateful String customerName; String customerId; List contents;

public void initialize(String person) throws BookException { if (person == null) { throw new BookException("Null person not allowed."); } else { customerName = person; }

customerId = "0"; contents = new ArrayList(); }

public void initialize(String person, String id) throws BookException { if (person == null) { throw new BookException("Null person not allowed."); } else { customerName = person; }

IdVerifier idChecker = new IdVerifier();

if (idChecker.validate(id)) { customerId = id; } else { throw new BookException("Invalid id: " + id); }

contents = new ArrayList(); }

public void addBook(String title) { contents.add(title); }

public void removeBook(String title) throws BookException { boolean result = contents.remove(title); if (result == false) { throw new BookException(title + " not in cart."); } }

public List getContents() { return contents; }

@Remove public void remove() { contents = null; }}

EJEMPLO DE WEB SERVICE QUE SAQUE DE MI TP, A MI ME LO TOMO. MAS ALLA DE LO QUE HACE EL METODO, ES IMPORTANTE LAS ANNOTATIONS

@WebMethod@Overridepublic String registrarVenta(@WebParam(name="xml") String xml) {System.out.println(xml);Response response = new Response();JAXBContext jaxbcontext;try{jaxbcontext = JAXBContext.newInstance(Venta.class);javax.xml.bind.Unmarshaller unmarshaller = jaxbcontext.createUnmarshaller();Venta venta = (Venta) unmarshaller.unmarshal(new StringReader(xml));FacadeUtil.connectBusinessFacade().registrarVenta(venta);response.setEstado("OK");}catch (Exception e){//e.printStackTrace();response.setEstado("ERROR");response.setMensaje(e.toString());}return generateResponse(response);}

19. Pregunto sobre WSDL, que es, cual es su objetivo, cual es su contenido y como se crea

Es un lenguaje implementado con XML, independiente de formas y de otros lenguajes.

Tiene dos tipos de descriptores:

Abstractas: Tipo de datos, mensajes, operaciones.

Concretas: bindings y servicios.

Estructura de un documento WSDL

TypesDefinen los tipos de datos utilizados en los mensajes.

MessageDefine un mensaje de entrada o salida involucrado en una operacin.

PortTypeDefine una agrupacin de operaciones, el equivalente en Java sera una interfaz.

Operation

Describe una operacin determinada, indica los mensajes de entrada y/o salida que la componen. Se agrupan en tipos de puertos y el equivalente en Java sera un mtodo de una interfaz.

Binding

Especifica una implementacin de una operacin, indica el estilo de una operacin y el transporte utilizado.

Service

Indica que operaciones soporta el servicio, relacionndolo con un portType. Especifica cmo esta implementado, relacionndolo con un binding. Indica donde est publicado, relacionndolo con una URL.

En nuestro TPO el servicio de WebService se publica en una clase del Proveedor con sus anotaciones y al levantar el JBoss se publica el WSDL en la url de Services. Los web services se van a implementar en los Session beans, en nuestro TPO lo implementamos en Session Beans Stateless en la capa de integracin, en la misma capa de MDB.

En tiempo de deploy el contenedor levanta los Session Beans y se fija en las anotaciones si hay Web Services para publicar. Para esto, debe armar el WSDL. Anotamos la url del Web Service que aparece en Local Host, ya que ser la que utilizara otra mquina para consumir los servicios.

File new other web Service web service Client (wizard) WSDL

Una vez creado el WSDL, lo que se debe hacer es consumirlo desde el cliente.

20.Indique donde se utiliza el patrn facade y cual es su beneficio.

Se utiliza este patrn para reducir el nmero de llamadas remotas e incrementar la performance, adems, se mejora el control transaccional e incrementa la escalabilidad. La frontera de la transaccin est en el servidor y no en el cliente, esto produce que el tiempo total de la transaccin se vea reducido.

Se fuerza una sola interaccin entre componentes, es decir, asla al cliente de tener que entender cuntos existen y cmo interactan los Session / Entity Bean. Al estar aislado, el cliente solo conoce la Api de la Fachada, nunca accede a los otros Session o Entity directamente. Todo lo que est detrs de la fachada puede cambiar, sin romper el contrato con el cliente.

21. Pregunto diferencia entre Mensajera y WS (dar pro y contras)

22. Pregunt que mtodo de integracin recomendaras vos en una empresa y por que.