Tuesday, February 13, 2007

TRUE or FALSE : SOA cannot be implemented without WebServices?



If you are ready with your answer, hold on to it…. Lets validate towards the end of this note.

Last week I met with couple of my customer architects in one of the technology roadshows. When one of the researchers mentioned that SOA is much broader than a technology concept and WebServices is just one of the technology enablers, a customer architect got agitated and argued vehemently against these notions. He later summed up in an email : "my only point is that if we decide that SOA is not about technology or webservices etc, then perhaps this topic should be discussed somewhere else (not between architects and researchers) .. I apologize if I wasn’t clear." This quasi confrontation, which I think is a healthy one, triggered some thoughts in my mind the result of which is the above quiz.

Here are my thoughts …. Before going into details below, lets keep one thing in mind loud and clear: SOA (Services Oriented Architecture) is about "Sharing of Services". It’s about reusability, repeatability, and maintainability!

WebServices are NOT essential to implement SOA: if you operate in a homogenous environment. Here's my explanation ...


Most of us techies, that work on OOAD principles Java/J2EE, C++ or .NET, can clearly visualize what I am talking about. If not, here's an example: when you write code, don’t you organize repeated calls to a specific algorithm to a separate function or a method?


Now expand the thought further. While developing a comprehensive application, you must have used common exception handling and security services across multiple different modules. Do you agree that's a shared-services approach?

Now, broaden that same thought to multiple applications in an environment that is pure J2EE. Cant one application communicate with other application to leverage some of its "services". Lets take a specific example - lets consider two different applications

Application 1 - Part Inventory System written in J2EE that has a method to query the database for available inventory.

Application 2 - Spare Parts Management system under development in J2EE, requires inventory information. In this scenario, cant we leverage the query function along with the data available in Application1? So, aren't we using the shared services approach?

In the scenarios described above, reusability, repeatability and manageability led to shared-services approach which I think is the foundation of Service Oriented Approach. In my mind, service oriented thought process started and proliferated when client-server computing emerged. Later when distributed computing gained pace, much more clarity got added to service oriented thinking through shared-services approach.

The key constraint here is that we operated in a homogenous environment! When you operate within a homogeneous environment where visibility among systems is not an issue, (same OS, networking infrastructure, common communication protocol etc), two disparate application can "share-their-services"

WebServices ARE essential to implement SOA: if the environment changes to a heterogeneous one, then YES.

So, where do we use WebServices? In a heterogeneous environment that requires two different technology stacks to interoperate or where there is no visibility among systems due to enterprise boundaries. A simple example of heterogeneous environment: J2EE and .NET. An example for no-visibility situations: two J2EE systems at different enterprises that are business partners that agree to share information. Here WebServices with the concept of service-provider, service-consumer and service-directory comes into play.

To conclude, WebServices are NOT essential if SOA is thought in a visible-homogeneous environment. But, WebServices are essential in a heterogeneous technology platforms or inter-enterprise environments.

So, the answer to my question: Neither true nor false.

What do you all think?


9 comments:

Ram Ravishankar said...

A very good response and analysis to my post by Udi Dahan

http://udidahan.weblogs.us/archives/378

I'll give my response soon

pebbles said...

yeah... I agree...I guess SOA is not a "techie" concept per se...it is a top down approach of looking at business processes... if your business processes are not ready for SOA then your organization is not ready for SOA....The right person for architecting an SOA for the organization will be the bsuiness process specialist..Web-services is a technology enabler for SOA... And yeah..I agree, , there is no need of web service for homogenious application environment..but still deson't the web service makes life easier there also?...

Ram Ravishankar said...

Thanks for the visit Arun; you should also read a very good analysis and response by Udi in the link above. He took the view, like I did, on SOA only from technology implementation perspective.

Nick Wagner said...

Sorry, but I am not quite buying your webservices is SOA second part. SOA is an architecture, hence that last letter. It is not an implementation method. Web services are an implementation method for SOA, but if you write your webservices to mimic a code module or class, then you are not using sound SOA principles to build your services. With the adoption of WCF from Microsoft, we are starting to see the blurring of the line between the contract and the underlying service implementation. SOA is about the design of the granularity of the messages and how they interact with other applications and services and fufill business processes. Look at REST services. They are not SOAP webservices, but are still SOA services none the less and being used throughout the mashup world. There needs to be a undestanding of the differences between SOA and webservices so that as new technologies for SOA are adopted, the SOA design principles still hold true.

Anonymous said...

SOA has reached the point where it is meaningless - a state many IT terms enter when the term comes to mean whatever the author wants it to mean. Or when the definition becomes so mangled that it is no longer useful.

Thinking back to Gartner's original notes where the term SOA was coined (see for example SPA-401-068, SPA-401-069, both published in 1996) we realize that
a) they were observing how new systems were being built and
b) there were no web services.

Back then, and still today in some areas, CORBA was (is) the "in" technology for heterogeneous SOA. For homogeneous environments people tended to use whatever technology was on the floor.

Another difference between the old days and today is the fact that, back then, many people believed that reuse and improved governance could increase the benefits of IT investments. Today most of the discussions I hear tend to be "if we buy/implement technology X then we will have an SOA and life will be good". Occasionally someone mentions business benefits but usually as a lead in to the technology discussions

Anonymous said...

I think udi Dahan is correct though i couldn't practice it due to lack of knowledge cross language implementation.
Do somebody have some sample application to share which pracically implement what udi says(
making interface,service and communication layer seperate)

Anonymous said...

While the question of are services needed for SOA is valid and even stumps you for a second, I think it is nonsensical. Before I get a lot of hate mail, here is why

SOA by definition is based on open standards otherwise this problem was solved a long time ago with the advent of EAI tools even in a heterogeneous environment. Case in point Biztalk, Tibco, SeeBeyond etc can communicate with various canned applications through "proprietary" adapters.

You of course can enable your business processes as "services" using these EAI tools. But I want to draw a difference between MOM and SOA.

Reusability is only one benefit of SOA and as you pointed out you can acheive this today in a tightly couple environments with concepts such as OO. You really have to approach SOA more from the business perspective where you can sell it for a value. The granularity of the service also allows it to be orchestrated (mashing up several services) to solve a bigger business problem or to "up-sell" it.

Ram Ravishankar said...

Ram -
Appreciate your opinion .. no hate mails from me ;-)
..ram

Flerkin McBlerkin said...

Haha, Nice comment! ^^
lasik surgery