Service Oriented Architecture

I was talking with my friend about the direction of software development, and the topic of service oriented architecture (SOA) came up. Having never heard of this term before, I asked for some clarification. Our discussion led me to believe that it’s programming geared towards providing valued services, towards business bottom lines, towards promoting company products.

Boy was I wrong.

I understood it as all efforts centered around the business core services. From top management, to sales, to marketing, to customer service, to programming. Teams are built based on services, say a manager, a customer service staff and a programmer forming a customer facing unit.

When I did some research on Wikipedia to further my understanding, I found my grasp on the subject fatally wrong. I’ll leave you to read up on Wikipedia’s entry on service oriented architecture. There’s a sinking gut feeling as I read the entry. Let me tell you what it was later.

The first sentence already put me to sleep

Service Oriented Architecture (SOA) is an architectural style that guides all aspects of creating and using business processes, packaged as services, throughout their lifecycle, as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes loosely coupled from the operating systems and programming languages underlying those applications.

The second sentence gave a less soporific challenge

SOA represents a model in which functionality is decomposed into small, distinct units (services), which can be distributed over a network and can be combined together and reused to create business applications.

After finishing the entire entry, I found it analogous to an N-tier application. There are user interface screens and business classes and possibly data access components. A new user interface screen is created by slapping on UI controls and running functions from existing business classes. If a new function or new business class is required, then it’s written.

The service oriented architecture simply creates new applications by stringing together existing applications (or services as they’re termed).

Now I have maintained and even coded entire web applications by myself. I know what it’s like to maintain a whole bunch of business classes and know every function quite intimately. And that’s just ensuring the code works cohesively within the web application. It’s hard, but with discipline, it becomes manageable.

But are we talking about inter-application functionality?

I have to admit that this model works well for certain businesses. Social media sites like Facebook and search engines certainly benefit from the publicly exposed API. They probably can survive only if their services are exposed and easily used.

So here’s my gut feeling: It sounds like a lot of work, and the whole thing seems ready to collapse. It also require a lot of control management, as is seen by something further down the entry

using a special software tool which contains an exhaustive list of all of the services, their characteristics, and a means to record the designer’s choices which the designer can manage and the software system can consume and use at run-time.

The concept sounds wonderful. String together a unique set of services in a specific order, and you get a brand new application. I’ve programmed for 5 years, and let me tell you, I’ve never seen an application that can be dismantled into independent and reusable parts for use in creating another application. Projects and requirements are sometimes extremely specific and often need customisation.

Of course, just because I’ve never seen it working doesn’t mean it doesn’t work (that’s a lot of negatives…). I’m just saying that if a business company adopts the model, then someone at a high level has to refactor everything. And I’m not talking about code. Customer service applications, billing applications, inventory applications.

Everything has to be decomposed into independent parts and rewritten as a service. Then someone has to string them up back together to work exactly as the original applications. It’s a huge task if we’re talking about companies offering a diverse set of services and products.

Independent services require structure and well-defined limits and capabilities. It means having the courage to say no. And you know how sales people find it extremely difficult to say that word. There goes billing applications…

I think I prefer the definition my friend and I were discussing…