Simple Object Apology Protocol? Are we, maybe, moving an itsy bitsy bit too fast here?


I just read David Ing’s post on Simple Object Apology Protocol.


He’s got some interesting ideas there, but some of his conclusions seem to be based on some serious hand-waving.   One excerpt:  



I think the ‘mistake’ of the Indigo cycle was trying to move a certain way (strong typed contracts and the stack of specs on top that go with them) in advanced of what people were wanting to use at that time. There was a lot of faith that tooling would ease the complexity concerns and it looks like it didn’t pan out for enough people.

While some areas of software can be truly good new ideas, that should be pushed at people to show them a better way to do something, in the area of ‘software talking to software’ it seems particularly fraught to do something that isn’t being begged for upfront.


Now that is an interesting question: where should a vendor draw the line between supporting “what people really want” versus delivering something innovative that pushes the envelope?  Christiansen’s book “The Innovator’s Dilemma” has some insight here. A vendor in any industry that only follows the trends is liable to become an endangered species.  On the other hand, it is possible to get out ahead of the market, too.  Answering this question well always results in a delicate balancing act. 


As for the statement “[WCF] looks like it didn’t pan out for enough people.”  First, it’s a pretty fuzzy statement, so it is hard to discuss it concretely.  What does “pan out” mean anyway?  But int he spirit of open discussion we’ll assume this means “it’s not really being used very often.”  Or maybe “it’s not being adopted as fast as people thought it might.”  Are those statements true?  Honestly, at this point there is no answer to that question.   Actually, I don’t even think it is valid to guess at this point.


Let’s look at some history.  When it was introduced in February 2002, the .NET Framework was arguably the first broadly-accessible toolkit that could do web services simply. Part of its success came from the utility in Visual Studio 2002.   Since that time, there have been other toolkits and tools made available with perhaps similar ease-of-use.  And, since then, we’ve seen a steady adoption of .NET and separately, a steady increase (a “democratization”) in the use of web services.  We measure these things with worldwide surveys that we conduct repeatedly, over a long period.  So, two things:  It didn’t happen suddenly.  And the combination of tools+frameworks made it possible. 


Let’s lay those 2 things on top of WCF (“Indigo”).  WCF was first made available in December 2006.  Whoa!  Five whole months ago.  And, the release of WCF did not accompany a release of Visual Studio with an additional set of design experiences for WCF apps.  In other words, the tools lag the framework, currently.    Is it time to conclude now that “WCF didn’t pan out” ?    Ummmmmmmm….. Obviously that is a matter of opinion.  Mine is that it is a wee bit too early to make that statement.   


For Microsoft, WCF and the model it promotes (contracts, messages, etc) is a fundamental piece of infrastructure. Interop is absolutely better and easier when using WCF.   We’ll reserve judgement on whether “it panned out” until we release better tools, and until a few more years have passed.  


 

Comments (2)

  1. David Ing says:

    Hello Dino,

    Apologies for my clumsy statement ‘didn’t pan out’. To clarify, what I was more implying that was more about ‘SOAP’ as the best/single way to use WCF vs just using WCF in general (as a way to conflate a bunch of existing comm stacks) is now more in question that it was a few years ago.

    Back in the day, the mindset was that SOAP/XSD/WSDL would/could be a universal application protocol toolset, while today we are seeing lots of different ideas take shape, certainly more ‘bare’ things HTTP/POX/JSON. Contracts and mapping them to types is certainly not the same as using SOAP as the first-class WCF guy. I agree it’s too early to tell, but I am seeing less ‘bet the farm’ on SOAP than I was last year – and that’s all I meant.

    As someone that used things like WSE/1(!) in production, it’s been a while on this road for me and it has probably warped my perspective of time. I do understand though that from a ‘WCF is now shipped’ point of view, the claim is too woolly and hand-wavy. No offense intended, and thanks for reading the post.

  2. dionysos1973 says:

    Hi,

    I really don’t see why anybody would not use WCF. It has been very stable since the first betas, and I’ve been using it since then. Even if you still use plain old web services, it is still wise to use WCF because it prepares you for future requirements. And with the help of the WCF extensions for VS, it is dead simple. I know plenty of developers here in the Netherlands that use it for large-scale enterprise applications. And don’t forget the enormous effort Patterns & Practices has put in their Web Service Software Factory.