Más sobre transacciones

Telegráficamente, sólo apuntar estos dos enlaces de sendos blogs de Arnon Rotem-Gal-Oz:

• En Dr. Dobb's Journal un artículo titulado Some More Thoughts on Cross-Service Transactions


• En su blog personal, un artículo titulado Cross-Service Transactions

Perdón por lo telegráfico. En cuanto tenga algo más de tiempo abundaré sobre este asunto porque es muy importante para el diseño final de una arquitectura basada en servicios,

WS-Transactions ya es estándar OASIS

Como explica Eric Newcomer en su blog, la conocidad organización de estándares OASIS ha adoptado WS-Transactions.



Pero, aunque es evidente que las transacciones son una necesidad para implementar SOA, me gustaría apuntar algo del artículo de Martin Fowler "Transactionless (Sin Transacciones)", donde explica que eBay tiene un modelo de datos repartido en numerosas bases de datos físicamente separadas, lo que dificulta el uso de transacciones.



También Newcomer trata un poco este tema en el artículo antes citado y matiza el concepto de transacción y su utilidad en SOA.



Hay mucha tela que cortar sobre este tema aún...

Primera experiencia con Mock Objects

Estoy emocionado porque acabo de terminar mi primer test unitario usando mock objects. He comprobado un validador JSF que ha hecho un compañero sin necesidad de ejecutarlo dentro del contenedor web y sin tener que codificar un costoso contexto (que podría, además, incorporar defectos ajenos al sujeto de la prueba -el validador-).



He probado jMock e EasyMock y me he quedado con EasyMock. Os enseño los dos ejemplos:



Con jMock:

import org.jmock.Expectations;

import org.jmock.Mockery;

import org.jmock.integration.junit4.JMock;

import org.jmock.integration.junit4.JUnit4Mockery;

import org.junit.Test;

import org.junit.runner.RunWith;



@RunWith(JMock.class)

public class PublisherTest {



	Mockery context = new JUnit4Mockery();



	/**

	 * A Publisher sends a message to a single registered Subscriber.

	 * 

	 */

	@Test

	public void oneSubscriberReceivesAMessage() {



		/*

		 * We first set up the context in which our test will execute. We create

		 * a Publisher to test. We create a mock Subscriber that should receive

		 * the message. We then register the Subscriber with the Publisher.

		 * Finally we create a message object to publish.

		 */



		// set up

		final Subscriber subscriber = context.mock(Subscriber.class);



		Publisher publisher = new Publisher();

		publisher.add(subscriber);



		final String message = "message";



		/*

		 * Next we define expectations on the mock Subscriber that specify the

		 * methods that we expect to be called upon it during the test run. We

		 * expect the receive method to be called once with a single argument,

		 * the message that will be sent.

		 */



		// expectations

		context.checking(new Expectations() {

			{

				one(subscriber).receive(message);

			}

		});



		/*

		 * We then execute the code that we want to test.

		 */

		

		// execute

		publisher.publish(message);

		

		/*

		 * After the code under test has finished our test must verify that the

		 * mock Subscriber was called as expected. If the expected calls were

		 * not made, the test will fail. The MockObjectTestCase does this

		 * automatically. You don't have to explicitly verify the mock objects

		 * in your tests. The JMock test runner does this automatically. You

		 * don't have to explicitly verify the mock objects in your tests.

		 */

		// mockery.assertIsSatisfied();



	}

}

Con EasyMock:

import org.easymock.EasyMock;

import org.junit.Test;



public class PublisherTest {



	private Publisher publisher;

	private Subscriber subscriber;

	

	/**

	 * A Publisher sends a message to a single registered Subscriber.

	 * 

	 */

	@Test

	public void oneSubscriberReceivesAMessage() {



		// create the collaborators as mocks

		subscriber = EasyMock.createMock(Subscriber.class); 

		

		// setup

		publisher = new Publisher();

		publisher.add(subscriber);

		final String message = "message";



		// expectations

		subscriber.receive(message);

		EasyMock.expectLastCall().times(2);

		

		// end setup

		EasyMock.replay(subscriber);

		



		// execution

		publisher.publish(message);

		publisher.publish(message);

		

		// assertion

		EasyMock.verify(subscriber);

	}



}

Como se puede comprobar, el código del test con EasyMock es más intuitivo. Sólo una salvedad: si queréis hacer "mocks" de clases abstractas necesitaréis también "EasyMock Class Extension" y CGLIB (yo me he descargado cglib-nodep-2.1_3.jar para evitar problemas de dependencias).





