Over the past few weeks I’ve been doing some R&D into the advantages of using NoSQL databases to implement Entity services (also known as Data Services).
Entity service is a classification of service coined in the Service Technology series of books from Thomas Erl. It’s used to describe services that are highly agnostic and reusable because they deal primarily with the persistence of information modelled as business data ‘entities’. The ultimate benefit of having thin layer of these entity services is in the ease at which you can re-use them to support more complex service compositions.
This approach is further described in the Entity Abstraction SOA pattern.
Entity service layers are therefore a popular architectural choice in SOA, and implementing them has meant big business for vendors like Oracle and IBM, both of whom offer software to support this very task. There is even a separate standard for technologies in this area called Service Data Objects (or SDO for short).
This is all well and good, but these applications come with dedicated servers and specialised IDE’s and its all a bit ‘heavyweight’. These specialised solutions can be terribly expensive if all you really want are some simple CRUD-F operations (Create, Read, Update, Delete, Find) on a service that manages the persistence of a simple canonical data type like a Product or a Customer.
I’m a big fan of CI (Continuous Integration) in the workplace but early on in my RESTful ‘Spike’ project I took the decision that I couldn’t be bothered creating a CI at home. From past experience I felt that the DIY-CI option takes up too much time and adds little value to a lone developer. What’s more, CI requires regular maintenance to remain effective.
However, as my project was coming to an end I remembered that my old colleagues at MikeCI.com have recently launched their hosted CI service that can automate Maven builds. Seeing as I was keen to avoid the hassle of CI, but appreciate the benefits it can bring – I thought I would give MikeCI a go.
Within minutes of using MikeCI, it became very apparent that it’s an astonishingly simple and very effective hosted service that can add a lot of value to any project, big or small.
Using Unfuddle as my SVN repository, within a few clicks I had MikeCI checking out my source code and completing simple builds. I needed a tiny bit of help from the guys at MikeCI.com to allow my build to access to some of the more obscure Maven repositories in my POM, but they handle these requests all the time and the service from the support team was top-notch.
Within a few hours (and very little effort on my part) I had a Maven build up and running and fully automated with a schedule.
Considering my project’s build includes starting and stopping an embedded Glassfish container and running SoapUI integration tests – I was amazed at just how easy it actually was!
Talking to the guys over at MikeCI, it sounds like the technical architecture behind the service is very cool. MikeCI uses Amazon’s EC2 elastic computing cloud to create a clean and secure virtual environment for every build, so there is no danger of them running out of infrastructure, or having multiple client’s builds interfere with each other.
If you’re looking to simplify your build infrastructure you should definitely evaluate MikeCI.com.
What does the basic architecture look like?
The service itself is a WAR packaged JEE6 deployable web application. The client can be anything. For the purposes of this project I used SoapUI as my client so that I could avoid messing about creating a custom UI. As I have already mentioned in other posts, the package only contains 8 or so files but delivers basic XML CRUD via a RESTful web-service.
The reason the package can be so light is because Glassfish, JavaDB, Jersey, JAXB and Eclipselink do most of the work. Deployment of the service is very fast – mere milliseconds on my PC.
What advantages does this RESTful XML based CRUD have over conventional methods like AL DSP or SOAP/WSDL?
First and foremost, it’s really, really, really simple. But also…
- Having the XSD at the core of the project makes the data model very easy to control.
- HyperJaxB3 makes the generation of marshal-able Java sources and JPA entities really easy.
- REST’s flexibility around content formats opens the application up for use by many different clients.
- Using JEE6′s simplified WAR packaging model makes the application project small and easy to package and deploy.
- JPA takes the effort out of entity persistence code and opens up lots of vendor choice.
Overall the service I have created here does basic XML based ‘CRUD’ persistence over HTTP using RESTful web-services in just 1 XSD, 2 Java classes and 4 xml configuration files. Very simple.
Finally REST with XML gives you the benefits of having a structured symantic model without the costs of using WSDL’s to define the service interface. Not using WSDL precludes you from using WS-* standards, but many people get on just fine without them.
In this post I’ll cover how my HyperJaxb3 based RESTful web-service gets built, tested and deployed.
What did I want the project’s build to demonstrate?
Fully automated end-to-end build, test and deployment with integration testing of JEE6 applications.
I chose Maven to handle the build because it’s well supported and perfect for this type of requirement. By choosing Maven I get the consistency of a prescribed build lifecycle and fully automated dependency management.
What frameworks does the project use?
The project is a JEE6 WAR packaged web-application containing stateless EJB’s (which is a new feature of JEE6). The jax-rs implementation I’m using is Jersey from Sun which also takes care of marshalling data in either JSON or XML format into Java objects and vice versa. The JPA implementation is Eclipselink, previously known as Oracle Toplink. The application depends on the default datasource provided in Glassfish which is based on the JavaDB database.
What happens during the Maven build?
In Maven I use the ‘verify‘ goal which sits towards the end of the Maven build lifecycle. This causes the following steps to occur during each build…
- Generate sources. The HyperJaxb3 Maven Plugin picks up my ‘Item.xsd’ in the generate-sources stage and creates a set of Java objects that are annotated as using both JPA for persistence and JAXB for XML marshalling. It also generates the container persistence configuration file used by Glassfish.
- Compile. The code is then compiled as usual using the generated sources from step 1.
- Test. The JUnit tests are then run using Mockito to mock out the JPA framework and the EJB used for CRUD operations.
- Package. The application is then packaged into a WAR archive.
- Start-domain. The Glassfish Maven Plugin starts an embedded Glassfish V3 instance using a customised configuration.
- The WAR archive is then deployed to the embedded server instance.
- Integration test. The SoapUI Maven Plugin then starts a SoapUI v3 test that tests the REST interface and ensures all the integrated components are working correctly together.
- The application WAR is undeployed.
- Stop-domain. Finally, the embedded Glassfish instance is shut-down.
This process ensures that everything can be built, tested, deployed and integration tested in one fully automated process. If this were handled by a CI server like Hudson or Mike, then you would get a full end-to-end test every time the build is triggered.
I enjoyed putting this project together and figured this was a pretty useful build process that I could use again and again. What do you think? Send me a comment.
Since my last post, lots of people have been asking me what exactly I’ve been doing with HyperJaxb3 and REST (jax-rs). In this post I’ll try and explain what I wanted to get out of this RESTful service prototype…
What was I trying to achieve?
- I wanted to learn how use the power of RESTful services, JAXB and JPA to create a very simple prototype service that can be used to Create, Read, Update, and Delete a simple XSD structure.
- I wanted an XSD based data model to sit right at the core of this project. The XSD would describe all the entities used by the application and govern all communications between the client and the service. The XSD would preferably also control the Java data model and the JPA database structure (DDL) in order to keep things simple.
- I wanted to create something quickly. I’m doing this prototype in my limited personal-time and I get bored with long drawn out projects when I’m working alone like this.
Why did I want to build this prototype?
In the past I have designed WSDL first SOAP services that have used proprietary products like BEA AquaLogic Data Services Platform (a.k.a. ‘Oracle Data Service Integrator’) to hande CRUD operations on an XSD document via a SOAP/WSDL interface.
Having used these products, I felt that they were a bit bloated, clunky, expensive and not particularly user friendly. Developers generally did not like these products and gave me some grief for towing the company line. That experience left me with a desire to ‘explore other options’.
If I could find an alternative to these products that was cheaper, simpler, faster and easier to work with – I’d be onto a winner.
What ‘User Story’ does my prototype implement?
Many companies need a Product Information Management system to keep track of product data. At the heart of these products is a simple CRUD mechanism for storing details about Products or Items. As I have some exposure to these systems it seemed like a logical place to start.
Was HyperJaxb in the frame from the start?
No. I discovered HyperJaxb3 during my ‘spike’ phase when I was looking for ways to combine JPA and JAXB. Of course once I’d found HyperJaxb3 I really wanted to make it work because it makes things so much simpler.
In my next post I’ll cover some details about the project’s build which does full integration testing using an embedded JEE server. Subscribe now to get an alert when I post…
Every now and again something comes along that just shifts the game along with a quantum leap. For me, the technologies that did this in the past were XML and Java Persistence (AKA Object Relational Mapping or ORM).
XML gave the world a standard language for describing pretty much anything, but until JAXB came along getting from Java objects to XML was a bit of a bind (no pun intended). Similarly SQL gave the world a standard(ish) way to talk to relational databases, but getting from Java objects to JDBC was also a bit of a chore – until JDO (and later JPA) came along to automate this process.
Recently though, as I have become more involved in implementing web-services, it became apparent that there was still a fair bit of manual labour involved if you wanted to go from client to database using XML and Java objects.
It is quite possible to mix JaxB and JPA by hand (tutorial here) but there are problems with this approach in my opinion.
- It’s usually code first and XML second.
- This makes the XML quite brittle and liable to change.
- Changing XML like this is hard for clients to keep up with.
- Generally it goes against the ’single semantic model’ approach advocated in SOA’s design principals.
- Generally it takes too long, and involves too much effort.
But most significantly, it’s quite tricky. You need a working knowledge of JPA and JAXB annotations and API’s to make it work. Skills like these are hard to acquire quickly and get in the way if you just want to get a project up and running.
However, a new java library from Aleksei Valikov called Hyperjaxb3 makes combining JPA and JAXB really easy. Hyperjaxb3 is basically an extension to JAXB that takes the objects generated by JAXB and annotates them so that they can also be used with JPA.
It’s a simple process which starts with the XSD of your object model and ends with database entries with Java objects being used in-between. Starting with XSD helps to maintain the integrity of your model, and prevents it mysteriously changing without your consent. Using JPA gives you a choice of Persistence Manager implementations including Eclipselink and Hibernate to name just a few. The code generation process can be tweaked and tuned quite a bit to ensure that you get the object model that you want.
The results are fantastic. A proper ‘Soup-to-Nuts‘, XML to Database technology that adheres to standards supported by a number of enterprise class vendors.
It makes BEA ALDSP look very bloated and lethargic, particularly if you build Hyperjaxb3 into a Jee6 compliant RESTful web-service (like I have).