Donnerstag, 6. März 2003 |
Sam defends WSDL (but doesn't try too hard :)
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:
What's left then? This: <operation name="ReserveSeat"> 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) 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:
Here's stuff that I wish that InfoPath was that it isn't:
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 [] |