Free SOA Service Design Cheat Sheet

This simple cheat sheet contains all the key goals, principals and design patterns that you should be aware of when designing SOA services and contains helpful links to places where you can find more in-depth information on each topic.

Implementing Entity Services using NoSQL – Part 5: Improving autonomy using the Cloud

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’…

Implementing Entity Services using NoSQL – Part 4: Java EE

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.

Commissioning Glassfish 3 application servers on AWS EC2

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.

Implementing Entity Services using NoSQL – Part 3: CouchDB

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.

Implementing Entity Services using NoSQL – Part 2: Contract-first

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…

Implementing Entity Services using NoSQL – Part 1: Outline

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.