Las ventajas de hacer tests con "mocks" son:

• evitamos costosas "fixtures" (objetos creados ad-hoc como contexto de la prueba) que, además, pueden introducir/ocultar defectos
  
  
• podemos probar el comportamiento de nuestro sujeto (no sólo el estado final)

Esto último es especialmente necesario en el caso de componentes a los que no podamos decirle assertEquals de nada y que debamos comprobar que interactúa con sus colaboradores como se haya definido.

Mocks

Tengo que probar un validador JSF y quería hacer el test unitario, pero me he encontrado con que no tengo un par de objetos que proporciona el contenedor y la implementación de JSF, con lo que me he decidido a ver eso de los Mock Objects. Mi compañero José Ramón me ha pasado este enlace titulado "Mocks Aren't Stubs" (de Martin Fowler, quién si no).



Me voy a descargar EasyMock y os mantendré informados de mis avances.

Más sobre Java CAPS

A propósito del comentario de Enrique .



¿Sería una "elección adecuada" el hacernos nosotros nuestra propia "suite" de productos? ¿Cuáles recomendaríais?



Podíamos ir haciendo una lista. Ahí van mis dos céntimos:

• ESB : OpenESB
• BPM : JBPM
• UDDI : ??
• Seguridad (control de acceso, autorización, manejo de políticas, propagación entre WebServices) : ??
• Acceso a un modelo de datos corporativo : ??
• ¿qué más?
  
  

Entiendo que para las aplicaciones (me refiero a las GUIs fundamentalmente) cada uno usaría lo que quisiera, pero siempre teniendo en cuenta que debemos hablar con nuestros WebServices a través del middleware (ESB) y que, para ello, tendremos que desarrollar un framework ¿Java? ¿.NET? o usar uno ya hecho ¿cuál?



Prometo hacer un resumen con las respuestas. :-)

Maquillaje

Simplemente hacer notar el cambio de estilo en el blog.



Por cierto, el guiño a la serie de TV "House M.D." es simplemente porque me gusta y porque está a punto de acabar la 3ª temporada (el 29 de mayo en USA). ¿Quién no desearía ser Greg House por un momento y decir a alguien "La arrogancia hay que ganársela, ¿qué has hecho tú para ganar la tuya?". Je, je...

Java CAPS

Hoy nos han hecho los de Sun España una presentación técnica de su producto para SOA llamado Java CAPS, antes conocido como SeeBeyond.

Se trata de una suite de productos que, todos juntos, te permiten implantar SOA en tu empresa. Está fuertemente basado en la existencia de un repositorio central donde se guardan las definiciones de todos los objetos: desde un proceso BPEL hasta una fuente de datos relacional (usando un conector JDBC proporcionado por CAPS). Para todo esto proporciona un motor más un ESB sobre el que se basa todo y un IDE con el que manejar la complejidad. En cualquier caso, no resuelve ni el desarrollo de las aplicaciones (web o swing) ni el paso del modelo a la implementación. Tampoco tienen resuelta asuntos más íntimamente relacionados con la calidad del desarrollo: pruebas unitarias de los WebServices ni de los procesos (y por supuesto nada de code coverage). Y finalmente, tampoco da una solución para acceder a un modelo de datos corporativo (como el AquaLogic) ni nos han hablado tampoco de SCA (Service Component Architecture).

Pero después de todo tengo una sensación un tanto ambigüa: por un lado me parece una buena solución para implantar SOA tomando como base un ESB, un IDE y el resto del motor BPM+workflow, pero por otro lado tengo la extraña sensación de que eso mismo me lo puedo hacer si localizo la colección adecuada de productos "open source" y de plug-ins Eclipse. Además, no sé si es mejor que el AquaLogic de BEA o la suite equivalente de WebSphere (IBM).

Lo cierto es que suelo tener una patente aversión a todo lo que sale de las factorías de Sun: reconozco que es un prejuicio (aunque no carente de un fondo de racionalidad). Actualmente estoy sufriendo en primera persona la combinación maléfica Glassfish + NetBeans y tengo siempre una vocecilla detrás de mi oreja que me dice: "WebSphere + Eclipseeee...". Vale, reconozco también que me tira bastante IBM, qué le voy a hacer... pero mi experiencia hasta el momento me confirma el prejuicio... Simplemente unas notas:

