In the previous posts I discussed how I went about building my SOA ‘Entity’ service for Products by using a combination of Java Web Services, Java EE and the CouchDB NoSQL database. In this final post in the series I’m going to leverage some of the technical assets that I’ve created and implement some new user stories using some popular SOA patterns.
My current Product Entity Service implementation is very business process agnostic, and therefore highly re-usable in any scenario where consumers want to discover or store Product information. However, as it stands the Product Entity Service is designed to be used within a trusted environment. This means that there are no restrictions on access to operations like Create, Update or Delete. This is fine within a strictly controlled corporate sandbox but what if I want to share some of my service operations or Product information with non trusted users?
Lets imagine that in addition to our in-house use of the Product Entity Service we also wanted to cater for the following agile ‘user story’…
Now that I have prepared a skeleton contract-first web-service and created a data access layer using Ektorp and CouchDB, it’s time to wire them together into a fully working entity service. To do this I’m going to use Java EE and Glassfish 3.1.
It’s worth noting at this point that it’s not strictly necessary that I use Java EE at all for his kind of R&D work. I don’t need the security or the transaction features that are provided by a JEE server like Glassfish and I could probably use something a little lighter like Tomcat or Jetty. However, I do like the convenience and the features of JEE, and many applications that begin life on an standard Java application server like Tomcat do end up either grafting JEE features into Tomcat (like JAX-WS) or migrating to a full JEE server like Glassfish.
Service Autonomy is one of the 8 key SOA design principals. One way that you can achieve better service autonomy and create more scalable services is to give each service it’s own hardware to play with. Cloud infrastructure like Amazon’s Elastic Compute Cloud (called EC2 for short) is designed to fill this need by alowing you to add hardware at short notice and scale it horizontally or vertically.
Following on from part two of this series where I created and deployed the Product Entity Service using the SOA ‘contract-first’ technique, I’m now going to work on the NoSQL database aspects of the service implementation.
It’s time to begin the coding of my SOA entity service with NoSQL project, and as promised I’m starting with the web service’s contract.
This technique of starting with a web service contract definition is at the heart of the ‘contract-first’ approach to service-oriented architecture implementation and has numerous technical benefits including…
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.
Being a SOA Architect, it’s been a while since I had to code a Java Enterprise application (a.k.a J2EE or JEE application) but I am still very interested in maintaining an up to date knowledge of the technical advances in the Java Enterprise platform so that I can fully understand the design implications and the implementation opportunities presented by the platform’s new features.
Enterprise Java Beans 3 (EJB 3) is a major update to the JEE platform which debuts annotation based aspect-oriented configuration and provides new services for entity persistence and new bean types to handle things like timers and scheduling in enterprise applications. This is a new and very efficient approach but it’s very different to the deployment-descriptor based approach of J2EE. There are plenty of EJB tutorials and individual examples on the web, but if you want a fast but still comprehensive coverage I always think you get further with a decent guidebook in hand.
Richard M Reese’s “EJB 3.1 Cookbook” is just such a guide. It’s a quick whistle-stop tour of the EJB 3 platform and covers all the new bean’s and annotations and also covers related hot topics like Web-services using SOAP and REST.
My aspiration in reading this book was to get a quick technical refresher on Enterprise Java Beans and then put this newly obtained knowledge to the test with some additional coding for the my personal SOA reference platform.
Each chapter in the book details a specific part of the EJB technology set. The JEE topics covered by the book include:
- Session Beans (EJB’s)
- Message Driven Beans (MDB’s)
- EJB Persistence (Entity Beans with JPA)
- EJB Persistence Queries (JPQL)
- EJB Transactions
- EJB Security
- EJB Interceptors
- EJB Timer Services
- Web Services (JAX-WS, JAX-RS)
Each topic is split into a selection of individual technical ‘recipes’, each written using a predictable format as follows:
- “Getting ready” provides an overview of how the recipe works.
- “How to do it…” provides a full description of how to achieve the recipe’s objectives.
- “How it works…” explains how any code samples are pulled together and explains any code referenced in the previous section.
- “See also” identifies any other recipes that may include pertinent information to assist the reader in their understanding.
By following this format the book is astonishingly easy to read. The simple structure means you can plough through it quickly from cover to cover if you want to or you can dip into it for hints when faced with a specific coding challenge.
Usually, code based tutorials and discussions can be a real bind but in using this recipe format Richard has avoided the lengthy code samples that you often see (the ones that usually send me to sleep). Instead he uses a tightly focussed code highlighting technique to illustrate his salient points. It’s an approach that works really well for experienced coders or those like me who are just looking for a refresher. However, novices or those looking for lots of detail may need to look elsewhere because a certain amount of experience with enterprise level coding, application servers, IDE’s, build tools and testing tools is helpful but these topics are not covered in the book.
Overall this book works really well as a technical refresher and really makes it easy to get started with EJB 3.1 (especially if you’re already familiar with some aspects of the JEE platform).
The JEE platform itself has gained some very powerful and useful features and from a SOA implementation perspective, the addition of JAX-WS, JAX-RS and EJB Interceptors into the mix means that JEE is now a great platform for SOA implementing using either SOAP, REST or EJB components.
I’d definitely recommend this book to anyone who has some experience of Java EE and is interested in the technical advances of EJB 3.1 and the opportunities those new capabilities bring. However, if you’re a novice or you’re looking to get started with EJB for the first time, I’d image you’d be better served by a book that has designed with novices in mind.