Book review: SOA Made Simple – Packt Publishing


SOA made Simple_covPackt Publishing’s latest SOA book: ‘SOA Made Simple‘, claims to lay bare the fundamental strategies, goals, principals, benefits and impacts of service oriented architecture in a way that is easily accessible. In this review we’ll see if these claims are justified, and if they are, what it might mean for the SOA community as a whole.

As a certified SOA Architect, I’m often surprised by how difficult it is for companies to create a shared consensus and understanding of what it means to become service-oriented and how important it is for the future survival of commercial and non-commercial organisations alike. Many of these difficulties are related to two basic issues: lack of knowledge and lack of experience. This book intends to help alleviate both.

The authors (Lonneke Dikmans & Ronald van Luttikhuizen) certainly have the knowledge and the experience required to create successful SOA implementations. Fortunately for us, they also have have a fluid and easy to read writing style and the advice that they dispense in this book is accurate, valuable, practical, consistent and of a very high standard throughout.

Many of my SOA gotcha’s are dealt with in the text. Registries aren’t for everyone, tick. ESB’s can be good for some use cases, but using them for EAI is a backwards step, tick. Canonical models are essential for broad-brush interoperability, tick. Data standards can be useful internally sometimes, but often more so at enterprise boundaries, tick.

Setting the scene.

In the preface, the book identifies the types of people that it is intended to help: Architects, Designers, Developers, and Team-leads involved in delivering SOA.  However, I would go much further. I think this book would also be of use to many of the UK’s CIO’s, CTO’s, IT Directors, Enterprise Architects, Department Managers, Project Managers and Programme Managers. Basically anyone who is new to SOA but has some responsibility to deliver it within their enterprise.

The book begins with a chapter that discusses the problems faced by modern businesses, most of which stem from a lack of alignment between business and IT leading to an increased exposure to risk. Duplication of functionality and data in application (and process) ‘silos’ is also identified as a common issue. These two themes are revisited throughout the book using various example case studies.

The following chapter covers Service-Orientation as a solution to these problems. It starts by discussing the SOA architectural style but quickly moves on to services, discussing what a service is and how services can be described using the concepts of contracts, interfaces and implementations (these three being separate facets of the same service).

Service Inventory, Service Design & Service Implementation.

Chapter three discusses the logical starting point for any service inventory: service identification and service design.  It uses simple business process models to illustrate the activities and decision making points in the process (as do I when working with my corporate clients). Top-down, bottom-up and meet-in-the-middle design approaches are covered in detail, with their respective advantages and disadvantages made clear. A set of service design principals are offered, but one of the few criticisms I have is that these are not simply taken from Thomas Erl’s more definitive SOA Principals of Service Design (albeit re-written to make them more accessible to the layperson).

Chapter four discusses the process of ‘classifying’ (grouping & typing) services, and offers a simple classification system that introduces three basic service types: Elementary services, composite services and process services. It’s not a classification system that I’ve used personally (I usually use Erl’s) but I will be considering it in future for use with clients thanks to the additional simplicity it affords.

SOA Platforms are discussed in chapter five with a look at the common building blocks of service oriented enterprise architectures and the technologies that support them. Services, events, compositions, rules, UI’s, security, registry & repository and design & development tooling are all examined and their associated technologies identified and explained (for example: application servers for hosting services, ESB’s for exposing endpoints, etc.). Chapter six then goes on to explore the platforms and components offered by the big three SOA vendors (Oracle, IBM and Microsoft).

Management and Politics.

The latter third of the book is devoted to what I call the ‘management and politics of SOA implementation’. First up is a section on how to create a viable SOA business case and migration roadmap, including an examination of SOA investment choices using basic business scenarios such as cost-cutting or reduced time to market. The reader is also warned about the naturally wavering enthusiasm for SOA as complicated change programmes progress through various emotionally charged stages experiencing both euphoria and despair.

Chapter eight covers the important topic of SOA life-cycle management, whilst chapter nine continues this thread with a discussion on SOA Governance.

In life-cycle management, the authors elaborate on techniques for versioning services and for the management of various service related artefacts (contracts, implementations, etc.). Registries and repositories are explained and their differences noted, alongside some refreshingly practical advice from an enterprise level book of this kind – namely that registries are often not required and repositories can be provided using the simplest of tools (if you’ve seen my InfoQ article on Simple Service Repositories and you’ll already know I’m a strong advocate of this approach).

When discussing SOA Governance, the authors suggest a strategic approach when ‘picking your battles’ – choosing which principles and practices to protect and which can be sacrificed for the greater good. Governance, they say, is about protecting the SOA strategy by guiding and influencing the architectural design choices and remaining outcome-oriented. There are many ways to tie a shoe-lace they say, the important thing is that the shoe stays on! Deviations are sometimes necessary, but they should always be recorded, monitored and corrected at the most suitable juncture available. I couldn’t agree more. It’s a sensible approach to an important SOA practice that’s often misaligned, misinterpreted, misunderstood or simply missed out.

The final section is devoted to methodologies and SOA. Europe’s most commonly used methodologies for demand management (business change), project management, IT management and development are all examined and SOA’s impacts on their processes and practices are explained. Modern SOA (what the management consultants now refer to as ‘digital business’) supersedes most of these methodologies, so it’s good that the authors have taken the time to explain where conflicts in approach may arise and what you can do about them.

My Summary.

As you may have already noticed, I really liked this book. Personally, I think it should be the minimum required reading for any Architect, Developer or Project Manager who adds ‘SOA’ to their profile. Let me explain why…

People who genuinely ‘get SOA’ understand that becoming service-oriented means realising a new strategic design direction for both business and architecture alike. It’s not simply about web service technology. That’s very much the underlying theme of this particular book. It provides the reader with clear information regarding the business motivation behind SOA and then backs up this new found understanding with some insights regarding the tools and technology used to support this new architectural design paradigm.

However, over the years I’ve met a small number of ‘SOA Charlatans’ – people who are ‘a bit vague’ on the motivation and business benefits behind SOA, but figured that they would go and get a SOA job anyway because they’ve “done loads of integration” or because “no-one understands SOA, so why not?”. In the past, this ‘SOA bluff’ strategy probably worked in many cases, but from now on beware – if the interviewer has read and understood just a fraction of this book, they’ll tear these imposters to pieces!

That’s my two-cents, what’s yours? Leave a comment or share…

About the Reviewer:

Ben Wilcock is a freelance SOA Certified Architect with a reputation for delivering exceptional Service Oriented Architectures. You can read his blog at http://benwilcock.wordpress.com/ or contact him via twitter (@benbravo73) or via his company website at http://www.soagrowers.com/.

Continue reading

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

Continue reading

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.

Continue reading

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.

Continue reading

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…

Continue reading