Book Review: Service Oriented Architecture with Java

Service Oriented Architecture with Java by Packt Publishing.
Ben Wilcock, June 2010.

Introduction.

For many, Java is the language of choice for implementing Service Oriented Architecture, and with such a rich and diverse development community, there are a number of implementation frameworks that offer to share the burden. But as an Architect, which should you choose for your project? Packt Publishing’s ‘Service Oriented Architecture with Java’ aims to give a fast introduction to the most successful Java frameworks, along with a crash course in some SOA principals and benefits. At 169 printed pages it’s certainly a quick read and it delivers on many of its promises. However, spread between 3 authors, the cohesiveness of the writing has suffered somewhat, so you should take this into account if you are considering buying this book.

What’s the book about?

Aimed at architects and developers who are familiar with Java, the book is organised into 6 chapters. It promises to explain the concepts of the business logic layer that lives at the core of a Service Oriented Architecture, how to design services for SOA, and how to implement Web Services using various Java frameworks.

In the first chapter the author chooses to start way back at the beginning with a ‘What is Architecture’ and and explanation of the ’1-Tier, 2-Tier, 3-Tier and N-Tier’ architectural patterns. Unfortunately this is  a discussion that has been served up a hundred times before in other books and blogs, and on 99 occasions it was probably covered better than it is here.

However, once this introductory section is out of the way, the author does go on to explain some useful basic SOA principals like contract-first, loose coupling, platform neutrality, standards, re-use and scalability whilst also ensuring that the reader understands that creating a SOA doesn’t simply mean building Web Services.

By Chapter 2 things have improved considerably. The author dishes up a rapid ‘whistle-stop’ tour of Web Service implementation in Java starting with XML documents over HTTP using POJO’s and REST. He then introduces the popular open-source Java Web Service frameworks such as JAX-WS, Axis, Spring and XFire in quick succession, showing briefly how each can contribute to reducing the implementation effort.

Chapter 3 extends this discussion further, adding more detail and encouraging the reader to get involved by downloading the sample code and having a go.

These two chapters are undoubtedly the best in the book. As an architect who has dealt with most of these frameworks in the past, I found the text to be a useful and enjoyable reminder of my experience with each of them.

Chapter 4 concerns itself with data persistence and enterprise integration. The chapter starts with JDO or Java Data Objects, an odd choice as its a rather moribund ORM framework which is largely commercially irrelevant and long since superseded by JPA and Hibernate. Service Data Objects (SDO) and Service Component Architecture (SCA) are covered next, but seem out of place in relation to the lighweight open-source frameworks of the previous chapters. Finally, Message Oriented Middleware (MOM) and Enterprise Service Bus (ESB) also get a mention. These latter discussions are very brief, not really gifting the reader with enough information on ESB’s unique functions and benefits for example.

Chapter 5 attempts to bring it all together by discussing one problem and two potential solutions. First, an old school ‘point to point’ integration is described followed by a equivalent built using SOA tools and techniques. The advantages and disadvantages of both are then examined. Unfortunately I found this discussion hard to get value from. Having experienced most of these problems at first hand, the fictitious organisation’s problem domain was over-simplistic and the subsequent ‘solutions’ felt contrived. What was missing was a sense of realism or integrity to the conclusions being made. The author did paint a positive and worthwhile picture of how SOA can add value, but it was an opportunity that was under utilised in my opinion.

The final chapter (Chapter 6) summarises what we have learnt and attempts to re-iterate that SOA isn’t actually about Java – it’s about Architecture. The benefits of SOA and Web Services are presented once more with particular attention being drawn to loose-coupling, re-use and ease of integration.

Conclusion.

The book delivers on many of its promises, but the main issue I had with it was with its overall quality.

The quality issues start straight away in Chapter 1. The basic standard of writing on display is quite poor, even for a techy book, with typo’s and unfathomable sentences throughout. For example, if you know what ‘joining the SOA wagon wheel’ means (as mentioned on page 24) then please get in touch. The consistency of the message is also weak in parts. E.g. the principle of ‘contract-first’ doc-literal service design is recommended in one chapter, but not re-enforced consistently in others.

What I did like about this book was its brevity. Covering a topic like this quickly from a high level makes the benefits very accessible to busy Architects. I’ve often lamented ponderous techy books filled with waffle, so this shorter 169 page format was a very welcome change. Even the code presented is cropped and chopped so that you can get the gist without pages and pages of dull listings.

However, the danger of shorter formats like this one are that they draw all the more attention to quality issues and consistency problems, as that was certainly the case here. Overall though, I would recommend this book – just be sure that you can live with these criticisms before you shell out your cash.

Links:

Sample Chapter: Chapter 4
Link to the Book at the Publishers Site: Service Oriented Architecture with Java

Biography:

Ben Wilcock is a freelance SOA Architect with an enviable reputation for delivering good quality Service Oriented Architectures. He has spent the last 3 years working with a FTSE 100 listed Retailer to create a brand new Service Oriented Architecture which is delivering substantial business value and new opportunities. You can read his blog at http://benwilcock.wordpress.com or contact him via his website.

RESTful service with HyperJaxb3 (Part 5 – CI with Mike)

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.

RESTful service with HyperJaxb3 (Part 4 – Architecture)

What does the basic architecture look like?

Architecture diagram

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.

RESTful service with HyperJaxb3 (Part 2 – Build)

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.

I also wanted an opportunity to use Glassfish V3 and JEE6. I prefer Glassfish to JBoss these days because of its great Admin console.

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…

1. 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.
2. Compile. The code is then compiled as usual using the generated sources from step 1.
3. Test. The JUnit tests are then run using Mockito to mock out the JPA framework and the EJB used for CRUD operations.
4. Package. The application is then packaged into a WAR archive.
5. Start-domain. The Glassfish Maven Plugin starts an embedded Glassfish V3 instance using a customised configuration.
6. The WAR archive is then deployed to the embedded server instance.
7. 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.
8. The application WAR is undeployed.
9. 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.