snellspace : a perfect world spoiled by reality


Wednesday, April 10, 2002

Simon Fell: "Sam & James have been debating this MSDN article by Scott Seely that discusses evolving SOAP / WSDL interfaces. I haven't had chance to read it yet, so will refrain from commenting, however past experience tells me that I could just agree with whatever Sam's saying, and save me the trouble of having to actually read it !"   It's not a debate, Sam and I are just seeing the issue from two different points of view, both of which are equally valid.  Given that his focus has been on runtime interoperability between toolkits and I'm coming more from a design/architecture point of view, the fact that we see things differently makes a lot of sense. 

Fact: designing Web service interfaces is a different task than ensuring that the toolkits that implement those interfaces are compatible with one another.

Regardless, blind agreement with anybody is a bad idea in any context -- even if it is the great right-more-often-than-not Sam Ruby.


10:10:31 PM    

Paul Kulchenko on SOAP::Lite: A fix for the phrack problem.
4:27:19 PM    

Sam Ruby: "cope with change just as the similar functions in other IDL languages do. Changing a namespace is not going to help when you realize that not all SOAP stacks dispatch on namespace."  What you describe is a runtime issue, not a design time one.  How a specific soap runtime dispatches messages is a separate issue than how a service interface is defined and evolved using WSDL.  Example: I can create an IDL description of an object interface and implement that in either Java or COM.  It's the same interface, but the dispatching mechanisms are going to be different.  Regardless of the dispatching mechanism, the best practice rules of IDL design still apply.  Where you run into problems is when WSDL is used as a means of dispatching requests which is why I also advocate that a clearer distinction be made between the abstract definition of a service (the message, portType and binding elements) and the concrete reference to a service implementation (the service element).


4:10:22 PM    

Rob Fahrni, at the core.: "You would think the city fathers would have enough sense to learn from the mistakes of others, but it doesn't look like they have. Urging retail to move to the extreme south of the city will do nothing but promote inner city decay. What a shame for such a beautiful city."  Rob doesn't agree that the new shopping center is a good idea.  Perhaps the location sucks, but we do need more retail business.  It sucks that a good deal of cash is spent in the next county feeding the Fresno economy when Kings and Tulare county have some of the worst unemployment rates in the country.  Sometimes it is a trade off, but yes, I probably would have tried to find a better location.
4:02:54 PM    

Rob Fahrni, at the core.: "When you can create something as useful as Visual Studio you'll have something"  VS.net is nice, so is Eclipse.
3:57:59 PM    

Rob Fahrni, at the core.: "Visalia Times: "Visalia planning commissioners gave approval -- but not a ringing endorsement -- to a massive shopping center Monday night to be built on Mooney Boulevard south of Packwood Creek." - [Hat tip Cass McNutt]"   Woo hoo!  For those of you who live in this backwoods ain't-nuttin-here-but-cows-and-cow-shit part of the state, this really is something to be happy about. 
3:53:12 PM    

Sam Ruby: "Scott Seely Evolving an Interface [Snell's Blog].  Hmmm.  If those are the rules that one should follow, then I have a hard time understanding why ASP.NET ignores values it doesn't expect and provides defaults for parameters it does expect.  One must also consider what happens when people other than the originator want to extend the interfaces.  My thoughts on the subject are captured in Coping with Change"   Personally, I am a big advocate of adding inheritence to the WSDL interface definitions (and have been ever since I did this).  Doing so would make it easier to cope with change just as the similar functions in other IDL languages do.  One challenge, however, is that WSDL's role as an IDL has never been fully developed.  I'd say that this is definitely something that needs to be dealt with in the WSDL's second coming.

Main point: WSDL needs to be treated like IDL, and must conform to the basic principles of IDL design.

Regarding the ASP.NET question: There is a distinct difference between identifying a best practice and implementing a best practice.  The tools, over time, will start to line up, but at least we know what to strive towards.  Regarding ASP.NET specifically, I would not be able to address that question as I'm not very familiar with ASP.NET in detail.


2:40:06 PM    

Evolving an Interface

Scott is right on in his discussion of how WSDL should be treated over multiple versions of a Web service interface.

  • The changes always go into a new namespace.
  • The new interface should be a superset of the old one.
  • It is a good idea to keep the data model the same when versioning the interface.
  • Never revise data structures. Instead, add new ones as needed.

I would add a couple more:

  • When creating new bindings, never change the binding style.  If your service uses "document" style, then you should continue to use "document" style in future iterations, otherwise you'll cause your users lots of hurt.
  • When creating new data types from old data types, make use of XML Schema derivation, this allows you to easily extend/restrict existing types in a type-safe way.
  • Be sure to do the magic juju dance before publishing your new interfaces to make sure the "I hope this doesn't break lots of code" Gods are pleased.

(ok, so the first two are a bit of a stretch)


11:24:58 AM    

BitWorking: "I didn't intend to start a language war between Sam, Simon and James. They have, however, been far too civil about the whole affair :-)."  Yes, it's a sad sad time when we can't muster up enough oomph to have a good flame war about our favorite programming languages.  Ah well, guess we'll have to find something else to fight about.... hmm, let's see..... any ideas?
11:03:58 AM    

3....
8:55:02 AM    



Copyright © 2002 James Snell.
Last update: 6/25/2002; 9:32:31 PM.
The views and opinions expressed on this site are solely those of the author, James Snell, and not necessarily of James' employer.