Tuesday, October 15, 2002

WS DevCon: Steve Lougharn: When web services go bad Steve was fabulous! He and Clemens share my prize for most entertaining speakers! In a well-prepared presentation Steve showed what it takes to roll out a large-scale commercial web service.  As expected, in large-scale systems web services don’t really make life easier. This stuff is hard by definition.   Steve offered advice regarding keeping healthy development environment for such projects such as: -          No barriers between r&d and operations -          Deploy early and often -          Operations tasks should be described as use cases -          Track operations issues as defects -          Instrument the code Not surprisingly, most of the points are similar for a “conventional” large-scale software project.        WS DevCon:Peter Drayton: Designing RESTful SOAP API Peter gave a great intro to REST design pattern and the philosophy behind it. I’ve learned there’s lively debate going on between REST and SOAP “camps”. Rather than fueling the debate, Peter crystallized the benefits REST that can be directly used in SOAP world: - Model your system as a set of resources. (This way you’ll be able to address them and work with them independently of the root SOAP interface) - Assign logical URLs to resources. (Practically speaking, use URI strings as oppose to oblique Ids to refer to things) - Define schemas for resource representations. (Now that a resource can be addressed via a URI, clients will also need access to WSDL) - Enable discoverability of resources. (Allow traversal of SOAP “content”) - Provide appropriate resource manipulation operations. (Define a small set of operations clients can assume are supported) After his talk, Peter, Tim and Sam talked about a need to get a WSDL from a SOAP URI. In order to enable discovery of resources, one would need to get a WSDL that corresponds to a URI referring to a SOAP resource. Everyone seemed to agree that this is one of the key missing links and will make "REST guys happy".      WS DevCon: Glen Daniels: Apache Axis Apart from good info on history of Apache project and the reasons behind open-source nature of Axis Glen gave an introduction to Axis architecture. It sounded like Axis has a simple and elegant pipeline-processing type architecture where a SOAP message flows though a series of “handlers”. Handlers can modify the message as it flows though and can also add or get name/value pairs (or properties) in order to communicate with other handlers. The whole thing is pretty extensible meaning that users can create their own handlers and plug them in various places in the pipeline. Amongst open issues Glen talked about difficulty in describing a SOAP error (fault). So I’ve wondered if there’s a way to marshal exception object within SOAP’s fault code? The simple answer would be to XML-serialize exception object on the server, pack it in fault code and re-throw it on the client side. That led to a hallway conversation with Steve Loughran who kindly answered by essentially saying “It’s more complicated than you think!”. Steve pointed out that such technique will not really interoperate because CLR function call does not prescript the kind of exception it could throw. So .NET web service can potentially throw any kind of exception, while client-side Java code must know in advance which exception can be thrown by a function (via ‘throws’ keyword). There seem to be nothing in WSDL to describe how the error would be reported. Looking forward to learning how to do this right.      WS DevCon: Sam Ruby: “Interop is All” Chris and Tim could not have picked a more appropriate keynote – the ideas from Sam’s talk resonated in most of the presentations that followed. The key take-away: Do NOT use SOAP is you always control both ends of the wire in a distributed system. The ONLY reason you want to use SOAP is to assure interoperability with other SOAP end-points (web services and clients).  Sam points out that systems that use things like ADO over SOAP are not interoperable right now, thus should not be used. Shawn Wildermuth counters this recommendation on his weblog by explaining how ADO DataSets can indeed be used in the context of Web Services. As Shawn writes: The trick is wrapping your DataSet in an XmlDataDocument. I had a pleasure to discuss .NET Remoting with Ingo in this context. People who think about building distributed applications should really think if they really need SOAP (and consider Remoting instead). And inversely, if you need interop – don’t use Remoting’s SOAP channel. It really gives people false impression they are building Web Services while they are using slow protocol inside a system that isn’t built for interop.      Back from WS DevCon.   This conference blew me away. It was at once exciting and humbling to spend two full days in the company of real experts. The energy in the room was truly amazing – there was zero marketing bs, no Java-vs-CLR religion, the audience was engaged in every talk, complementing it with questions and comments.   I won’t try to summarize the talks here – Brian Jepson posted near real-time account on his weblog. I’ll simply add my own impressions and observations. The number one reason you’ve been hacking too many web services?       You no longer see the angle brackets, "just blond, brunette, redhead"

Site Statistics

© Copyright 2003 Alexis Smirnov. Last update: 5/6/2003; 5:41:31 PM.