(Microsoft != Web Services && Web Services != SOA)

I'm trying a new tactic with the blog. I've added my brother Matt to make this a team blog. hopefully he can help me in keeping posts pretty regular. I think I've first thought about having him make posts about web services, but we may end up just co-blogging on web services and open source.

now, I read an interesting opinion. I'm all for healthy skepticism and realism, but Fergesun isn't offering a good deal of either. the "tone" of his writing seems more like whining than real criticism.

he first shows his Microsoft fanboy side with this whopper:

"Web services are great! If you have to interoperate with non-Microsoft systems, they may be your only option."

now, even if one doesn't hate Microsoft, one would have to have their head buried pretty far into the sand to ignore the growing interest among enterprises in running platform-neutral software systems. hell, Java's popularity is largely a result of that single capability. I think it's a pretty safe assumption that if you're building software that will handle any meaningful amount of a company's business, you're going to need (or at least want) to interoperate with other systems in the company - be they non-Microsoft, non-.Net, non-Windows, non-American, non-Expensive, non-UnderYourTotalProprietaryControl, etc.

and his last direct quote I'd like to deal with:

"What I do not buy into is the idea that all systems should be seen either as services that expose their functionality only via unidirectional XML messaging or as clients of such systems."

well, news flash to Mr. Fergesun, "unidirectional XML messaging" is not SOA. what you've described is Web Services, though even web services are growing out of the unidirectional phase. while most SOA proponents think Web Services are the best means to achieving SOA, the two terms are not synonymous. so I'll be sure to make note when Fregesun is criticizing a technical aspect of Web Services that is not intrinsic in every SOA architecture.

Fergesun's problems listed are the "change in thinking" that comes along with asynchronous system operations, versioning, and reliability. in all of these cases, he mistakes Web Services as the only means to SOA, and furthermore, his Microsoft-centric perspective keeps him from seeing how these problems are actually addressed by web services.

in mentioning asynchronous operations, Fergesun ignores the fact that SOA != Web Services. it is entirely plausible to build service-oriented software that communicates via synchronous protocols. however, there is a very good case already made(by someone much smarter than myself) that asynchronous architecture is more appropriate for modern systems - that is, highly networked systems using the internet as their core platform. but Fergesun does not mention any of the merits of asynchronous architecture; he only laments the need of a "change in thinking." perhaps if Microsoft had written a white-paper on the subject and released Microsoft Change-In-Thinking XP, he would be more willing to buy...er, accept change.

