jueves, marzo 11, 2010

WebLogic Server 11g on Mac OS X

The purpose of this article is to describe the process by which a user can have Oracle WebLogic Server 11g installed and running on a Mac OS X Snow Leopard. First disclaimer: The installation explained bellow is not officially supported by Oracle.

Apple nowadays ships Snow Leopard with Java 6 as the only JVM on Snow Leopard. Fortunately, this is the JVM version supported by Oracle WebLogic Server 11g. But most (if not all) of the native enhancements that WebLogic has for the supported UNIX systems will be lost when installed on an Mac due to lack of the same native libraries.

I have managed to configure a cluster with two nodes and one server instance per node plus the admin server. I have also managed to configure Node Manager so I can start and stop servers from the admin server (or any wlst client). Second disclaimer: this installation is only intended to be a demonstrative exercise and it is not intended as a recommended installation in case of production systems.

Downloading

In order to download WebLogic, go to the next page: Download. Accept the license and select "Oracle WebLogic Server 11gR1 (10.3.2) - Package Installer" Generic (under the Additional Platforms).

Preparing Apple's JVM

By default, WebLogic's installer will not recognize the Java Virtual Machine provided by Apple. As a workaround for this problem, you can create the following resources on your system:

$ cd /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
$ sudo mkdir jre
$ sudo mkdir jre/lib
$ sudo mkdir jre/lib
$ sudo touch jre/lib/rt.jar
$ sudo touch jre/lib/core.jar

Executing Installer

For a successful execution of the installer, you must open the Terminal, go to the directory where the installer is and execute the following command:

java -Dos.name=unix -jar wls1032_generic.jar

Note: If you double click the jar file you have just downloaded, it will complain about the Insufficient disk space! independently of the available space there really is on your system.

The rest of the installation is business as usual, so please refer to other documentation in case of need.

Running the servers

Running the servers should not involve any problems. WebLogic does complain with an error message because of not being able to load performance pack and states that it will be using Java I/O instead. That's just fine for us and our exercise of having it running on a development machine.

Running the Node Manager

The Node Manager as the rest of the components is also unable to use the native enhancements but in this case it does suppose a problem: it won't start. In order to make it work, it is needed to set the NativeVersionEnabled to false. This can be done in two ways, either create a nodemanager.properties file in the domain home directory or set it as an environment variable when starting the java virtual machine.

On the first case, just create the file and write NativeVersionEnabled=false on it as it's only content. Save the file and execute the following commands from the domain home directory:

/wlserver_10.3/server/bin/setWLSEnv.sh
java weblogic.NodeManager

On the second case, just execute:

/wlserver_10.3/server/bin/setWLSEnv.sh
java -DNativeVersionEnabled=false weblogic.NodeManager


I hope you have found this article useful. I personally enjoy very much being able to run J2EE Applications on my Mac laptop using Oracle WebLogic Server.

viernes, febrero 29, 2008

Enterprise Service Bus

