Smooks Data Integration » Java Binding

Introduction: Using a factory to instantiate beans with the javabean cartridge

Maurice — Mon, 12 Oct 2009 08:01:59 +0000

I would like to introduce the new factory feature in the Javabean cartridge of the up coming Smooks 1.3 release. This new features makes it possible to use a static factory method or a factory object to instantiate objects with the Javabean cartridge.

Before this new feature you could only instantiate new beans by providing the class name of the bean and the bean would then be created using it’s public parameterless constructor. So it was mandatory to have a parameterless constructor on the Javabean. Here is an example:

But now it is possible to use a factory to instantiate the bean. So you don’t need a public parameterless constructur anymore. You even don’t have to define the actual class name any more. Any of the interfaces that the class implements suffices. However only the methods of that interface are available for binding then. Here is an example where we instantiate an ArrayList object using a static factory method:

With the factory attribute you set the factory definition. The class attributes defines that a List object is returned. What kind of List object (ArrayList, LinkedList) is up to the ListFactory to decide. Here is another example:

Here we define that an instance of the ListFactory needs to be retrieved using the static method getInstance() and that then the newList() method needs to be called on the ListFactory object to create the List object. This construct makes it possible to easily call Singleton Factories.

The default factory definition language looks like this: factory.class#static_method{.instance_method}

It is also possible to use MVEL as the factory definition language. MVEL has some advantages over the basic default definition language, for example you can use objects from the bean context as the factory object or you can call factory methods with parameters. These parameters can be defined within the definition or they can be objects from the bean context. To be able to use MVEL you must set the ‘factory.definition.parser.class’ global parameter to ‘org.milyn.javabean.factory.MVELFactoryDefinitionParser’.

Here is an example using MVEL:



	
		
			org.milyn.javabean.factory.MVELFactoryDefinitionParser

Maybe you wonder why we don’t use MVEL as the default factory definition language? Currently the performance of the basic definition language and MVEL is about equal. The reason that the basic definition language isn’t faster is because it currently uses reflection to call the factory methods. However there are plans to use byte code generation instead of reflection. This should improve the performance dramatically. If MVEL where the default language then we couldn’t do anything to improve the performance for those people who don’t need any thing more then the basic features that the basic definition language offers.

If you have any questions or remarks then I would gladly hear them.

posted in Java Binding by Maurice Leave A Comment

Smooks Persistence part 2: How to use Hibernate/JPA

Maurice — Wed, 25 Mar 2009 11:20:09 +0000

With the new Smooks Persistence cartridge in Smooks 1.2 you can directly use several entity persistence frameworks from within Smooks. In this post I will show you how this works with Hibernate and any other JPA compatible framework.

This post is part of a multi post article. You can find the previous post here: Smooks Persistence part 1: The Introduction

In this post we will look at an example of how to persist Hibernate Entities. This example is based on the example of the previous post.

First, lets take a look at the data we are going to process. In this example we are processing XML data. It should be noted however, that the input data could also be CSV, JSON, EDI, Java or any other structured/hierarchical data format. The same principals apply, no matter what the data format is!

These are the Hibernate entities we are going to use:

@Entity
@Table(name="orders")
public class Order {

	@Id
	private Integer ordernumber;

	@Basic
	private String customerId;

	@OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
	private List orderItems = new ArrayList();

	public void addOrderLine(OrderLine orderLine) {
		orderItems.add(orderLine);
	}

       // Getters and Setters....
}

@Entity
@Table(name="orderlines")
public class OrderLine {

	@Id
	@GeneratedValue(strategy=GenerationType.IDENTITY)
	private Integer id;

	@ManyToOne
	@JoinColumn(name="orderid")
	private Order order;

	@Basic
	private Integer quantity;

	@ManyToOne
	@JoinColumn(name="productid")
	private Product product;

       // Getters and Setters....
}

@Entity
@Table(name = "products")
@NamedQuery(name="product.byId", query="from Product p where p.id = :id")
public class Product {

	@Id
	private Integer id;

	@Basic
	private String name;

       // Getters and Setters....
}

The Smooks configuration looks like this:




	
	

		
		
		
	

	
	

		
		
		
	

	
	

		from Product p where p.id = :id

If we want to use the named query ‘productById’ instead of the query string then the DAO locator configuration will look like this:

The following code executes Smooks. Note that we use a SessionRegister object so that we can access the Hibernate Session from within Smooks.

        // Note: In a real world application you should cache the Smooks instance
        // else you will have enormous performance penalties.
        Smooks smooks = new Smooks("smooks-config.xml");

        ExecutionContext executionContext = smooks.createExecutionContext();

        // The SessionRegister provides the bridge between Hibernate and the
        // Persistence Cartridge. We provide it with the Hibernate session.
        // The Hibernate Session is set as default Session.
        DaoRegister register = new SessionRegister(session);

        // This sets the DAO Register in the executionContext for Smooks
        // to access it.
        PersistenceUtil.setDAORegister(executionContext, register);

        Transaction transaction = session.beginTransaction();

        Source source = new StreamSource(new File("order.xml"));        

        smooks.filter(source, null, executionContext);

        transaction.commit();

If you want to take a JPA version of this example for a spin, simply check out the examples from subversion (http://svn.codehaus.org/milyn/trunk/smooks-examples/) and you’ll find it in the “dao-router” folder. It also shows you how to use custom DOA’s with the Persistence Cartridge.

With Scribe and the Persistence Cartridge it is very easy to use Hibernate, JPA and most other persistence frameworks within Smooks. Later on in this series I will explain how too write your own DAO Adapters, so that you can add support for other persistence frameworks.

In the next post of the series I will explain how you can use Ibatis with the Persistence Cartridge.

posted in Java Binding by Maurice Leave A Comment

Smooks Persistence part 1: The Introduction

Maurice — Thu, 26 Feb 2009 11:31:44 +0000

One of the major new features in Smooks v1.2 will be the new Persistence Cartridge. This cartridge enables the use of several entity persistence frameworks from within Smooks, currently targeting Hibernate, Ibatis and any JPA compatible framework. It also allows you to use your own Data Access Objects (DAOs).

This cartridge is great for those cases where you already have your data access layer and want to use its power from within Smooks. It also allows you to reuse these persistence resources on any format of data, not just XML e.g. EDI, CSV, JSON etc.

This is the first post of a series of posts about the persistence cartridge. This post is an introduction of the cartridge. I will give an overview of what the cartridge can do and also show an example where I use custom DAO’s to persist the data of an XML document. In the next posts in this series, I will show examples of how Hibernate, JPA and Ibatis entities can be used.

The Persistence cartridge is build around a data access layer abstraction library called “Scribe”. Scribe is a new Milyn subproject, born out of the needs of the Persistence cartridge. It enables the Persistence cartridge to use your DAOs without it actually needing to know the details of your DAOs. In fact, they don’t need to be DAOs at all. You can also use any entity persistence framework without the Persistence cartridge seeing the difference. Scribe supports abstracting the default actions you can expect from any DAO or persistence library like inserting, updating, deleting and querying for entities.

For Scribe to understand how to use your DAOs, it needs a mapping. Scribe offers two methods for doing this:

Java Annotations
Scribe has a set of Java Annotations like @Insert, @Update, @Delete and @Locate. These annotations enable you to map your DAOs to the DAO actions.
Java Interfaces
Scribe defines a set of Java interfaces like DAO, Locator and Queryable. You build your DAOs By combining and implementing these interfaces. These interfaces are primarily meant to be used for implementing adapters for persistence frameworks.

The Persistence Cartridge defines a set of Smooks Visitor components that use the DAO actions defined by Scribe. For example, the Inserter visitor can insert your entities by calling the method defined by the DAO action mapping. We see an example of this later.

The cartridge has the following Smooks Visitor components:

Inserter
Inserts/Persists entities
Updater
Updates/Merges entities
Deleter
Deletes entities
Locator
Locates entities with a query or with your own lookup method.

Now that you have an idea of what the Persistence cartridge can do, let’s take a look at a DAO based example. We will see Hibernate, IBatis and JPA examples in the followup posts in this series.

The example will read an XML file containing order information (note that this works just the same for EDI, CSV etc). Using the javabean cartridge, it will bind the XML data into a set of entity beans. Using the id of the products within the order items (the element) it will locate the product entities and bind them to the order entity bean. Finally, the order bean will be persisted.

The order XML message looks like this:

The following custom DAO will be used to persist the Order entity:

@Dao
public class OrderDao {

   private final EntityManager em;

   public OrderDao(EntityManager em) {
     this.em = em;
   }

   @Insert
   public void insertOrder(Order order) {
     em.persist(order);
   }
}

When looking at this class you should notice the @Dao and @Insert annotations. The @Dao annotation declares that the OrderDao is a DAO object. The @Insert annotation declares that the insertOrder method should be used to insert Order entities.

The following custom DAO will be used to lookup the Product entities:

@Dao
public class ProductDao {

   private final EntityManager em;

   public ProductDao(EntityManager em) {
      this.em = em;
   }

   @Lookup(name="id")
   public Product findProductById(@Param("id") int id) {
      return em.find(Product.class, id);
   }
}

When looking at this class, you should notice the @Lookup and @Param annotation. The @Lookup annotation declares that the ProductDao#findByProductId method is used to lookup Product entities. The name parameter in the @Lookup annotation sets the lookup name reference for that method. When the name isn’t declared, the method name will be used. The optional @Param annotation let’s you name the parameters. This creates a better abstraction between Smooks and the DAO. If you don’t declare the @Param annotation the parameters are resolved by there position.

The Smooks configuration look likes this:

The following code executes Smooks:

Smooks smooks = new Smooks("./smooks-configs/smooks-dao-config.xml");
ExecutionContext executionContext = smooks.createExecutionContext();

// The register is used to map the DAO's to a DAO name. The DAO name isbe used in
// the configuration.
// The MapRegister is a simple Map like implementation of the DaoRegister.
DaoRegister register =
	MapRegister.builder()
		.put("product", new ProductDao(em))
		.put("order", new OrderDao(em))
		.build();

PersistenceUtil.setDAORegister(executionContext, mapRegister);

// Transaction management from within Smooks isn't supported yet,
// so we need to do it outside the filter execution
EntityTransaction tx = em.getTransaction();
tx.begin();

smooks.filter(new StreamSource(messageIn), null, executionContext);

tx.commit();

If you want to take this example for a spin, simply check out the examples from subversion (http://svn.codehaus.org/milyn/trunk/smooks-examples/) and you’ll find it in the “dao-router” folder. It also shows you how to use JPA directly, without any DAOs in between.

The cartridge is almost ready for it’s first release. There is one thing that I am still not completely sure about and it would be great if people could provide some feedback. I am not completely happy about the action names: insert, update and delete. In the world of persistence frameworks, different sets of names are used for these actions. JPA, for instance, uses persist, merge and remove. Hibernate (outside of JPA) uses save, update and delete and Ibatis uses insert, update and delete. Which names would you choose and why?

In the next post of the series I will explain how to use Hibernate directly.

posted in Java Binding by Maurice Leave A Comment

Java to XML, without a template??

Tom Fennelly — Wed, 28 Jan 2009 17:13:00 +0000

Some people use Smooks as a Java Binding framework for marshalling and unmarshalling XML, in a similar fashion to how JAXB can be used. An “issue” that has been raised by a number of people is the fact that, with Smooks, you need to define a template for serializing the populated Java Object model (to XML, or other format). Some people find this a bit of a drag. They expect Smooks to be able to do it automagically. JAXB etc support it, so why can’t Smooks?

So first off… why do I think this is not easy with Smooks? The main issue I see is that in order for Smooks to be able perform out-of-the-box unmarshalling and marshalling, without having to use a template to serialize back to XML (or whatever), it would really need to know the schema for the input/output message and how it maps to/from the associated Java object model.

As I see it, one of the advantages of Smooks from a pure Java Binding perspective is the ability to bind data from an input message without requiring knowledge of the full structure of the message being processed. Smooks is fragment based, so the binding configs can be targeted at message fragments and as long as the selector is specific enough to select the bind data, you’re OK.

So, without knowing the full message structure (schema) and how exactly that schema maps to/from the java object model, it’s not really possible (in a practical sense) to take the populated object model and serialize it back out to an XML structure that conforms to the same schema as the input message.

Possible solutions:

If all you’re doing is marshalling and unmarshalling a message for which you have the schema (i.e. you’re not transforming it), well then you could just use JAXB, XStream etc. Smooks might not be what you want!
One suggestion that has been made was to use the binding selectors to “infer” the message structure and from that, build a template that can be used to serialize. This might work in a few use cases, but it really is a hack and would be broken more often than not. Our hearts would also be broken answering questions on “why it doesn’t work” in lots of situations.
To Smooks, add support for serialization via some of these other binding frameworks (JAXB etc). We already have some JIRAs for this. I don’t think it would be a lot of work!

Personally, I prefer option #3 because it’s going to produce the most dependable result. So, taking an example where you need to transform an EDI message to XML, you could do the following:

Get/create the mapping model for the EDI message.
Get an XSD for the target XML and from it, generate a JAXB model.
Create the binding configs that bind the data from the EDI message into the JAXB model.
In the same binding config (#3 above), configure a new JAXBSerializer visitor to fire at the end of the message ($document visitAfter), outputting the result of the JAXB model Serialization as the result.

So in that example, you’re using Smooks to bind the data from the EDI data stream into the XML Structure (JAXB model), and then using JAXB to serialize it in conformance to the XML’s schema.

Alternatively, you could just do what I’d do and write a template to generate the required output. Seems like a more direct route to me

posted in Java Binding by Tom Fennelly Leave A Comment