as far as versioning goes, the .NET CLR approach does not alleviate versioning problems, it only changes them to be more like Java-on-Windows (other platforms, if you're crafty). for example, if your program requires functionality that is in 1.1 of the .NET framework and not in 1.0, you have to upgrade your .NET CLR to 1.1. (note: I came across this gem while searching for 'web services versioning' and literally laughed out loud.) the CLR approach might avoid "DLL Hell" but is that really of huge benefit? I know one of the things I like about Lx (and php, to a lesser extent) is being able to upgrade only certain components to enable new features, rather than having to buy/download/upgrade to the latest version of dozens of packages all at once that may or may not break my other code relying on them.

but back to the world of Web Services (again remembering SOA could actually be achieved without Web Services, even with completely proprietary .NET system architecture)...

UDDI is the (open-standards-based, non-proprietary) means to address the versioning and deployment of web services, and there are already a good deal of introductory methods for the practice. so we find that UDDI is the out-of-the-box standard for versioning web services. perhaps if Microsoft isn't on the ball with it, there's a problem with Microsoft. it typically happens that they will try to create an out-of-the-box tool instead of a standard - perhaps a nice little .NET Deployment Wizard that will be released in late 20X6.

since Fergesun makes only passing mention of the reliability "problem" with web services (again, not equivalent to SOA), I'll only make this link as my passing rebuttal.

Finally, I will close, mirror of Fergesun, with the eternal benefits of all new software technologies - revolutionary new productivity, nearly-infinite opportunity, vast new markets for new products, and perhaps most importantly, independence from proprietary legacy vendors.

I may be giving Derek too hard of a time, because I've not read up on his other posts. but my guess is that this editorial post was meant to kick up controversy and "pick a fight." in that he has succeeded. but in providing real criticism or insightful analysis of SOA's "problems," he has failed - largely because he has only criticized web services, and only web services development from a Microsoft perspective.

Greetings

How nice to be invited in here. Here's my WS comment for the day:

In the raging war between microsoft and massachussets, I hear a lot about XML being an "open enough" standard to provide the interop benefits sought by the commonwealth. This, in my opinion, is a case of trying to buzzword a problem away. So any WS afficionados who are all excited about MS Office XML being the default format for Office 12/Vista, take note:

(disclaimer: I don't pretend to know nearly as much about this as many others do)

-MS XML can contain binary objects that depend on MS Office and Windows.

Which is a pretty uncomfortable fact, w/r/t the Whole Point of webservices, viz: "to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer" (src). That is to say, if Office really wraps up your doc in well-formed XML, it's great 'cause you'll get some sort of response back from any WS that asks about it.

But if the response is -- more or less -- "There's no telling what's in here", then I don't see the big fat advantage. So before we all celebrate the use of XML in Office 12, maybe look closely at how it is used. In my opinion, it's mostly used to keep trendy.

(Yes, if you haven't figured it out I'm the resident raving anti-microsofty here at WS-Comments. Future posts will be more on-topic, though. I promise.)

erl @ WSJ

I can't find it online, but T. Erl wrote what I hope is an introductory-type article to his new book. I appreciate that he makes an attempt to talk about SOA in a vendor-neutral standpoint, and I think WSJ is pretty good about being agnostic with regard to this or that vendor's marketing hype.

Erl:

"Its popularity to date is largely the result of vendors advertising SOA support or capability as part of their product lines. Because SOA has been so vendor-driven, its meaning has been somewhat divergent, skewed by proprietary technology that is...identified with common characteristics that transcend proprietary boundaries."

and

"Vendors...have published numerous papers, blueprints, and even frameworks. Most such document serve the dual purpose of educating readers about SOA while marketing related products or services. This is nothing new...However, because a core expectation of SOA is its ability to harmonize and streamline diverse technical environments, preserving an abstract viewpoint is required to achieving its potential." (emphasis mine)

He talks a bit about Service Orientation (SO) and Object Orientation - they are tantamount in pursuing "separation of concerns," but with different approaches. In describing SO's approach, he describes 8 common principles of SO that should be considered and encouraged when designing systems on any platform, regardless of vendor/language. (Sun/J2EE, MS/.NET, Zend/PHP, etc)

I hate that vendors often prattle on about SOA without actually saying anything. But Erl may be too much on the other extreme - describing SOA in such idealistic technical terms that it escapes any relation to real down-to-earth, or in-the-trenches, programming. his first book was okay in providing example situations and scenarios, but he never seems to go into any run-time code detail, instead focusing only on the XML syntax of the various WS-* techs.

when I create my uber-l33t service-oriented system, I'll be sure to write an entire book/dissertation/case-study on it down to the code level. hopefully I will show the link between the SO common principles and the SO code. that is, as soon as I write and master the SO code. here's hoping...

gates is losing his mind

I feel relatively entitle to comment on this, because Gates talks a bit about software-as-a-service and, somewhat unintentionally, web services. that being said, my first comment goes something like this:

being a dilatant is not necessarily a bad thing, but having a dilating business model is completely FUBAR.


in this interview (supposedly about Google, but mostly about whatever pops into Gates's head), Gates manages to one-line the following topics:

Google
software-as-a-service (almost web services)
open source
CRM
Voice Recognition
IPTV

I'd first like to talk about Google because I'm currently on the "honeymoon" WITH Google, and I like how our life-long relationship is starting.

Responding to the question, "Do you feel you're in competition with Google, Yahoo and other Web properties for developers' attention?"

Gates: "No, I don't think so. The architecture we are interested in we call server-equals-service, so that we will have the full Exchange capability that you can subscribe to, where we run it, or you can have it on-premise with the traditional licensing approach. At this conference, we do give out APIs (application programming interfaces) for the MSN Search and the MSN Virtual Earth capability, so things that have been cloud-based services, you can have client applications that other services can connect to. So, I'd say the evolution is server to service, and bringing that symmetry in."

in what I imagine could only have been about 10 seconds, Bill has moved from the topics of "web as a platform" and "developers' attention" to Microsoft Exchange Server. this is pretty formulaic of a Microsoft response to any question or comment relating to anything in the software industry that's NOT Microsoft - quickly and baselessly brush aside whatever meaningful question was asked, and then prattle on about Microsoft ______ XP like it's the answer to every question, meaningful or not. his innovative idea (which I guess he's trying to relate to "web-as-a-platform") is one in which you pay Microsoft to host the physical machine on which your Exchange server runs? I'm not an expert, but I think this kind of "virtual hosting" has been around at least since last year or so. also of interesting note is that the service-like API's to those MSN features were only just released last week.

this post is being cut short because some major news re: Microsoft hit while I was writing this, so I have to write the follow-up post now.