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.
Please Note: I’m reviewing this book from the perspective of an independent SOA Architect, not as an Oracle SOA Suite Developer – the role for whom this book is really intended. If you’re interested in an architects perspective, please read on…
At some point you have to stop analysing your SOA and start turning the various designs and specifications you have into working services. In recent years the toolsets available to create services have been maturing very quickly indeed.
Packt Publishing’s Oracle SOA Suite 11g R1 Developers Guide intends to help you understand exactly how you can leverage the power of Oracle’s SOA Suite 11g. It’s goal is to introduce you to the tools and techniques you’ll need in order to quickly and efficiently implement services using the development frameworks made available in this comprehensive, and well regarded SOA Suite.
What I liked.
Make no mistake, Oracle SOA Suite is huge encompassing years of development and gathering together many products that used to exist separately and even from other vendors (like BEA’s Aqualogic DSP for example, now simply the SDO implementation inside the suite). The sheer scale of the thing can be really quite off-putting at first, but this book does a brilliant job of making it totally accessible via a series of simple and easy to follow steps that are well thought out.
Working with Oracle SOA Suite (O.S.S) means learning how to build services using the accompanying Oracle JDeveloper IDE and then understanding how to deploy the services that you’ve develop onto an O.S.S server where they can be administered and executed at runtime.
O.S.S is billed as providing a standards compliant environment and toolset, and in the main that seems an entirely fair statement with a vast majority of popular standards and psuedo standards at your disposal. Of course not all standards are equal, and some require extensions that are proprietary in nature.
At 720 pages the book covers a lot of ground, but even so, due to the vast scope of Oracle SOA Suite, that’s still just the tip of the iceberg. The book starts well with a section on the concepts behind service-oriented architecture in which the author examines each of those keywords in turn and together (services, orientation and architecture). It’s a neat idea for scene setting and it uses some simple examples that are very helpful for those amongst the readership who are still quite new to SOA.
The topics covered in the main text include writing your first SOA Suite composite, service-enabling existing systems, using BPEL to build composite services and business processes, adding human workflows and using business rules & events. The text then goes into a worked example via a tutorial that spans multiple chapters and pulls many of the core concepts together using facilities available in the SOA Suite software. Concepts like persistence of data, validation, error-handling, deployment, testing and security are all explored to a basic level of detail.
Although I didn’t try all the tutorials in the book, the ones I did try were well written, clear and concise with plenty of helpful screen-shots and pointers along the way. There were a few minor differences between the version of the software covered in the book [R1] and the latest version available from Oracle, but these were not significant and didn’t impact my ability to follow the exercises. However, you should be aware that troubleshooting issues with this vast suite can be a bit of a black art, but this is in not something the book can do much about. Prevention is better than cure in most cases, so just follow the guide carefully.
Overall this book is a hugely impressive feat. It covers a lot of ground in O.S.S and JDeveloper, and it does it in a way that is admirably consistent, comprehensive and cohesive.
What I liked less.
The book itself is intended to support SOA developers rather than SOA architects, SOA designers or SOA analysts. In a mature environment the latter roles would probably have a say regarding the methods and approaches used for SOA development and service implementation. For example, the output of the SOA designer in the form of service contracts or implementation designs is an important input for a SOA Developer. So therefore, one criticism I do have of the book is that these role relationships and the dependency and interaction between them is not reflected strongly enough.
The second issue I have with this ‘developer in a bubble’ approach is one that can be laid at the door of most developer books – sometimes they offer up bad practices quite early on in the interests of showing how ‘simple’ life can be if you take some architectural short-cuts. This is fine if caution is recommended or if the developer is encouraged to be aware of the bigger picture and compensate for the negative effects of these practices in real-life code. However in this case I didn’t feel this danger was understood as no such warning was forthcoming.
For example – the ‘contract-first’ loose coupling approach is quite important to SOA design and development as it helps to avoid negative consumer-to-implementation tight-coupling. Avoiding this issue does affect how a new SOA Suite composite would be created in JDeveloper but this highly advisable best practice is not really mentioned in the book and there is no tutorial on contract-first approaches in the text. There is a section on loose-coupling, but unfortunately the content is way off the mark. The authors understanding of what loose-coupling is and how it should be implemented do not match my own experiences with the problem. As a SOA architect I see this as storing up potential issues by not emphasising to developers the importance of good design in SOA.
One final criticism of the book is the over ‘selling’ of the usefulness of Oracle Service Bus (aka E.S.B) for things like endpoint discovery & data transformation. In my opinion an ESB isn’t always necessary. A well designed SOA would use contract standardisation to avoid data transformation and may use a registry or some other form of dynamic endpoint resolution, thereby negating the requirement for the use of common E.S.B features. In my experience, E.S.B’s are often misused or used too early and there is nothing here to caution the reader to the dangers. It’s a bit of an ‘own goal’, giving false kudos to E.S.B’s in a fast moving SOA world that’s learning to do without E.S.B’s most of the time. The section in the book on configuring a simple service proxy in Oracle Service Bus also highlights just how poor the actual user experience is in this particular software application. My advice would be to skip these E.S.B sections all-together, as it will save you time and you can always come back to it later.
My overall conclusion.
It covers good ground and gives you enough detail to start to get to grips with Oracle SOA Suite, JDeveloper and the Oracle Enterprise Manager. Some of the theories, practices and architectural choices are a little sub-optimal in my opinion, but as a ‘way in’ to understanding what Oracle SOA Suite can offer and how you could leverage value from it as a service developer, I would definitely recommend it over the default Oracle offerings.
Oracle SOA Suite 11g R1 Developers Guide.
Language : English
Paperback : 720 pages [ 235mm x 191mm ]
Release Date : July 2010
ISBN : 1849680183
Chapter 1: Introduction to Oracle SOA Suite
Chapter 2: Writing your First Composite
Chapter 3: Service-enabling Existing Systems
Chapter 4: Loosely-coupling Services
Chapter 5: Using BPEL to Build Composite Services and Business Processes
Chapter 6: Adding in Human Workflow
Chapter 7: Using Business Rules to Define Decision Points
Chapter 8: Using Business Events
Chapter 9: Building Real-time Dashboards
Chapter 10: oBay Introduction
Chapter 11: Designing the Service Contract
Chapter 12: Building Entity Services Using Service Data Objects (SDOs)
Chapter 13: Building Validation into Services
Chapter 14: Error Handling
Chapter 15: Advanced SOA Suite Architecture
Chapter 16: Message Interaction Patterns
Chapter 17: Workflow Patterns
Chapter 18: Using Business Rules to Implement Services
Chapter 19: Packaging and Deployment
Chapter 20: Testing Composite Applications
Chapter 21: Defining Security and Management Policies