Se hace camino al andar…

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,

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…

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.

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.

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.

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…

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.

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.

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