Rocky,
This assessment is from an application-developer-only point of view. But the world is bigger than that. There are a lot of IT practitioners that do more than LOB apps. Look at the integration industry - it is booming. In fact - some thought leaders[1] seem to think that enabling IT to hook up their existing apps and design new ones to be easily integratable has a pretty bright future. I think you'll find that people that grok stuff like Biztalk are going to be in higher and higher demand. I think you'll see some architects and devs that "get" SO putting systems in place that are easily integratable. I also think that IBM, Microsoft, and others realize that introducing asynch and autonomy makes things much harder. But programming windows used to be pretty hard too. The next few years will see incredible innovations in making this problem easier. Saying the "Battle of SOA" is lost today is like saying DOS will win vs. those hard to program GUI things back in the 80s.
Cheers,
Ed
[1]http://www.microsoft.com/mscorp/execmail/2005/02-03interoperability.asp

I discussed my strongly held belief that SO != WS in my post at http://blogs.msdn.com/richardt/archive/2004/08/24/219871.aspx. SO is ABSOLUTELY NOT about WS. SO is abstract and independent from WS.

However, the oppoiste is true for WS. WS are modelled very much according to the principles of SO. But WS are not the only SO fruit. You can build SO systems using almost any existing technologies that exchange messages that conform to a schema between services that are expressed in a contract and which share no behavioral semantics.

Rich.

Interesting read. I completely agree that what is currently happening with web services has very little to do with SOA. But I really think that very few developers have experience with message-based systems. First thing is the interface in message-based interfaces namely consist of a single method. Like your example

result = procedure( request)

should be

result = ProcessRequest( request )

or

ProcessRequest ( request )

result and request are both xml strings. Every one that participates in the message ring has a ProcessRequest interface. SOA is about contract and content. An SOA interface is very simple, and certainly, a web service could be used to implement this, but so could DCOM, RPC, asp.net or message-queues.

I have to admit I don't "get it". Mainly to me the example looks 1: Fragile, 2: Reinventing the Wheel.

I'll tackle #2 first: I have to admit I haven't written a WS yet, so I may be wrong, but do WebMethods not allow overloads? If they do, then what's the problem with versioning the requests? If you're going to have to write extra code for one overload, or extra code for one version of a WebMethod, what's the dif?

And #1: Writing the code to serialize parameters into "messages" seems a fragile process. A client can easily get it wrong, and it's extra code that just isn't necessary with parameterized requests. Like I said I haven't actually written an in-use WS though, so perhaps my assumption that Messages are basically just serialized parameters is off-base.

I would imagine there's a lot of developers looking at it from my POV, perhaps just not getting it because we're completely ignorant of the vocabulary though?

Gentlemen,

Dont really mean to be rubbing more salt here. In my recent talks and prezzos on SOA != WS and the challenges associated with the acceptances of that in the broader business industry, I tend to sometimes throw in this slide:

"In the W3C's Web Service Glossary, you'll find service oriented architecture, or SOA, defined as "a set of components which can be invoked, and whose interface descriptions can be published and discovered."

This definition describes a group of services that work together based on common semantics. These services are modularly implemented components that can be invoked by a consumer or a client. Their interface can be identified and used with no need for knowledge of its internal design. The producer and the consumer of these services can be separated from one another, and the services can be registered so that a consumer or client can locate them either statically or dynamically in the registry.

I am sorry, but isnt even the W3C subscribed to the fact that SOA = WS ?

It sure is a long climb ahead :)

The battle was lost as soon as it began. Think about it - if it weren't for this misunderstanding it's likely neither WS nor SOA would have taken off like it has. SOA couldn't be grasped and endorsed by the suits who had to approve the projects except to always explain it in the context of WS. Everybody's talking about WS because SOA is the latest greatest thing that's going to save the world and WS comes along for the ride.

The failure of the previous attempt to right everything wrong in the world with web-based applications may also contribute. How many companies are now running internally on performance pigs because they bought into this? But now, hey they can leverage all that work by throwing on some WS in between all the layers and BAM! they've got real power and productivity!

Anyway, for fun here's the CramCession practice test question I received today via email. While the first option is technically correct, it illustrates the subtle misleading blurring that we're talking about.


...Which is NOT a characteristic of a XML Web Service?

* XML Web Services allow you to provide data to web client applications programmatically
* XML Web Services are discoverable via UDDI
* XML Web Services are web sites that provide dynamic information and web content
* XML Web Services can be created with any .NET language

I'm not an expert in message-based architectures so I'm hardly the person to comment on certain architectural symantecs being discussed in this thread, but I thought I'd chime in with my two cents, anyway.

I always understood SOA in two lights:

1) it allows for loosely-coupled systems/components to interact without having direct knowledge of the internals per se, but the consumer must have knowledge of what the results are in order to do anything useful with it. The format of the result, as I understood it, is unimportant. Could be an string of numers or words, could be an xml string containing more sophisticated data such as a datatable schema or a custom schema of sort, could be html. In any case, the consumer needs to know what to do with it and how to interpret the "expected" result format. Whether the message passed into the service is a formated xml string/schema or a set of parameters or binary is unimportant, as long as it is agreed how to get data into the service, and how to interpret responses return from the service.

2) I see webservices as a decent enabler of this technology, with respect to a medium of transport only. It doesn't matter (as I understood it) whether you open a TCP socket using some protocol to send the message and receive a BLOB and interpret the message, or whether you use an agreed XML format to send the message and an agreed XML format to recieve the response and interpret it.

Now, to my point, thus my confusion in this thread: If the service resembles an object, or an API, does that make it less of a service than if it was purely message-based? If I need functionality to verify a full address from a USPTO "service" does it really matter what format I pass my address in and how I interpret the true/false reponse, whether it is WS-based or TCP/IP based, or some sort of html request/response based? What if I need to consume a service from the Social Security agency to indicate whether a SSN is authentic? Or the IRS to indicate of an EID is authentic? Or more complex, if I'm partnering with Amazon and consuming some "services" that allow me to do whatever they allow me to do with the service?

What I don't understand is how does message-based vs. WS (SOAP?) based services make a difference in the service world?

Now... what I do understand is that the way many WS are implemented do in fact require you to understand the archiecture of the service, or more closely resemble an API or sorts, that's where I believe it becomes more-or-less RPC based, as Rocky described.

Pardon me if I got it all wrong, but somehow I think I'm seeing a deeper picture with SOA and some incredible potential, and just don't know how to put my finger on it. Too much hype and bad examples out there coupled with what I think is lack of true understanding of what problem it is trying to solve and how to deliver the solution.

Thanks,
Shawn