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:

• 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.

Para soportar esta estrategia es necesario contar con un conjunto de herramientas que den el soporte necesario para cumplir con el ciclo de vida de BPM. Este conjunto de herramientas son llamadas Business Process Management System y con ellas se construyen aplicaciones BPM.

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.

WS-CDL

Cuando hablamos de coreografía de Servicios Web se debe mencionar a WS- CDL (Web Services Choreography Description Language) y por tanto de colaboración entre actores; es decir, de interacciones entre servicios web. Este lenguaje, basado en XML, permite lograr interacción entre servicios Web. Dicha interacción es independiente del lenguaje o de la plataforma utilizada.

La coreografía es una visión más abstracta y descriptiva de los actores que intercambian mensajes para ejecutar varios procesos particulares (varios flujos de control). WS-CDL tiene como propósito definir la interoperabilidad necesaria para crear un sistema compuesto por servicios web.

Orquestación y Coreografía

La integración se debe llevar a cabo mediante un mecanismo que permita que los servicios cooperen entre ellos. Para ello comúnmente se utilizan dos términos: La orquestación y la coreografía. Hablamos de orquestación de servicios cuando es controlado por una única unidad, es decir un cliente y un servicio establecen un acuerdo con respecto al transporte de mensajes y al contenido. Un proceso es una coreografía de servicios cuando las colaboraciones son definidas entre cualquier tipo de aplicaciones.

La coreografía brinda reglas que revelan como múltiples componentes pueden colaborar entre pares, lo que denominamos peer-to-peer, y de que forma o en que secuencia. Esta colaboración se realiza mediante el intercambio de mensajes. Una coreografía describe la colaboración entre más de un servicio para lograr un objetivo común. Por lo tanto no se centra en un servicio en particular, pero si en un objetivo que tiene que cumplir el flujo de proceso. Para ello, la lógica de control es distribuida sobre los servicios participantes. Para diseñar una coreografía, se debe describir primero las interacciones que los servicios tienen que realizar entre sí para cumplir el objetivo y las relaciones que existen entre estas interacciones. Una coreografía no describe las acciones que son realizadas internamente por el servicio principal para realizar el flujo de procesos.

Si usted alguna vez pudo apreciar una presentación de ballet, puede haberse percatado como cada integrante del equipo (servicios) inicia y finaliza un conjunto de movimientos (flujo de proceso), estos movimientos siguen una trilla (interacciones entre los servicios) musical determinada.

Una orquestación describe el comportamiento que el servicio principal implementa para realizar un flujo de proceso. Esto quiere decir, que el enfoque se centra sobre un servicio en particular, y la lógica de control es centralizada sobre el servicio principal el cual implementa el comportamiento. Para diseñar una orquestación, se describe las interacciones que el servicio principal tiene con las otras partes (servicios, adaptadores, interfaces, etc.) y las acciones que el servicio principal realiza internamente para realizar el flujo de proceso. Una orquestación es ejecutada por una máquina de orquestación. Por lo que es llamado proceso ejecutable.

Para entender mejor la definición de orquestación, imagine como un maestro de una orquesta sinfónica dirige y controla a cada uno de los integrantes (servicios) de la orquesta con el fin de poder lograr un objetivo común (un flujo de proceso), que es el de poder establecer una melodía armoniosa basada en un conjunto de especificaciones (objetivo principal y interrelaciones entre servicios) que contienen las notas, que instrumentos deben tocarse, que notas deben tocar cada uno de esos instrumentos y cuando deben iniciar o detener sus melodías.

Coreografía nos permite especificar las reglas de unión y trabajo colaborativo (entendiendo por colaboración, una función/es de negocio surgidas de la interacción cooperativa de múltiples actores). Es lo que normalmente se entiende por un proceso de negocio global donde se modela el estado de negocio de diversos servicios web.
La orquestación es un mecanismo para el intercambio de mensajes desde una visión más detallada a través de un proceso (un flujo de control). La Orquestación podría verse como la ejecución de un proceso de negocio definido en BPM o BPEL y que puede ser ejecutado por un motor BPM o BPEL.

La coreografía se define mediante WS-CDL y la orquestación puede definirse con BPM o BPEL.

Herramienta SOA: Registro o repositorio

Sólo se puede gobernar lo que se ve, por lo tanto, el primer paso es crear un único catálogo maestro en el que estén visibles, para todas las partes interesadas, los elementos más importantes de su SOA. El registro/repositorio se ha erigido en el estándar para la creación de este tipo de sistema de registros.

El registro es donde se publican los servicios y es donde se debe consultar los servicios existentes para poder consumirlos.

El registro puede ser desde una base de datos LDAP a una entrada en wiki de la empresa, dependiendo de los requerimientos de la empresa. Pero siempre debe tener al menos esta información:

• Punto final del servicio (donde esta publicado).
• Descripción del servicio.
• Ubicación WSDL si usamos servicios SOAP o como se utiliza el servicio.
• Numero de revisión y versión.

Gobierno SOA

Los servicios por si solos son incompletos, necesitan una arquitectura que los mantenga y soporte sus ventajas. Por ejemplo a la hora de desarrollar un nuevo servicio ¿cómo se si no existe ya? O ¿existen servicios que pueden ayudar al nuevo servicio? Por lo tanto debo tener un registro donde registrar mis servicios, en el cual puedo buscar los servicios ya existentes.

El gobierno SOA es el conjunto de roles, políticas y procedimientos que sirven de guía para la adopción de la SOA. Al implementar los componentes tecnológicos de gobierno, está creando la infraestructura para soportar y aplicar estos roles, políticas y procedimientos en toda su SOA.

Luego de desarrollar los servicios hay que gestionarlos, la gestión de los servicios se le llama gobierno SOA.

Gobierno de SOA es una ampliación del gobierno de IT centrada en el ciclo de vida1 de los servicios y en las aplicaciones compuestas en una arquitectura orientada a servicios (SOA) de una organización. La función del gobierno de SOA es definir:

• Derechos para tomar decisiones para el desarrollo, el despliegue y la gestión de nuevos servicios.
• La supervisión y notificación de procesos para capturar y comunicar los resultados del gobierno. Debido a que las aplicaciones SOA están intrínsecamente fragmentadas, introducen nuevos retos de gobierno. No obstante, con políticas, principios, estándares y procedimientos adecuados, los empresarios pueden darse cuenta de todas las ventajas que ofrece la arquitectura orientada a servicios. Una plataforma de gobierno de SOA eficaz no sólo ayuda a los equipos de IT y negocio a identificar mejor qué proyectos contribuyen más a los objetivos empresariales, sino que también dotan de más facilidades a los empleados para trabajar y colaborar de forma más eficaz definiendo claramente sus roles y sus responsabilidades.

El Gobierno SOA pretende dotar de los mecanismos de control, procesos, procedimientos y métodos probados en la práctica para garantizar el orden en las decisiones que se tomen en una iniciativa SOA, evitando el caos en cualquier proyecto SOA que se plantee, logrando la efectividad y agilidad esperada en la transición hacia SOA.

