Alexander Smirnov’s personal Weblog

May 20, 2011

R3 Web Application Pattern

Filed under: Java — alexsmirnov @ 3:46 pm


The most popular pattern for web application development is Mode View Controller. In this pattern, controller processes Request, updates the Model and call View to generate representation. The pattern is pretty simple and powerful, while it has some disadvantages. Take a look for diagram from Wikipedia article:

The solid lines show direct associations, and dashed ones are optional indirect. All three parts of the application are tight coupled: Controller should know Model structure to update values, View depends from the model structure, and once again Controller depends from view; at least for names of input parameters. That’s pure procedural architecture with dumb model. Controller cannot be reused for different models or views, even different request methods require different procedures in the Controller. So, the goal of proposed pattern is to reduce dependencies between parts of application, and use the power of Object Oriented programming languages.

W3C Architecture

From the “Architecture of the World Wide Web”, each  URI identifies one resource. Resource itself associated with some object. When agent request URI for some resource, it gets back Resource representation. A representation is data that encodes information about resource state. As you can see, it doesn’t complete match MVC pattern.

Resolver, Resource, Representation

The proposed Resolver, Resource, Representation pattern ( R3 ) follows W3C architecture and better fit Object Oriented Architecture.

  • Resolver processes URI from client request and returns Resource instance associated with request URI ; this is called dereferencing the URI.
  • Resource is the programming Object instance, that represent some concept. It contains data fields and methods. Requests that modify resource change its attributes or call methods on Resource Object . Resource can have relations to others. These relations represented as links to URI’s associated with these resources.
  • Each resource has one or more Representations, that converts Resource object into web data.
  • Additional parts of application include mapping between request data and Resource methods / attributes and Representation controller that decides how to show resource for client.

In this architecture Controller becomes URI Resolver decoupled from the both Model and View internals, dumb Model evolves into rich Resource Object with data and methods. In comparison with MVC, only one tight coupling between Resource and View remains.
It’s also fit full REST architecture recommendations. Instances of application Model objects becomes Web URI’s, relationships between them can be represented as links, and object methods mapped to the request methods and data, and Representations can be selected from content negotiation.
Programming Application flow also can be pretty easy: Resource method can return the next object, that becomes a new application state either for the current request or as redirect to URI associated with new state.

May 18, 2011

Neo4j Java EE connector

Filed under: Uncategorized — alexsmirnov @ 12:28 pm

Recently, I needed to add ‘graph relations’ to the data objects in the some JEE application. That application uses JPA and MySQL to store data objects, and first attempt was done by adding “many-to-many” relationships that points back to entity itself, but such schema doesnt work well in SQL. Therefore, we decided to keep graph-like relationships in the Neo4j database.

The next question was: how to add Neo4j to our application and how to coordinate transactions between JPA and Neo4j ? Because we run inside Glassfish 3.1 container, we put graph database outside of application and created Java EE connector neo4j-connector that deployed to server as resource adaptor and manages Neo4j database. Application get instance of GraphDatabaseService from JNDI and doesn’t have to care about database startup/shutdown, configuration, and transactions.

Connector features:

  • Standard JCA 1.6 connector, that can be installed on any Java EE 6 compatible server. For the oldest servers, It’s pretty easy to convert connector to JCA 1.5 API.
  • ResourceAdapter starts Neoj4 database at first request and shutdown it with server.
  • Supports both LocalTransaction and XA transaction. XA support may be not quite correct – instead of using proper XAResource from adapter, it provides access to platform TransactionManager for Neo4j server. Diving into Neo4j internals, I’ve found that it creates couple of XAResource objects and enlists them in the Transaction, while ResourceAdaptor lets to create only one XAResource. Finally, I creater Provider for JEE Server TransactionManager, similar to the Spring Data project.


  1. Check out source code from the Github neo4j-connector project and build it with Maven. Project uses some artifacts from the Jboss Maven repository, so you have to configure it before build.
  2. Deploy connector to your application server. For Glassfish 3, there is shell script that deploys resource adapter and configures connector. All what you need is having asadmin application in the path or GLASSFISH_HOME environment variable. The connector supports two configuration options: dir for the Neo4j database location and boolean “xa” property that switches adapter from Local to XA transactions.
  3. Add neo4j-connector-api library to comple your application. JCA classes loaded in the parent Classloader on the server, you don’t need neo4j classes at runtime. For maven, just add dependency to ejb or war project:

There you go – Neo4j GraphDatabaseService now available as JNDI resource!

 Neo4JConnectionFactory neo4jConnectionFactory;

 GraphDatabaseService createDatabaseService() throws ResourceException{
 return neo4jConnectionFactory.getConnection();

In the EJB services, you don’t have to start/stop transactions by hand, it will be done by container if you set apporpriate @TransactionAttribute for EJB/business method.
In the XA mode, you can use JPA/SQL and Neo4j together, and container will take care for data consistency ( of course, database connection also have to use XADataSource ).

Future plans

  1. Add database configuration parameters to adapter.
  2. Support Neo4j High Availability cluster in the adaptor. I plan to start and configure all necessary services directly in the adapter, using Application Server cluster service where possible. Therefore, JEE application can be scaled without any changes in the code, as it supposed for JEE.
  3. Provide JPA style Object to Graph mapping, most likely as the CDI extension.

Create a free website or blog at