Con el auge de la tecnología SOA (Service Oriented Architecture) y EDA (Event Driven Architecture) se perfila la necesidad de un nuevo componente en la ya compleja infraestructura de los servicios de información: el bus de servicios de empresa (ESB). Dicho componente viene a cubrir un espacio creado por la necesidad de permitir la comunicación entre componentes o servicios de la empresa.
Hasta la fecha, el papel integrador venía dado de la mano de EAIs (Enterprise Application Integration), una tecnología que permitía comunicar distintos recursos informáticos para poder hacer uso de ellos conjuntamente. El problema que tiene esta tecnología es que los tiempos de desarrollo son largos, los proyectos conllevan un desembolso importante y existe una absoluta dependencia del fabricante (vendor lock-in).
Debido a esta difícil situación respecto a los EAIs, la industria ha evolucionado hacia lo que se ha pasado a llamar ESB. El corazón de un ESB es un MOM (Message-Oriented Middleware); lo que permite que la comunicación entre distintos componentes se haga de manera transparente, fiable y asíncrona (en el caso de que fuese necesario el sincronismo también deberá estar permitido en el ESB).
Además del sistema de mensajería hacen falta conectores para comunicar los distintos recursos de la empresa con el ESB. Dichos conectores permitirán exponer los recursos de la empresa como servicios dentro del propio ESB (de hecho la definición de los mismos se queda en el nivel de abstracta, sin necesidad de definir puertos). De manera que la comunicación interna del ESB se realiza con XML como formato impuesto, permitiendo con ello acceder de manera sencilla y rápida a la información que transita por dentro del ESB. Este último hecho permite aplicar tecnologías como BAM (Business Activity Monitoring) sobre los datos que transitan por un ESB.
Por último, pero no menos importante, es responsabilidad de un ESB el enrutamiento de los mensajes y la orquestación de los mismos. Por enrutamiento se entiendo el proceso de recibir la entrada de un mensaje y decidir la salida o salidas que el mensaje debe tomar (pudiendo hacer transformación del contenido, gracias al hecho de que es un XML, se pueden usar tecnologías XSLT). La orquestación es el esqueleto de una aplicación compuesta, en la que a través de lenguajes formales se permite definir el flujo de actividades y estados por los que ha de pasar un proceso de empresa para su realización (un ejemplo bastante extendido es BPEL).
Existe la creencia de que un ESB no tiene por qué ser un producto final, sino más bien una manera de enfocar una arquitectura SOA. Sin embargo, lo cierto es que en el mercado ya existen tanto especificaciones que hacen de un ESB un contenedor de componentes estándar (JBI: JSR 208) como productos que las implementan. Respecto a este último punto, es importante ver cómo reacciona la industria ya que actualmente dos de los grandes fabricantes (IBM y BEA) por el momento se niegan a seguir el estándar y tienen su productos propietarios en el mercado.
Para terminar, resaltar que no han sido enumeradas todas las características de un ESB sino que solo se han referido las más importantes tanto por su novedad como por su importancia a la hora de decidir si se ha de invertir tiempo y recursos en implantar un ESB en la empresa.

sábado, febrero 03, 2007

Axis2 y servicios web




La verdad es que se puede decir que he llegado un poco tarde al mundo de los servicios web, por lo menos lo suficiente para haberme encontrado a Apache Axis 2 donde antes estuvo Axis 1. Dicen los de Apache que Axis 2 es una reescritura desde cero del motor más famoso de servicios web en el mundo de java. Parece ser que han conseguido mejorar la velocidad además de darle unas cuantas funcionalidades extras a Axis 2, como puede ser el asincronismo que tan de moda se ha puesto.

Yo hasta ahora no he sacado partida al asincronismo, pero sí he hecho unos cuantos servicios web con esta tecnología. Como no puede ser de otra manera he usado Springframework acompañándola (sobra decir que la unión de ambas tecnologías está soportado en la versión 1.1 de Apache Axis 2 de manera fácil y elegante). Además me he dejado llevar por mi herramienta favorita y he mavenizado el proyecto con Apache Maven 2.0.4.

La verdad es que no se puede decir que todo resulta fácil y cómodo. Yo he tenido que pelearme bastante con el tema de la configuración de los plugins en Maven para conseguir hacer funcionar tanto el java2wsdl como el wsdl2java, pero una vez conseguido el propósito, todo funciona a la perfección.

A la hora de integrar Spring en Axis 2, dan dos soluciones al problema: levantar el contexto de aplicación de spring desde el propio servlet o hacerlo dentro de lo que se llama un archivo de axis 2 (aar). En el primer caso el contexto de aplicación puede ser compartido por todos los servicios web alojados en la misma aplicación web de Apache Axis 2. Mientras que en el segundo caso no sería así, y cada servicio web dispondría de su propio contexto de aplicación de Spring.