El Gobierno se refiere a los procesos que una empresa establece para garantizar que las acciones realizadas se adhieren a las mejores prácticas, normativas, estándares y principios de arquitectura, con objeto de gobernar la adopción e implementación de SOA.

La ausencia del Gobierno SOA puede desembocar en los siguientes problemas:

• El Programa SOA entrega resultados inconsistentes.
• Crecimiento caótico a nivel de infraestructura y servicios.
• Servicios con funcionalidad redundante.
• Disponer de servicios que no se pueden reutilizar en la organización.
• Inconsistencia en la identificación, diseño y uso de los servicios.
• No se definen métricas para cuantificar el éxito.
• Ausencia de coordinación entre proyectos.

La definición de una Estrategia de Gobierno SOA proporciona la coherencia necesaria para todas las acciones que se lleven a cabo en un Plan de Adopción SOA, siguiendo un enfoque incremental de adopción en distintas fases para reducir riesgos, y proporcionando un modelo de gobierno que constituya un marco de referencia para las decisiones que se tomen.

Por lo tanto podríamos definir a SOA como la suma de servicios y gobierno SOA.

El Gobierno SOA comprende varias herramientas que permiten gobernar los servicios:

• Registro de servicios, permite registrar nuestros servicios y consultar servicios existentes.
• Bus de servicios o ESB (Enterprise Service Bus) facilita la comunicación entre diferentes servicios.
• Orquestación y coreografía, herramienta que permite definir la interoperabilidad de los servicios.
• CEP (Complex Event Processing) y Procesador de flujos de eventos o ESP(Event Stream Processing) son herramientas para diseñar, gestionar y monitorizar los eventos que fluyen a través de un entorno orientado a EDA dado.
• Integración de aplicaciones empresariales o EAI (Enterprise Application Integration) facilita la integración con aplicaciones o bases de datos de una empresa.

A la vez existen muchos frameworks que nos permiten desarrollar servicios SOA, con mayor flexibilidad y rapidez. Permitiendo obtener más fácilmente los beneficios del uso SOA y a la vez preparados para ser Gobernados por el gobierno SOA. En la tesis nos centraremos en el estándar de OASIS4, SCA (Service Component Architecture). SCA es un estándar que simplifica el desarrollo SOA basándose en el concepto de componentes. Nos centraremos en esta especificación dado que brinda gran facilidad en el desarrollo, además promueve el uso de las mejores prácticas.

No necesariamente se deben tener todas las herramientas descriptas para conformar el gobierno SOA. Se deben adoptar las herramientas que satisfagan las necesidades propias de la empresa que adopta SOA.

Servicios.

Los servicios son funcionalidad necesaria para la empresa, es decir son funcionalidad expuesta a otros servicios, sistemas o una interfaz gráfica. Los cuales fueron concebidos para solucionar un requerimiento. Los servicios son los ladrillos de nuestra arquitectura SOA. Ellos pueden contener lógica de negocio, acceso a bases de datos, accesos a otros servicios, etc.

Los servicios están descriptos en una interfaz que indica como utilizarlos. Pero los servicios nunca exponen como funcionan; son una caja negra. Lo que permite cambiar un servicio fácilmente por otro, favoreciendo la mantenibilidad y agilidad de desarrollo. Los servicios exponen como se utilizan pero no exponen como funcionan.

Los servicios pueden acoplarse para formar nuevos servicios, que solucionan nuevos requerimientos, esto ayuda a que no se duplique el código. Los servicios son atómicos y sin estado lo que permite distribuirlos en diferentes maquinas favoreciendo la escalabilidad de los sistemas.

¿Que define la Arquitectura SOA?

La arquitectura SOA define :

• Los servicios.
• Como localizar un servicio.
• Como conseguir que se comuniquen diferentes servicios.
• Como encajar diferentes servicios para que funcionen como un sistema.

En una SOA, los servicios se encuentran documentados en un repositorio denominado registro, se ensamblan mediante las llamadas aplicaciones compuestas, y el plano que le sirve de guía es lo que se conoce como esquema global de la SOA.

¿Que es SOA?

Todo el mundo habla de SOA, que SOA esto que una arquitectura SOA es mejor, bla, bla... Pero que es SOA? En este post vamos a intentar dar una idea general.
En la Facultad nos enseñan que para comprender una realidad compleja se debe dividirla y de esta manera analizar cada componente y comprenderlo para luego analizar la totalidad de la realidad. Utilizaremos este método para definir la Arquitectura Orientada a Servicios. Primero analicemos el término servicio.
Servicio tradicionalmente se ha utilizado para describir una función de negocio autocontenida, con una interfaz bien definida y estable, que recibe requerimientos de sus clientes. El servicio no depende del contexto de sus clientes y puede ser consumido por varios sistemas sin ser modificado. Los servicios son instalados (o desplegados) una única vez, esto lo diferencia de los componentes que deben ser incluidos dentro del contexto de cada aplicación que requiera de su uso y permanecen disponibles, sin consumir recursos hasta que son invocados.

Propiedades de un servicio:

• Interfaz bien definida.
• Autocontenido.
• No depende del contexto de sus clientes.
• No requiere ser desplegado con cada cliente.

Luego de definir servicio especificaremos arquitectura. Una definición reconocida es la de Clements: “La Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones”.

Una vez aclarada la definición de servicio y arquitectura, podemos avanzar sobre la de SOA. Se podría definir como un estilo arquitectónico que propone modelar la empresa como una colección de servicios expuestos en la red. Nos propone ver a la empresa no como sistemas aislados sino como un todo.

La principal utilidad de los servicios web es que promueven la interoperabilidad entre diferentes plataformas, sistemas y lenguajes. Con servicios web, por ejemplo, sería posible integrar una aplicación Windows desarrollada con Microsoft .NET con una aplicación desarrollada en JEE desplegada en un servidor de aplicaciones bajo un sistema Linux.

Alrededor de los Web services, que dominan el campo de un estilo SOA más amplio que podría incluir otras opciones, se han generado las controversias que usualmente acompañan a toda idea exitosa. Al principio hasta resultaba difícil encontrar una definición aceptable y consensuada que no fuera una fórmula optimista de mercadotecnia. El grupo de tareas de W3C, por ejemplo, demoró un año y medio en ofrecer la primera definición canónica adecuada, que no viene mal reproducir aquí:“Un Web service es un sistema de software diseñado para soportar interacción máquina-a-máquina sobre una red. Posee una interfaz descripta en un formato procesable por máquina (específicamente WSDL3). Otros sistemas interactúan con el Web service de una manera prescripta por su descripción utilizando mensajes SOAP, típicamente transportados usando HTTP con una serialización en XML en conjunción con otros estándares relacionados a la Web”

Un servicio es una entidad de software que encapsula funcionalidad de negocios y proporciona dicha funcionalidad a otras entidades a través de interfaces públicas bien definidas.
Los componentes del estilo (o sea los servicios) están débilmente acoplados. El servicio puede recibir requerimientos de cualquier origen. La funcionalidad del servicio se puede ampliar o modificar sin rendir cuentas a quienes lo requieran. Los servicios son las unidades de implementación y diseño.

