RMI
RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para invocar un método de manera remota. Forma parte del entorno estándar de ejecución de Java y proporciona un mecanismo simple para la comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java. Si se requiere comunicación entre otras tecnologías debe utilizarse CORBA o SOAP en lugar de RMI.
RMI se caracteriza por la facilidad de su uso en la programación por estar específicamente diseñado para Java; proporciona paso de objetos por referencia (no permitido por SOAP), recolección de basura distribuida (Garbage Collector distribuido) y paso de tipos arbitrarios (funcionalidad no provista por CORBA).
A través de RMI, un programa Java puede exportar un objeto, con lo que dicho objeto estará accesible a través de la red y el programa permanece a la espera de peticiones en un puerto TCP. A partir de ese momento, un cliente puede conectarse e invocar los métodos proporcionados por el objeto.
La invocación se compone de los siguientes pasos:
Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad de serialización de Java).
Invocación del método (del cliente sobre el servidor). El invocador se queda esperando una respuesta.
Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al cliente.
El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local.
Arquitectura
La arquitectura RMI puede verse como un modelo de cuatro capas.
Primera capa
La primera capa es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicación que quiera que sus métodos estén disponibles para su acceso por clientes remotos debe declarar dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa básicamente para "marcar" un objeto como remotamente accesible. Una vez que los métodos han sido implementados, el objeto debe ser exportado. Esto puede hacerse de forma implícita si el objeto extiende la clase UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de forma explícita con una llamada al método exportObject() del mismo paquete.
Segunda capa
La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa directamente con la capa de aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y retorno de objetos tienen lugar en esta capa.
Tercera capa
La capa 3 es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. También es responsable de la gestión de la replicación de objetos y realización de tareas específicas de la implementación con los objetos remotos, como el establecimiento de las persistencias semánticas y estrategias adecuadas para la recuperación de conexiones perdidas. En esta capa se espera una conexión de tipo stream (stream-oriented connection) desde la capa de transporte.
Cuarta Capa
La capa 4 es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una máquina a otra. El protocolo de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que solamente es "comprendido" por programas Java.
Elementos
- Toda aplicación RMI normalmente se descompone en 2 partes:
- Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos accesibles, y espera a que el cliente los invoque.
- Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca.
Para mas información visite http://es.wikipedia.org/wiki/Java_Remote_Method_Invocation
CORBA
En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información.
CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existen para Ada, C, C++, Smalltalk, Java, Python, Perl y Tcl.
Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto.
CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en si, en realidad es un middleware.
Para mas información visite http://es.wikipedia.org/wiki/CORBA
BPM
Se llama Gestión o administración por procesos de negocio (Business Process Management o BPM en inglés) a la metodología corporativa cuyo objetivo es mejorar el desempeño (Eficiencia y Eficacia) de la Organización a través de la gestión de los procesos de negocio, que se deben diseñar, modelar, organizar, documentar y optimizar de forma continua. El Modelo de Administración por Procesos, se refiere al cambio operacional de la empresa al migrar de una operación funcional a una operación de administrar por procesos.
Ventajas
Un proceso se puede ver como un conjunto de recursos y actividades interrelacionados que transforman elementos de entrada en elementos de salida. Los recursos pueden incluir personal, finanzas, instalaciones, equipos, técnicas y métodos.
A través del modelado de los procesos de negocio, al interior de una organización, puede lograrse un mejor entendimiento de la operación de la empresa y muchas veces esto presenta la oportunidad de mejorar los procesos y con ello mejorar el desempeño. La estructuración de los procesos reduce errores, asegurando que los procesos se comporten siempre de la misma manera, reduciendo el margen de error y dando elementos que permitan visualizar el estado de los mismos durante cada etapa. La administración de los procesos permite asegurar que los mismos se ejecuten eficientemente, cumpliendo con estándares de calidad previamente establecidos, y ayudando a la obtención de información que luego puede ser usada para mejorarlos. Es a través de la información que se obtiene de la ejecución diaria de los procesos, que se puede identificar posibles ineficiencias o fallas en los mismos, y actuar sobre ellos para optimizarlos.
CORBA
En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información.
CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existen para Ada, C, C++, Smalltalk, Java, Python, Perl y Tcl.
Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto.
CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en si, en realidad es un middleware.
Para mas información visite http://es.wikipedia.org/wiki/CORBA
BPM
Se llama Gestión o administración por procesos de negocio (Business Process Management o BPM en inglés) a la metodología corporativa cuyo objetivo es mejorar el desempeño (Eficiencia y Eficacia) de la Organización a través de la gestión de los procesos de negocio, que se deben diseñar, modelar, organizar, documentar y optimizar de forma continua. El Modelo de Administración por Procesos, se refiere al cambio operacional de la empresa al migrar de una operación funcional a una operación de administrar por procesos.
Ventajas
Un proceso se puede ver como un conjunto de recursos y actividades interrelacionados que transforman elementos de entrada en elementos de salida. Los recursos pueden incluir personal, finanzas, instalaciones, equipos, técnicas y métodos.
A través del modelado de los procesos de negocio, al interior de una organización, puede lograrse un mejor entendimiento de la operación de la empresa y muchas veces esto presenta la oportunidad de mejorar los procesos y con ello mejorar el desempeño. La estructuración de los procesos reduce errores, asegurando que los procesos se comporten siempre de la misma manera, reduciendo el margen de error y dando elementos que permitan visualizar el estado de los mismos durante cada etapa. La administración de los procesos permite asegurar que los mismos se ejecuten eficientemente, cumpliendo con estándares de calidad previamente establecidos, y ayudando a la obtención de información que luego puede ser usada para mejorarlos. Es a través de la información que se obtiene de la ejecución diaria de los procesos, que se puede identificar posibles ineficiencias o fallas en los mismos, y actuar sobre ellos para optimizarlos.
Razones de La Gestión de Procesos
Existen diversos motivos que mueven la gestión de los Procesos dentro de una organización, entre los cuales se encuentran:
- Extensión del programa institucional de calidad
- Cumplimiento de legislaciones vigentes
- Crear nuevos y mejores procesos (mejoramiento continuo)
- Entender qué se está haciendo bien o mal a través de la comprensión de los procesos
- Documentar los procesos para la subcontratación y la definición del Service Level Agreement (SLA)
- Automatización y organización de los procesos
- Crear y mantener la cadena de valor
Para mayor Información visite http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_procesos_de_negocio
BPML
BPML es un metalenguaje XML para el modelado de procesos de negocio. Una norma publicada por Business Process Management Initiative (BPMI), que proporciona una forma universal para describir los procesos de negocio en las organizaciones. Los procesos de negocio modelados con BPML se pueden implementar y ejecutar en cualquier sistema de gestión de BPML compatible con procesos de negocio (BPMS).
Fundamentos BPML
Proceso
El proceso es el concepto básico de BPML. Los componentes clave de un proceso son:
* Ejecución de un conjunto de actividades
* La interacción con los participantes por el intercambio de mensajes
* Las reglas predefinidas para determinar el flujo de la ejecución
* Los horarios para gobernar el inicio y la finalización de la ejecución
* Procesamiento de los datos mediante la celebración de los datos internos que pueden ser accedidos por todas sus actividades
Voy a usar un proceso handlePurchaseOrder simple para ilustrar cómo modelar un proceso que utiliza BPML. El proceso contiene los siguientes pasos:
1. En el inicio del proceso esperará a que la "orden de compra" del mensaje.
2. Cuando se recibe una orden de compra, el proceso será comprobar si es un cliente existente, y creará una cuenta de cliente si se trata de un nuevo cliente.
3. El proceso de revisar el sistema de inventario para ver si hay suficiente inventario para cumplir con la orden.
4. El proceso envía un intento de envío a todas las compañías se contrae. Se establece un precio predefinido, y aceptar la primera oferta que cumpla con el criterio de precio.
5. Los horarios de procesar una orden de entrega con el portador seleccionado.
6. El proceso envía una notificación de envío para el cliente.
Tomado de http://business.highbeam.com/436115/article-1G1-90305758/model-your-business-processes-using-bpml-just-bpml
BPML
BPML es un metalenguaje XML para el modelado de procesos de negocio. Una norma publicada por Business Process Management Initiative (BPMI), que proporciona una forma universal para describir los procesos de negocio en las organizaciones. Los procesos de negocio modelados con BPML se pueden implementar y ejecutar en cualquier sistema de gestión de BPML compatible con procesos de negocio (BPMS).
Fundamentos BPML
Proceso
El proceso es el concepto básico de BPML. Los componentes clave de un proceso son:
* Ejecución de un conjunto de actividades
* La interacción con los participantes por el intercambio de mensajes
* Las reglas predefinidas para determinar el flujo de la ejecución
* Los horarios para gobernar el inicio y la finalización de la ejecución
* Procesamiento de los datos mediante la celebración de los datos internos que pueden ser accedidos por todas sus actividades
Voy a usar un proceso handlePurchaseOrder simple para ilustrar cómo modelar un proceso que utiliza BPML. El proceso contiene los siguientes pasos:
1. En el inicio del proceso esperará a que la "orden de compra" del mensaje.
2. Cuando se recibe una orden de compra, el proceso será comprobar si es un cliente existente, y creará una cuenta de cliente si se trata de un nuevo cliente.
3. El proceso de revisar el sistema de inventario para ver si hay suficiente inventario para cumplir con la orden.
4. El proceso envía un intento de envío a todas las compañías se contrae. Se establece un precio predefinido, y aceptar la primera oferta que cumpla con el criterio de precio.
5. Los horarios de procesar una orden de entrega con el portador seleccionado.
6. El proceso envía una notificación de envío para el cliente.
Tomado de http://business.highbeam.com/436115/article-1G1-90305758/model-your-business-processes-using-bpml-just-bpml
No hay comentarios:
Publicar un comentario