La verdad es que a mi me gusta más la segunda manera de hacer las cosas, puesto que permite aislar mejor las cosas haciendo que cada servicio web sea independiente a la vez que autónomo. Sí es cierto que la segunda manera te obliga a hacer más cosas (como tener cuidado con los classpath ya que parece ser que hay problemillas al respecto, un jar que esté en el classpath de axis2 no verá un jar que esté en el classpath del archivo aar).

miércoles, agosto 09, 2006

Java Server Faces: La siguiente generación de MVC Web

Llevaba tiempo queriendo aprender esta nueva tecnología que lleva años dando vueltas por el JCP (Java Community Proccess) pero que no terminaba de florecer. Tengo que reconocer que esta vez fuí infiel a Manning y terminé comprando el libro de O'reilly cuyo título es "Java Server Faces".
La meta de esta tecnología es abstraer lo suficiente el desarrollo de aplicaciones web, el protocolo http y sus limitaciones, para conseguir que los desarrollos que hagan al estilo de aplicaciones gui (por eventos) de toda la vida. Según parece le pidieron al mismísimo Craig R. McClanahan (creador del framework de Struts) que les ayudase con la especificación de la tecnología. Y, actualmente le han pedido unirse al proceso de especificación a Howard Lewis Ship, el creador de Tapestry, dado que este framework hace que las aplicaciones web sean todavía más parecidas al modelo de desarrollo por eventos.
La verdad es que cuando uno se enfrenta con Java Server Faces por primera vez nota unas ciertas reminiscencias con respecto a Struts. Cosas como la validación y el control de la navegación así lo demuestran, aunque el grado de sofisticación es mucho mayor.
Aunque Java Server Faces sea una tecnología reciente, es cierto que tiene un esfuerzo que demostrar, y es conseguir integrar la funcionalidad de AJAX en las propias especificaciones de la tecnología. En caso de que no sea así, dudo que JSF ocupen el lugar en el mundo del desarrollo de aplicaciones web que sus autores reclaman.
Java Server Faces dispone de un catálogo de componentes gui que facilita la vida a los desarrolladores de webs, además existen distintos catálogos por parte de todo tipo de fabricantes (open source y propietarios).
Yo solo he tenido oportunidad de trabajar con la implementación de Apache llamada MyFaces. Además de dicha implementación disponen también de más componentes gracias al proyecto Tomahawk así como el proyecto Tobago.
La curva de aprendizaje de Java Server Faces yo diría que es más pronunciada que la de Struts, quizás debido a que viniendo de Struts se tienen una serie de manias innecesarias.
En Java Server Faces el código de la aplicación va en beans que son registrados en un archivo xml en el que se configura la aplicación JSF. La manera de configurar los beans de la aplicación recuerda a Spring en el sentido de que permite la inyección de dependencias (o la Inversión de Control). Y ya que hablamos del archiconocido framework Spring, debemos dejar claro que la integración entre ambos resulta de lo más sencillo del mundo (solo hay que cambiar lo que se llama un "resolvedor de variables" para que sea spring quien se encargue de mapear e inyectar los beans en la aplicación).
Aparte de la curva de aprendizaje, con JSF se pueden hacer desarrollos más profesionales y con mejor calidad de código que con otros frameworks en menos tiempo. Gracias a todos los componentes que se pueden usar out-of-the-box así como la filosofía de orientación a eventos que supone, hacen que la aplicación resulte muy completa.

martes, agosto 01, 2006

AOP: ¡Enriquece tus programas con aspectos!

