SOA at First Glance

Posted on | 24 November 2006 | No Comments
Tags: soa

Introduction
Lately, I’ve found myself immersed in the world of integration, or Enterprise Application Integration (EAI). Coming from a programming background, EAI is literally a different world. The difference is whether the focus is on building your own software or integrating other people’s software. In the programming world, the hot topic of the day is Service Oriented Architecture (SOA), supposedly the solution to the integration problem. As I investigated the SOA story, I found that it seems to come with an overabundance of terms and acronyms, as if to say, look what a difficult problem this is. I finally got to the point where they don’t cause my head to spin. In this article, I will try to cut through the fog and introduce these terms that came flying at me during my research. I will try to do so from a programmer’s perspective, as opposed to an integrator’s or client’s perspective.

Motivations for SOA
As applications get bigger and more mature, and as companies have more and more vested investment in various software packages such as CRMs, there is a motivation to not reinvent the wheel and instead, focus on reusing existing software. To the business, reuse equals cutting of costs, which is music to the ears. From a technical point of view, SOA abstracts away the age old question of programming language and platform. The key word is interoperability. Let’s not fight over Java or .NET or PHP. XML is the language and what’s more, it’s (mostly) human readable.

Messaging
Traditionally, integration of software has been implemented using Remote Procedure Call (RPC), passing data in binary form as opposed to XML. Nowadays, the way to connect software is via messenging. In such an architecture, messages are passed around on a Enterprise Service Bus (ESB), which is the messaging framework that abstracts over the transporting medium. At the very least, ESB provides routing, security, transformation, and validation.

Web Service
Not every service is a web service. To me, a service is closely related to an interface, which is an abstraction on the underlying implementation of a functionality. A service’s interface can be any contract between the software vendors, but in a SOA environment, they are in XML form. And if the interface conforms to a SOAP (Simple Object Access Protocol) or REST (Representational State Transfer) message and comes with a WSDL (Web Services Description Language), then it is considered a web service. There is an open industry initiative to make a registry of available services called UDDI (Universal Description Discovery and Integration). Services can be discovered either at design time or runtime.

Process-Driven Development
Traditional approaches to EAI had been to create an entire application stack that encompassed the various software as underlying components. In contrast, applications within a SOA are designed according to business processes, as opposed to the IT infrastructure. A SOA application enables the workflow of a document instance or task through a business process. To me, a workflow is a state machine of an instance and can be modelled as such in a UML state diagram. The efforts of a company to streamline their business processes is called Business Process Management (BPM). And lately, SOA has become part of the BPM effort. BPEL (Business Process Execution Language) is used to describe the business processes in an abstract (XML) fashion and used to orchestrate the web services that are used.

Vendors
A number of vendors have popped up who claim to provide everything you need to implement a SOA-based application. The front-runners are old-timer Tibco, marketleaders in software like IBM, BEA, and even Oracle, who come from more of an application server background and who have to opportunity to sell their SOA framework to their existing customers and partners, and newcomers like Cordys, who by virtue of having designed from scratch probably has the most well-thought-out technology.

Summary
In this article, I spoke about the motivation for the move to SOA, tied together the terms that are often heard together with SOA. The terms play a part of the technology used within a SOA application and the process by which the applications are developed. Lastly, I named some vendors that provide frameworks to develop SOA applications. The list should be many more and I will add to it as I discover them.

What’s Next
Just at first glance, I had to use more than 10 acronyms just to tell the story. In the next article, I will share what I discovered about SOA governance, which is a fancy term for organizations to keep track of what is going on in their SOA applications. Governance will easily lend to the subject of testing and monitoring. Furthermore, I will discuss how the right balance needs to be reached all the more in a SOA environment between business and IT concerns.

Comments