Donnerstag, 6. März 2003

Sam defends WSDL (but doesn't try too hard :)

In defense of WSDL. Clemens Vasters: Why I want WSDL to die. I agree in principle with the sentiments expressed in this excellent rant. It is the execution and details that things become problematic. What actually concerns me more that the (valid, IMHO) irritations that Clemens so eloquently describes is the process of getting consensus and widespread adoption of any new format.

There also is one important aspect that Clemens seems to have overlooked, which I will generically refer to as bindings. When doing SOAP using XML over HTTP, a URI and a SOAPAction are required. Non HTTP and non pointy-bracket serializations of the XML Infoset should also be supportable. A concrete example: a binary message sent over MQSeries may be a vital part of a flow of business process.

[Sam Ruby]

I was hoping Sam would pick this up :) What I am (not clear enough) saying is that bindings are not the job of the primary contract description in the presence of routing. First, I want SoapAction: to die with WSDL and see all SOAP stacks dispatch on the message and not on information that's not even part of the message. Second, when you go and pick up the schema, you are going to pick up the policy and there you should also be able to pick up a WS-Referral instance (or whatever that'll turn into when the current wave of specs is complete). There you have the endpoint binding. That's essential, because before I can submit to your MQSeries, I will talk to my MSMQ and (implicitly) ask it to drop it into Host Integration Server that'll drop it into your MQSeries queue and therefore your MQSeries binding won't be of much immediate help to me.

5:14:45 PM      comments []

Why I want WSDL to die.

Frequent readers of this blog, people who've seen my Web Services demos and those who downloaded the source for my ASP.NET SoapExtensions (yet another link) know that I am pretty serious about supporting the WSDL features that are there.

Whenever you plug a security feature or a transaction feature or a session feature into the ASP.NET pipeline using one of my SoapExtension attributes, I will make sure that the WSDL gets properly augmented, and that all the schemas and headers get emitted in the right places (which most SoapExtensions don't do because the documentation is suboptimal, at best). I will also make sure that the client portion will evaluate the format extensions emitted into WSDL and code-generate the necessary client extensions by hooking into VS.NET or wsdl.exe. The goal is that the effort to implement the services part of an end-to-end solution that is secure, promotes TIP transactions and is session aware will be close to zero. I strongly believe in "ease of use" there - even complex (read: powerful and serious) web services should not need to be complicated to build. I am using the expressiveness of WSDL to carry as much metadata as I can to make that work. The goal of my extensions is to make and carry that statement and provide an example of how to do implement it.

So, I hereby declare myself as an expert on that matter ;)  Based on what I've seen WSDL do for me and looking at what's been evolving in the WS-* spec realm lately, I want it to die. I think its time is up and we no longer need it and I believe it will cause more problems than provide solutions moving forward. Here are a few questions illustrating why:

  • Show me a good reason for why I would want to have a <wsdl:message> element that contains more than a single reference to an XSD element definition. Examples of <wsdl:message> with multiple elements sidestep <xsd:complexType>. If 1:1 mappings from <wsdl:input> to <wsdl:message> and <wsdl:message> to schema is what's left to keep things conherent, why have it? (I respect that there are other schema languages, read on)
  • Show me a good reason for why I would want to maintain a flat "interface" notion where I have a fixed set of operations bound to a single endpoint. Either an endpoint "accepts more" as per Sam Ruby's mantra or an endpoint accepts a single well-defined thing. The "interface" idea is a remainder of the thinking of IDL compilers that had to emit a compilable chunk of code. A web service endpoint should be either a "little yellow thing" (or for the US: a "little blue thing") that acts like a mailbox and happily accepts any letter and deals with its out-of-band metadata (a router or dispatcher would do that) or it is something that understands a single semantically well understood message that may be expressed based one of multiple supported schema variants (--> REST folks, here you go.). "Interfaces" in a web services world must be dynamic, regroupable "business process endpoint" definitions that group all endpoints that are part of a message exchange pattern. One endpoint can be part of many business processes. The "interface" notion doesn't work on that level. It's a code-driven thing, not a service- and data-driven thing.
  • Show me a good reason for why I would want to put a single header-reference into an operation binding if most protocol extensions (WS-Security) cry out loud for a flexible policy mechanism as defined by WS-Policy, anyways. If I decide that the transport for my SOAP package is going to be a message queue, I probably don't want to do message-level reliable messaging control, because that'd mean overhead and I sure need it for HTTP. How do I express such choices in WSDL where the "required"ness of a header depends on the underlying transport? I can't. It's going to be wrong either way. If I rely fully on WS-Policy and don't declare my headers, the WSDL is invalid.
  • Show me a good way to express <wsdl:service> in the presence of WS-Routing. In short, you can't. At the time of (early) binding, you get an endpoint reference that may go away the next minute, while your next routing hop may very well know where it went. And how do I bind to a service that I can't see but which I only can route to? Will every router have to be able to proxy and provide an adjusted version of any WSDL that lurks behind it so that the <wsdl:service> binding is accurate?
  • Speaking of routers; in the presence of WS-Routing all <wsdl:operation> header information will be void once you get switched over to an intermediary that requires additional out-of-band information such as authentication in its role. You can request a router's WS-Policy dynamically and act on it, but do you really want to dynamically rebind to an intermediary's mod'ded version of a foreign WSDL? Why have two dynamic things to look at?