Lo primero pedir disculpas por no haber escrito en el blog desde hace tanto tanto tiempo. La vida moderna de trabajador junto con las actividades extralaborales hacen complicado dedicarle tiempo a escribir artículos. La verdad es que fue una sorpresa encontrarme con un compañero recién llegado a mi antigua empresa que me contó que leía mi blog (¡hay gente que me lee!).
He decidido cambiar de aires, y cambio de trabajo y de casa (aunque no de ciudad). Aire nuevo aspecto nuevo, ¿no?
La programación orientada a aspectos no deja de ser una abstracción más a las abstracciones que se han ido realizando para crear lenguajes que cada vez son de más alto nivel. Igual que la orientación a objetos es un paso más de la programación procedural, los aspectos son el siguiente paso. No sé como se encontró el lector cuando paso de procedural a oop, pero yo recuerdo que durante un tiempo se me puso cara de no terminar de entender nada y encontrarme en un mar de dudas. Y la verdad es que en cierta manera me ha pasado lo mismo cuando he pasado de oop a aop.
¿Qué necesidad hay para la AOP? Cuando uno se pone a programar una aplicación se da cuenta de que hay una serie de cosas que se repiten en la mayor parte de los componentes de la aplicación. Por ejemplo, el traceo o logueo de mensajes, la seguridad, la caché, las transacciones... Son todos conceptos que tocan muchas partes de la aplicación que no tienen nada en común. En inglés, a este concepto se le llama crosscutting concerns (conceptos concernientes a distintas partes de la aplicación).
Para entender mejor la AOP conviene definir unos conceptos básicos: join points, point cuts, advices y aspects.

Join Point (punto de unión): lugar de la aplicación donde puede producirse una unión entre el aspecto y el programa. Son lugares que el compilador de aspectos puede reconocer y donde pueden introducirse advices. Como ejemplos podemos citar constructores, llamadas a métodos, asignaciones de variables...

Point cuts (Cortes de punto): Para definir en qué join point queremos actuar deberemos definir los point cuts. Un point cut no deja de ser una expresión regular (con sus particularidades) que indica en qué puntos de unión queremos meter los distintos advices.

Advices (avisos): Un advice en AOP se puede comparar a un método en OOP, aqui otra vez encontramos peculiaridades. Hay distintos tipos de advices: before, around y after y estos se pueden definir de manera que refinen más todavía el momento de actuación respecto al point cut asociado. Imaginemos que tenemos un point cut para un método de determinada clase pero solo queremos que nuestro advice actue cuando dicho método lance una excepción... Este tipo de refinamiento es posible en la declaración del advice.

Aspect (aspecto): Un aspecto en AOP viene a ser lo que un objeto en OOP. Un aspecto se compone de los point cuts, los advices y todo el código que se quiera. Dentro de un aspecto podemos usar objetos, de manera que dentro de un advice podemos tener la lógica de, por ejemplo, el traceo de la aplicación (haciendo las importaciones adecuadas, p.e. log4j).

¿Y todo esto como se come? Pues después de habernos hecho nuestros aspectos pasamos a usar el compilador de aspectos. Un compilador de aspectos lo que hace es tejer (weave) el código del programa con el de los aspectos, dando como resultado un código compatible con la tecnología (en caso de aspectj y java, no da un bytecode compatible).

Por supuesto, esto solo es una introducción a la programación orientada a aspectos, pero espero que sirva a alguno para introducirse en tan fantástica tecnología.

miércoles, enero 04, 2006

Spring, la primavera deseada



