SOA in the Cloud

To name a few buzzwords, the Cloud and SOA are the ones that keep buzzing in ICT land. You'll hear sales pitches like "The Cloud is the future" and "Cloud Computing is a revolution that will define IT in the next decade" and "Only with Service-Oriented Architecture (SOA), organizations will reach the cloud".

What is the Cloud?

When we talk about "the Cloud" we are actually talking about Cloud computing. Currently, most companies and organizations maintain their own IT infrastructure. Wouldn't it be great if your organization could rent a piece of infrastructure such that the responsibility of its maintenance shifts to the side of the lessor or provider. This is especially significant when loads fluctuate and high peaks are reached. In such cases the infrastructure can be easily scaled up on demand (at least that's the general idea) without your IT-department having to take action.

Exactly this is what the whole concept of Cloud computing is all about supplying everything as a service even infrastructure. It doesn't end here as also the platform can be delivered as a service and even applications can be delivered as a service. These three delivery models form the pillars of the Cloud. Companies like Google, Amazon and the likes are already offering such services. Do you use Gmail or Google docs? Congratulations, then you've reached the Cloud!

Let's reiterate these delivery models as well as their characteristics:
1) Infrastructure as a Service (IaaS) – the raw computing and networking resources
2) Platform as a Service (PaaS) – services for developers to build new applications and services
3) Software as a Service (SaaS) – applications and business tasks rendered as services
Taken together, these are often referred to as the SPI stack as described by the National Institute of Standards and Technology (NIST).

NIST also hands us the following definition of Cloud computing:
'Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three delivery models, and four deployment models.'

Let's skip the deployment models for now. Does this definition makes sense to you?

What is SOA?

It's not easy to catch the essence of SOA in a few lines. There are many good and not so good descriptions to be found in literature. Unfortunately, there are a myriad of answers to the question "what is SOA". I'll give it a shot and give you my view on SOA. SOA is all about integrating a set of highly heterogeneous systems resulting into new governing systems and applications. It is an architecture based on solid principles and methodologies for creating software as a set of services that can cooperate. If we can expose the power of legacy systems as services then we can reuse that power as part of a (business) process. SOA is not a ready-made solution, it is an architecture and as such it takes time and effort to design and develop a system based on SOA.

SOA in the Cloud

As the Cloud is just a bunch of services, SOA is well suited for plugging all these nice services together. SOA also provides the means to seamlessly integrate internal and external services (Cloud) allowing for new configurations. SOA works best when it is perfectly aligned with the business. Currently we see that Business Process Modeling (BPM) is becoming more important in the SOA world as BPM is ideal for higher level, more ‘business’-oriented processes that can easily be shared with the business people.

As the cloud sees everything as a service let's introduce Business Process Management (BPM) as a Service (BPMaaS). Peter Fringar provides an exellent description of BPaaS:
[ BPM services represent the highest level in the Cloud services hierarchy. BPaaS provides the complete endto-end business process management needed for the creation and follow-on management of unique business processes. What’s the difference between SaaS and BPMaaS? There’s much more with BPMaaS. With SaaS offerings, a company is buying “same-old” packaged software (though initially configurable), and the “much more” goes far beyond canned “business software as usual” being put online. It goes on to creating unique business processes designed for unique and specific purposes to link together multi-company value delivery systems that in the past weren’t feasible or economical to join together. Call them “collaborative, situational business processes” if you like. Fortunately, those “canned SaaS applications” can become “participants” in unique end-toend business processes that deliver business innovation on demand to create competitive
advantage. ]

The best definition and description of an Enterprise Service Bus (ESB)

Nowadays IT integration consists of a solid Service-Oriented Architecture (SOA) where primarily web services technology is used. Many consider the Enterprise Service Bus (ESB) to be a major component of the SOA infrastructure.