Como todos los otros estilos, las SOA poseen ventajas y desventajas. Como se trata de una tecnología que está en su pico de expansión, sus virtudes y defectos varían con el tiempo.

Un sistema sencillo basado en servicios. Una aplicación además de implementar sus propios componentes de negocio y datos, también puede reutilizar la funcionalidad de servicios existentes en la red empresarial.

SOA no es un concepto concreto para un área de la empresa, sino que dependiendo del punto de vista que se emplea. Ya que un ejecutivo de negocio lo puede ver como un conjunto de servicios de negocio, un arquitecto de software lo verá como un estilo arquitectónico y el desarrollador un conjunto de estándares, herramientas y tecnologías concretas que permiten llevar a cabo sus tareas.

Actualmente en el mercado se encuentran múltiples frameworks para implementar el modelo SOA, algunos basados en el modelo empresarial de Java y otros no. Además hay que analizar la madurez de la solución y la aceptación que tiene en los programadores.

Reia la fusión de Erlang y Ruby.

Reia es un lenguaje de programación script inspirado en Ruby que corre sobre la maquina virtual de Erlang. Reia une lo mejor de los dos mundos Ruby y Erlang. Reia tiene reflexion, meta-programación, bloques de código, manejo de concurrencia mediante el modelo de actores, distribuido, hot code y tolerancia a fallos.

Veamos de la pagina de Reia una pequeña muestra del lenguaje:

# Hello, world!
"Hello, world!".puts()

# Assignment
number = 42
opposite = true

# Conditions
number = -42 if opposite

# Lists (stored as immutable singly-linked lists)
list = [1, 2, 3, 4, 5]

# Tuples (think of them as immutable arrays)
tuple = (1, 2, 3, 4, 5)

# Atoms (known as symbols to Ruby people)
# Think of them as an open-ended enumeration
atom = :up_and_atom

# Dicts (also known as hashes to Ruby people)
dict = {:foo => 1, :bar => 2, :baz => 3}

# Strings (unlike Erlang, Reia has a real String type!)
string = "I'm a string! Woohoo I'm a string! #{'And I interpolate too!'}"

# Ranges
range = 0..42

# Funs (anonymous functions, a.k.a. lambdas, procs, closures, etc.)
# Calling me with plustwo(40) would return 42
plustwo = fun(n) { n + 2 }

# Modules (collections of functions)
# Calling Plusser.addtwo(40) would return 42
module Plusser
def addtwo(n)
n + 2
end
end

# Classes (of immutable objects. Once created objects can't be changed!)
class Adder
# Reia supports binding instance variables directly when they're passed
# as arguments to initialize
def initialize(@n); end

def plus(n)
@n + n
end
end

# Instantiate classes by calling Classname(arg1, arg2, ...)
# For you Ruby people who want Classname.new(...) this is coming soon!
fortytwo = Adder(40).plus(2)

# Function references can be obtained by omitting parens from a function call,
# like JavaScript or Python
numbers = [1,2,3]
reverser = [1,2,3].reverse

# Function references can be invoked just like lambdas
reversed = reverser() # reversed is now [3,2,1]

# You can add a ! to the end of any method to rebind the method receiver to
# the return value of the given method minus the bang.
numbers.reverse!() # numbers is now [3,2,1]

# List comprehensions
doubled = [n * 2 for n in numbers] # doubled is [6,4,2]

### Numbers

42 # integer
4.2 # float

### Booleans

true # All expressions evaluate true in a boolean context except false and nil
false
nil

### Atoms (an open enumeration, like Ruby's symbols)

:foobar # A simple atom
:"I am the very model of a modern major general" # quoted

### Lists

list = [3,4,5] # lists are singly linked and good for ordered sequences
list2 = [1,2,*list] # the splat operator lets you prepend to an existing list
[1,2,3,*rest] = list2 # splats match patterns. rest is now [4,5]
five = list[2] # List#[] retrieves the nth (zero indexed) member

### Tuples

tuple = (1,2,3) # tuples are immutable arrays
two = tuple[1] # Tuple#[] retrieves the nth (zero indexed) member
# Tuple#[]= produces new versions of a tuple and binds them to the receiver
tuple[1] = 42 # tuple is now (1,42,3)
tuple[2] += 40 # tuple is now (1,42,43)

### Dicts

dict = {:foo => 1, :bar => 2, :baz => 3} # Dicts are key/value maps
bar = dict[:bar] # Use Dict#[] to retrieve a value for a given key. bar is 2
dict[:bar] += 40 # Dict#[]= alters the value of a member

### Strings

"Ohai!" # strings can be double quoted
'Ohai!' # or single quoted
"Ohai, #{name}!" # double quoted strings interpolate
'Ohai, #{name}!' # single quoted strings interpolate too

### Binaries

<[1,2,3]> # binaries allow you to store binary data without stringy fluff
<["string"]> # you can make binaries from strings, too
<[1,2,x]> = <[1,2,3]> # pattern matching can be used with binaries too

### Regexps

%r/^.{3}/ # I'm a regex literal! (Soon %r will go away and /.../ will work)
%r/^.{3}/.match("foo bar baz") # Returns "foo"

### Ranges

1..10 # I'm a range!
(1..10).to_list() # Returns [1,2,3,4,5,6,7,8,9,10]
[n * 2 for n in 1..10, n % 2 == 1] # List comprehension of a range, returns [2,6,10,14,18]

### Funs (a.k.a. anonymous functions or lambda expressions)

adder = fun(x, y) { x + y }
adder(40, 2) # returns 42

multipler = fun(x, y) do
x * y
end

multiplier(7, 6) # returns 42

Como siempre dejo link:

http://reia-lang.org/

Apache Shiro

Apache Shiro es un poderoso y fácil de usar framework para la seguridad de nuestras aplicaciones echas en java. Este framework provee autorización, autenticación, criptografía y manejador de sessiones y además puede ser usado en diferentes aplicaciones, desde una aplicación de lineas de comando, una aplicación móvil o empresarial

Shiro proporciona una API para llevar a cabo los siguientes aspectos:

• Autenticación - que verifique la autenticidad del usuario, a menudo llamada "entrada" del usuario.
• Autorización - control de acceso
• Criptografía - proteger u ocultar los datos de miradas indiscretas
• Gestión de sesiones - el estado del usuario en el tiempo

Shiro también es compatible con algunas características auxiliares, tales como seguridad de aplicaciones web, pruebas unitarias, y el soporte a multi-hilo, pero estos aspectos existen para reforzar las cuatro principales preocupaciones.

Como todos los proyectos apache es open source y ademas es Apache Software Foundation Top Level Project.

Muchas comunidades open-source estan usando Shiro por ejemplo: Spring, Grails, Wicket, Tapestry, Tynamo, Mule y Vaadin, entre otros.

Como siempre dejo links:

http://www.infoq.com/articles/apache-shiro
http://shiro.apache.org/
http://shiro.apache.org/10-minute-tutorial.html

Skinnability

Siguiendo con los post sobre RichFaces:

http://emanuelpeg.blogspot.com/2011/02/richfaces.html
http://emanuelpeg.blogspot.com/2011/03/arquitectura-de-richfaces.html