Ya pasó... 2005 ya es historia, nos guste o no. A mi la verdad es que el año 2005 me ha traido más alegrias que penas y firmaría ahora mismo porque el 2006 lo mantenga. Como buen ciudadano de país católico (ateo gracias a dios), me he tomado unas vacaciones bien merecidas, lo que no me esperaba era la sorpresa que me iba a encontrar en Hannover. Mi novia había invitado a mis grandes amigos que también participan en mob y había preparado todo para ir al concierto de Method Man y Redman en una ciudad a 50km (ni siquiera sé ahora como se llamaba la ciudad pero ¡tengo testigos y fotos!).
Como os podeis imaginar ha sido un fin de año inolvidable... Pero también he pasado frio como nadie, y las largas horas de aeropuerto me han ayudado a terminar el libro que tenía entre manos "Spring in Action". Llevaba tiempo comentar cosas sobre spring, la mayoria muy buenas y tenía ganas de aprender a desarrollar con esta nueva tecnología.
La tecnología de Spring se basa en dos ideas: Inversion of Control y Aspect Oriented Programming. Ambas ideas se plasmas en código fuente y un documento xml de configuración de la aplicación. La idea de spring es que todo objeto que es cliente de otro objeto deberá ser inyectado este último objeto por el contenedor (en spring se usa la clase BeanFactory o ApplicationContext). Puedes inyectar el objeto en el constructor o a través de un método setter (la diferencia es importante). De esta manera se facilita enormemente el desarrollo TDD (Test Driven Development) al facilitar al extremo el uso de stubs o mock objects.
Por otro lado, Spring hace uso del Aspect Oriented Programming con una implementación propia de la misma que también es configurada en el archivo del contenedor.
Estas dos ideas básicas mueven el esqueleto de Spring, pero este ha ido creciendo hasta tener un MVC Web propio, ayudas para el acceso a objetos remotos, servicios de mensajería, bases de datos, integración con otros frameworks, etc...
Spring se está considerando como una alternativa a los EJBs en los desarrollos J2EE y creo que será una tecnología a tener en cuenta los próximos años.
La comunidad MOB ya ha aceptado el uso de Spring en la capa de negocio de los proyectos que hay en marcha. Así que ya os iré contando qué resultados nos vamos encontrando.

miércoles, octubre 12, 2005

Hibernate, comienza el frio

¿Quién no ha hecho una aplicación en su vida que se conecte a una base de datos? Incluso quizás sea mejor pregunta: ¿Quién ha hecho una aplicación que no se conecta a una base de datos? Quizás a esta respuesta contestasen menos personas y nos ahorraríamos tiempo de contar manos en alza. Lo cierto es que para un programador, las bases de datos son fundamentales.
Casi desde el principio, en el mundo javero, se ha tenido en cuenta dicho hecho, y ya desde principios se diseñó JDBC para poder facilitar a los programadores el acceso a bases de datos. JDBC es una API que sirve para conectar a base de datos de manera independiente del tipo de base de datos uses.
Esto es extremadamente útil porque con un poco de elegancia en el diseño de la aplicación, puedes conseguir una aplicación que sea completamente independiente de la base de datos.
Hoy en día las bases de datos en su mayoría son bases de datos relacionales. Existen bases de datos orientadas a objetos pero en la práctica, las más usadas son las relacionales. Y lo cierto es que parece ser que esto va a seguir siendo así bastante tiempo (por lo menos no hay muestras de alguna tendencia que incite a pensar lo contrario).
Las bases de datos relacionales, tal y como indica su nombre, se basan en relaciones entre entidades. Concepto que dista mucho de lo que es la oop (abstracción, encapsulación, polimorfismo y herencia). El hecho de que exista dicha diferencia puede complicar la manera de conseguir que la aplicación persista correctamente los objetos de negocio en la base de datos.
Debido a esto se han creado frameworks de persistencia de objetos. Sirven para persistir los objetos de una forma transparente al programador.
¿Como funciona Hibernate? La verdad es que es bastante sencillo, como concepto, después las cosas se pueden complicar bastante si no se tiene un buen diseño de la base de datos. Si se quiere usar Hibernate se han de crear los objetos de negocio y sus relaciones. Después se deberá crear una serie de archivos xml que indican a hibernate qué objeto se guarda en qué tabla, indicando la relación entre propiedades del objeto y columnas de la tabla. Por ejemplo, yo tengo una clase Persona tal y como sigue:


package org.edvera.hibernateexample;

public class Persona {

private String nombre;
private String apellido;

public String getNombre()
{
return nombre;
}

public void setNombre(String nombre)
{
this.nombre = nombre;
}

public String getApellido()
{
return apellido;
}

public void setApellido(String apellido)
{
this.apellido = apellido;
}
}

Esta clase quiero que guarde sus datos en la tabla PERSONAS, que viene definida:

CREATE TABLE PERSONAS (
id int primary key auto_increment,
nombre varchar(32) not null,
apellido varchar(32) not null
);