• Comparad la gestión de defectos y el proceso de integración de Eclipse y el de NetBeans o Glassfish.
• La información disponible sobre el resultado de un build de Eclipse te dice incluso cómo han ido los tests.
• La gestión de los bugs de Eclipse es más robusta.
• Han conseguido una comunidad muy activa.
• Eclipse es un producto mucho más productivo que NetBeans:
• Es más fácil refactorizar
• Es más fácil probar tu código
• Es más fácil compartir proyectos
• Es más fácil mantener el control de tu configuración (infinitamente más)

pero claro, para gustos hay colores... :-)

Pero dejando aparte mis prejuicios, me gustaría saber si alguien está teniendo experiencia real con Java CAPS: no me agradaría nada encontrarme "pillado" haciendo las cosas "a la Sun" simplemente porque nos hemos comprometido con este producto.

Y si no estáis usando Java CAPS, ¿qué estáis usando para implantar vuestra SOA? Si hay muchos votos, haré un resumen. :-)

JavaOne 2007

Ya no hace falta viajar hasta San Francisco para asistir a la JavaOne. :-)



http://sunfeedroom.sun.com



Un ejemplo en concreto con James Gosling (ojo a la camiseta).

Powered by ScribeFire.

Mashups

Estaba leyendo un artículo en el blog de Enrique y me ha gustado la definición de "mashup" que recoge la Wikipedia.



El otro día alguien (que no tiene blog) me habló de Zimbra y luego estuve echando un vistazo. Incluso me he descargado el código fuente para (si tengo tiempo) echar un vistazo. Desde luego, las demos que tienen son es-pec-ta-cu-la-res. Claro, mi amigo Stephane (que tampoco tiene blog) me dirá que en una aplicación swing (que puedes ejecutar desde web con Java Web Start) eso no es nada nuevo... vale, pero la idea de la composición de aplicaciones es lo que realmente me parece interesante, no tanto si es web o cliente pesado.



Además, he visto otra presentación de un producto de IBM para desarrollar "mash-ups" (QEDWiki) que también tiene buena pinta. Me recuerda, de alguna manera, al antiguo Quickplace (no sé cómo se llamará ahora o si se sigue llamando igual).



Aunque, desde luego, Zimbra me ha dejado especialmente sorprendido. Un último apunte: el ejemplo de cómo usar un zimlet para "empastar" (¿es esa una traducción aceptable para "mashup"?) sesiones de webex en nuestras aplicaciones.





P.S.

Sí, Enrique, sí, también es un ejemplo de mashup esos enlaces tan chulos de snap.com que hay en tu blog. :-)

Automation for the people

Acabo de ver uno de los mejores resumenes prácticos sobre integración continua.

Es un artículo de developerWorks muy reciente (Mar-2007) y hace un repaso (con ejemplos de uso) de Junit, DbUnit, JUnitPerf, Selenium (incluso llamado desde ant), Cobertura y CruiseControl.

Es un resumen suficiente como para indicar el camino.

Yo me alegro porque nosotros estamos en el camino (salvo que no usamos DbUnit porque hacemos la persistencia con JPA ni JUnitPerf porque usamos JMeter). No está mal: 4 de 6. :-)

Pruebas unitarias

He leido ayer un artículo (muy corto pero muy esclarecedor) sobre pruebas unitarias.
Os lo recomiendo a todo el mundo porque explica qué estrategia debemos seguir para hacer pruebas unitarias dependiendo del estado de nuestro proyecto.

Powered by ScribeFire.

Axis2 o Glassfish

En relación a lo que yo escribía en el artículo anterior y un correo que le envié, Enrique Álvarez me comenta:

Sobre Glassfish la verdad no conozco mucho ya que no he trabajado con él.

Respecto a Axis2 creo que soporta JAX-WS 2.0 (no estoy del todo seguro, no se si ya lo soporta actualmente o está en el roadmap). Yo en mi caso y por las necesidades particulares que he tenido no he mirado mucho acerca de si cumple la JSR ya que no lo he necesitado.

En cualquier caso, JAX-WS 2.0 es un compendio de estándares (SOAP 1.2, WSDL 2.0, etc...) e imagino que lo cumplirá... por si te sirve de referencia la gente de XFire hicieron una comparativa de las pilas SOAP en su momento (posiblemente sea algo antigua...):



http://xfire.codehaus.org/Stack+Comparison



De todas formas, si apostais sobre Glassfish posiblemente tengais la ventaja de que tras la liberación del código de SUN, la comunidad Open Source le dará bastante empujón y siempre cumplirá más a rajatabla las especificaciones nuevas...