The ESB is often set against other solutions, such as message brokering technologies, commonly described as hub-and-spoke. Hub-and-spoke, on the other hand, has benefits over point-to-point since the number of routes is reduced.

The hub-and-spoke model is often depicted as




The hub is right in the center of the diagram and forms the central control unit. But hey! Let's do some stretching and squeezing.



and some more!



Amazing!, suddenly we have a figure that is very close to how an ESB is commonly depicted. It appears that the ESB is just another hub-and-spoke model. How can this be? Well, first of all the distinction between an ESB and a hub-and-spoke model is incorrect and confusing. Two different issues are being addressed: the centralization of control, and the distribution of infrastructure. Both ESB and hub-and-spoke solutions centralize control of configuration, such as the routing of service interactions, the naming of services, etc. Similarly, both solutions might deploy in a simple centralized infrastructure, or in a more sophisticated, distributed manner. In fact, if the Hub-and-spoke model has these features it is essentially an ESB.

Now let us iterate the main principles that SOA relies on:
● Explicit implementation-independent interfaces to define services.
● Communication protocols that offer location transparency and
interoperability.
● Services that encapsulate reusable business functions.

Where does the ESB step-in?
The ESB enables the infrastructure, at the most basic level. The ESB provides the capabilities to route and deliver service requests to the correct service provider. The ESB supports the substitution of one service implementation by another with no effect to the clients of that service.
This requires not only that the service interfaces be specified according to SOA principles, but also that the ESB allows client code to invoke services in a manner independent of the service location and the communication protocol involved. Such service routing and substitution are amongst the many capabilities of the ESB.

So what are the minimum capabilities of an ESB? The following list sums it up.
● Routing and addressing services providing location transparency
● An administration capability to control service addressing and naming
● At least one form of messaging paradigm (for example, request / response, publish / subscribe, and so forth)
● Support for at least one transport protocol that is or can be made widely available
● Support for multiple means of integration to service providers, such as web services, asynchronous messaging, adaptors, and so forth.
● An open and implementation-independent service messaging and interfacing model, that should isolate application code from the specifics of routing services and transport protocols, and allow service implementations to be substituted.

If this seems a little too technical then a quote might be interesting.
Stuart Ransom, a vice president at Sonic Software, described the minimum requirements — the ESB table stakes as he put it — as messaging, transformation and routing.

That's consistent with Gartner's ESB definition, which the firm developed in late 2002.

The messaging layer — the Bus (B) in ESB — provides an intermediary through which applications can communicate. Transformation involves mapping data to a format that both sending and receiving applications can use. Routing helps deposit a message at the proper destination.

Finally remember, an ESB is an architecture not a product.

It's the data stupid!

Object orientation has been around for a long time and seems the de facto standard for any new development project. It has helped the development community to develop reusable components, replacing `good old’ procedural designed software. This software was hard to maintain and, except for useful libraries, was far from reusable.
Having arrived in the `age’ of SOA the focus has shifted from reusable components to business processes and reuse of services. In essence SOA is about the flow of data inside a business process across several services.

The figure shows a simple business process.
There are two services used in this business process: [DetermineInvoices] and [Deliverproducts]. The state of the process between services is determined by the data that flowed from the service DetermineInvoices. One can say that the process is data-driven. Many of the services will be implemented in an object oriented language but the business-process is only interested in the service response, which is just structured data. The process is ignorant regarding the object structure serving up the service.

This leads us to the question whether the services should actually be build according to an OO design. Do we really need living objects when the sole responsibility of the service is to transfer the requested data to their destiny? There is really no user interaction on the instantiated objects during a service request so why bother having those objects around? Only when dealing with an user-interface living objects are really handy, as we can modify them, turn them around, change their color and so on. This is also the place where all those wonderful design patterns find their origin. However services should be implemented as simple as possible. One could argue that changing insight will require the implementation of a true domain model, but in practice domain models never last and will most likely get corrupted with time. The data driven design is most likely much simpler and easier to implement.