What's left then? This:

<operation name="ReserveSeat">
<input message="res:ReserveSeatInput" /> 
   <output message="res:ReserveSeatInput" /> 

which could easily be expressed by augmenting XSD properly:

<?xml version="1.0" encoding="utf-8" ?>
s:schema xmlns:s="" elementFormDefault="qualified"
<s:element operations:operation="ReserveSeat" operations:direction="input" name="ReserveSeatInput">
<s:element minOccurs="0" maxOccurs="1" name="Airline" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="FlightNumber" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="Row" type="s:int" />
<s:element minOccurs="0" maxOccurs="1" name="Seat" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="DepartureAirport" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="DepartureTime" type="s:dateTime" />
<s:element minOccurs="0" maxOccurs="1" name="ArrivalAirport" type="s:string" />
s:element operations:operation="ReserveSeat" operations:direction="output" name="ReserveSeatOutput">
<s:element minOccurs="0" maxOccurs="1" name="ReserveSeatResult" type="s:string" />
<s:element operations:operation="ReserveSeatVariant1" operations:direction="input"
name="ReserveSeatVariant1Input" ref="ReserveSeatInput" />

In the end, all I want is to know is a set of augmented schemas that an endpoint understands and can make sense of, some metadata to map that properly into a client-side and server-side (sum that up as "endpoint side") programming model and information about the policies that the endpoint and any intermediary on the route want to enforce and that I need to respect. XSD and about any other schema format will allow the former, WS-Policy takes care of the latter. WS-Routing (and what it'll turn into very soon) will take care of finding and dispatching to the appropriate service endpoint. Dump WSDL.

(Hint: From such annotated schema, WSDL is just an XSLT transform away in case you're worried about backwards compatibility)

1:00:17 PM      comments []

Instant Love

On the surface, InfoPath is "just" a forms editor that allows you to build editable Forms for XML Schema, Web Services and Databases very quickly. From a technology perspective that's very cool in itself, but the way InfoPath hides all of that behind its UI will simply make you say "Well, yes, that's how it should be". It's really a no-nonsense data-capture and data-presentation centric variation of what could have been yet another feature of FrontPage that few people would have ever noticed, just because it's UI is so simple. It's all Office.

The actual power of InfoPath lures in the details:

  • When you design a form based on an XML Schema, and fill out that form later, the document that you'll save will be a pure XML document instance of the exact underlying schema, without any other goo. InfoPath will only associate the instance with itself by injecting a processing instruction.
  • InfoPath understands XML Schema type restrictions, validates them and gives you red frames on fields that are wrong. It spell-checks and gives you red squiggles for misspelled words. It gives you repeating edit regions for arrays of complex types. It gives you date pickers for dates. It gives you combo-boxes for enums.
  • When you "export" a form template (whose native storage format is, inexplicably, binary), you will find an XSLT innocently hanging out in your output directory. That stylesheet is capable of rendering an XML instance of the underlying schema to a proper DHTML page that is visually (and functionally) equivalent to the form you've designed.
  • You can submit a filled out form to a file or to a web service; however, most importantly, you can submit to a Windows Scripting Host script (JScript/VBScript). Which means that you could smuggle (for instance) a COM/Interopped managed pipeline underneath it (think WSE) that will wrap the payload into an envelope and add all the current and essential web services stuff to it. Or you could submit to a disconnected message queue on a client and have a server do the processing for forwarding your data into a service-oriented bus. Or you could drop stuff into BizTalk.

Here's stuff that I wish that InfoPath was that it isn't:

  • I want (very very much!) and you all want InfoPath to be a reusable component. By all I can see now, it isn't an ActiveDocument server or an ActiveX control or has a reusable Windows Forms component.
  • I want InfoPath to be a dev tool. I want to use it with C# and VB.NET and NetCOBOL and Eiffel -- not just with Script.
  • I don't want InfoPath to be part of Office only. I want and InfoPath "filler" app. InfoPath deserves to be an integral part of Visual Studio!

On Tuesday, I hijacked the Q&A portion of one of my talks in Helsinki/Finland to throw in a demo of InfoPath. I have never demoed any feature of Office (except PowerPoint freezing up on me). People stared at the thing in disbelief when I highlighted the potential.

Microsoft, you have a winner there: Bring it back home to where it belongs - make it a reusable thing, make it a redistributable thing, let us make it the center of our smart client apps -- make it a Dev Tool. Please.


11:41:23 AM      comments []