Steve and Clemens all over Europe.

This going to be great fun! I will be doing a speaking tour with my friend Steve Swartz (who was/is the architect of most of the new things in Windows Server 2003's COM+ 1.5). The topic is scalable application architectures and we have given it the unmarketable title "Scale, extend, stay running and don't forget to lock the door".

It's 7 cities (Warsaw, Bukarest, Moscow, Copenhagen, Oslo, Paris, Lisbon) in two weeks. The party starts April 22 in Warsaw. At most Microsoft subsidiaries the event will unfortunately be "invite only" due to organizational (space) constraints, but at least in Denmark, everyone can apparently sign up.

Expect us talking, discussing, agreeing and disagreeing about layers, tiers, process models, transactions, patterns, anti-patterns, security, Enterprise Services and other interesting things and expect the one or the other hint at the future of Web Services....


March 30, 2003
@ 12:44 AM

Dear W2K, dear WXP. Thanks. You both served me well. This week I will be switching to the next generation for good.


March 29, 2003
@ 04:23 PM

AOP demo.

MS Finland put up a (long, 30min.) Windows Media 9 series stream of the demo that I did in my AOP talk over in Helsinki. And Matt Powell from MSDN is so nice to mention the things I demo there in his MSDN TV episode on SoapExtensionReflectors/Importers. My demo code is here.


March 29, 2003
@ 02:20 PM

Reconsidering UDDI

For the record: I was wrong when I said this here. When I started to look into and think about service oriented architectures*, I understood the relevance of UDDI.

To cite Don (more than half a year ago): "If WSDL and UDDI were both hanging from a cliff and I could only save one of them, it would be UDDI."  And in case someone didn't notice, yet, I really, really want WSDL to go very near that cliff.

[*this is the most current deck for the SOA talk I do on the Microsoft EMEA Architect's Tour 2003. Check out slide 20 for an illustration of how WS-Routing, WS-Addressing, WS-Policy, message contracts and UDDI fit into a single picture]


March 29, 2003
@ 02:02 PM

Messaging rules.

I haven't blogged or even read blogs for almost two weeks. Too much time on the road. Reading (UK), Zürich, Hannover, Bled (Slovenia), Amsterdam, Budapest. Next week it's Bad Ems and then it'll be Athens, Madrid and Milano in the following two weeks.

Anyways... I find it very interesting that more and more people are seeing the light in regards to the true potential of Web Services (could someone please drop the "Web" term from that?): Messaging. We're getting there ...


IIS 6.0 process model in a nutshell

Sam Gentile has blogged a compact overview on the IIS 6.0 process model. Because pictures say more than a thousand words, I recommend that you get this PPT file from Bill Staples (Group Program Manager for IIS at MS) in addition to reading what Sam has to say.


March 16, 2003
@ 06:51 PM

The bigger language problem 

C#? C++? VB? Java? English! Whenever I speak at conferences across Europe (right now that's about twice a week), every other attendee's first comment when talking to me after any speech will not be a technical one. Instead they say "your English is fantastic". People seem indeed surprised s'at mei englesh iss not vot s'ey vutt expeckt.

I don't think that it is a "fantastic skill", but rather just part of doing my job right. Having reasonable control of the language that is the "one and only" of the IT business -- and that happens to be (American) English -- is essential. I was lucky enough that my former employer sent me on a two year assignment to New York City in '95/'96 and that was the time where I got a sobering reality check on my "school English", picked up all the idioms that let me understand what the Americans are saying between the lines, and (somewhat unfortunately) had all my English teachers' efforts to provide me with a polished "British" spoiled for good.

There is a huge problem here. There are unknown (but large) numbers of very bright people out there, who simply cannot make themselves heard to a broader, world-wide audience just because they don't write and speak English "well enough". Also, English language skills are essential to understand anything happening on the "cutting edge" of computing, because there is always a considerable lag for specifications, books and white papers to appear in any other language than English.

Right now, it's more important for my company that people know English than knowing specifically Java, C#, VB, C++ or SmallTalk. If they have a good understanding of programming as such, it's a tiny step to switch between languages. However, even if they are fabulously eloquent and well read in German, they still may not be able to get a single understandable English sentence together and, just as bad, may miss implied statements in English material they read.

Can we fix this? The answer is certainly not to lament about "language imperialism". The answer is to deal with the facts as they present themselves today and for the future as far as we can see ahead. Being "proudly European", I think that in order to be able to successfully compete with America in this industry, the Europeans, especially the French and the Germans, will have to start to understand that technical degrees must come with proper education in English on a level that's far beyond current "school English" and that a good deal of technical material should indeed be taught and tested in English. Likewise, students need to understand that it's not enough to be a German or French tech-geek. "My English is not very good" is unfortunately not a valid excuse if you are in the IT industry -- it's indeed even worse than saying "my C++ is not very good" when you apply for a systems programmer job.

What's really bad is that I am writing this in English. Sorry, I can't write it in all the languages in which it would matter to say this. Therefore I have to opt for a somewhat neutral choice.....


March 15, 2003
@ 11:47 PM
Sam has a new essay on nouns vs. verbs. Thank you, Sam. All roads lead to Rome. Rome doesn't care. ;)

W3C Web Services Description Group makes a good move.

While they are yet not as far as to they drop the ball, go home and call WSDL dead ;) but there's a noteworthy action item on the activity's task list as per their most recent teleconf call: "2003-03-13: Don [presumably Don Mullen from TIBCO and not Don Box from Microsoft] will write a proposal for annotating schema with part information.", which is an action item apparently added when they were talking about killing the <wsdl:message/> element. I am all for that.

When we get to the point that WSDL's job becomes not to describe a "Web Service", but rather only the applicable message exchange patterns (MEP) for a conversation between two points (which both may engage in other conversations following different MEP's), would kill the <wsdl:service/> binding (see WS-Addressing), and would then be appropriately renamed, I will be fairly happy with it.

