{"id":1850,"date":"2012-09-10T10:00:00","date_gmt":"2012-09-10T10:00:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/implementing-entity-services-using-nosql-part-1-outline.html"},"modified":"2012-10-22T06:57:45","modified_gmt":"2012-10-22T06:57:45","slug":"implementing-entity-services-using_10","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2012\/09\/implementing-entity-services-using_10.html","title":{"rendered":"Implementing Entity Services using NoSQL – Part 1: Outline"},"content":{"rendered":"
Over the past few weeks I\u2019ve been doing some R&D into the advantages of using NoSQL databases to implement Entity services<\/a> (also known as Data Services).<\/p>\n

Entity service is a classification of service coined in the Service Technology series of books from Thomas Erl. It\u2019s used to describe services that are highly agnostic and reusable because they deal primarily with the persistence of information modelled as business data \u2018entities\u2019. 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. <\/p>\n

This approach is further described in the Entity Abstraction SOA pattern<\/a>. <\/i> <\/p>\n

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<\/a> (or SDO for short). <\/p>\n

This is all well and good, but these applications come with dedicated servers and specialised IDE\u2019s and its all a bit \u2018heavyweight\u2019. 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. <\/p>\n

So the usual and basic implementation method would be to break out the Java and use a normal relational database with something like JPA<\/a> (Java Persistence API) to help you with the object\/relational mapping and persistence. This is a good choice and it can simplify the code a great deal, but there are still challenges. In web services where XML is being used as the payload, there is still the matter of converting between JAXB<\/a> generated Java objects and the Java objects used to persist data via JPA. You can use something like HyperJaxB<\/a> to annotate JAXB objects with JPA annotations, making the resulting data objects dual purpose, but you still have some issues with versioning and get none of the scalability advantages of NoSQL. Besides, I\u2019ve used this method before in an earlier blog<\/a>, so it where\u2019s the fun doing it again?

<\/div> <\/div><\/p>\n

Using NoSQL.<\/strong> <\/p>\n

A relatively new and enticing alternative is to use a NoSQL database for persistent storage. NoSQL databases have proved incredibly popular over the last few years, due mainly to their ability to achieve huge scalability and strong resilience. Lots of very high profile and high throughput websites use NoSQL datastores to manage and persist their data including Goole, Twitter, Foursquare, Facebook, and Ebay. <\/p>\n

The term NoSQL is used to describe \u201ca class of database management system identified by its non-adherence to the widely used relational database management system (RDBMS) model\u201d \u2013 Wikipedia<\/a>. <\/i> <\/p>\n

NoSQL datastores do not follow the conventional wisdom of a relational table based approach opting instead for a schema-less data structure that\u2019s often \u2018document centric\u2019 and capable of supporting very large volumes of data in highly distributed environments. <\/p>\n

Choosing a NoSQL Database.<\/strong> <\/p>\n

There are lots of different NoSQL implementations, so I won\u2019t go into detail here other than to say that my requirements were simple. I wanted something\u2026 <\/p>\n