{"id":1846,"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-5-improving-autonomy-using-the-cloud.html"},"modified":"2012-10-22T06:57:04","modified_gmt":"2012-10-22T06:57:04","slug":"implementing-entity-services-using","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2012\/09\/implementing-entity-services-using.html","title":{"rendered":"Implementing Entity Services using NoSQL – Part 5: Improving autonomy using the Cloud"},"content":{"rendered":"
In the previous posts I discussed how I went about building my SOA \u2018Entity\u2019 service for Products by using a combination of Java Web Services<\/a>, Java EE<\/a> and the CouchDB NoSQL<\/a> database. In this final post in the series I\u2019m going to leverage some of the technical assets that I\u2019ve created and implement some new user stories using some popular SOA patterns<\/a>. Take a look at Part 1<\/a> and Part 2<\/a> as well.<\/p>\n

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? <\/p>\n

Lets imagine that in addition to our in-house use of the Product Entity Service we also wanted to cater for the following agile \u2018user story\u2019\u2026 <\/p>\n

So that:<\/strong> My published product information is accurate and constantly available to off-site customers.
\n As a:<\/strong> Sales Director & IT Manager.
\n We want to:<\/strong> Offer a highly-available \u2018read-only\u2019 copy of my product information to off-site users and systems. <\/i> <\/p>\n

This scenario is not uncommon in business and I\u2019ve implemented user stories like it in the past with some of my clients<\/a>. But what\u2019s fantastic about the technologies that we\u2019re using to implement our Entity service (Java\/JAX-WS and CouchDB NoSQL) is that they make developing this scenario very easy. <\/p>\n

First of all, the architectural design.<\/strong> <\/p>\n

In order to implement this user story I\u2019m going to call upon two more SOA design patterns for the service architecture \u2013 Service Data Replication and Concurrent Contracts. In post two, we already talked about the \u2018contract-first\u2019 approach so I won\u2019t go into any more detail other than to say that it still applies here. The contract is still a Standardised<\/a> and Decoupled Contract<\/a>. <\/p>\n

Service Data Replication<\/a> is a pattern that helps you to achieve high levels of service autonomy and availability by creating whole copies of the data required by the service elsewhere on the infrastructure. This copy can then be used instead of the original in order to balance the load on the infrastructure. <\/p>\n

The Concurrent Contracts<\/a> pattern is used when \u2018[an existing] service\u2019s contract may not be suitable for or applicable to all potential service consumers\u2019. For example, when security, protocol or accessibility concerns require that something similar (but not the same) be made available to a specific subset of users (like off-site consumers or mobile devices with restricted processing power or bandwidth). <\/p>\n

In order to implement our new user story, we\u2019ll use both of these patterns together to provide a \u2018read-only\u2019 version of the Product Entity Service. However, by providing a second \u2018read-only\u2019 version of the Product Entity service, you could also say that we are partially implementing the Redundant Implementation<\/a> SOA pattern, because we\u2019re offering a second redundant option for some of the service\u2019s key operations.

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

The resulting architecture looks something like this (click to enlarge)\u2026 <\/p>\n

<\/a><\/div>\n

The service contract.<\/strong> <\/p>\n

The original Product Entity Service<\/a> offered five operations \u2013 Get, Find, Create, Update and Delete <\/i>but offering all these capabilities to outsiders is not necessary and would probably be quite problematic (in terms of security, integrity, etc.). We certainly don\u2019t want any external users creating or updating our product information without our permission. <\/p>\n

Therefore, in our web service contract for the new \u2018Read-only Product Entity Service<\/i>\u2018 I\u2019ve removed the Create<\/i>, Update<\/i> and Delete<\/i> operations completely and only provided Get<\/i> and Find<\/i>. All the datatypes remain the same (the same Product.xsd describes the product entity etc.). Keeping the datatypes the same is important because I\u2019m deliberately applying the Canonical Schema<\/a> and Schema Centralisation<\/a> patterns and utililising the Standardised Service Contract<\/a> principal in order to avoid transformation. <\/p>\n

The Java code.<\/strong> <\/p>\n

With this new read-only service I\u2019m still working contract first, so I\u2019ve created a new Maven <\/a>project who\u2019s first task during a build is to import the Read-only Product Entity Service\u2019s WSDL contact and create from it a set of JAX-WS service interfaces and data objects. <\/p>\n

From this point on, I can reuse some of the code that I\u2019ve developed already for the \u2018full\u2019 Product Entity Service. By refactoring my previous codebase into modules, I can even get Maven to treat the original code as a dependency for this new service. In essence, the bits that I\u2019m interested in are the EJB\u2019s and DAO\u2019s I created for the business and persistence logic of the Get<\/i> and Find<\/i> operations. <\/p>\n

By reusing the existing code and by creating a Glassfish server on the Amazon cloud<\/a>, I can stand-up the new service in record quick time and be halfway to completing the user story. All I need now is some replicated Product data to work with\u2026 <\/p>\n

Starting the data replication.<\/strong> <\/p>\n

Couch DB offers a fantastic enterprise class replication system out of the box and for free. This makes implementing the Service Data Replication SOA pattern<\/a> very easy. <\/p>\n

Couch DB\u2019s built in data replicator can replicate whole databases of documents between any two CouchDb instances that are available on the network or over the web. In this case I\u2019ve created a CouchDb database at a hosted provider called IrisCouch<\/a>. They can provide me with secured CouchDB instances or various sizes at the drop of a hat and will look after all the necessary infrastructure and backup requirements. For small users they even do this free. <\/p>\n

In order to setup a replication I just need to use the CURL command-line tool to issue specific instructions via HTTP to my local CouchDB instance. These instructions tells my local CouchDB service to replicate my Product data with my remote CouchDB database on IrisCouch<\/a> over the web. <\/p>\n

The database replication instruction is a JSON document and looks something like this\u2026 <\/p>\n

{'source':'products',\r\n 'target':'https:\/\/username:password@instance.iriscouch.com:6984\/products',\r\n 'create_target':true,\r\n 'continuous':true}<\/pre>\n
In essence this JSON instruction says \u201creplicate the local Products database documents to the remote iriscouch instance, forever<\/i>\u201c. Immediately on issuing the command, CouchDB sets to work and starts replicating my local data to my remote database instance. This includes updates and deletes and any \u2018design documents\u2019 stored in the Products database. This replica of Products is then immediately available to my Read-only Product Entity Service which is hosted in the Amazon EC2 cloud.         <\/p>\n
From this point onwards, service consumers using the Get or Find operations on this service will see a replica of the data that is used in-house. The information will be kept up to date by the replication.         <\/p>\n
Finally, the user acceptance test.<\/strong>        <\/p>\n
So how well did we do against our new user story\u2019s requirements?         <\/p>\n
By hosting the read-only version of the Product Entity Service on the Amazon cloud, we\u2019ve created an off site web-service that that is highly available. The data it provides is an exact replica of the data we use on-site with only the smallest amount of latency between the two copies under normal conditions.         <\/p>\n
If my on-site network goes down, the read-only cloud based version of the Product Entity Service will carry on regardless, and because we\u2019re using the Amazon cloud infrastructure it can benefit from almost unlimited runtime resources if necessary. Availability shouldn\u2019t ever be a problem. We can add more machines at any time, and offer load balancing and potentially spread machines over multiple continents if necessary.         <\/p>\n
My guess is that the Sales Director will be pleased that our customers can always see the information in our product catalogue and customers themselves should be be pretty satisfied with the comprehensive and reliable service that they now receive. Finally, the IT Manager will be pleased that network security remains intact and that the new off-site hosted service will cost next to nothing to run and be very reliable.         <\/p>\n
All that remains is to publicise the Read-only Product Entity Service endpoint to our customers and support them in their use of it. All in all a pretty successful day at the office.         <\/p>\n
Would you like to try the Read-only Product Service for yourself?<\/strong>        <\/p>\n
The endpoint details can be found in the SOA Growers Simple Service Repository<\/a>. Follow the \u2018Service Repository\u2019 link and look for the \u2018R20121231? <\/strong>release. In there you fill find links to the service\u2019s WSDL, WS-I certificate and link to a live demo web-service endpoint hosted on an AWS micro-instance.         <\/p>\n
The best way to experience the live demo is to download the SOAP-UI test suite. This test suite requires SOAP-UI<\/a> v4 (which can be downloaded for free). The test suite contains a simple test of all the operations available on the service.         <\/p>\n
Catch-up with the entire blog series online\u2026<\/strong>        <\/p>\n
That\u2019s probably the last in this series on building entity services with Java and CouchDB. If you missed any of the earlier blog posts in this series and you would like to catch up, the other entries are listed below\u2026         <\/p>\n