Yet, looking at it that way, there should probably be only one WG for this instead of two. There's a Web services description and a Web services choreography WG and that's somewhat like one language designer designing "method" and another guy designing "interface" and looking at it as if they were only loosely related. Of course I may be entirely off base...

newtelligence should probably really join W3C and WS-I, so that I am not just a loud, complaining troublemaker, but an active, constructive troublemaker.


March 13, 2003
@ 06:19 PM

First look at WS-Addressing

WS-Addressing, which gives us a lightweight mechanism to communicate references to endpoints, is, in my view and contrary to what the spec itself explicitly says, yet another nail in the coffin of WSDL. That's because it essentially overrides the <wsdl:service/> element for any scenario, in which the message contract shall be applicable to several different or changing endpoints or intermediaries (in other words: any endpoint that wants to support transport-independent redirection/routing)

WS-Addressing is also a good choice for configuring proxies. You typically develop using a "development cloud" of a web service and not using the actual production endpoint references. If you use WS-Addressing endpoint references as part of your configuration infrastructure, you can flip back and forth between a development and production clouds without recompiles and do so in a standard way now. Until this morning, we had no standard way of expressing this; now we do and that means that framework code for proxies can be written that allows dynamic switching. The roadmap document promises a WS-EndpointResolution spec to further formalize this.

Completing the picture

So, here we have it. A web service UDDI registration (or LDAP entry) should really have three technical entries: A message contract description (WSDL for the time being), a policy description (WS-Policy) and a qualified set of endpoint references (WS-Addressing). The policy refers to the capabilities of the service (WS-Transactions, WS-Security, WS-ReliableMessaging, ...). As per the roadmap, I expect this composition to be expressed using the upcoming WS-MetadataExchange.

For a routed infrastructure on top of registries, you can have then local registries with local WS-Addressing endpoint references that identify endpoints which themselves will use "regional" or "global" registries to find further hops. For a routed infrastructure with dynamic reconfiguration, you can send something like WS-Referral-encapsulated WS-Addressing references around that will update routers. I expect that we will see adjustments to WS-Referral and WS-Routing to eliminate current overlaps with WS-Addressing. The message contract will never have to change, the policies are according to the requirements of specific endpoints and the endpoint defintions you use may vary depending on who, where and how connected you are. 