http://emanuelpeg.blogspot.com/2011/03/manejo-entre-componentes-en-richfaces.html

Skinnability es la habilidad que tiene RichFaces de darle un mismo estilo a todos sus componentes.

Una importante característica son los skin parameters con estos se puede definir un valor y reusar esto en un selector css. Estos valores puede asociarlos a un particular skin.

Un skin es un simple archivo de propiedades que contiene parámetros y valores. Para crear un skin solo es necesario crear un archivo con la siguiente forma skin_name.skin.properties y es necesario que este dentro del classpath.

Con el objetivo de cambiar el skin por defecto es necesario setear la propiedad org.richfaces.SKIN en el web xml.

 org.richfaces.SKIN
 skin_name

RichFaces incorpora skins predefinidos, estos son:

• DEFAULT
• plain
• emeraldTown
• blueSky
• wine
• japanCherry
• ruby
• classic
• deepMarine

Estos skin cotienen los parametros usados por Riche Faces para dar el Look and Fell a los componentes de de RichFaces.

Plain sking es un sking que no tiene parámetros es usado para proyectos que tienen su propio css.

RichFaces skinnability también permite asociar custom renders, nuevos skin y skings para nuevos custom componentes.

RichFaces permite cambiar skin es tiempo de ejecución. Permitiendo elegir al usuario un skin que prefiera.

Manejo entre componentes en RichFaces

Siguiendo con los post sobre RichFaces:

http://emanuelpeg.blogspot.com/2011/02/richfaces.html
http://emanuelpeg.blogspot.com/2011/03/arquitectura-de-richfaces.html

Veamos un concepto importante en Richfaces, RichFaces no puede agregar, ni eliminar ningún elemento pero puede remplazar a uno existente. Veamos un ejemplo que gráfica este comportamiento:

Este código a simple vista funciona, pero no es así. OutputText es renderizado al inicio con el valor false en rendered por esta razón el javascript no puede encontrar este elemento. Para seleccionar este problema se debe recurrir a un contenedor para outputText:

Como se puede ver, lo que se refresca es out2 el cual siempre esta presente y de esta forma se refrescara out1.

Arquitectura de RichFaces

Siguiendo con los post sobre RichFaces

http://emanuelpeg.blogspot.com/2011/02/richfaces.html

Ahora vamos a ver un poco su arquitectura. Con RichFaces se puede utilizar componentes Ajax para invocar pedidos asincronos que son automáticamente sincronizados con el árbol de componentes y actualizar un área de la pagina, sin recargar toda la pagina. La siguiente Imagen fue tomada de la documentación de Rich Faces y muestra el camino de procesamiento de un pedido:

Esto no difiere del estandar JSF y no es necesario escribir javascript para usar componentes RichFace Ajax.

La arquitectura del framework esta compuesta en 5 partes:
Filtro Ajax: Esto es esencial para agregar la capacidad Ajax a sus paginas JSF. Este filtro maneja todos los pedidos (ajax y jsf estándar), corrige y valida el código enviado, maneja los scripts, la carga de estilos, recursos de cache, etc. Se debe registrar el filtro en el web.xml
Componentes Ajax: Son similares a los componentes estándar de jsf pero envían pedidos asíncronos.
Contenedores Ajax: El framework soporta contenedores que describen áreas de la pagina web, las cuales van a ser refrescadas sin refrescar toda la pagina web. Se pueden definir varias áreas que van a ser refrescadas en una pagina, sin refrescar la pagina.
Skinnability: Permite agregar a su aplicación JSF la capacidad de skinning (temas)
RichFaces JavaScript Engine: Esto corre en el cliente y maneja las ajax requests y responces esto es manejado por el framework si necesidad de programar el comportamiento ajax, ni javascripts.

Se puede elegir cuando utilizas Ajax request o request estándar de JSF.

Frases graciosas

• Hay 10 tipos de personas en el mundo: Los que entienden binario, y los que no.
• Me gustaría cambiar el mundo pero lamentablemente, no me dieron el codigo fuente.
• Mi software nunca tiene fallos. Simplemente desarrolla características aleatorias
• La caja decía “Requiere Win95 o superior". Asi que instale Linux
• La gente dice que si pones un CD de WinXP al reves, escuchas voces satanicas. Pero eso no es nada! Si lo pones normal, te instala Windows!
• Acabas de recibir un virus gallego. Como los Gallegos no tenemos experiencia en programación, este virus trabaja basado en un sistema de HONOR. Por favor: Borre todos los archivos de su disco duro manualmente. Gracias por su cooperación.
• Las contraseñas son como la ropa interior. No debes dejarla tirada donde la gente la pueda ver. Debes cambiarla regularmente. Y no debes prestársela a desconocidos.
• Linux para Servidores, Mac para graficos, Palm para Mobilidad y Windows para Solitario
• La Inteligencia Artificial no es rival para la Estupidez Natural.
• Las chicas son como los dominios de Internet, las que te gustan no están disponibles.
• El código mas dificil de corregir es el que sabes que es imposible que tenga errores.
• UNIX es basicamente un sistema operativo simple, pero tenes que ser un genio para entender su simplicidad
• Alerta! Error del Usuario. Por favor reemplacelo y presione una tecla para continuar.
• “Una imagen vale mil palabras”, pero consume mil veces mas memoria.

Libros sobre smalltalk

Dejo un link de libros sobre smalltalk, si ven la lista al final hay uno que se llama Programando con Smalltalk de Diego Gomez a simple vista parece interesante lo voy a leer y les cuanto.

Dejo el link:

http://stephane.ducasse.free.fr/FreeBooks.html

Tutorial de Android

Gracias a JavaHipano encontré este tutorial de Android que esta muy bueno:

http://www.sgoliver.net/blog/?p=1313

Que lo disfruten!

Validacion por Hibernate Validator

La JSR 303 - Bean Validation propone un API de validación basada en un modelo de metadatos, además establece como principal método de definición las anotaciones, aunque estas también pueden ser especificadas y/o extendidas a través de archivos de configuración XML. Otra de las características interesantes de la JSR 303 es que su API no liga especificamente la ejecución de las validaciones a una capa en particular como podría ser la capa web o la de persistencia, sino que puede ser utilizada desde cualquier punto de la aplicación.
Hibernate Validator es la implementación de referencia de la JSR 303.

Cuando validamos datos es posible que la validación sea puesta en la capa de presentación. Poniendo la validación en la capa de presentación corremos el riesgo de replicarla cuantas pantallas se puedan cargar los datos o si por ejemplo hay que exponer una funcionalidad por un web service o mecanismo remoto. El mejor lugar para las validaciones es la capa de presentación y hibernate validator nos ayuda a escribir estas validaciones por medio de anotaciones o xml.

Hibernate validator permite:

• Definir validaciones usando XML y/o anotaciones
• Validación completa y recursiva de objetos
• Definición a medida de constraints y validadores
• Personalización de mensajes de error

Las anotaciones más útiles son:

@Length(min=, max=): Chequea si el largo del string se encuentra en el rango indicado.
@Max(value=): Chequea que el valor sea menor o igual que el valor indicado.
@Min(value=): Chequea que el valor sea mayor o igual que el valor indicado.
@NotNull: Chequea que el valor no sea nulo
@Email: Chequea que el valor sea un mail valido.
@Range(min=, max=): Chequea que el valor se encuentre entre el rango especificado.
@Future: Chequea que el valor sea una fecha futura.
@Past: Chequea que el valor sea una fecha pasada.
@Pattern(regex="regexp", flag=): Cheque a que la propiedad machea con la expresión regular, given a match flag (see java.util.regex.Pattern for more information)
@Patterns( {@Pattern(...)} ): Como @Pattern, pero con multiples expresiones regulares.

Veamos un ejemplo de una clase validada por medio de Hibernate Validator:

package org.assembly.fenrir.model.student;

import java.util.Calendar;
import java.util.Date;

import org.hibernate.validator.NotNull;
import org.hibernate.validator.Past;


/**
* class that represents a student
*
* @author emanuel
*
*/
public class Student {

private static final int COUNT_MONTH_IN_YEAR = 12;

private String name;

private String lastName;

private Date birthDate;

private String comment;

public Student(String name, String lastName, Date birthDate){
 this.name = name;
 this.lastName = lastName;
 this.birthDate = birthDate;
}

public Student() { }


@NotNull
public String getName() {
 return name;
}

public void setName(String name) {
 this.name = name;
}

@NotNull
public String getLastName() {
 return lastName;
}

public void setLastName(String lastName) {
 this.lastName = lastName;
}

@NotNull
@Past
public Date getBirthDate() {
 return birthDate;
}

public void setBirthDate(Date birthDate) {
 this.birthDate = birthDate;
}

public String getComment() {
 return comment;
}

public void setComment(String comment) {
 this.comment = comment;
}


}

Pero como es que se valida? En cualquier punto de la aplicación se puede validar si los datos son correctos en cualquier capa de la aplicación, pero por ejemplo utilizando en la capa de presentación richfaces; este ya hace las validaciones atravez de las anotaciones o xml.

Si utilizas maven y quieres agregar este framework, aca va la dependencia del pom:

 

  org.hibernate

  hibernate-validator

  3.1.0.GA

 

Como siempre dejo link:

http://docs.jboss.org/hibernate/validator/4.0.1/reference/en/html_single/

TDD vs BDD vs ASEREJE vs Equipo

A raíz de un post que ley de dos ideas, que me resulto sensacional. Me quede pensando como a travez del tiempo nos pasamos aprendiendo metodologías para que el equipo sea más productivo, en vez de concentrarnos en formar buenos equipos. Nos preocupamos más en la daily meeting que en programador trabaje, pueda trabajar y se sienta feliz con su trabajo.

Tal vez es más fácil diseñar una metodología nueva en vez de preocuparse por el equipo. Por ejemplo, un equipo bien capacitado en una metodología la cual a modificado según su forma de trabajo y de forma que el mismo cree que es más productivo va a ser más productivo que un equipo que sigue la ultima y más top de las metodologías. Además la persona se va a sentir cómoda y feliz con su trabajo.

En conclusión seguir una metodología a raja tabla, hacer cosas inútiles solo por la metodología es una perdida de tiempo. Tiempo que sería más útil para unir al equipo limar asperezas y crear un ambiente agradable para trabajar.

Y recuerden leer www.dosideas.com que esta muy buena esta web.

Apache Chemistry

Apache Chemistry Provee una implementación Open Source de Content Management Interoperability Services (CMIS) Pero que es CMIS? Bueno CMIS es una especificación de OASIS, para mejorar la interoperabilidad de los sistemas Enterprise Content Management (ECM)

CMIS es un conjunto de Web Services pensados para compartir información entre repositorios de contenidos y que buscan la interoperabilidad de los diferentes sistemas ECM.

CMIS está compuesto de los siguientes elementos:

• Un modelo de dominio, para definir los objetos y relaciones que pueden existir en el repositorio.
• Un conjunto de APIs de comunicación, Web Services y REST, que permiten a las aplicaciones conectarse, navegar, leer y crear contenidos en los diferentes repositorios.
• Un lenguaje de consultas, similar a SQL, capaz de definir criterios de búsqueda sobre propiedades, ubicación o "full-text" de los objetos.

Apache Chemistry consiste en los siguientes proyectos:

• OpenCMIS: CMIS librerias cliente y servidor para Java
• cmislib: CMIS librerias cliente y servidor para Python
• phpclient: CMIS librerias cliente y servidor para PHP
• DotCMIS: CMIS librerias cliente y servidor para .NET

Y Obviamente con Licencia Apache.

Dejo links:

http://chemistry.apache.org/

http://chemistry.apache.org/project/community.html

Maven!!!

Este post es para repasar un poco los aspectos de apache mave...

Maven es un framework de gestión de proyectos Java, basado en POM (Project Object Model), que nos proporciona funcionalidades desde la compilación hasta la distribución, despliegue y documentación de los proyectos.

Maven se basa en patrones y en estándares. Esto permite a los desarrolladores moverse entre proyectos sin la necesidad de aprender como compilar o empaquetar, mejorando de esta forma, el mantenimiento y la reusabilidad.

Que provee maven??

• Características generales de Maven

  • Convención sobre configuración

    • Si todos estamos de acuerdo en ciertas cosas ¿Para qué configurarlas? Démoslas por hechas y mantengamos la opción de configuración por si fuera necesario

  • Uso de buenas prácticas

    • Por ejemplo ejecutar los test unitarios antes de hacer un deploy o instalación

  • Un ciclo de vida extensible declarativamente basado en fases y goals

    • Facilita automatizar tareas sencillas o todo el proceso de construcción de forma rápida y simple, una única orden

  • Un modelo centralizado y transparente de gestión de dependencias

    • Se acabó el “Jar Hell”, el buscar jars por internet y las dependencias de estos jars, o casi del todo…

El principal objetivo de maven es permitir a un desarrollador comprender el estado completo del esfuerzo del desarrollo en el período más corto de tiempo. Para lograr este objetivo existen distintas áreas de las que maven se ocupa:

• Hacer el proceso de construcción sencillo.

• Proporcionar un sistema de construcción uniforme

• Proporcionar información de la calidad del proyecto.

• Proporcionar lineamientos a seguir para el desarrollo de las mejores prácticas.

• Permitir migraciones transparentes a nuevas características.

Maven utiliza el término artifact para denominar a la unidad mínima que maneja en su repositorio. Puede ser por ejemplo un jar, un ear, un zip, etc. Cuando Maven compila y empaqueta código, produce también artifacts que instala en el repositorio.

Los artifacts están agrupados bajo el id de grupo (groupId) y tienen un id propio (artifactId), una versión, un clasificador y una extensión.

Maven está basado en torno al concepto de ciclo de vida de build (build lifecycle). Esto significa que el proceso para construir y distribuir cualquier artifact (proyecto) está claramente definido.

Para la persona que construye un proyecto, esto significa que solo debe aprender un número pequeño de comandos para construir cualquier proyecto Maven.

