Es la primera edición de Programming in Scala, es buenisimo este aporte.
Dejo el link:
http://www.artima.com/pins1ed/
martes, 19 de abril de 2011
Publican Libro Gratuito de Scala
Es la primera edición de Programming in Scala, es buenisimo este aporte.
Dejo el link:
http://www.artima.com/pins1ed/
domingo, 17 de abril de 2011
Seguridad con JEE
JEE y EJB proveen un conjunto de servicios que los desarrolladores pueden integrar de forma declarativa o programática. Estos servicios incluyen autorización y autenticación.
Autenticación e identificación
La autenticación es comprobar que el usuario sea quien dice ser. En un sistema EJB un usuario es asociado con una identidad segurizada, esta esta lista para ser usada por los EJB. Cuando un cliente invoca un método de un EJB, el servidor pasa la identidad del cliente con la invocación del método. Cuando el contenedor de EJB recibe la invocación valida la identidad del usuario y si este puede invocar el método invocado.
La especificación EJB no indica como se autentica. Aunque esta definido como la seguridad se propaga del cliente al servidor, no esta definido como el cliente obtiene la identidad y la credencial con una invocación EJB, tampoco define como el servidor guarda y obtiene las autenticaciones.
Cuando accedemos a un EJB muchas aplicaciones utilizan la JNDI API, por ejemplo podemos autenticar el acceso a un EJB de este modo:
properties.put(Context.SECURITY_PRINCIPAL, "username");
properties.put(Context.SECURITY_CREDENTIALS, "password");
Context ctx = new InitialContext(properties);
Object ref = jndiContext.lookup("SecureBean/remote");
SecureRemoteBusiness remote = (SecureRemoteBusiness)ref;
En el ejemplo, el usuario es autenticado con la conexión a el “JNDI InitialContext”
Autorización.
Como sabemos en las aplicaciones no todos somos iguales, cada usuario tiene un rol ante una aplicación por ejemplo “administrador”, “empleado”, etc. y cada rol puede hacer o no determinadas acciones, es decir tiene o no tiene permiso para.
En EJB existen diferentes tipos de granularidad de permisos, puede ser por usuario o por rol. Esto permite que la autenticación sea un proceso separado de la autorización.
Los roles son definidos de forma logica y pueden representar roles, grupos de usuarios, o cualquier otro sistema de identificación. Los roles del los EJB son mapeados a los usuarios y grupos reales cuando el bean es deployado.
La autorización esta bien definida en la especificación EJB. Se declaran los roles de forma programática y luego se indican los permisos a los beans por medio de anotaciones o declararlos en ejb-jar.xml
Vimos de forma teoría la seguridad en EJB, en un próximo post vamos a hace algo más práctico.
Por que no EJB 3?
Soy un promovedor del uso de Spring pero por X motivo estoy estudiando un poco JEE 5 y la verdad estoy sorprendido por su simpleza, cambio mucho. Lo único que critico es que el tiempo de levantar jboss o glassfish o otro servidor JEE es mayor que usar solo tomcat o jetty (obviamente).
La especificación EJB 3 deja atrás el mal sabor que tenían las anteriores versiones de EJB a la hora de desarrollar. El paso más importante ahora los EJB son pojos, que por medio de anotaciones se infiere el comportamiento. No es necesario heredar de ningún objeto, ni hacer interfaces (gracias a Dios).
Veamos los tipos de beans que existen:
Session EJB: Son los beans que tienen las acciones; son los que tienen la lógica del negocio. Este tipo de bean viene en 2 sabores Stateless (no mantiene el estado en el servidor) o Statefull (mantiene el estado en el servidor). Además se agrego un Sigleton Beans, para cuando necesitamos solo una instancia de nuestro objeto de negocio.
Message-Driven Beans: La mensajería asíncrona es un paradigma en el cual dos o más aplicaciones se se comunican mediante un mensaje que describe un evento de negocio. Estos beans pueden generar mensajes asíncronos y consumirlos.
Entity Beans: Son objetos que modelan nuestros datos (Pojos) y son persistidos por medio del javax.persistence.EntityManager. Usando JPA (descripto en JSR-317) podemos persistir nuestros entity beans como si usáramos un ORM común.
Este es un pequeño resumen de la que nos brinda EJB 3. En próximos post ampliaremos!!
miércoles, 13 de abril de 2011
Java Magazine is Coming!
La idea es que en fines de julio va salir la revista oficial de Java gratuita. Es una interesante propuesta de oracle.
Todavía no se encuentra un nro publicado pero ya nos podemos registrar.
Dejo el link:
martes, 12 de abril de 2011
java.util.Objects la nueva librería de java 7!
La verdad es que mucho no me gusta (sera resistencia al cambio), yo pienso que le roba trabajo a los objetos, para mi debería estar esta funcionalidad en Object o de otra forma, no lo se.
Más allá de mi humilde opinión era necesaria, siempre teníamos que escribir un util que haga cosas que hora hace esta librería.
Veamos unos ejemplos:
public void showFoo(Foo foo) { Foo foo2 = new Foo();
//lot of code
if(foo.equals(foo2)) {
System.out.println("Two Men");
} else {
System.out.println("And a Half");
}
}
Esto puede dar NullPointer veamos como lo resolvemos con Objects:
public void showFoo(Foo foo) {
Foo foo2 = new Foo();
//lot of code
if(Objects.equals(foo,foo2)) {
System.out.println("Two Men");
} else {
System.out.println("And a Half");
}
}
Podemos hacer el hash con Objects, que sera de org.apache.commons.lang.builder.HashCodeBuilder
@Override public int hashCode() {
return Objects.hash(name, age, job);
}
Podemos chequear que un objeto no sea null
public void showFoo(Foo foo) {
this.bar = Objects.requireNonNull(foo);
}
Podemos tomar tomar el toString si no es nulo, y de lo contrario devolver un valor:
return Objects.toString(foo, “Foo is Empty”);
Interesante no? que les parece la nueva librería?
Fuente: http://alexsotob.blogspot.com/2011/04/another-shot-of-whiskey-cant-stop.html
sábado, 9 de abril de 2011
La historia de linux
Con motivo de los 20 años de Linux se realizo el siguiente vídeo que explica la historia del sistema operativo.
domingo, 3 de abril de 2011
GO
...no voy a cambiar, no voy a cambiar mi modo
ellos me dicen : "nena,
nena vos lo tenes todo."
Oh, negro go...
Rara forma de empezar un post del no tan famoso lenguaje de google Go!
El pequeño párrafo de la canción de los piojos “go negro go” resume un poco mi sensación con respecto a este lenguaje, es como que tiene todo pero hecho como le gusta a google. Que no digo que este mal, pero por ahí tantas vueltas de rosca no son muy buenas a veces.
El lenguaje de programación Go es un proyecto de código abierto con el objetivo de la productividad en los programadores.
Go es expresivo, conciso, limpio y eficiente. Sus mecanismos de concurrencia hace fácil escribir programas que sacan el máximo provecho a múltiples núcleos y las máquinas en red, mientras su novedoso sistema de tipado permite la construcción de programas flexibles y modulares. Compila rápidamente a código de máquina, pero tiene la comodidad del garbage collection y el poder de reflexión en tiempo de ejecución.
Veamos un ejemplo:
package main
// fib returns a function that returns
// successive Fibonacci numbers.
func fib() func() int {
a, b := 0, 1
return func() int {
a, b = b, a+b
return b
}
}
func main() {
f := fib()
// Function calls are evaluated left-to-right.
println(f(), f(), f(), f(), f())
}
La salida de este programa es: 1 2 3 5 8
Se puede ver fácilmente la influencia de python y c++
Veamos un hola mundo:
package main
import fmt "fmt" // Package implementing formatted I/O.
func main() {
fmt.Printf("Hello, world; or Καλημέρα κόσμε; or こんにちは 世界\n")
}
Go es un lenguaje compilado. Para compilar este programa podemos utilizar Gccgo que utiliza GCC. También hay una serie de compiladores para diferentes arquitecturas por ejemplo: 6g para 64-bit x86, 8g para 32-bit x86, etc. Estos compiladores corren más rapido que Gccgo pero generan codigo menos eficiente. Veamos como compilar y correr go:
$ 6g helloworld.go # compile; object goes into helloworld.6
$ 6l helloworld.6 # link; output goes into 6.out
$ 6.out
Hello, world; or Καλημέρα κόσμε; or こんにちは 世界
o
$ gccgo helloworld.go
$ a.out
Hello, world; or Καλημέρα κόσμε; or こんにちは 世界
Dejo links como siempre:
http://golang.org/
http://wh3rd.net/practical-go/
sábado, 2 de abril de 2011
Recursos sobre Rails
Estoy estudiando un poco rails y encontré unos links de la apis de Rails.Si quieren ver el código de rails:
git clone http://github.com/rails/rails.git
cd rails
Para ver la api de rails
http://api.rubyonrails.org
http://apidock.com/rails
http://railsapi.com
Espero que les sirva.
jueves, 24 de marzo de 2011
Aprendiendo SOA
Dejo una serie de libros y links para la persona que quiere empezar con SOA
Libros:
Open Source SOA.
Autor: Jeff Davis
Publicado por Manning Publications corp.
ISBN: 1933988541
Java SOA cookbook
Autor: Eben Hewitt
Publicado por O’Reilly Media, Inc.
ISBN: 978-0-596-52072-4
Service-Oriented Architecture: Concepts, Technology, and Design
Autor: Thomas Erl
Publicado por Prentice Hall PTR
ISBN: 0-13-185858-0
Service-Oriented Architecture Governance for the Services Driven Enterprise
Autor: Eric E. Marks
Publicado por Wiley Publishing.
ISBN 978-0-470-17125-7
Adopción de SOA para Dummies.
Autores:Miko Matsumura, Bjoern Brauel y Jignesh Shah
ISBN: 978-0-470-48334-3
Publicado por Wiley Publishing.
Introducción a BPM para Dummies.
Autores: Kiran Garimella, Michael Lees y Bruce Williams
ISBN: 978-0-470-37359-0
Publicado por Wiley Publishing.
Papers:
Introducing SCA
autor: David Chappell
Url: http://www.davidchappell.com/articles/introducing_sca.pdf
BPM and SOA
Autor: Mike Rosen
Oracle SCA – The Power of the Composite
Autor: Pat Shepherd
Fabric3 Reference Guide
Url: http://dist.codehaus.org/fabric3/releases/doc/1.6/fabric3-reference-1-6.pdf
Sitios Web:
http://msdn.microsoft.com/webservices/
¿Que herramienta de registro utilizar?
El objetivo de tener un registro de las funcionalidades desarrolladas es que todos los desarrolladores conozcan las funcionalidades y no exista duplicidad de servicios. Para esto se podría utilizar diferentes herramientas de propósito más general, como una wiki o una base LDAP, pero es mejor utilizar una herramienta de propósito particular. En el mercado existen herramientas open source para el registro de servicios. Entre los más importantes podemos mencionar a MuleSource Galaxy y Registro de WSO2.
MuleSource Galaxy: Esta basado en un diseñador de repositorios para la gestión de artefactos de software basados en SOA. Entre ellos se incluye la configuración del ESB Mule, WSDL, archivos xml y configuración de Spring. Es una perfecta herramienta de registro cuando se utiliza ESB mule ya que se integra totalmente con ese producto.
Registro de WSO2: Esta diseñado para almacenar, catalogar, indexar y gestionar metadatos de empresa relacionados con artefactos SOA. Incluye el control de versiones y su rapidez lo hace un buen candidato para sistemas empotrados.
El producto Galaxy tiene soporte para las mismas funcionalidades generales que el registro de WSO2, como puede ser la categorización de recursos, la monitorización y la gestión de ciclo de vida y de la dependencia. Además, su versión 1.5 incluye nuevas funcionalidades como la replicación (disponible solo la versión de pago) tiene soporte para scritps y una API de eventos.
El producto de registro WSO2 es muy sencillo de utilizar y en este punto supera a Galaxy gracias a su mejor infraestructura para Atom/Rss y sus funcionalidades de control de versiones y de restauración de versiones anteriores.
Las funcionalidades más atractivas de Galaxy se encuentran en la versión de pago mientras que la herramienta de registro de WSO2 es 100% libre y gratuita. Por esta razón y la facilidad de uso, optamos por la herramienta de registro de WSO2.
MuleSource Galaxy: Esta basado en un diseñador de repositorios para la gestión de artefactos de software basados en SOA. Entre ellos se incluye la configuración del ESB Mule, WSDL, archivos xml y configuración de Spring. Es una perfecta herramienta de registro cuando se utiliza ESB mule ya que se integra totalmente con ese producto.
Registro de WSO2: Esta diseñado para almacenar, catalogar, indexar y gestionar metadatos de empresa relacionados con artefactos SOA. Incluye el control de versiones y su rapidez lo hace un buen candidato para sistemas empotrados.
El producto Galaxy tiene soporte para las mismas funcionalidades generales que el registro de WSO2, como puede ser la categorización de recursos, la monitorización y la gestión de ciclo de vida y de la dependencia. Además, su versión 1.5 incluye nuevas funcionalidades como la replicación (disponible solo la versión de pago) tiene soporte para scritps y una API de eventos.
El producto de registro WSO2 es muy sencillo de utilizar y en este punto supera a Galaxy gracias a su mejor infraestructura para Atom/Rss y sus funcionalidades de control de versiones y de restauración de versiones anteriores.
Las funcionalidades más atractivas de Galaxy se encuentran en la versión de pago mientras que la herramienta de registro de WSO2 es 100% libre y gratuita. Por esta razón y la facilidad de uso, optamos por la herramienta de registro de WSO2.
¿Cómo se desarrolla sobre una arquitectura SOA?
El desarrollo sobre una arquitectura SOA debe siempre tener en cuenta las funcionalidades desarrolladas y debe consumir estos servicios y exponer las nuevas funcionalidades. Por lo tanto es importante tener un registro actualizado donde se registran los servicios desarrollados y si la empresa cuenta con sistemas heredados con servicios expuestos se debe realizar un relevamiento de los servicios desarrollados y reflejarlos en el registro. Que el registro esté actualizado y sea visual para todos los desarrolladores es vital para que no exista comportamiento replicado.
El desarrollador esta obligado a pensar los servicios de forma atómica y desacoplada. Un servicio nunca debe depender de una implementación sino de una interfaz que describe a dicha dependencia, agregando más complejidad a la tarea de diseñar pero disminuyendo el esfuerzo de mantenimiento ante un cambio. Promoviendo el desacoplamiento y la mantenibilidad.
El estilo arquitectónico SOA no es intrusivo, no nos obliga a utilizar una forma propia de SOA para desarrollo, ni un Paradigma de programación, ni un lenguaje, ni plataforma. Pero si nos obliga a no repetir funcionalidad publicada y publicar los servicios de tal forma sean útiles a otros sistemas. Por ejemplo podríamos programar con POO y publicar la funcionalidad por medio de servicios o utilizar el patrón facade. En este esquema los servicios van a seguir la arquitectura SOA, dando la libertad de diseñar nuestros objetos independientes de la arquitectura SOA. Lo más recomendado es utilizar una arquitectura en Capas sumado a la arquitectura SOA.
Una arquitectura en capas nos permite separar de forma lógica las incumbencias generales en capas. El objetivo de separar las incumbencias en capas, es el desacoplamiento. De esta forma podríamos cambiar ciertas capas si necesidad de modificar las demás.
Sumado a la arquitectura SOA con la arquitectura en Capas, aprovechamos lo mejor de los dos mundos.
En la actualidad existen gran cantidad de framework que nos permiten desarrollar servicios web (CXF, Spring WS, Apache AXIS 1 y 2, Metro, etc.) y a la vez existen muchas formas de exponer estos servicios REST, SOAP, Mensajería, etc. y también existen diferentes formatos de datos JSON, SOAP, RSS, ATOM, etc. Todas estas tecnologías pueden conformar mis sistemas lo cual dificulta la comunicación ya que diferentes aplicaciones hablan diferentes idiomas.
Dada esta problemática surgió del mercado un estándar llamado Service Component Architecture (SCA), que propone una forma de desarrollo SOA. Basándose en el concepto de componentes promueve que un componente publica servicios que le permiten hablar idiomas diferentes (más usados) y entender la mayoría de los formatos de datos.
También a raíz de la diversidad de tecnologías para exponer servicios nace el ESB, que como dijimos anteriormente es un adaptador de diferentes “lenguajes”. Por lo tanto podríamos decidir utilizar un framework para exponer servicios y un ESB con su adaptador, o desarrollar con SCA. Dependiendo de los requerimientos se debe realizar una elección.
El desarrollador esta obligado a pensar los servicios de forma atómica y desacoplada. Un servicio nunca debe depender de una implementación sino de una interfaz que describe a dicha dependencia, agregando más complejidad a la tarea de diseñar pero disminuyendo el esfuerzo de mantenimiento ante un cambio. Promoviendo el desacoplamiento y la mantenibilidad.
El estilo arquitectónico SOA no es intrusivo, no nos obliga a utilizar una forma propia de SOA para desarrollo, ni un Paradigma de programación, ni un lenguaje, ni plataforma. Pero si nos obliga a no repetir funcionalidad publicada y publicar los servicios de tal forma sean útiles a otros sistemas. Por ejemplo podríamos programar con POO y publicar la funcionalidad por medio de servicios o utilizar el patrón facade. En este esquema los servicios van a seguir la arquitectura SOA, dando la libertad de diseñar nuestros objetos independientes de la arquitectura SOA. Lo más recomendado es utilizar una arquitectura en Capas sumado a la arquitectura SOA.
Una arquitectura en capas nos permite separar de forma lógica las incumbencias generales en capas. El objetivo de separar las incumbencias en capas, es el desacoplamiento. De esta forma podríamos cambiar ciertas capas si necesidad de modificar las demás.
Sumado a la arquitectura SOA con la arquitectura en Capas, aprovechamos lo mejor de los dos mundos.
En la actualidad existen gran cantidad de framework que nos permiten desarrollar servicios web (CXF, Spring WS, Apache AXIS 1 y 2, Metro, etc.) y a la vez existen muchas formas de exponer estos servicios REST, SOAP, Mensajería, etc. y también existen diferentes formatos de datos JSON, SOAP, RSS, ATOM, etc. Todas estas tecnologías pueden conformar mis sistemas lo cual dificulta la comunicación ya que diferentes aplicaciones hablan diferentes idiomas.
Dada esta problemática surgió del mercado un estándar llamado Service Component Architecture (SCA), que propone una forma de desarrollo SOA. Basándose en el concepto de componentes promueve que un componente publica servicios que le permiten hablar idiomas diferentes (más usados) y entender la mayoría de los formatos de datos.
También a raíz de la diversidad de tecnologías para exponer servicios nace el ESB, que como dijimos anteriormente es un adaptador de diferentes “lenguajes”. Por lo tanto podríamos decidir utilizar un framework para exponer servicios y un ESB con su adaptador, o desarrollar con SCA. Dependiendo de los requerimientos se debe realizar una elección.
EAI (Enterprise Application Integration)
EAI (Enterprise Application Integration, traducido al español como integración de aplicaciones empresariales) es definido como el uso de software y sistemas de computadora para integrar un conjunto de aplicaciones.
El propósito de la EAI es lograr la interoperabilidad y organización del flujo de información entre aplicaciones heterogéneas, es decir, asegurar la comunicación entre las distintas aplicaciones y formar el sistema de información de la empresa, incluso de los clientes, socios o proveedores.
Por lo tanto, y en primer lugar, un proyecto de EAI implica implementar una arquitectura bajo la cual las distintas aplicaciones se comuniquen entre sí. En consecuencia, esto conlleva el desarrollo de conectores (middleware) que posibilitan la interfaz de aplicaciones mediante el uso de distintos protocolos de comunicación (por lo general exclusivos).
Sin embargo, el proyecto de EAI va más allá de la interoperabilidad de las aplicaciones: ofrece la posibilidad de definir un workflow entre las aplicaciones; así, representa una alternativa a la ERP1 con un enfoque más modular.
No obstante, la EAI todavía presenta limitaciones relacionadas con la rigidez de los sistemas heredados (en inglés legacy), porque se debe modificar el middleware cuando hay cambios importantes en las aplicaciones.
Cuando los sistemas no pueden compartir su información efectivamente se crean cuellos de botella que requieren de la intervención humana en la forma de toma de decisiones o en el ingreso mismo de la información. Con una arquitectura EAI correctamente implementada, las organizaciones pueden enfocar la mayoría de sus esfuerzos en la creación de competencias que generen valor en lugar de enfocarse en la coordinación de labores operativas.
Durante varias generaciones, los sistemas de las empresas han servido para un propósito especifico a un único usuario o grupo de usuarios, los cuales actúan como la interfaz de dicho sistema con el resto de la organización, con lo cual se ha limitado su conexión con otros sistemas modernos o más amplios en la empresa, más aún por la creciente demanda de las empresas por compartir datos y usarlos en sus procesos sin tener que realizar cambios en sus aplicaciones o en sus estructuras de datos.
Uno de los retos que encaran las organizaciones modernas es darles a sus empleados información completa en tiempo real. Muchas de las aplicaciones en uso actualmente se apoyan en tecnologías antiguas, por lo cual esos sistemas enfrentan dificultades a la hora de mover esta información entre las aplicaciones.
EAI, como una disciplina, busca solventar muchos de esos problemas, así como crear nuevos paradigmas para ciertamente mejorar las organizaciones, tratando de trascender el objetivo de conectar las aplicaciones individuales para buscar ser un mecanismo de incrementar el conocimiento de la organización y crear ventajas competitivas futuras a la empresa.
La integración de aplicaciones de empresa ha incrementado su importancia porque la computación en las empresas frecuentemente toma la forma de islas de información. Esto ocasiona que el valor de los sistemas individuales no sea aprovechado al máximo debido a su mismo aislamiento.
El propósito de la EAI es lograr la interoperabilidad y organización del flujo de información entre aplicaciones heterogéneas, es decir, asegurar la comunicación entre las distintas aplicaciones y formar el sistema de información de la empresa, incluso de los clientes, socios o proveedores.
Por lo tanto, y en primer lugar, un proyecto de EAI implica implementar una arquitectura bajo la cual las distintas aplicaciones se comuniquen entre sí. En consecuencia, esto conlleva el desarrollo de conectores (middleware) que posibilitan la interfaz de aplicaciones mediante el uso de distintos protocolos de comunicación (por lo general exclusivos).
Sin embargo, el proyecto de EAI va más allá de la interoperabilidad de las aplicaciones: ofrece la posibilidad de definir un workflow entre las aplicaciones; así, representa una alternativa a la ERP1 con un enfoque más modular.
No obstante, la EAI todavía presenta limitaciones relacionadas con la rigidez de los sistemas heredados (en inglés legacy), porque se debe modificar el middleware cuando hay cambios importantes en las aplicaciones.
Cuando los sistemas no pueden compartir su información efectivamente se crean cuellos de botella que requieren de la intervención humana en la forma de toma de decisiones o en el ingreso mismo de la información. Con una arquitectura EAI correctamente implementada, las organizaciones pueden enfocar la mayoría de sus esfuerzos en la creación de competencias que generen valor en lugar de enfocarse en la coordinación de labores operativas.
Durante varias generaciones, los sistemas de las empresas han servido para un propósito especifico a un único usuario o grupo de usuarios, los cuales actúan como la interfaz de dicho sistema con el resto de la organización, con lo cual se ha limitado su conexión con otros sistemas modernos o más amplios en la empresa, más aún por la creciente demanda de las empresas por compartir datos y usarlos en sus procesos sin tener que realizar cambios en sus aplicaciones o en sus estructuras de datos.
Uno de los retos que encaran las organizaciones modernas es darles a sus empleados información completa en tiempo real. Muchas de las aplicaciones en uso actualmente se apoyan en tecnologías antiguas, por lo cual esos sistemas enfrentan dificultades a la hora de mover esta información entre las aplicaciones.
EAI, como una disciplina, busca solventar muchos de esos problemas, así como crear nuevos paradigmas para ciertamente mejorar las organizaciones, tratando de trascender el objetivo de conectar las aplicaciones individuales para buscar ser un mecanismo de incrementar el conocimiento de la organización y crear ventajas competitivas futuras a la empresa.
La integración de aplicaciones de empresa ha incrementado su importancia porque la computación en las empresas frecuentemente toma la forma de islas de información. Esto ocasiona que el valor de los sistemas individuales no sea aprovechado al máximo debido a su mismo aislamiento.
Si la integración se aplica sin seguir un enfoque estructurado de EAI, las conexiones punto a punto crecen al interior de la organización resultando en una masa imberbe que es difícil de mantener. Esto se denota normalmente como el espagueti, en alusión al equivalente en programación: el código espagueti.
EAI puede ser usado con diferentes fines:
EAI puede ser usado con diferentes fines:
- Integración de datos (información): asegurando que la información en varios sistemas es consistente. Esto también se conoce como EII (Enterprise Information Integration).
- Integración de procesos: enlace de los procesos de negocios entre diferentes aplicaciones.
- Independencia de proveedor: extrayendo las políticas o reglas del negocio de las aplicaciones e implementándolas en un sistema EAI, de forma que cualquiera de las aplicaciones usadas pueda ser cambiada sin que dichas reglas de negocio deban ser reimplementadas.
- Facade común: Un sistema EAI puede actuar como el front-end de un cúmulo de aplicaciones, proporcionando una interfaz de acceso única y consistente a esas aplicaciones y aislando a los usuarios sobre la interacción con distintas aplicaciones.
CEP (Complex Event Processing) y ESP (Event Stream Processing)
Las tecnologías emergentes como el Procesamiento de Eventos Complejos (Complex Event Processing o CEP) y el Procesamiento de Flujos de Eventos (Event Stream Processing o ESP) han comenzado a ocuparse de problemas de mayor complejidad que no podían resolverse con el procesamiento de eventos tradicional. Por ejemplo, con CEP se puede analizar, correlacionar y resumir eventos de bajo nivel en eventos de más alto nivel adecuados para informar a las personas en términos humanos o para desencadenar procesos automáticos. CEP y ESP emplean técnicas como la detección de patrones complejos en numerosos eventos, utilizando algoritmos de procesamiento de reglas para la correlación y abstracción de eventos, empleando jerarquías de eventos y relaciones entre los eventos. Los análisis de causalidad, membrecía, oportunidad y procesos impulsados por eventos son capacidades centrales de estas tecnologías.
ESP permite analizar los procesos e identificar eventos inusuales, lo que permite a raíz de estos eventos informarlos o ejecutar algún proceso. Por ejemplo una persona que saca del cajero un monto inusual de dinero el sistema podría enviar un e-mail al cliente notificando la extracción. Otro ejemplo podría ser: un servicio demora más de lo normal esto puede generar un evento el cual sea notificado a un servicio que informe al administrador.
ESP y CEP se consideran parte de una tendencia más extensa llamada EDA (event-Driven Architecture) EDA es un estilo arquitectónico, que esta centrado en comunicaciones asíncronas basadas en eventos. Es totalmente complementario a SOA y utiliza mensajes asíncronos en lugar de llamadas a funciones al estilo RPC, para realizar computación distribuida. Un evento es simplemente la acción de algo que está ocurriendo, bien sea un pedido, un aviso de entrega o la finalización del trabajo de un empleado. El sistema que registra el evento (también llamado sensor) genera un objeto de eventos que se envía mediante una notificación. El consumidor de la notificación o receptor puede ser otro sistema que por su parte, utilice el evento para iniciar alguna acción como respuesta. Aquí es donde el concepto de ESP entra en juego.
ESP permite analizar los procesos e identificar eventos inusuales, lo que permite a raíz de estos eventos informarlos o ejecutar algún proceso. Por ejemplo una persona que saca del cajero un monto inusual de dinero el sistema podría enviar un e-mail al cliente notificando la extracción. Otro ejemplo podría ser: un servicio demora más de lo normal esto puede generar un evento el cual sea notificado a un servicio que informe al administrador.
Implementar ESP en una arquitectura SOA nos facilita su mantenimiento y permite manejar eventos complejos de una forma fácil.
BPEL
Business Process Execution Language (lenguaje de ejecución de procesos de negocio), se trata de un lenguaje XML para la especificación de procesos de negocio ejecutables, aplicado principalmente a la orquestación de los servicios web. BPEL es un subconjunto de BPM. Definido para representar workflows de servicios web.
La interacción entre servicios web puede ser descripta de dos formas: procesos de negocio ejecutable y procesos de negocio abstracto.
Bpel fue diseñado con los siguientes objetivos:
La interacción entre servicios web puede ser descripta de dos formas: procesos de negocio ejecutable y procesos de negocio abstracto.
- Proceso de negocio ejecutable: es el comportamiento real de un participante de una interacción.
- Proceso de negocio abstracto: es el proceso que no está destinados a ser ejecutados, puede ocultar algunos de los detalles necesarios de las operaciones concretas. Los Procesos abstractos desempeñan una función descriptiva, con más de un caso de uso posible, incluyendo el comportamiento observable y plantilla de proceso. Un proceso abstracto que incluye información como cuándo es mejor esperar para mensajes, cuándo enviar mensajes, cuándo compensar las transacciones fallidas, etc.
Bpel fue diseñado con los siguientes objetivos:
- Definir procesos de negocio que interactúan con entidades externas a través de operaciones de Web services definidas en archivos WSDL, y que se manifiestan en los servicios Web definen utilizando WSDL.
- Esta basado en xml. No define una representación gráfica de procesos, ni provee algún particular metodología de diseño.
- Definir una serie de conceptos de orquestación de servicios Web que pretenden ser usados por vistas internas o externas de un proceso de negocio.
- Proveer sistemas de control jerárquicos y de estilo grafo, que permitan que su uso sea lo más fusionado e inconsútil posible. Esto reduciría la fragmentación del espacio del modelado de procesos.
- Proveer funciones de manipulación simple de datos, requeridas para definir datos de procesos y flujos de control.
- Soportar un método de identificación de instancias de procesos que permita la definición de identificadores de instancias a nivel de mensajes de aplicaciones. Los identificadores de instancias deben ser definidos por socios y pueden cambiar.
- Brindar la posibilidad de la creación y terminación implícitas de instancias de procesos, como un mecanismo básico de ciclo de vida. Operaciones avanzadas de ciclo de vida como por ejemplo "suspender" y "continuar" pueden agregarse en futuras versiones para mejorar el manejo del ciclo de vida.
- Definir un modelo de transacción de largo plazo que se base en técnicas probadas tales como acciones de compensación y ámbito, de tal manera a brindar recuperación a fallos para partes de procesos de negocios de largo plazo.
- Usar servicios Web como modelo para la descomposición y ensamblaje de procesos.
- Construir sobre estándares de servicios Web (aprobados y propuestos) tanto como sea posible, de manera modular y extensible.
BPM
BPM (Business Process Management) podría ser definido como un Flujo de trabajo o workflow1, es una forma de representar los procesos, los cuales son seguidos por el sistema. Permitiendo en tiempo de ejecución modificar el workflow y que se aplique estos cambios sin volver a compilar ni a bajar o subir la aplicación.
BPM marca al sistema el orden de ejecución de procesos dando la flexibilidad para poder modificar este orden cuando se lo desee. Esto permite centrarse en la lógica de negocio dando el poder de decisión al usuario final el cual por medio de un editor puede modificar el workflow como crea más conveniente. Se centra en el negocio.
BPM es un concepto muy sencillo. Es un conjunto de métodos, herramientas y tecnologías utilizados para diseñar, representar, analizar y controlar procesos de negocio operacionales; un enfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la información con metodologías de proceso y gobierno.
El objetivo de una solución para la gestión de procesos de negocio es proporcionar, dentro de las TI, implementaciones automatizadas de procesos de negocio de la vida real, como por ejemplo los procesos de pedidos y cobros, o de gestión de reclamaciones. Combinada con una SOA, esta forma de proporcionar funcionalidades de TI, con una visión orientada a procesos.
La tecnología BPM incluye lo necesario para diseñar, representar, analizar y controlar los procesos de negocio operacionales:
BPM no esta acoplado al mundo SOA, se puede controlar procesos de una aplicación usando BPM sin tener servicios web. Pero BPM se puede utilizar para modelar flujo de trabajo llamando servicios web. Permitiendo una gran flexibilidad el flujo de trabajo no depende de una aplicación sino que esta constituido por servicios referenciados por una URI. El motor BPM no esta acoplado a implementaciones sino que conoce solo interfaces dadas por WSDLs o otros descriptores desacoplando el motor BPM de los servicios. Además se puede extender el motor BPM para que ofrezca información del workflow por servicios web. Proporcionando funcionalidades completas por servicios web.
BPM es un concepto muy sencillo. Es un conjunto de métodos, herramientas y tecnologías utilizados para diseñar, representar, analizar y controlar procesos de negocio operacionales; un enfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la información con metodologías de proceso y gobierno.
El objetivo de una solución para la gestión de procesos de negocio es proporcionar, dentro de las TI, implementaciones automatizadas de procesos de negocio de la vida real, como por ejemplo los procesos de pedidos y cobros, o de gestión de reclamaciones. Combinada con una SOA, esta forma de proporcionar funcionalidades de TI, con una visión orientada a procesos.
La tecnología BPM incluye lo necesario para diseñar, representar, analizar y controlar los procesos de negocio operacionales:
- El diseño y modelado de procesos posibilitan que, de forma fácil y rigurosa, pueda definir procesos que abarcan cadenas de valor y coordinar los roles y comportamientos de todas las personas, sistemas y otros recursos necesarios.
- La integración le permite incluir en los procesos de negocio cualquier sistema de información, sistema de control, fuente de datos o cualquier otra tecnología. La arquitectura orientada a servicios (SOA) lo hace más rápido y fácil.
- La ejecución convierte de forma directa los modelos en acción del mundo real, coordinando los procesos en tiempo real.
- La supervisión de la actividad de negocio (BAM) realiza el seguimiento del rendimiento de los procesos mientras suceden, controlando muchos indicadores, mostrando las métricas de los procesos y tendencias clave y prediciendo futuros comportamientos.
- El control le permite responder a eventos en los procesos de acuerdo a las circunstancias, como cambio en las reglas, notificaciones, excepciones y transferencia de incidentes a un nivel superior.
BPM no esta acoplado al mundo SOA, se puede controlar procesos de una aplicación usando BPM sin tener servicios web. Pero BPM se puede utilizar para modelar flujo de trabajo llamando servicios web. Permitiendo una gran flexibilidad el flujo de trabajo no depende de una aplicación sino que esta constituido por servicios referenciados por una URI. El motor BPM no esta acoplado a implementaciones sino que conoce solo interfaces dadas por WSDLs o otros descriptores desacoplando el motor BPM de los servicios. Además se puede extender el motor BPM para que ofrezca información del workflow por servicios web. Proporcionando funcionalidades completas por servicios web.
Suscribirse a:
Comentarios (Atom)
