Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Book Review: Applied SOA

Book Review: Applied SOA

Applied SOA is a new book on Service Oriented Architecture written by 4 leading SOA practitioners: Michael Rosen, Boris Lublinsky, Kevin Smith and Marc Balcer. This book is a handbook that aims at making you successful with you SOA implementation. We asked a few questions to the authors before reviewing the book.

In addition to our review, InfoQ was able to obtain a sample chapter. Chapter 3: Getting Started with SOA can be downloaded here.

InfoQ: What has been the major hurdles people encountered in their SOA?

Boris: I think that majority of people are more interested in the SOA technologies, aka Web services, rather then in business modeling and decomposition -i.e. the SOA foundation. For example, a typical SOA debate is Rest vs SOAP, not why do we need to use services. Do not get me wrong, technology debates are important and I enjoy them, but as a result, in today's reality JBOWS (Just a Bunch Of Web Services) rules. That is why, in the book we deliberately were staying away from these and other implementation debates and were trying to address the heart of SOA - its architectural underpinnings. 

Kevin: We have painfully experienced that the lack of planning and governance has led to many chaotic SOA implementations. As Boris mentioned, many times, JBOWS will quickly get deployed without any focus on planning, semantic interoperability or enterprise data standards, and this makes integration difficult as new business partners eventually want to use these services. When services are deployed without plans related to service change management, enterprise management and real-time operations gets to be quite difficult and painful. One of the reasons that we wanted to write this book is to provide guidance based on the lessons that we have learned in this area, focusing on practical implementation – including planning, management, and governance.

Another hurdle that we have seen is security. Real business solutions demand real solutions for security, and this is sometimes underestimated or overlooked in new SOA projects – with dire consequences. The “alphabet soup” of overlapping (and sometimes competing) standards, specifications and technologies used for securing SOA can be overwhelming, and most security standards for SOA include various options, each demanding an in-depth knowledge of the fundamentals of information security. We have found that some of the major challenges for businesses are identity and attribute federation between business partners, the subtleties of identity and attribute propagation, tradeoffs between security approaches and performance and availability, and access control policy management and enforcement – just to name a few. The questions that we see people asking are, “How do we get started?”, “What are our options for building security into our SOA?”, “How do we balance security and performance?” and “How do we actually apply the standards?”  We are answering these questions in our book, providing a practical guide for SOA security, with solution blueprints and decision flows to help this decision-making process easier.   

Michael: As with most new technology solutions, the challenges are not technical but rather are around motivating and managing the structural changes required to effectively utilized the new technologies. Anyone can build a ervice. The challenge is building the right services, and doing so within the context of the enterprise rather than the limited scope of a single project. These are issues that we specifically address with the architecture presented in our book.

InfoQ: "Lack of skills" is often considered as the #1 problem in SOA, how can a company go about solving it, beyond sharing Applied SOA with their architects and analysts?

Boris: "Lack of skill" is a serious problem, the question is which skills are we talking about? In my opinion, SOA is more business problem then technical, so bringing together even very skilled technical people will not always solve SOA pain. We need "true architects" to advance SOA. I would love to say - "Buy a book - it will solve all of your problems", but realistically, reading a book may help to pinpoint the issues and evaluate some of the solution approaches, but the actual solutions still have to come from inside the company  

Kevin: I would like to echo that. We need technologists with a good background in architecture and design, first of all – and some of this guidance is in our book. Probably as important is the fact that companies need analysts who understand the business problems for a particular domain. For example, if you are responsible for an enterprise SOA for a medical community, and you don’t actually have people in your company who intimately understand that medical community’s internal processes, then you aren’t going to do a good job. A company really needs to hire expertise from the business domain they are supporting, because as Boris said, SOA is more about solving business problems than technical.

Michael: There is lots of training available today on important topics such as business process design, SOA analysis and design, architecture etc. The important thing for a company to figure out first is what processes and approaches will work for them given their requirements, environment, culture and so on, and then to ramp up on the specific skills that will actually provide them value. Often some sort of competency center is a good approach to building a critical mass of the appropriate skills.

InfoQ: Where are we with SOA today, is it real? where is the level of maturity going? What's next?

Boris: I think SOA today is real, but not mature. The majority of companies are opting for a low hanging fruit - Service Oriented Integration (SOI). As indicated in the recent Barton's group report this is today a prevalent reason for SOA failure. Unless we will start to seriously link SOA with enterprise business model and organizational structure it will probably never fully mature and live to its expectations. 

Kevin: I would say that SOA is real, but the implementing technologies are not yet meeting the vision of what SOA can be. Many vendors push for you to buy their product suite for a “SOA in a box” solution, where interoperability works well if you use all of their products, but not so much if you integrate with other systems. Many web service toolkits have convenient point-and-click component to web service tools, and so developers find it easy to use them, and the result is that the services are no more well-designed than the initial components. Typical POJOs are not initially designed with a corresponding schema in mind, so when they are transformed into web services, semantic operability typically loses as the resulting service is very literally tightly coupled to the object’s implementation.  I do think that the implementing technologies for SOA are getting much better, but it does take some discipline for architects, designers, and programmers to not choose the quick-and-dirty approaches that are offered.

I think the hype factor is dying down on SOA, and that is a good thing. In the past, SOA evangelist salesmen were trying to sell a utopian vision of a SOA that brings world peace and is the silver bullet for all that ails you. It is important to know that SOA can help solve your business problems, and there are many technologies and standards used for SOA implementation. It is also important to know that SOA itself is technology agnostic. I think SOA as an architecture discipline will continue to mature and has a bright future.  

