Over a million developers have joined DZone.

Getting SOA Right – Thinking Beyond 'The Right Angles'

DZone's Guide to

Getting SOA Right – Thinking Beyond 'The Right Angles'

· Integration Zone
Free Resource

Share, secure, distribute, control, and monetize your APIs with the platform built with performance, time-to-value, and growth in mind. Free 90-day trial of 3Scale by Red Hat

There was a time when Service Oriented Architecture was a buzzword. That time is now long gone, and SOA has become one of the essentials of enterprise software architecture. Due to the adaptation of SOA by many leading enterprises (such as Facebook, Amazon) and software systems, there is a trend of everyone wanting to be ‘service oriented’. Engineers talk about building web services, JSON services, RESTful APIs, but a significant number of them have been mislead by various misnomers (no pun intended) regarding SOA.

SOA is based on a concept which is inline with the basics of object orientation, and component based software engineering. What it advocates is to build services that focuses on a specific functionality (thus coherent), and to have a well defined API, backed by an encapsulated implementation. There’s more to it (and above sentence does no justice to SOA, I agree), but that’s the basic idea behind SOA. This might be one reason why Gregor Hohpe calls it ‘Same Old Architecture’ [1]. However, this simplicity is often mistaken, and solutions which are not at all SOA are labelled as SOA today.

One of the nicest descriptions of SOA is the one circulated by Jeff Bezos, CEO of Amazon within his organization. Steve Yegge, who was an ex-amazonian and currently works for Google, wrote and amazing article about how well Amazon developed their platform in a SOA way, and how Google should improve on the platforming and SOA front. Yes, you heard that right. Even Google, the tech-giant is yet to learn the right use of SOA. Steve’s post was supposed to be published in an internal blog of Google, but he mistakenly published it in his public blog (which was withdrawn later). If you are interested, you can still read it at http://news.ycombinator.com/item?id=3101876 (which is a very insightful article).

Coming back to the topic, Jeff Bezos circulated the following at Amazon around 2002, when he decided that Amazon should build a platform. He never said it’s SOA, and he didn’t care about technology. Yet it worked, and transformed Amazon to the massive services platform it is today. Bezos said,

  1. All teams will henceforth expose their data and functionality through service interfaces.
  2. Teams must communicate with each other through these interfaces.
  3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
  4. It doesn’t matter what technology they use. HTTP, Corba, Pub-Sub, custom protocols — doesn’t matter. Bezos doesn’t care.
  5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
  6. Anyone who doesn’t do this will be fired.

Above six points (or the first five) lays down the foundation for building a service oriented architecture. All communication happens through well-defined service interfaces, no exceptions. Each service is self-contained. Services are re-usable and externalizable. Another key point that should be highlighted is that ‘technology is not important’ for SOA. SOA is an architecture which can be applied for any technology.
Let’s analyze few common misnomers / mistakes with respect to SOA that is notoriously infamous among EAI community.

1. If you have ‘service’s in your architecture, You have SOA.

Take a look at the following solution diagram. This depicts a possible solution for a scenario of a hypothetical reservation system. The solution consists of three sub-systems, a user management service which is responsible for managing user accounts, authentication and authorization; a content management service which is responsible for maintaining necessary information (details, images, etc) regarding hotels and their offerings; and a core reservations sub-system which is responsible for creating room reservations and maintaining availability, etc. The Booking Engine, which is the public portal, connects with all three sub-systems via the Service APIs.

EAI - SOA Done Wrong

The reservation system needs to access information from the content management service to get details on hotels, the room types being reserved, etc. Also, the reservation system requires information regarding the user who is creating the reservation to enforce access control and authorization levels. An easier way of accessing this information is directly reading it from the data store of the other system, as shown in the below diagram. But that approach violates the 3rd point above. The reservation service accesses data stores of other services directly. Therefore, services are not self-contained, and the SOA is breached.

If we are to implement it with SOA, it could be done as follows.

EAI - SOA Done Right

It looks nice with all the right angles, but there’s more to it. In this approach, each sub-system (service) is self-contained. There are no direct reads from data stores other than the services own data store. All interactions between services is wired through the Service APIs, which are well-defined and documented. The communication between services can be mediated (ex. via an ESB) to enhance the loosely-coupled nature of the overall solution. It can be further enhanced by introducing a service registry, which can be used to register & lookup services, facilitating location independence (that is, a service need not know the exact location of a service that it depends on, it can be found in runtime by doing a service lookup n on the registry). With location independence, it is much easier to implement high availability and also high scalability.