Gracias, Enrique, justamente confirmas nuestra decisión: hemos apostado por Glassfish justamente con la "esperanza razonable" de que la comunidad Open Source adopte, evolucione y guíe el estándar. Nos cuesta mucho trabajo vernos ligados a un producto (salvo que éste sea realmente bueno).



Por cierto, ¿alguien tiene alguna experiencia con JCAPS aka SeeBeyond? Estamos valorando si incorporarlo a nuestro entorno de desarrollo y nos ayudaría mucho que alguien compartiera sus experiencias con nosotros.

Powered by ScribeFire.

Axis2 y JAX-WS

En mi empresa (Degesys) estamos desarrollando con JAX-WS 2.0 y Glassfish (v1 de momento). La verdad es que desde el primer momento habíamos descartado Axis porque no era JAX-WS 2.0.

He encontrado el siguiente enlace sobre Axis2 + JAX-WS pero llevan cerca de un año sin decir nada al respecto. Acaban de sacar la versión 1.2 de Axis2/Java, pero no veo nada sobre compatibilidad con JAX-WS. ¿Alguien tiene idea de los planes de Axis2 al respecto?

Y una pregunta un poco más de fondo... ¿es tan importante ser compatible con JAX-WS? ¿En qué consiste exactamente ser compatible JAX-WS? ¿Tiene que ver con los descriptores de despliegue, con las anotaciones, con ambas o con ninguna?

En cualquier caso, cuando veo la lista de características y leo:

• WSDL 2.0


• POJO annotation (JSR 181)


• JAX-WS intregration

¿No es eso la definición de compatible JAX-WS 2.0?

:-s No entiendo nada...

TheServerSide Java Symposium en Barcelona

He visto que entre el 27 y el 29 de Junio se celebrará en Barcelona el TheServerSide Java Symposium en Barcelona.



En la lista de sesiones BOF me han llamado la atención los siguientes títulos:

• How to Write Stateful Web Applications That Scale Like Stateless Ones



• ESB How To: From Software Selection to Mission-Critical Application Deployment



• y, por supuesto, en la que participa Rod Johnson sobre Spring, que además también expondrá "Spring 2.0 and Beyond" (ver la lista de sesiones)
  
  

y en la lista de sesiones "normales" relacionadas con SOA me han llamado especialmente la atención:

• SCA/Fabric3: Not the Same Old Architecture



• Programming without a Call Stack - Event-driven Architectures



• jPDL: Simplified Workflow for Java

Pero si sigo con otros temas... también me interesaría mucho oír lo que Erik Doernenburg va a contar sobre TDD (Test-Driven Development). En DEGESYS estamos apostando por métodos y técnicas ágiles, tanto de modelado como de desarrollo, y cuyo objetivo sea proporcionar un entorno orientado a la calidad real.

NetBeans 6.0 Preview

Los que me conocen bien saben que no me gusta nada NetBeans, especialmente si lo comparamos con Eclipse para el desarrollo de Java. Pero, para mi desgracia (quizás es una penitencia debida a algún pecado en una vida anterior), debo usar NetBeans 5.5 en mi trabajo. Por eso mismo, cada vez que arranca NetBeans me da la bienvenida con su canal de noticias. Y hoy he visto que anunciaban la "Preview Milestone 9" de la versión 6.0 en http://www.netbeans.org/servlets/NewsItemView?newsItemID=1043

Para los que tengan tiempo y/o curiosidad, hay un tutorial interesante sobre cómo plantean los de Sun que debemos hacer aplicaciones de escritorio con acceso a base de datos (http://www.netbeans.org/kb/60/ide-gui-db-prev.html) y con NetBeans 6.0 Preview, claro. :-)

Análisis de código

He estado "jugando" con Checkstyle. Desgraciadamente, no he tenido tiempo de ver cómo se lanza con maven y lo he hecho con ant. Sé que también hay un plug-in para diferentes IDE, pero yo lo quiero para ponerlo en un proceso de integración continua y apoyar a la formación de juniors en mi empresa.

Mi impresión final del producto es un tanto agridulce... me ha costado un poco obtener un informe suficientemente bueno (las xsl que vienen "de serie" son francamente mejorables), pero reconozco que es un producto bien trabajado, extensible, configurable y con una buena documentación de referencia. Quizás estaría bien un pequeño manual (la ayuda en la web está bien, pero es un manual de referencia y yo pienso en un manual de usuario).

Mi próximo objetivo es PMD. Ya he hecho una prueba preliminar, usando la xsl que viene con CruiseControl, pero no he visto cuáles son las reglas que implementa y cómo se modifican éstas.

Muy pronto más...