Existen tres ciclos de vida built-in con Maven: default, clean y site.

Default	Administra hasta el proceso de deployment
Clean	Administra las tareas de reseteo del build anterior
Site	Administra la creación del sitio de publicación del proyecto

Cada uno de los ciclos de vida está definido por una lista de fases, donde cada fase representa una etapa en el ciclo de vida.

Este ciclo de vida define la secuencia de fases que va desde validar la integridad hasta el despliegue (deploy).

Cuando se solicita la ejecución de una fase Maven ejecuta primero todas las fases anteriores siguiendo la secuencia y termina en la fase solicitada.

Las principales fases del ciclo de vida default de maven son:

validate	Valida si el proyecto es correcto y si tiene toda la información necesaria
compile	Compila el código fuente del proyecto
test	Corre los test utilizando el framework de unit test disponible
package	Toma las clases compiladas y recursos y crea un paquete (jar, war, ear).
integration-test	Procesa y despliega el paquete, para que corran las pruebas de integración.
verify	Ejecuta los chequeos necesarios para verificar que el paquete cumple los criterios de calidad.
install	Instala el paquete en el repositorio local para ser usado como dependencia por otros proyectos localmente
deploy	Copia el paquete a un repositorio remoto para ser compartido con otros usuarios y proyectos.

Las fases del cilo de vida clean:

pre-clean	Ejecuta los procesos necesarios, previos al clean
clean	Remueve todos los archivos generados en un build previo
post-clean	Ejecuta los procesos necesarios para finalizar el clean

Las fases del ciclo de vida site:

pre-site	Ejecuta los procesos necesarios, previos a la generación del site
site	Genera el site con la documentación del proyecto
post-site	Ejecuta los procesos necesarios para finalizar la creación del site
site-deploy	Realiza un deploy del site de documentación, en el web Server especificado.

Tener en cuenta que para el deploy del site, debemos configurar el web Server.

website
scp://www.mycompany.com/www/docs/project/

Bueno hasta aquí un maven, repaso general.

RichFaces

RichFaces es un framework web que combina las tecnologías Ajax con JSF. Lo cual permite hacer aplicaciones web con ajax de forma fácil sin preocuparse por mantener complicados métodos javascripts.
RichFaces es un proyecto open sources que permite agregar capacidades Ajax a su aplicación JSF sin escribir javascript por lo tanto sin preocuparse por la compatibilidad entre distintos browsers.

RichFaces provee 2 conjuntos de librerías:

• Core Ajax: Contiene componentes que son útiles para “ajaxiar” las paginas jsf y los componentes estándares de JSF. También provee componentes que generan recursos binarios como imágenes, pdfs, cvs, etc.
• UI: Es un conjunto avanzado de etiquetas Jsf que utilizan Ajax usados para agregar características de una interfaz rica de usuario en su aplicación. Estos componentes soportan Ajax y están perfectamente integrados a la librería Core. Además soportan skills y pueden ser totalmente adaptados a sus necesidades.

Otra característica de RichFace es Component Development Kit (CDK) el conjunto de herramientas usado para crear la libraría UI, y puede ser utilizado para crear nuevos componentes.

Este post explica solo un poco de RichFaces, en futuros post veremos como hacer una aplicación con este framework.

PHP for Android project (PFA)

PHP for Android project (PFA) es una plataforma que nos permite programar en PHP sobre Android. Y además nos provee de la documentación y herramientas

Además esta bajo Licencia Apache!!

Dejo links:

http://www.phpforandroid.net/manual/en/index
http://www.phpforandroid.net/
http://code.google.com/p/android-scripting/wiki/ApiReference

Erjang

Erjang no es otra cosa que una mv escrita para correr erlang sobre la plataforma java.

Como trabaja esto? Lo que permite erjang es pasar un .beam a un .class lo que permite que este corra en la jvm. Además también tiene una consola interactiva.

Este proyecto esta en pañales pero le veo mucho futuro.

Dejo links:
http://groups.google.com/group/erjang
https://github.com/trifork/erjang/wiki

JBoss Seam

JBoss Seam es un framework que integra y unifica los distintos standars de la plataforma Java EE 5.0, pudiendo trabajar con todos ellos siguiendo el mismo modelo de programación.
Ha sido diseñado intentado simplificar al máximo el desarrollo de aplicaciones, basando el diseño en Plain Old Java Objects (POJOs) con anotaciones. Estos componentes se usan desde la capa de persistencia hasta la de presentación, poniendo todas las capas en comunicación directa.

El núcleo principal de Seam está formado por las especificaciones Enterprise JavaBeans 3 (EJB3) y JavaServer Faces (JSF).
A grandes rasgos podemos definir EJB3 como una arquitectura para un sistema transaccional (como bases de datos) de objetos distribuidos basado en componentes que permite construir aplicaciones portables, reusables y escalables.
JSF es un framework de la capa de presentación que define componentes para el interfaz gráfico y "managed beans" para la lógica de la aplicación que interactúan a travé de un sistema de eventos.

Sin embargo, estos frameworks tienen algunas limitaciones y no han sido concebidos para trabajar juntos (esto pretende resolverse con la futura especificación web beans ); tienen distinto tipo de configuraciones (JSF usa archivos XML mientras que EJB3 usa anotaciones), distinto ciclo de vida y no pueden comunicarse directamente a nivel de framework.
Para hacerlos cooperar necesitaríamos escribir "clases fachada" y multitud de código de relleno que se encargase de pasar las llamadas de una capa de la aplicación a otra. Ahí es donde entra en juego Seam.
Seam elimina la barrera existente entre estas tecnologías, permitiendo usar EJBs directamente como "backing beans" de JSF y lanzar o escuchar eventos web.

El maldito libro de los descarrilados

Publico un tutorial de Ruby on Rails en castellano.

http://yottabi.com/mld.pdf

Saludos

El conocimiento cuando es compartido crece, va mejorando y se diversifica

Algunas veces me preguntan ¿porque el blog? , ¿que gano escribiendo esto? Y es difícil, muy difícil explicar en especial a gente que piensa “costo-beneficio” que el blog es solo compartir. Nunca gane ni un peso ni reconocimiento, ni nada y no es necesario ganar algo de esto para seguir.

Yo como muchos de ustedes usa framework open sources, o lee blog de otras personas. Y pienso que este blog es devolver un poco todo lo que recibo gratuitamente y solo porque gente quiere compartir su conocimiento.

Al compartir el conocimiento, leer un articulo y querer compartirlo, buscar que la gente se interese por la tecnología o lo que sea, crea una pequeña responsabilidad a mejorar, escribir cada vez mejor. Y a la vez cada vez que uno escribe fija mejor el conocimiento y aprende más, por mantener el blog se “obliga” a leer alga nuevo. Comparte su entusiasmo y siente que es un poco útil a la comunidad.

El conocimiento cuando es compartido crece, va mejorando y se diversifica; un ejemplo claro es Linux. En este pequeño post quiero aconsejarlos a que sean valientes escriban un blog, inicien un proyecto open source o participen en una comunidad. Y de paso agradezco que me lean, opinen, pidan nuevos post; esto es sumamente gratificante y ayuda a seguir escribiendo.