2. SOA needs Web Services

SOA is not a technology, but an architectural style. An architectural style is an abstract guideline which suggests a set of ‘do’s and ‘don’t do’s, so that a set of design objectives can be met. Being an abstract concept, it is technology agnostic, meaning that you can use various technologies to implement it.

However, a common misnomer is that if SOA is to be implemented, web services should be used. While web services is a popular choice for implementing SOA, it can be implemented with any technology that can facilitate communication between services. For example, technologies like Google Protocol Buffers, Apache Thrift provides much faster communication than SOAP based web services. Recently, with the popularization of REST, community is widely becoming aware about this fact, and think twice before adopting ‘web services’ as the de-facto technology for SOA.

3. SOA needs ESB

Another misconception related to SOA, probably much more stronger than the previous (SOA needs Web Services), is that SOA needs to have a ESB. While it is true that SOA could benefit a lot from what an ESB has to offer (mediation, routing, transformation, enrichment, orchestration), it is not necessary to have one to implement SOA. The ESB movement has popularized the concept so much (especially by marketing hype from vendors) that it is the next thing that comes out when someone starts off a discussion on SOA. ESBs are powerful, and it is the right choice for SOA implementations in some cases, but it is not always. One should carefully evaluate the scenario to identify the requirements, and then evaluate to see whether putting up an ESB is a good idea, rather than putting up an ESB in the middle and then think of how to build SOA on top of it. The latter case is like throwing up design patterns in your solution because you want to use it, rather than because the problem at hand requires it.

4. ESB means SOA

Yet another widely (or rather wildly) speculated concept is that if you have ESB, you have SOA. Just because you throw in an ESB does not mean that your entire architecture is suddenly service oriented. Even with an ESB, it is easier to build services which are not self-contained, and you can still share data stores between services regardless whether its plugged to an ESB or not. Also, usually ESBs allow you to directly plug your data source to the ESB and expose it as a service, which is not a good approach for building up a service oriented architecture. Just by plugging in your data store to ESB will not make it a service, because there’s no business logic or business responsibility in your datastore. This is analogous to the anemic domain model.

Also, many modern ESBs (not all) are bloated with features that you would not use at all. You will be entangled in the problems introduced by ESB itself, like complex configurations, slower startup times, and so on and so forth, and loose your time dealing with the ESB, rather than focusing on your real problem at hand. ESBs today are moving towards a modular approach which is good, but that also does not come free (overhead introduced by technologies like OSGi). Also, if you believe that throwing in an ESB will bring you all the scalability, reliability, availability (and the rest of the *ilities), you are sadly mistaken, but you are not alone. EBSs won’t scale itself in reality like it does in Powerpoint [2] ; and it could be a pandora’s box in some cases, which is why Martin Folwer calls it Erroneous Spaghetti Box [2].

5. SOA is the Holy Grail of EAI

When SOA came up, it appeared to be the holy grail of Enterprise Application Integration. Years of pragmatic SOA experiences have shown that it is not. Yes, SOA is a good approach to address problems faced in integration architectures, but it has its own deficiencies. One of the key problems in SOA is debugging. You can easily plug your favorite debugger to a monothlic application and debug it, because it shares the same address space. With SOA, it is not the case. Another problem with SOA is performance. When you have to invoke multiple services to get things done (with serialization and de-serialization overheads), things are many times slower than direct method invocations. And often, when you build services, you need to have additional layers of logging and fail-safe mechanisms, security mechanisms to ensure the robustness of the solution, all of which affects the overall performance. There’s more to it, but above should be sufficient to show that SOA is not the holy-grail of EAI practice.

So in conclusion, SOA is good. But you have to carefully evaluate and see whether you really need it. If you do, there are many options for implementing a service oriented architecture, but regardless of the technology, it is crucial that you adhere to the basic concepts of SOA, which is outlined in the description by Jeff Bezos of Amazon. First of all, it is important to understand that SOA is an architectural style, not a technology. Also it is important to keep in mind that being an architectural style, it is not bound to a particular technology, like Web Services or ESBs. With that understanding, you could do a proper evaluation beyond the hype built by various vendors, and get your architecture ‘right’.

Explore the core elements of owning an API strategy and best practices for effective API programs. Download the API Owner's Manual, brought to you by 3Scale by Red Hat

java ,opinion ,architecture

Published at DZone with permission of Yohan Liyanage, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}