Today should be a very happy day in Web services land.


WS-ReliableMessaging and WS-Addressing are public!


Here's BEA's, TIBCO's, IBM's and Microsoft's take on how to do reliable messaging on web services. There are more than subtle differences compared to the "WS-Reliability" spec by NEC, Sun, Oracle, etc: WS-ReliableMessaging is extensible, takes WS-Security and WS-Policy into account and it does not have (less is sometime more) any specific transport bindings -- and it's routable (read on).

I will likely write about a couple of observations later, but here's a little "reading guide" for a single sentence in section 3.1 saying "There MUST be no more than one <Sequence> element in any message". That language is a bit confusing an could be worded a bit better, because what it really says, when read having SOAP 1.2's "role" or SOAP 1.1's "actor" model present in your mind is indeed "There MUST be no more than one <Sequence> element targeted at one role in any message".

That's because in the presence of roles, all headers become technically "invisible" to any but the targeted role and there is indeed never more than one <Sequence> element existing in the message as far as a certain role is concerned. It'd be helpful if the language was a bit clearer there, but SOAP actually takes care of enabling roles for this, even in the presence of that sentence.

Why are roles relevant? Because this now enables reliable delivery in the presence of routing intermediaries, which want to establish reliable links between them. If you have A->B->C->D with reliable messaging being used for the end-to-end connection A->D and the hop B->C shall be individually outfitted with reliable messaging for purposes of optimization, you can do that by specifying roles on an additional <Sequence> that applies to B and C.


