snellspace : a perfect world spoiled by reality

Friday, April 12, 2002

One last parting thought to leave on Vacation with..... what if the Google API could be leveraged to find Web services?  Google could index WS-Inspection documents as it crawls the Web.  A search option flag could be created to return only Web services that match the query.... just something to think about....

Talk to y'all in two weeks.


5:05:34 PM    

What would a two-way Google API look like? A simple exploration.

4:46:14 PM    

EVHEAD: "Think again. Dan Shafer writes, "...if you're not Microsoft or maybe IBM/Sun with Java, development tool makers don't stand a chance against good Open Source projects." The first thing that comes to mind is one of my favorite programs, Visual SlickEdit, a kick-ass, award-winning programming tool made by SlickEdit Inc. in Morrisville, North Carolina. "  There's also XML Spy, Rational (who developed an empire prior to going the open source route with Eclipse), Macromedia, and a long list of others. 
3:07:29 PM    

Wow, Sam must be pretty upset that I disagree with him over the WSDL version issue, he removed me from his navigation link list and his current subscriptions.  I guess I've just been blacklisted.
1:30:44 PM    

In off-blog communication, Sam and I seemed to have agreed to disagree. Here is the basic recap of my position:

  • New versions of a Web service interface should be declared in their own namespace.
  • It is possible to design a Web service interface so that the addition/modification of parameters/operations do not require a change to the interface, and therefore do not require a new interface namespace. You avoid WSDL Hell (the web service equivalent to DLL Hell) through proper consideration of expected change requirements BEFORE you publish your interface, not after.
  • You can achieve the same results Sam expects simply by taking more time to properly design the interface and the underlying implementation so that change is expected and dealt with. 
  • To achieve the type of flexibility Sam wants, you have to design it into the system -- it does not happen on it's own. 
  • There is no single recipe for how to cope with change.  Each situation is different and you deal with it on a case by case basis.  General patterns will emerge over time and you apply those patterns where it makes the most sense to apply them.
  • The technique I offered in Patterns of Change 2 is completely compatible with what Sam suggests in Coping with Change.  In fact, my technique details one method of actually realizing what Sam is suggesting.

That's it.  Hope y'all had fun.  :-)

1:17:54 PM    


12:11:17 PM    

Sam Ruby: "What I described in Coping with Change is not related to late binding or IDispatch. It is all about things - even early bound things - continuing to work after change."

Alas, communication is a difficult thing.  The reference to IDispatch was metaphorical. What you talk about is an approach that very much resembles the scripting and IDispatch way of doing things.  Think metaphorical, not literal.

Several points from your doc:

"If you have a protocol which is designed to support named parameter associations, adding a new parameter is easy.  One merely requires the recipient to match the actual parameters to the arguments that they were expecting, to ignore anything they do not understand, and provide reasonable defaults for anything that they were expecting that they do not receive. "


"Once you accept that interfaces may change over time, you will soon see the need for some level of metadata in order to aid discovery. XML schema can be embedded in the message to make the content self defining. Or it can be contained in a separate document (e.g.., WSDL). "


"As a general rule, the more metadata the better."

The point that sticks out here is: Your technique works without runtime metadata (early binding), but it works best if there is runtime metadata (late binding).  Who cares if the metadata is included in the SOAP message, a WSDL document, or anywhere else.  Your talking about a programming style.  I'm talking about a design style.  Two different things.  I say again: we're looking at this from two different points of view.  They are not mutually exclusive to one another. 

The original discussion is about how to best treat WSDL interface descriptions through multiple iterations.  The technique I describe in Patterns of Change 1 & 2 is one method of achieving exactly the type of thing you are talking about in Coping with Change using a strongly typed WSDL interface description that is capable of being extended dynamically without changing the underlying interface. 

Go back and look at the example.  New operations and new parameters (or modified operations and modified parameters) can be added to the service ad infinitum without ever having to change the WSDL interface.  The requester and provider can then choose to support whichever combination operations and parameters they wish.  If the client sends a request to the server that the server doesn't support, the server can either throw an error or ignore it.  If the server responds with data that the client doesn't understand, the client can throw an error or ignore it.  The point is, the interface description supports type safe evolution by design. 

To explain the IDispatch metaphor a bit more, let's look at how your scenario would be realized in pre code:

Two ways in the old VB to allow extensible parameters (e.g. the ability to add a title parameter)

  • Sub PostItem(String body, Optional String title)
  • Sub PostItem(ParamArray options() as Variant)

The first allows for named parameters, the second allows for unnamed parameters.  A COM scripting client doesn't really care which is used. Because it uses IDispatch under the covers, it is provided the necessary metadata at runtime (metaphorical equivalent to loading the WSDL or putting a schema in the request/response) it can cope with the change.  Early bound clients can support this as well, but it takes more work.

The approach I suggest, however, looks something like (switching to Java now)

  • public CommandResponse doCommand(CommandRequest command)

CommandRequest is completely flexible.  Not only can the server/client support/ignore/reject new parameters, but entirely new operations, and multiple even versions of operations.  We achieve the result you describe while still promoting good interface design. 

Anyway, that's it, I'm getting ready to go on vacation now.

9:39:23 AM    

8:03:52 AM    

Patterns of Change Part 2. A detailed example illustrating the concepts discussed in part 1.  Evolution by Design.
12:23:27 AM    

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