ActiveMQ con Spring

Vamos a crear dos aplicaciones con spring y maven. Una para publicar mensajes asincronos en ActiveMQ y un cliente para leerlo. Creamos 2 proyecto para que sea notoria la separación de cliente-servidor.

Primero creemos los proyectos con maven:

mvn archetype:create -DgroupId=org.assembly -DartifactId=creadorDeMensajes

mvn archetype:create -DgroupId=org.assembly -DartifactId=lectorDeMensajes

Ahora editemos los pom's para utilizar spring:

pom.xml de creadorDeMensajes:

4.0.0



org.assembly



creadorDeMensajes



1.0-SNAPSHOT



jar



creadorDeMensajes



http://maven.apache.org





 UTF-8











   org.springframework

    spring

   2.5.6.SEC02

 





 org.apache.activemq

  activemq-all

  5.4.2

pom.xml de LectorDeMensajes:

4.0.0



org.assembly



lectorDeMensajes



1.0-SNAPSHOT



jar



lectorDeMensajes



http://maven.apache.org





 UTF-8









  

   org.springframework

    spring

   2.5.6.SEC02

 





 org.apache.activemq

  activemq-all

  5.4.2

Importante que borren los test porque no tenemos la dependencia con jUnit vayan a la carpeta:
creadorDeMensajes/src/test/java/org/assembly y lectorDeMensajes/src/test/java/org/assembly y borren AppTest.java

Corremos:
mvn clean install
mvn eclipse:eclipse

para los dos proyectos, es decir entramos en la carpeta: creadorDeMensajes y corremos los comandos y luego hacemos lo mismo para lectorDeMensajes. Lo cual nos bajara los jars necesarios.

Creador De Mensajes
Antes que nada es recomendable utilizar una ide yo estoy usando eclipse. Para importar los proyectos a eclipse vea el siguiente link:

http://united-coders.com/phillip-steffensen/maven-2-part-3-configuring-eclipse-for-apache-maven-2-projects

Vamos a centrarnos en este proyecto, que va a crear los mensajes para luego ser leídos por el lector.
En el la carpeta creadorDeMensajes/src/main/resources (si no existe la crean) vamos a generar el archivo xml para configurar los beans que vamos a utilizar para enviar mensajes. Creamos el archivo spring-context.xml con el siguiente contenido:

El primer bean que definimos es la fabrica de conecciones a ActiveMQ, como piedad definimos la URL del corredor de mensajes. EL segundo bean es el destino que como parametro se pasa un nombre de destino. El terser bean es el objeto Template que nos hace la vida más facil a la hora de programar con ActiveMQ es una clase de spring y se configura la fabrica de conección. El cuarto bean es nuestra clase que envia mensajes.

Necesitamos una interfaz que describa el servicio, la llamamos EnviadorDeMensajes.java :

package org.assembly;



/**

* @author emanuel

*

*/

public interface EnviadorDeMensajes {



void enviarUnMensaje();



}

Luego programamos la implementación EnviadorDeMensajesImpl.java:

package org.assembly;



import javax.jms.Destination;

import javax.jms.JMSException;

import javax.jms.MapMessage;

import javax.jms.Message;

import javax.jms.Session;



import org.springframework.jms.core.JmsTemplate;

import org.springframework.jms.core.MessageCreator;



/**

* @author emanuel

*

*/

public class EnviadorDeMensajesImpl implements EnviadorDeMensajes {



private static final String MENSAJE = "Hoy te escribo una carta mi pequeña Maria, " +

                               "yo que tanto te quiero y que todos los días me acuerdo de ti, " +

                               "yo me acuerdo de ti.";



private JmsTemplate jmsTemplate = null;



// usado por spring para inyectar el jms template.

public void setJmsTemplate(JmsTemplate jmsTemplate) {

this.jmsTemplate = jmsTemplate;

}





private Destination destino = null;



// usado por spring para inyectar el destino.

public void setDestino(Destination destino) {

this.destino = destino;

}





/**

* @see org.assembly.EnviadorDeMensajes#enviarUnMensaje()

*/

@Override

public void enviarUnMensaje() {

jmsTemplate.send(

  this.destino,

  new MessageCreator() {



    @Override

    public Message createMessage(Session session) throws JMSException {

     MapMessage mensaje = session.createMapMessage();

   

     mensaje.setString("mensaje", MENSAJE);

   

     return mensaje;

    }

   }

  );

}



}

La Clase envía el mensaje gracias a JmsTemplate.

Y ahora programamos la aplicación llamada AppCreador.java :

package org.assembly;



import org.springframework.beans.factory.BeanFactory;

import org.springframework.beans.factory.xml.XmlBeanFactory;

import org.springframework.core.io.FileSystemResource;





public class AppCreador

{

 public static void main( String[] args )

 {

  BeanFactory fabricaDeBeans = new XmlBeanFactory(new FileSystemResource("src/main/resources/spring-context.xml"));



  EnviadorDeMensajes enviador = (EnviadorDeMensajes) fabricaDeBeans.getBean("miEnviadorDeMensajes");



  enviador.enviarUnMensaje();

 }

}

Utilizamos a spring como fabrica de beans y le pedimos que cree el enviador; luego con el enviamos un mensaje.

Para probar esto hay que subir activeMQ, para subirlo hay que hacer:
activemq console (en sistemas Unix-Like)
activemq (en Windows)
Luego podemos ejecutar el AppCreador.

Lector De Mensajes
El lector es similar al enviador, veamos el spring-context.xml:

Ahora configuramos el destino como default en jmsTemplate para no pasarlo al lector y de esta forma es más ágil.
Necesitamos una interfaz para el lector:

package org.assembly;



import javax.jms.JMSException;



public interface LectorDeMensajes {



String leer() throws JMSException;



}

Y la implementación:

package org.assembly;



import javax.jms.Destination;

import javax.jms.JMSException;

import javax.jms.MapMessage;

import javax.jms.Message;

import javax.jms.Session;



import org.springframework.jms.core.JmsTemplate;

import org.springframework.jms.core.MessageCreator;



/**

* @author emanuel

*

*/

public class LectorDeMensajesImpl implements LectorDeMensajes {



private JmsTemplate jmsTemplate = null;



// usado por spring para inyectar el jms template.

public void setJmsTemplate(JmsTemplate jmsTemplate) {

this.jmsTemplate = jmsTemplate;

}





/**

* @throws JMSException

* @see org.assembly.EnviadorDeMensajes#enviarUnMensaje()

*/

@Override

public String leer() throws JMSException {

MapMessage mensaje = (MapMessage) jmsTemplate.receive();

return mensaje.getString("mensaje");

}





}

Ahora creamos la aplicación lectora:

package org.assembly;



import javax.jms.JMSException;



import org.sprin

gframework.beans.factory.BeanFactory;

import org.springframework.beans.factory.xml.XmlBeanFactory;

import org.springframework.core.io.FileSystemResource;



/**

* Hello world!

*

*/

public class AppLector

{

 public static void main( String[] args ) throws JMSException

