InfoPath Fodder from the Boneyard

I am sitting in my home office and I am (after being told so by the emperor of the house) cleaning out old stuff, sorting papers, etc. pp.   This includes checking, invalidating and throwing out a couple hundred of old CDs and consolidating all that's worth keeping. Aaaaaaanyways.... I just did something very, very scary and outrageous: I installed my PDC 2001 copy of the Hailstorm SDK to get some schema fodder for InfoPath. Uh! Oh! Where does that go?

Categories:

Ingo understands Juliet's dilemma.
Categories:

March 7, 2003
@ 06:11 PM

Juliet's night.

Juliet sits down at her desk and writes a letter, a love letter, in her own words, in her own style, using a turquoise ink pen and sprays some perfume on it as she's done, because it's all about love. It's to Jonathan, the guy from Australia she met eight weeks ago in that odd little bar in Singapore. Then she takes an envelope and carefully sticks the letter into it. The envelope gives her a new clean bit of paper that she uses to write Johathan's address on, sticks a post stamp on it, and writes "Air Mail" on it. The envelope will protect her letter from being stained, losing its pleasant scent and protects it from curious eyes. She rushes downstairs, walks up to the next mailbox and drops the letter in -- all in hope that she will get an answer in the same spirit. Early in the morning, the postman will eventually make his rounds to pick up the mail from the mailbox, and the letter will be timestamped and then transported all the way, by truck, plane, train and bicycle to the (hopefully) overwhelmed and joyful Jonathan, who will (hopefully) immediately pick up a clean sheet of paper to respond. Maybe it would be better if he wouldn't respond, maybe he should better forget her and she him.

On her way home from the mailbox, right outside her door, she stops by the little convenience store at the corner to grab some milk and coffee for the next morning. Because the lotto jackpot went up to an insane sum this week, she decides to play; something she usually wouldn't do. She gets a lotto card, checks a few numbers, flips the card over and writes her address on the back of the card -- that's how it works here -- and gives the card to the store attendant. He runs the card through a machine which reads the infomation off the card and prints up a receipt listing her numbers and showing the time, store location and a reference number. She pays, takes coffee, milk and the lotto receipt and walks back the few feet to her building and back upstairs. Maybe she'll win -- maybe she shouldn't win. Thinking about it, it would be a very bad thing if she did.

Because back up in her apartment, Juliet needs to go about her business -- a dark, stealthy business. She does not only have a romatic side in her, but also this other side -- she's a spy -- and of course her name isn't Juliet. She takes another piece of paper and this time she takes that pen with the special ink which will become invisible except if held under a special light and eventually will disappear entirely. She writes a short notice about what she found out these last 3 days and takes another envelope. This time, the envelope is of a different style, not paper but a small plastic tube. It's there for protection and equipped with a special mechanism that will drench the message in a bright pink color if opened incorrectly. As she's leaving the house, she makes sure that noone is following her by taking the usual odd turns that will take her 60 minutes through the city for a distance that would only take her 5 minutes if she drove straight to where she's going. She stops at a street corner and drops the plastic tube into a street sewer; one of those who have a little basket keeping the most coarse street dirt out of the rainwater -- it's one of the well known dead-letter boxes of her agency (well-known in her agency only, of course). Three hours later, a truck in the colors of the city sanitation dept. stops by the sewer.

Having returned to her cozy place, Juliet is still nevous. Going near those places is dangerous. She can't sleep. So she decides to prepare herself a bubblebath to get some rest and relax. Maybe she'll find a way to get all of her life together in peace ... some day.

Categories:

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.

Categories:

March 6, 2003
@ 01:00 PM

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" /> 
</operation>

which could easily be expressed by augmenting XSD properly:

<?xml version="1.0" encoding="utf-8" ?>
<
s:schema xmlns:s="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
              
xmlns="urn:schemas-newtelligence-com:flightsrus:demo:v4"
              
xmlns:operations="urn:schemas-newtelligence-com:messaging:metadata"
              
targetNamespace="urn:schemas-newtelligence-com:flightsrus:demo:v4">
  
<s:element operations:operation="ReserveSeat" operations:direction="input" name="ReserveSeatInput">
     
<s:complexType>
        
<s:sequence>
           
<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:sequence>
   
</s:complexType>
 
</s:element>
  <
s:element operations:operation="ReserveSeat" operations:direction="output" name="ReserveSeatOutput">
   
<s:complexType>
      
<s:sequence>
         
<s:element minOccurs="0" maxOccurs="1" name="ReserveSeatResult" type="s:string" />
     
</s:sequence>
  
</s:complexType>
 
</s:element>
 
<s:element operations:operation="ReserveSeatVariant1" operations:direction="input"
                 
name="ReserveSeatVariant1Input" ref="ReserveSeatInput" />
</
s:schema>

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)

Categories:

March 6, 2003
@ 11:41 AM

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.

 

Categories:

February 28, 2003
@ 08:07 PM

I've seen the future and it will be.

InfoPath may become for XML, what the Basic language was and is for binary stuff. 

Thinking that technical knowledge about all the odd stuff around angle brackets and infosets alone will remain to be a sufficient foundation for a career or even a whole business may be as fatal as thinking in the 1980's that your x86 assembly skills will be enough to support your family for the next 30 years. It works for a few, it won't work for most. Ladies and Gents, it seems like XML is growing up and is getting all dressed up for prime time -- get over it.

Categories:

February 27, 2003
@ 02:17 PM

My dinner with Don.

I had a fantastic dinner with Don and Steve Swartz (Steve should start a blog so I can finally link to him and so that he can share his infinite wisdom; folks, you don't know what you're missing). Great Indian food and surprisingly good beer -- and we Germans have pretty high standards.

We were talking lots about (multidimensional!) XML, Web services moving forward and on the way home in the car, we've discussed a sufficient set of requirements for the metadata you need to bind to an XML Web service that is reliable, secure (and all the other WS-I goo). Result: You need a way to describe the message body and you need a way to describe the QoS and security features. (Mildly) annotated XSD covers the first, WS-Policy covers the second. Where does that leave WSDL?

Categories:

February 22, 2003
@ 04:42 AM

Sun FUD against IBM: Now, here's an interesting quote from InfoWorld on Sun's upcoming Web services stack: "When you buy it from Sun, you'll be able to buy it all at one price, install it all [for] one price, and have blueprints and guidance to install it yourself," Bauhaus [Sun vice president of Java Web Services] said. This is unlike IBM's Web services products, which require purchasing integration services from IBM Global Services, Bauhaus contended.

100% pure comedy (too bad that "comedy" doesn't start with a "J") 

Categories:

February 20, 2003
@ 06:13 AM
BusyBusyBusy (I am). For those with more time and some curiosity for things that mattered (mostly) in the past: check out Microsoft's newly released docs on NDR. ;)
Categories:

February 9, 2003
@ 05:38 AM
Airport WLAN (no, not Apple). Greetings from Dubai airport. They've got a wireless LAN here; one more airport to add to the "we like that very much" list. Good connectivity and a freebie - at least in the lounge.
Categories: