This morning I had an interview with Kurt Mackie from Application Development Trends Magazine, and discussed the implications of the completion of WSDL 2.0.
In retrospect I realized I’m used to long-winded deliberations from years in Working Groups, rather than sound bites that are easy for the press to grab on to. I guess Kurt Mackie had the same impression, since he decided to transcribe large parts of our conversation ;-). I’m not too disappointed with the result though. Even managed to get in an unexpected plug for the WSO2 Mashup Server. Take a look at the article and see if you agree…
Today, almost 6 years after I became involved, WSDL 2.0 became a W3C Recommendation. The Web Services Description Working Group of which I’m a co-chair ends shortly too, with it’s charter running out this week and the Working Group disbanding thereafter. Seems like the end of an era.
But it’s really just a new beginning. IBM’s testimonial indicates support in a new version of the IBM CICS Transaction Server being released this week. Support in our own WSO2 Web Services Application Server appears imminent, with a 2.0 version due out in a few weeks. And my own pet project the WSO2 Mashup Server makes significant use of WSDL 2.0; we’re trying to do our first alpha release in the next week or two as well. A number of helpful tools are appearing, like the W3C WSDL 1.1->WSDL 2.0 converter, a similar converter at WSO2.org, and my own annotated stylesheets.
I was especially gratified to see a number of companies indicating that they will support WDSL 2.0 in their products and operations, and even willing to go on the record. From the press release:
Many companies have stated that they expect to support WSDL 2.0 in upcoming product releases, including Adobe Systems Inc.; CA; IBM; Sun Microsystems, Inc; webMethods; and WSO2…
I’m confident that developers, given the opportunity to choose WSDL 2.0 over WSDL 1.1, will be happy to make the upgrade, and will be favor vendors make that option available.
Congratulations to all the WG members for the long and hard work involved in getting us there. Recs and WG endings can seem rather anticlimactic, but don’t forget to raise a glass tonight wherever you are to a job well done!
 While you’re holding your breath for the anticipated WSDL 2.0 Recommendation, check out Eran’s podcast on the WSO2 Oxygen Tank, talking about WSDL 2.0 and how it’s supported in the WSO2 Web Service Application Server.
I’ve been silent on WSDL 2.0 a bit as I’m guilty of crying wolf on our last attempt at Proposed Recommendation, but today we really truly finally completely are at Proposed Recommendation!
At last, after many years of development of the Web Service infrastructure we are on the cusp of having an open standard for Description, replacing the crufty old WSDL 1.1 that everyone loves to hate.
In addition the auxiliary specs (which are also complete but we’re not taking them through the official voting process to issue them as Recommendations) were republished.
The voting and comment period lasts until June 20th, so we might not need a third charter extension (currently through June 30th) after all!
I’ve been doing some fun things with WSDL 2.0 for the WSO2 Mashup Server (more on that soon!), and it’s hard to imagine anyone getting a taste of WSDL 2.0 wanting to return to WSDL 1.1.
I’ve been working on a WSDL 2.0 description of the Flickr API. My first attempt is here. Follows are some thoughts on this process:
Why a WSDL?
There are two reasons motivating me to want a WSDL for Flickr. First of all, the WSDL 2.0 WG needs to prove that the HTTP binding has utility in describing existing REST or POX services. Flickr seemed like a good stress test. Secondly, once I have a WSDL I can automatically generate stubs for dynamic languages (a part of the Web Services Mashup Server I’m working on). That should (ideally) simplify the interactions with Flickr and I wanted to see how much progress could be made.
Google failed to uncover any Flickr WSDL (1.1), just a number of people bemoaning the lack of one. So I had to set forth on my own.
Flickr SOAP and WSDL
A quick look at the Flickr SOAP interface (the one you’d expect to be reasonably describable by WSDL 1.1) shows that they use a wrapped technique that make it very difficult to write a clean XML Schema, and therefore WSDL, for the service. Traditionally, each operation in a SOAP-based Web service (e.g. flickr.photos.search) accepts and returns blocks of XML, which is described by XML Schema. Since XML Schema associates an element name with a single structure, different operations, at least those requiring different structure, choose different names for the XML payload. Flickr however wraps the parameters which comprise each request in a single element:
<x:FlickrRequest xmlns:x="urn:flickr">
<method>flickr.test.echo</method>
<someparameter>value</someparameter>
</x:FlickrRequest>
Note that the name of the operation (flickr.test.echo) is buried inside the payload. There is a co-constraint between the value of the <method> element and the other parameters in the body. This co-constraint is not expressible in XML Schema, which associates the <x:FlickrRequest> element with a single structural type. Responses are similarly wrapped in an <x:FlickrResponse> element. Because each operation returns the same element, a straightforward WSDL can’t do much better than an xs:anyType when describing the messages.
Note that WSDL 1.1 had a hack that helped here - you could describe the type of the body, rather than pointing to an element declaration that represented it. WSDL 2.0 removed this hack in the name of simplification - a good choice in general but Flickr really could use the hack.
Flickr SOAP and HTTP
The WSDL 2.0 HTTP Binding actually does a better job than the SOAP binding here. Since the XML structure of the operation is mapped into parameters, a wrapper element declaration doesn’t appear on the wire, so one can make up a different element name (as I’ve done) for each operation. The return types from the Flickr REST API are still a single type of element (even worse than the SOAP case since the same wrapper element appears around both successful responses and faults). But formulating the request has the highest value-add from the stub-generation point of view.
Flickr Authentication
The Flickr authentication scheme seems likely to make the WSDL description less than useful. Most of the operations (the "write" ones) require authentication, yet the mechanism for authentication and signing seems pretty unique to Flickr - and therefore is likely to interact badly with general-purpose tooling. I’ll have to play with this more to see whether this will require so much hand-coding that having WSDL at all is irrelevant.
Random Thoughts
One thing that an official WSDL would force, is a little more rigor in versioning the Flickr API. It appears from the mailing list that changes to the API happen occasionally, but I wasn’t able to find a clean identifier for the various versions of the API as it evolves. Having metadata that could be associated with stable (dated) identifiers would help customers of the API have a consistent experience over time.
An interesting anomaly is that the SOAP API and the REST API really must be considered different APIs at this point from the WSDL perspective. That is, the XML Payload you get back is different depending on whether you access it through the SOAP or REST API. WSDL separates the payload structure from how the XML is transmitted on the wire, but would require some XML transformation capability in the bindings to expose a single abstract set of messages through alternate transports (like SOAP vs. raw HTTP). That means, if you change the way you get the payload delivered to you, you also have to change the way you access the contents of the payload - a Flickr poorly separates these concerns IMO (predicated on the definition of "payload" being the child of the <soap:Body> or the HTTP envelope).
Also I need to think a little more on whether Flickr’s design is optimal as a REST API and just hard to describe within the constraints of WSDL and XML Schema, or whether it’s generally suboptimal and that’s what is making it hard to describe. Right now it seems neutral to me - the API would be just as easy to use if it were designed in a little more WSDL-friendly way but I can’t yet see compelling rationale for changing it other than to make it more WSDL-friendly.
Anyway, please send me any feedback you have on the WSDL.
 WSO2 today hosts the WS-Metadata Exchange Interop Workshop here in Auburn, California. Representatives from Microsoft, IBM, WSO2, Sun, Oracle, and Adobe are currently present, and already showing some initial progress at running the interop scenarios.
WS-Metadata Exchange is a fairly simple spec, allowing one to approach another service and query it about it’s capabilities (WSDL, XML Schema, WS-Policy). Having a common way to do some initial handshake allows services to bootstrap communication with each other. I think the most likely scenario for this is doing some alignment of security policies so that subsequent communications can be done in a secure fashion.
Update: As of Thursday, we had overall excellent interop results with most of the matrix filled in green. Still a few reds in the matrix between a few vendors that will hopefully get filled in next week. Overall, I think the meeting went very well and I think everyone enjoyed coming to the "WSO2 Auburn campus." Hopefully we can make this a regular occurrence!
I’d hoped to announce WSDL 2.0 was a Proposed Recommendation by now, but we hit another small delay - the W3C team thought it prudent to do another short Last Call to make sure people were aware of the namespace change.
WSDL 2.0 adopts the namespace convention http://www.w3.org/ns/wsdl instead of the dated URL http://www.w3.org/2006/01/wsdl. The idea is to make the namespace shorter and more memorable, especially since it’s used as the base not only for the WSDL 2.0 family of namespaces, but also for other identifiers defined in the language, such as style and message exchange pattern identifiers.
However, changing the namespace when going to Proposed Recommendation seems to have raised some eyebrows. I’m not precisely sure why. It does destabilize implementations underway during the Candidate Recommendation - just as you achieve a level of successful interop the fundamental identifier of the language changes. But in this case we believe we know very well who the implementers are and we verified that a namespace change was manageable.
It seems semantically pure to change the namespace when significant changes to the spec have been made. In the case of WSDL, the most significant change was the removal of features and properties. The resulting language is different enough to warrant a namespace change. Features and properties were marked as "at risk" which is supposed to (in part) reserve the ability of the group to proceed from Candidate Recommendation to Proposed Recommendation without another Last Call period. But apparently this doesn’t extend to the accompanying namespace change? Puzzling.
I suppose the best advice I can give on namespace changes is to replace the long (1 year+) Candidate Recommendation phase with a shorter series of CR or even LC publications whenever a major change occurs. That way the final CR to PR transition will be wholly editorial.
That said, arguably a more important reason than a namespace change, is to allow the WG to prove more definitively the utility of the WSDL 2.0 HTTP binding by demonstrating its ability to describe some popular existing HTTP based services. That proof is unfortunately missing at present and it is a wise task for the WG to engage in.
In any case, get your comments in by this Sunday, that’s when the Last Call period ends!
 Moments ago, the Web Services Description Working Group voted to move WSDL 2.0 to Proposed Recommendation, culminating over 5 years of effort by the likes of Charlton Baretto, Allen Brookes, David Booth, Roberto Chinnici, Glen Daniels, Paul Downey, Youenn Fablet, Martin Gudgin, Hugo Haas, Amelia Lewis, Tom Jordahl, Anish Karmarkar, Jacek Kopecky, Kevin Liu, Philippe Le Hegaret, Jeff Mischkinsky, Jean-Jacques Moreau, David Orchard, Gilbert Pilz, Tony Rogers, Arthur Ryman, Jeffrey Schlimmer, William Vambenepe, Asir Vedamuthu, Sanjiva Weerawarana, and Ümit Yalçinalp. And I could go on and on…
Congratulations and many thanks to all for the hard work getting us here! Still a bit of work to do to get these specs published and then approved as Recommendations, but I’m confident the road from here out will be smooth and largely administrative.
I’ve been in Boston for a couple of days to attend the WSEC workshop. I’ll avoid some of the interesting (but still inconclusive) discussion about the ultimate relationship of REST and WS-*. But two of the emerging conclusions of the workshop are interesting.
First, my proposal for a WS-Core WG to continue the active maintenance of the raft of specs being completed in the W3C, and continuing to keep the pressure up on interoperability testing, was well received, and ended up being a primary area of agreement for the Working Group participants. I don’t think that’s because it is a brilliant idea, rather because it’s fairly obvious, modest, and concrete.
Secondly, one of the major pain points in WS-* remains the poor support of XML Schema that is being addressed in the understaffed XML Schema Patterns for Databinding Working Group. A renewed effort to address this customer pain point is essential. I’m confident WSO2 can continue to participate and maybe even step up our work in this critical area, and I hope other vendors who wrongly dismissed the effort as irrelevant after Microsoft didn’t show up will reevaluate their positions.
The consequences of not doing so are to weaken confidence in the description side of WS-* that remains in my mind one of the primary advantages of WS-* over REST. If we can’t do a better job, I think REST and REST description languages such as WADL will gain momentum. That’s not a bad thing in itself, but some healthy competition will keep the architectures competing on their merits rather than their execution.
Thanks to all the participants for some engaging and informative discussion.
 WSO2 is hosting the WS-Metadata Exchange Interoperability Workshop, here in my hometown of Auburn, California. After years of travelling to the far corners of the world to attend meetings, this is the first time I’ve hosted a meeting I myself didn’t have to travel to (at Microsoft I hosted meetings at the Redmond and Silicon Valley campuses.)
If you’ve got a WS-Mex implementation, sign up and come along! We expect to be testing WSO2’s Mex implementation with the likes of Microsoft, and IBM. We’re sure to have a great time!
As WSDL 2.0 approaches it’s launch into Proposed Recommendation, Jacek has pointed out the apparently duplication between the wsdlx:safe annotation (and it’s corresponding {safety} property) and the Semantic Annotations for WSDL sawsdl:modelReference="http://www.w3.org/2006/01/wsdl-extensions#SafeInteraction" annotation. Both these annotations have essentially the same characteristics. How should the existence of two ways to say the same thing be rationalized with the goal of standardization, which is how to agree on one way to say something so we have the best chance of understanding each other?
The issue has now found it’s way to the TAG for their comment. I already put in my two cents. But part of my claim may benefit from some exposition.
Besides the spelling of the feature (wsdlx:safe="true" vs. sawsdl:modelReference="…#SafeInteraction") and the terminology underlying it ({safety} vs. {modelReference}), there is only one other significant difference between the two mechanisms. That is, that the WSDL 2.0 HTTP Binding has a dependency upon the wsdlx:safe annotation.
If the HTTP Binding moved its dependency to SAWSDL, it might accidentally suck in the whole SAWSDL framework, overkill if all you really want to implement is the HTTP Binding, like a tapioca pearl drink when all you have is a regular size straw (wsdlx:safe is small enough to slip through a coffee stirrer). So unless this dependency can be dislodged, our only reasonable choice is to discourage SAWSDL from competing with our wsdlx:safe extension. That would be unfortunate because wsdlx:safety sticks out like the energizer bunny in a polar bear habitat. Safety really describes "what does the service do" rather than "how do I use it" which is what WSDL is really about. SAWSDL seems a much more appropriate home for the concept of safety.
The detail of the dependency is, that when an operation is marked as safe (wsdlx:safe="true"), and bound with the WSDL 2.0 HTTP binding, and there is no default HTTP method specified (whttp:methodDefault), and there is not explicit method on the operation (whttp:method), the operation will be bound to GET rather than POST. Notice that:
- Removing wsdlx:safe does not prevent someone from binding an operation to GET.
- If you really want GET, whttp:method="GET" is much more straightforward than wsdlx:safe="true" and omitting the whttp:method.
Which came first, GET or safety? GET is the poster child for why safety is interesting. Safety is the abstract quality of GET that has proven so useful on the Web. As an abstraction, it’s by definition less concrete to users. Most of the people I know that understand safety thoroughly understand GET thoroughly, so it’s unlikely that anyone who asserts safety will be unable to figure out how to simply bind explicitly to GET instead. And I think there are quite a few people who can use GET without understanding the subtleties of safety. And indeed, that level of abstraction can be dangerous to those who don’t know what safety is. "Yes, it’s safe to dereference the URL ‘debit me $100′ because I don’t have a criminal record. So I’ll mark that operation as safe." I don’t think you have this understanding problem with GET.
So why is safe interesting at all if it’s simply a synonym for GET? Well, I think that’s a bit backwards. GET is often equated with safety, but POST can have the property of "safe interaction" as well. Perhaps you want to invoke a safe operation with a bulky payload like a SOAP envelope for which POST is appropriate. The knowledge that the POST was safe could be used by caching infrastructure with immediate benefits. But the HTTP binding’s dependency has nothing to do with this primary use case. So sawsdl:modelReference is just as good for that usage as wsdlx:safe.
So why did safety end up in WSDL in the first place? Well, it seemed like a good train to latch onto at the time, and we fought back many similar requests to hook cars to that train. Eventually I think it became clear to the "hookers" that this train wasn’t actually leaving the station for a while (this week marks the 5th anniversary of our first teleconference). They mostly went looking for other trains. I say let’s unhook this caboose since once it’s attached it can never really be unattached, even if our train is going somewhere different than the caboose wants to.
I suspect the decision will come down to whether SAWSDL is perceived to have enough momentum to become a common companion to WSDL 2.0. I also suspect SAWSDL would like to keep this functionality because it might drive initial adoption. I just implemented SAWSDL annotations in wsdl-xslt, showing that the extensions are rather trivial from the WSDL perspective. Maybe that demonstration will also help drive SAWSDL adoption, and thereby allow us to restore safety to it’s rightful family.
The WSDL WG continues to struggle to get it’s Candidate Recommendation issue list down to zero - something we’ve been close to for a long time (and even acheived momentarily a few times) but never quite able to make stick.
Rolling up the graph of our issues, it’s pretty clear what the culprit is - there have been two major spikes in the number of issues - one last June, and another last November. Not terribly surprisingly, these spikes coincide fairly directly with the two interop events we’ve held (July 5-7, Nov 14-18). Clearly dedicated interop events do result in closer examination and improvements to a spec!
So, is the solution to speedy specs simply not holding interop events? Instead, I’d propose a new model - instead of specially arranging interop events as necessary, plan from the beginning to hold a recurring series of interop events, every two to three months, stopping only when the spec is complete. Which I think means we’re due for another one…
At long last, the tiny but valuable WS-MTOM Policy assertion spec has been acknowledged as a W3C Submission. 90% of the spec is boilerplate, so rather than wade through that, here’s a summary:
The spec defines the following element as a WS-Policy assertion:
<OptimizedMimeSerialization xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization"/>
When this policy assertion is used, all messages to and from a Web Service MUST be MTOM encoded; thus they will all have the application/xop+xml mime type. The assertion can be used on, and thus applies uniformly to, a wsdl:binding or wsdl:port. Although the spec doesn’t mention WSDL 2.0, there is an obvious implication that it will work just fine on a wsdl2:binding, or a wsdl2:endpoint. That’s the spec in a nutshell.
This spec is bare-bones and thus avoids a number of nasty issues. A few things the spec doesn’t define:
- It does not constrain which parts of a message, if any, should or must be optimized. Most messages sent and received from an endpoint will have the
application/xop+xml mime type even though they only have a single message part (and thus no optimization).
- It does not provide for operation-level granularity of describing MTOM encoding. That is, all operations in the interface have to be optimized, or not.
- It does not provide for message-level granularity of describing MTOM encoding. That is, you should not expect to be able to send XOP and get back plain old SOAP, or vice versa.
- wsp:Optional="true" is allowed on the assertion, so that you can still interoperate with the service without MTOM engaged. However, this doesn’t mean you can mix and match MTOM and plain old SOAP at will. Specifically, if you send a regular SOAP message to such an endpoint, it can infer that you have chosen the policy alternative that doesn’t include MTOM engagement, and so you won’t get an optimized message in response. I have a feeling wsp:Optional will be an interop problem in practice, and don’t expect Microsoft to be emitting it in their WSDLs.
P.S. you might chuckle to note me as the editor - 3 months after leaving Microsoft. And it was on my project list for, maybe, a year? So you can see I wasn’t the only bottleneck ;-).
 I’m on my way home from France, having attended a very successful WSDL 2.0 Interop Event, in which we made dramatic progress in completing the test suite infrastructure, running tests of various sorts, fixing bugs in implementations, and even debating some ambiguities in the spec. Everyone worked incredibly hard (often into the wee hours - 4AM was my best[worst]), and the accomplishments are impressive. Merci boucoup to all who attended and worked so hard! Final victory is within sight…
 But besides the nearly round-the-clock hack-a-thon, we did take a bit of time out to enjoy the local attractions - a nighttime tour of Mont Saint Michel, crepes and a walk around the old town of Saint Malo, an over-abundance of excellent meals, and even a few rounds of Werewolf. Pictures are available here.
Yes, that’s where I’m landing. I’ve known and admired Sanjiva since early in the XSL Working Group, and his year-old startup WSO2 is sure to be a rewarding place to work. WSO2 is developing products around the Axis2 open-source Web Service Stack, and while Axis2 itself is open source, WSO2 plans to provide support and service to corporations making Axis2 a critical part of their infrastructure. It’s a model that has worked well for MySQL and Red Hat.
My title is Director of Architecture, Mashup Technologies, and I’ll be working on ways to make the consumption of Web Services as trivial as possible, and the deployment of Web Services just as simple. This is a perfect overlap for me - I’ve been working on Web Services, especially the Enterprise-level, back-office, strongly-typed variety for a long time, but my background and affinities are with the script-friendly, quick-and-easy, dynamically-typed web hackers. If I’m successful, Web Services will become a more important part of the grass-roots Web toolbox.
Working at WSO2 will in some ways be completely different than working at Microsoft:
- Open Source Software versus Commercial Software (I know commercial isn’t quite right, as there is commerce in Open Source, but calling it Closed Source or Proprietary Software has a negative connotation that I don’t think is justified. Neither model is inherently bad, they are just different. In any case I’m looking forward to understanding the Open Source business and development models better.)
- Diplomacy versus Design (While I’ll continue to work on standards, the majority of my time will be devoted to designing new ways to make Web Services accessible to the grass-roots of Web developers.)
- Unstructured versus Bureaucratic (An organization the size of Microsoft requires a level of rigor, process, fixed roles, and yes even bureaucracy that I won’t miss all that much. You can often get more done faster flying by the seat of your pants. And you can have more fun doing it.)
- Time zones (I’ll continue to work at home in Auburn, but I’ll no longer be in the same time zone as the main office. In fact, I’ll be 11 1/2 hours off. That’s the only part of the new job that scares me!)
And in other ways it’ll be just the same:
- Web Services (I’ll be building on my recent experience rather than taking up something completely new like lion taming.)
- WS Description Working Group (I’ll continue to co-chair the WG, and in fact hope to be even more involved in proving implementation experience to move the specs out of Candidate Recommendation stage.)
- International travel (While I hope to reduce my travel somewhat, I still look forward to meeting my colleagues in exotic locations. Now Sri Lanka will be on my repeat destination list!)
I’m very excited about this move, and it feels like it’s happening at just the right time for me. Well, a few weeks later than I’d hoped, but now at last I’ve cleared the road and am ready to hit the gas. Starting on Monday when I leave for the Apache conference in Austin. If you’re in the area, let’s do tea!
|
|
Posts (RSS)