 {

  BeanFactory fabricaDeBeans = new XmlBeanFactory(new FileSystemResource("src/main/resources/spring-context.xml"));



  LectorDeMensajes lectorDeMensajes = (LectorDeMensajes) fabricaDeBeans.getBean("miLectorDeMensajes");

  System.out.println(lectorDeMensajes.leer());

 }

}

Si ejecutamos esta aplicación devolvera el mensaje enviado por el creadorDeMensajes.
Este es un pequeño ejemplo del uso de Apache Active con spring espero que les sirva.

Facelets framework.

¿Que es Facelets?
Cuando JSF fue ideado, la intención fue reutilizar JSP como principal tecnología para la creación de paginas web, dado que es un estándar en la comunidad web.
La idea fue hacer natural la adopción de JSF por medio de etiquetas naturales que ya tienen una adopción el el mundo java.

Desafortunadamente JSP y JSF no se complementan entre si. JSP se usa para crear paginas web dinámicas pero no para crear arboles de componentes. En JSP los elementos son procesados desde el principio de la pagina hasta el final. JSF, sin embargo, tiene un ciclo de vida mucho más complejo, generación de componentes, y una generación separada en faces claras.

Si se mezcla JSP con JSF, el JSF se renderizara a medida que se vaya encontrando, en cambio los componentes JSF tiene cada uno su propio renderizado. Esto puede traer ciertos problemas.

Facelets llena el gap entre JSP y JSF. Esta centrado en la creación de arboles de componentes y el entrelazamiento de contenido con el complejo ciclo de vida de JSF. Facelets remplaza a JSP con una muy simple API que es el reflejo de principios simples y esto incorpora numerosas características que facilitan el desarrollo.

¿Porque utilizar Facelets?
Hay muchas razones por las que usar Facelts antes que JSP para el desarrollo de JSF:

• No depende del contenedor, Facelts puede trabajar con cualquier implementación y versión de JSF.
• La interacción entre JSP y JSF puede traer problemas.
• Facelets provee templates, que pueden ser reutilizados
• Su simpleza maximiza la reutilización, es extensible y escalable.
• Facets soporta EL (Unified Expression Language)
• Facets no requiere ninguna librería especial para el renderizado.

Descargar Facelets.
Facelets se puede descargar de la siguiente URL: http://facelets.dev.java.net/
El jar que se necesita para trabajar con Facelets es jsf- facelets.jar y las dependencias puede ser buscadas en el directorio lib.

Si usan maven la dependencia es:

 com.sun.facelets

 jsf-facelets

 1.1.6

Configuración
Para configurar un proyecto web para que use Facelets en necesario configurar el Web Descriptor (web.xml) agregando lo siguiente:

..............





 javax.faces.DEFAULT_SUFFIX

 .xhtml

De esta forma indicamos que nuestras paginas van a finalizar con el subfijo xhtml.
Además como cualquier proyecto JSF hay que agregar el servlet y el servlet-mapping

 Faces Servlet

 javax.faces.webapp.FacesServlet

 1





 Faces Servlet

 /faces/*

Además es necesario crear un archivo Configuración de Faces Descriptor (faces-config.xml) como cualquier proyecto JSF, donde es necesario remplazar el ViewHandler traido por defecto por:
com.sun.facelets.FaceletViewHandler de la siguiente manera:

 

   com.sun.facelets.FaceletViewHandler

 

En faces-config.xml también se define las reglas de navegación.

 

     home

     /index.xhtml

 





 

     parrot

     /parrot.xhtml

 





 

     eagle

     /eagle.xhtml

 

Como se puede ver se define cada uno de los links a que htmlx debe ir.


Tags
Es necesario que las paginas Facelets sean un XML valido, cuando se utiliza una librería es necesario que se declare como un namespace, donde podemos mapear la URI a un prefijo como se puede apreciar en el siguiente ejemplo:

En el ejemplo usamos 3 librerías, una XML sin prefijo, otra para Facetlet tag con el prefijo ui y otra básica de JSF con el prefijo h.
En la siguiente tabla se puede ver los namespace más comunes:

NAMESPACE	PREFIX LIBRARY	XHTML
http://www.w3.org/1999/xhtml	--	Facelets Templating
http://java.sun.com/jsf/facelets	ui	JSF Core
http://java.sun.com/jsf/core	f	JSF HTML
http://java.sun.com/jsf/html	h	MyFaces Tomahawk
http://myfaces.apache.org/tomahawk	t	MyFaces Tomahawk
http://myfaces.apache.org/sandbox	s	Sandbox
http://myfaces.apache.org/trinidad	tr	MyFaces Trinidad
http://java.sun.com/jstl/core	c	JSTL Core
http://java.sun.com/jsp/jstl/fmt	fn	JSTL Functions

Si se agrega un componente pero no se agrega el espacio de nombre correspondiente para el componente, habrá un error en el momento de compilación de la pagina.

Carga de las librerías de Tags
Facelets usa la siguiente estrategia para cargar las librerías de etiquetas. Primero, busca las librerías en la carpeta /META-INF dentro de los jars. Intenta cargar los archivos que tienen la siguiente forma *.taglib.xml. De esta forma se cargan librería de etiquetas estándares.
Luego, facelets chequea las librerías definidas en web.xml, inicializado como parámetros facelets.LIBRARIES. Esta estrategia es ideal para cuando se desea cargar una librería de etiquetas propia.

Varias librerías de etiquetas ya son incluidas en el jar de facelets:

• Templating library: Contiene las etiquetas para la creación de plantillas.
• JSF libraries: Dos librerías de etiquetas las cuales son incluidas por la especificación de JSF, son librerías incluidas por defecto por Facelets.
• JSTL: Facelets provee soporte parcial a etiquetas de JavaServer Pages Standard Tag
• Library (JSTL). Mientras la librería Function es totalmente soportada, La Core es parcialmente soportada, las etiquetas soportadas son: c:if, c:forEach, c:catch y c:set.

Otras Librerías
Para incluir otra librería de etiquetas se debe agregar la misma en la carpeta /META-INF y además se debe incluir el import del Taglib dentro de la aplicación.

Creación de plantillas
En las plantillas nosotros definimos básicamente el layout de la pagina, y los estilos. Con la etiqueta ui:insert podemos definir las áreas en la pagina que pueden ser sobreescritas, por las paginas que usan la plantilla (clientes). Para usar esta etiqueta es necesario el espacio de nombre: http://java.sun.com/jsf/facelets
El cliente usa este template con los tags ui:component, ui:composition, ui:fragment, o ui:decorate. Veamos un ejemplo de plantilla:

 

 





 

     
The Happy Birds Directory

     


         

     

     

         Welcome to the nest!

     

 

La pagina que utilice esta plantilla sera algo así:

 

     

         Hola Mundo!!

     

 

Es usada la etiquete ui:composition para referenciar la plantilla utilizada. La etiqueta ui:define es utilizada para indicar a Facelts cual area se va a redefinir.
Las plantillas no están limitadas a un nivel, es posible tener varios niveles de plantillas, de este modo un cliente para un template puede ser un template para otro cliente.