Si quiero que hibernate me haga la persistencia (guardar) del objeto tendré que indicarle la relación entre el objeto y la tabla. Esto se hace mediante un archivo xml que llamaremos Persona.hbm.xml, como el que sigue:

<hibernate-mapping>
<class name="org.edvera.hibernateexample.Persona" table="PERSONAS">
<id name="id" column="id" type="int">
<generator class="native">
</generator>
</id>
<property name="nombre" type="java.lang.String" column="nombre"/>
<property name="apellido" type="java.lang.String" column="apellido"/>
</class>
</hibernate-mapping>


De esta forma ya tenemos mapeado el objeto con la base de datos. Nos queda crear otro archivo para configurar la conexión que ha de usar hibernate (hay varias maneras de hacerlo, yo voy a usar la más sencilla para mayor claridad). Este archivo se llama hibernate.cfg.xml y es el siguiente:


<hibernate-configuration>
<session-factory>
<property name="connection.driver_class">com.mysql.jdbc.Driver</property>
<property name="connection.url">jdbc:mysql://localhost/bbdd</property>
<property name="connection.username">bbdd_user</property>
<property name="connection.password">bbdd_passwd</property>
<property name="connection.dialect">net.sf.hibernate.dialect.MySQLDialect</property>
<property name="show_sql">true</property>

<!-- mapping files -->
<!-- ficheros relacionados con los productos -->
<mapping resource="org/edvera/hibernateexample/Persona.hbm.xml"/>
</session-factory>
</hibernate-configuration>


En este archivo se dan los datos para poder hacer la conexión (aquellos que son los elementos property de la session factory) así como los archivos de mapeos (nosotros solo tenemos uno que es el de Persona.hbm.xml).
Ahora que tenemos hibernate configurado y listo para servirnos, veamos como usarlo en el código. Vamos a hacer una clase con un método principal que usa hibernate para guardar en la base de datos una persona ejemplo.


package org.edvera.hibernateexample;

import net.sf.hibernate.*;
import net.sf.hibernate.cfg.*;


public class HibernateExample {

public static void main (String args[])
{
Configuration configuration = new Configuration(); //Objeto que guardará la configuración de hibernate
try
{
//Leemos el archivo de configuración de hibernate (que deberá estar en el classpath
configuration.configure();
//Creamos la factoria de sesiones
SessionFactory sessionFactory = configuration.buildSessionFactory();
//Obtenemos una sesion
Session session = sessionFactory.openSession();
//Creamos la persona y la dotamos de información
Persona persona = new Persona();
persona.setNombre("Perico");
persona.setApellido("ElDeLosPalotes");
//Usamos la sesion de hibernate para persistir el objeto Persona
session.save(persona);
//Nos aseguramos de que se guardan los datos de la sesión en la base de datos
session.flush();
//Cerramos la sesión
session.close();
}
catch (Exception e)
{
//Excepcion no esperada.
}
}
}


Como se puede ver, a pesar de la simpleza y poca utilidad del código, el resultado es un código más limpio, sin necesidad de usar sentencias sql en cosas tan triviales.
De todas maneras las cosas no son tan sencillas con hibernate como parecen. Hay que tener en cuenta de que hibernate guarda los datos del objeto en la sesión, y que hasta que no se hace un flush no se persisten realmente los datos. El hecho de que la sesión se interponga entre los datos y la base de datos obliga a tener mucho cuidado en como se gestionan las sesiones. Puesto que una sesión debe pertenecer a un único Thread y un único Thread no debería de tener más de una sesión porque en caso contrario no se puede asegurar la integridad de los datos (dos threads usando la misma sesión podrían estar poniendo en peligro los datos).
Espero que este artículo sirva como primer acercamiento a esta tecnología y que el lector, después de haberlo leido, tenga una noción de lo que son los famosos frameworks de persistencia así como una idea general de para qué sirve hibernate. Por supuesto no he hablado ni del 10% de lo que puede hacer Hibernate, pero no pretendo quitarle trabajo a los chicos de JBoss (XD).