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 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 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.

Top 5: SOA gotcha’s and how to avoid them.

After 5 years of designing and building award winning service oriented architectures, I thought I’d share my top 5 SOA gotcha’s and some general hints on how you can avoid them in your SOA programme.

Oracle SOA Suite 11g R1 Developers Guide – Book Review

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…

Introduction.

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 List:
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

Avoiding the “I’m Spartacus” scenario in SOA.

Remember the movie “Spartacus” – the Stanley Kubrick classic starring Kirk Douglas? In the movie there’s a famous scene where the bad guy’s (the Romans) want to capture Spartacus (Douglas) who’s the leader of a Slave army. After a huge battle the Slave army is defeated and the Romans promise that no further punishment will be dished out as long as the slaves identify their leader, Spartacus. “Who among you is Spartacus?” ask the Romans. To which, one by one hundreds of guys each reply in turn “I’m Spartacus” thereby protecting their leader by creating a huge array of ‘false positive’s‘ so that the Romans can’t properly identify the one true Spartacus.

What’s this to do with SOA?

In large SOA programmes I’ve seen a similar scenario where all of a sudden, multiple in-flight projects each start to claim that they are delivering ‘the SOA’. However, in reality very none of them are because it all hinges on how you measure ‘SOA’.

This ‘SOA Spartacus’ scenario usually occurs quite soon after SOA is articulated as the primary strategic direction of the programme, but before the organisation’s SOA capability is mature enough to understand what is meant by SOA, and how it should be designed and delivered. The problem occurs because people are inherently good, and they want to be seen to be doing the right thing even when exactly what constitutes ‘the right thing’ is not terribly well understood.

The risk for these SOA programmes is that should this situation be allowed to continue, the organisation may ultimately deliver none of the strategic benefits of SOA because the project teams are not properly coordinated and each ends up doing SOA very differently.

The Solution:

The solution to the problem is in two parts. Part one is to have a clear understanding of what constitutes SOA in your environment by creating a single set of SOA Design Standards.  Part two is to provide robust SOA Governance so that adherence to the standards is universally enforced.

1. SOA Design Standards.

Business-aligned and intrinsically interoperable service-oriented architecture can only be created by widespread adherance to a consistent set of SOA design standards. It needs to be made very clear what does constitute good SOA within your domain and what doesn’t. Your service design standards should support the SOA design principals and ensure that the goals and benefits of SOA can be achieved. The overall policy of the SOA programme should be to enforce the SOA standards using SOA Governance…

2. SOA Governance.

In order to avoid deviation from the SOA standards and policies, you need to introduce an element of governance & control across the whole SOA programme that can ensure that the SOA Design Standards are applied consistently by each project team. If you do this it’s far more likely that you’ll get the outcomes you want and that the resulting SOA will meet the strategic goals of SOA.

Finally, a simple shortcut.

If you’re planning a SOA programme, quickly obtaining maturity in SOA design and implementation will save you a small fortune and help you avoid these simple gotcha’s. If you don’t have a SOA expert on your team, then my advice go and get one as soon as possible. It could be the best decision you’ll ever make. I’m confident you’d see a respectable return on that investment in a very short space of time.

My latest article on InfoQ

InfoQ have just published an article of mine entitled DIY SOA: Building your own Simple Service Repository.

You can read the article in full here: http://www.infoq.com/articles/SimpleServiceRepository

You can also see the cloud based demo of my version of the Simple Service Repository web application here: http://www.soagrowers.com/simpleservicerepository