Michael: SOA is definitely real. We know of many companies that have had SOA in place for 10 years. All the major tools, platforms and packaged applications are moving to SOA and more and more SaaS services are available all the time. But, the majority of companies today are just getting started with SOA. On the typical maturity scale of 0 to 5, most are probably around 1, so now is definitely the time for them to focus on architecture rather than services.

Book Review

All topics are treated in depth and should be applicable readily to solve a lot of the issues that you might encounter as you implement a Service Oriented Architecture whether you are an architect, analyst, designer or CTO/CIO. All topics are illustrated with concrete and relevant examples, directly coming from real-world projects:

The current collection of SOA books and articles is rich on high-level theory by light on practical advice

In particular, this book will help you tie your SOA initiative with your Enterprise Architecture, IT Governance, Core Data and BPM initiatives.

The authors have noted that after working with different companies, there are several common areas of confusion:

  • First, what is SOA, and how it differs from Web Services or other distributed technologies?
  • Second, what is the relationship between the business and SOA?
  • Third, how do you design a good service?
  • Fourth, how do you effectively integrate existing applications and resources into a service-oriented solution?
  • Finally, how do services fit into overall enterprise solutions?

In particular, the authors argue that if it is easy to build "a" service, because the tools have reached a high level of maturity, it is still a challenge to build a "good" service based on solid design principles that fits into an overall architecture and can be combined into larger business processes within the enterprise.

The book is divided into three parts:

  • Understanding SOA
  • Designing SOA
  • Case Studies

A key to understand SOA is to understand the challenges it tackles:

  • Reuse
  • Efficient Development
  • Integration of applications and Data
  • Agility, Flexibility and alignment

From this starting point, the authors develop an understanding of what is needed to achieve these goals (Chapter 3: Getting Started with SOA can be  downloaded here). From their perspective, one must focus on:

  • Methodology and Service lifecycle
  • Reference Architecture
  • Business Architecture
  • Information Design
  • Identifying Services
  • Specifying Services

One of the points that they emphasize is the importance of the Information Architecture when implementing a Service Oriented Architecture and in particular the role its plays in the definition of the service interface.

In the second part, the authors share a deep level of expertise. Their approach is decidedly focused on the knowledge of the business. They rely on business context, business domain and business process models to identify services. Chapter 5 is dedicated to the relationship between information modeling and service design: 

A fundamental difference between service operations and object methods is that service operations have a much larger granularity. Rather than many simple operations with simple parameters, services produce and consume big chunks of a document.

This relationship is one of the toughest problems that needs to be solved in a Service Oriented Architecture, regardless of the technology that you are using. It helps with identifying appropriate interface footprints (which are easier to reuse by new consumers) and it helps with analyzing the impact of information model changes on service interfaces (versioning).

Chapter 6 looks at the design of service interfaces. This chapter reviews interaction styles and provides step-by-step design guidelines to help with each aspect of the service: documents, operations, exceptions...

Chapter 7 provides service implementation guidelines based on a Service Architecture which includes:

  • Service Interface Layer
  • Service Business Layer
  • Resource Access Layer

In particular, the authors provide the detailed responsibilities of each of these layers.

Chapter 7 looks at Service Composition.

Service Composition is one of the great benefits of using SOA

The chapter covers the Architecture Models of service composition as well as the different implementation models which include: plain old code, service component architecture, event-based and orchestration-based composition. The chapter also provides an in-depth discussion about the relationships between compositions and business rules, transactions and human activities. 

Chapter 9 shifts gears and focuses on using services to build enterprise solutions. This topic remains one of the least understood amongst architects and analysts.

Building enterprise solutions typically requires leveraging existing enterprise applications for service implementations and combining multiple existing services into enterprise solutions.

The authors offer an adaptation of the Model-View-Controller pattern as the foundation of the architecture of Service Oriented Enterprise Solutions. The chapter also offers important discussion on service versioning, security, exception handling and logging, and management and monitoring, which are all important aspects of enterprise solutions.  

Integration is an important part of SOA. Chapter 10 is dedicated at exploring the role that integration plays in SOA. The authors identify several "islands" that require some levels of integration:

  • Islands of data
  • Islands of automation
  • Islands of security

In the authors' opinion, the role of SOA is to rationalize information, activities and identities to enable existing and new consumers to reuse functionality from legacy systems of record and properly align their state. The chapter provides several patterns which can be used to efficiently implement services from legacy systems.

Chapter 11 introduces the concepts of SOA security. The authors start by providing a thorough introduction to the WS-Security standards and discuss important topics such as auditing, authorization and user identity propagation.

Chapter 12 concludes this section with an practical SOA governance and service lifecycle framework. This chapter provides in depth knowledge to identify, implement, deploy, operate and version service. The authors introduce the OMG's Reusable Assets Specification (RAS) that can potentially be used to capture metadata about services. The chapter also covers run-time policies.

The last section introduces two use cases:

  • Travel Insurance
  • Service-Based Integration in Insurance

Each use case is developed in depth with a sample of each artifacts recommended in the previous section of the book. These use cases represent state-of-the-art SOA implementation of enterprise class solutions.

Applied SOA represent a complete introduction to SOA with practical steps to set up an organization capable of delivering complex service oriented solutions.

Rate this Article