InfoPath Kool-Aid. I rushed home today to sit down and enjoy a big glass of InfoPath Kool-Aid. I can certainly see that there is much goodness, but I'm still trying to get my head around the implications for my daily life. So far the only blog-worthy observation I have is that the .XSN files it produces aren't XML. I was expecting to see angle brackets. I hoped to design a form that manipulated InfoPath metadata. Curious. [Brian Graf's Weblog]

Just open the *.xsn file with WinZip. It's a CAB file ;)


AOP Serviced Components status update. I am still working on it. I've managed to get around most of the big issues and I am now working on stability issues, most prominently on a pretty huge memory leak that's caused by some side effect of what I am doing down there, in the dark dungeons between RCWs, CCWs and more CCWs. While I do it, I keep showing it at presentations around Europe and get quite positive feedback.

March 11, 2003
@ 06:38 PM

SOAP, REST, and beyond.

I am pleasantly surprised that there indeed seems to be a lot of common ground between the "transport binding matters" people in the REST camp and the "transport binding doesn't and shouldn't  matter" people in the messaging camp. Mark is one of the most vocal proponents of the REST model (and I have a lot of respect for many things he is saying). I have to admit that up until now I considered him a warrior on the REST side of the fence of a "SOAP vs. REST" battle that I never really understood. So, either I didn't understand what he was saying or Mark adjusted his position towards SOAP a bit. Either way would be good ;)

I especially agree with two of his beliefs, given that I understand them right:

I believe that using SOAP as a means for extending underlying application protocols, is the most valuable thing it can be used for.

I believe that using SOAP as a framework from which to build new application protocols has some value, so long as those new protocols are built on transport protocols and not tunneled over other application protocols.

To me, this says essentially: If an application protocol has certain gaps to fill or does explicitly not address specific concerns, wrapping the payload data in SOAP envelopes and utilizing the extensibility of the SOAP envelope (headers) allows to create protocol extensions and protocol rules that help layering additional, required functionality on top of the existing application protocol. If an underlying application protocol already exposes a capability, SOAP-based extensions should not attempt to override them.

This makes very obviously a lot of sense. If you send a message through MQSeries or MSMQ, it would be rather silly to use reliable messaging headers on top of that. If you make those queues transactional, there's little need to enforce an atomic commit protocol between both endpoints in most scenarios, because the queue infrastructure is going to handle that for you. If you simply want to use SOAP to implement RPC-style methods like "createAddress()", "deleteAddress()", "updateAddress()" and "getAddress(arg1 .. argN)", you will find that there's already a set of functionally and semantically equivalent operations in the combination of HTTP and URI addressing and therefore it's not SOAP's job to wrap and obscure this.

The catch is that this only makes very obvious sense for simple scenarios, which are, admittedly, fitting for the vast majority of web services as we see them implemented today. I understand Web services moving forward as a model where the simple scenario of having direct "line of sight" and working in a request/response style will not be sustainable and will have to be replaced with a model that is much more flexible, effectively virtualizes the entire networking infrastructure as we know it today and puts us onto a new level of abstraction to enable interoperability not only vertically inside your applications and horizontally across technology infrastructures, but also across the time-axis.

This means to me: If I build a system today that requires reliable messaging when talking to other systems, it should neither matter whether I am using MSMQ or MQSeries or some other message queuing product, nor should it matter whether I am not using a message queuing product at all, but just approximate reliable messaging on top of HTTP and it should likewise not matter whether I am going to be using something I now can't even envision existing in 4 years from now. To make this work, "capability policies" for the services that I am using and processing hints contained in the message that I am sending need to be able to express such fundamental requirements so that they can be mapped onto the concrete capabilities of an underlying transport and application infrastructure. If the service policy says that reliable messaging is required, this does not necessarily mean that a set of SOAP headers must be used and the protocol must be instantiated on the service as long as the policy requirements are fulfilled. Requirements for security and messaging reliability and data consistency will remain to be important, no matter how much technology changes -- and additional requirements will be added on top of that. Technology will continue to change.

For all of those reasons I am a big fan of the WS-* family of specifications from IBM, Microsoft, "", because all of them provide first and foremost an abstract and extensible framework that addresses something as broad as security or transactions. Only in the next step do these specs provide mappings of today's fashion of implementation technologies that balance between concrete enough to allow proper interop and are loose enough so that vendors have enough headroom to map them into their technology stack. None of these specifications does really worry much about concrete bindings to transports. 

Another reason for the absence of transport bindings in most of these specs is that they are built to work in a virtualized network environment that layers its own routing infrastructure on top of existing networks. True, IP does that today and because it's ubiquitous one would think that virtualization of routing is pure overkill. Still, there are plenty of transport protocols that have a slightly different idea of routing, especially in the realm of so-called "legacy" systems. There is also a huge space that is rapidly growing by the day and for which IP's transport-level model of routing isn't feasible -- because (a) your IP router doesn't know when you are leaving your desktop PC and want to get your IM messages on that cell phone now and (b) you have to switch off your cell phone when you get on an airplane. With a virtualization of routing, the biggest part of the work (getting stuff from here to there) is still done by IP, but the negotiation and setup of application-motivated destinations and routes isn't IP's job. In the presence of application-level routing, applications also get the freedom to choose the best transport for a particular message destination or the next hop on the route. That may be HTTP, but it may also be a Queue, a database store & forward table, a TCP socket, ZMODEM on COM1: or a carrier pigeon.

In the presence of such routing scenarios, where HTTP may just be used as the "Internet-crossing" hop a much longer route, HTTP really is "just a transport" and not an application protocol. Call it abuse, but it's just pragmatic.

All of the above are reasons why I think that in search for a generic interoperability infrastructure, a HTTP centric model like REST is much less desireable than a transport and application protocol (HTTP, SMTP, BEEP, etc.) independent approach -- the same set of arguments is also the reason for why I think that WSDL is a bad idea. WSDL creates a very unfortunate link between transport-bindings, concrete service capability requirements (headers) and message content declarations, which all should be declared in separate places.


March 9, 2003
@ 03:07 PM

Just how RESTful is TV?

I've spent some time this morning going though a bunch of web pages explaining and debating RESTful web services. The claim that I see repetitively is that REST is scalable, because it works like the web works and that has proven to be massively scalable. What I don't get together is the basic idea that "every thing is a uniquely identifiable resource" with the bare fact that the seemingly limitless scalability of the largest websites is indeed an illusion created by folks like those at Akamai, which take replicated content around the globe and bring it as close as possible to the clients. It's a lot like TV. TV scales endlessly as long as you are in reach of a broadcast antenna or a satellite beam. It all works beautifully in one direction. However, we don't really have fully interactive TV, yet, because the whole backchannel story is a major problem. It's a pure scalability problem.

If you GET something from the web, you think you are getting it from a uniquely identifiable bucket, but you are indeed quite often smartly spoofed elsewhere and you will get nearly current information. If you PUT or POST something, however, the data will ultimately have to end up in a single bucket -- and unfortunately there is no magically better concurrency story in REST just because it sits directly 'in' the web technology stack.

I will have to admit that I had a weak moment yesterday where I thought that the whole REST story makes a lot of sense. I was thinking of ways to really make it dead simple to use a tool I am currently playing with in the context of a larger application and REST has a lot of appeal there. The "create" story of REST using HTTP PUT is very pretty for this and HTTP GET speaks for itself. It all falls apart when you think about concurrent updates and concurrent deletes. These simply can't exist in such a world. As long as you only create stuff and reference stuff, all is fine.

One of the core problems with turning the REST model into an universal approach for dealing with data is that it is, in all its simplicity and purity, absolutely unaware of what data it is dealing with and it has no sense of the sort "identity" that grows from within the data itself. Once you assign a URL like '' to a data set in reply to a create request (PUT), you may essentially be locking down a whole set of properties of this data set that can never be changed if the URL shall not lose all of its own organizational qualities. Even more so, the data gets totally locked down once you follow this path of "object identity" to the last consequence and allow direct references into the data like through this URI '!item/manufacturer/foundrylocation/@country' where the second portion (here separated by a '!') is an XPath reference into an assumed XML InfoSet located at aforementioned URL. If two parties working on a data snapshot (that's all you GET) were competing for updates here, and the first party to hit the resource would do a wholesale replacement of the 'manufacturer' data, the second party would now only manipulate a well-known place (/item/manufacturer/foundrylocation/@country), but a wholly different data context. Taken to the last consequence of every data facet being uniquely identifiable through a URI (which it then should be and is) this model can't properly deal with any modification concurrency. [Note that we have a 'manufacturer of this item' relationship here where the 'country' is immediately relevant to this exact type of item and not to the manufacturer in general - so we can't factor the manufacturer data out to a different URL]

As said, REST can deal beautifully with creating and referencing data sets, but how do you pass references around for which any guarantee of currency can given? In the end, I am interested in a data record that represents a specific data item of interest. In the absence of updatability, I will still always know that there is a URI that points to the most current data set for this data item, but unless I have created this item myself, I can never know which URI that is. So, what are the limits of data granularity to which REST applies? How do you define boundaries of data sets in a way that concurrency could work in some way and how do you define the relationship between the data and the URI that identifies it?

The theory behind REST sounds a lot like the theory behind distributed objects (not distributed systems), where you have one virtual thing that represents one real thing. An 'item' in a catalog is a uniquely identifiable thing with its own object identity. I used to be a big fan of this idea until I found it not to be working for a lot of aspects, including, most prominently, high scalability alongside proper concurrency management. This basic idea is very much in the spirit of what CORBA is all about -- and, don't get me wrong here, that model is very good and very valid for a big number of use cases, especially in real-time or near real-time enviornments that deal with a lot of transient data. [As a sidenote, it's quite interesting that if you go and look in Google's Usenet archives and look for the term CORBA combined with the names of some of the most prominent REST proponents you will find what you would expect.]

I have written about the REST'ish view of HTTP being the one and only protocol in the context of transactions and reliability quite a while ago and that perception hasn't changed. Werner Vogels had some additional comments on the reliable messaging angle two weeks ago.

All that being said - I do believe there is a place for REST and plenty of use-cases. These use-cases are likely very much those for which CORBA's fundamental idea of objects already was a very good model. And there are plenty of use-cases for stateless and stateful RPC (in the absence of the 'single thing' idea) and there are plenty for messaging. There is a place for SOAP, which is at its core simply an envelope for annotating data as it crosses system and organization boundaries, in all of these models. That's what Juliet's night is really about.


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?


Ingo understands Juliet's dilemma.

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.


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.


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

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)


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.