Friday, October 11, 2002

Clemens Vasters' The XML Web Services X-Files: Tales from the Labs at Web Services DevCon, Day 2 Many developers need simplicity: no time to deal with XML philosophy no time to craft or learn schema and WSDL less time to deal with things like GXA .NET's attributes make it easy to take advantage of the plumbing: [CheckArguments] [TipTransaction] [KerberosAuthentication][PrincipalPermission] [ExceptionMonitor] [MethodStatistics] [WebMethod] public string MakeReservations( [MinLength(8), MaxLength(8)] string FlightCycleID, ... etc, etc. ... It's just attributes you inject into your metadata. No special programming skills needed to use this capability. ASP.NET Runtime Environment: ASP.NET is independent of web server (Apache, IIS, Cassini), but not independent of Windows. ASP.NET SOAP Extensions use a plug-in architecture (declarable, configurable) The extensions build a pipeline for handling the exchange of messages. Clemens is showing a bunch of extensions in this talk, and many are available under a BSD license. His site is at http://www.newtelligence.com. 6:58:18 PM

Keith Ballinger's talk on .NET Web Service Security Support at Web Services DevCon, Day 2 Keith's presentation has no slides, it's an XML document that he's expanding as he goes. Maybe that's how I should do it. it's easier to see where the speaker is in the talk if you space out. Sending a message: SOAP message is fed into the WSDK runtime, which contains custom filters (Routing, Security, DIME). You end up with a bigger SOAP message that goes out on the wire. Receiving a message: SOAP message returns to the WSDK runtime, the customer filters hit it again (Routing, Security, DIME), and the smaller SOAP message makes its way back to the user code. He asks: Why can't I just use SSL? Too many intermediaries, not all of them trusted Maybe you're not running over HTTP (Moving the security info out of the transport and into the layer enables more flexibility in such scenarios) WS-Security includes: Security tokens (binary and XML) Message integrity (XML signature, key information) Message encryption (XML encryption, encrypted keys and data) Out of time—that's all, folks! 3:46:46 PM

Eugene Kuznetsov's talk on Network Infrastructure Requirements for Web Services at Web Services DevCon, Day 2 Why might web services not take off? Too difficult/expensive Lack of sound business model/ROI Security fiascos (direct pipeline to the corporate backend; it's not a matter of some credit cards getting stolen, it's a matter of hackers reaching your backend databases. Performance Reliability/availability HTTP load balancing holds useful lessons: scalability needs exceeded what one server could provide. Load balancing complexity (cookies, URL mangling) grew enough that developers needed to be aware of it, and adjust their architecture to support it. The network architecture must provide acceleration, Security, and management facilities: SOAP Load Balancer can examine XML data to make routing decisions. XML/SOAP firewall (checks well-formedness, looks for DoS attacks, performs validation, etc.) He makes an interesting point about these devices: the firewall will be vulnerable to the same problems (giant XML files as DoS attacks) as the system you are protecting. XML Accelerator (validation, XSLT, etc.) XSLT Accelerator (server returns XML; accelerator converts to HTML; it could customize the output for different browsers) Web Service payment/billing gateway (payment & authorization) 2:54:53 PM

Tim Ewald's session, Building Web Services with System.XML at Web Services DevCon, Day 2 Web Services are really about XML; the plumbing converts XML to objects; How do you build Web services that use XML and expose it to the developer? Once you convert XML to objects, you lose the power of XML. .NET APIs: low-level .NET APIs System.Xml for SOAP message System.Net for client-side Web access System.Web for server-side HTTP support He's got an IHttpHandler that includes a method called SatisfyGlenByLookingForMustUnderstandHeaders(header). His web services using using XmlTextWriter to send back the SOAP response. This gives him a lot of control over the stream. You get access to the stream, but you have to do a hell of a lot of work (with power comes responsibility). Kind of a hassle. WSDK in the raw: you can write custom SOAP handlers, and it's a little easier (for example you get a SOAPEnvelope class that's better suited to your needs than plain old XMLWriter). But it's still "all you". So, on to Extreme WebMethods: Building from scratch is fun Gives choice of programming models Supports other folks' extensions Better tool support Requires other adjustments. WebMethods will: dispatch messages generate WSDL marshal parameters Code and presentation available here. 2:48:44 PM

I drink all the flavors of koolaid. When I got out of high school, I worked in "food service" (Burger King, to be precise). Like a lot of people in food service, I would fill my cup with Coke, Sprite, orange soda, etc. to make a unique drink out of all the flavors. Little did I know that was a metaphor for the way I approach computing: a little .NET and Windows, some Java, Linux, FreeBSD, and maybe a big dose of one flavor in particular (Mac OS X). 12:51:18 PM

Mindreef's Mark Ericson and Dave Seidels on Web Services Diagnostics at Web Services DevCon, Day 2 Web Services diagnostics: Not just debugging code, but debugging data. Monitoring (I use Ethereal): They are monitoring a Dining Philosopher's (deadlock) scenario with Simon Fell's proxyTrace. Logging: Sticking messages in the HTTP header is the Web Service equivalent of printf. You can open log files and dump info + timestamp to them, but how do you correlate it to a given client? Log4J, LogKit, JDK 1.4, .NET's trace object, etc. WSDL management: WSDL's out of sync; use IBM AlphaWorks' XMLDiff (Microsoft has something like this, too; I use W3C tidy -xml + diff for XML comparisons). Visualization: they are showing Mindreef's SOAPscope. Validation: Does WSDL match the spec? Does the message match the WSDL? They are showing SOAPScope again, and mentioned WS-I Analyzer, coming out in the future. Ideal WS Diagnostic Tool would combine everything they've shown, and would be non-disruptive (doesn't need changes to code, doesn't interrupt normal operations), and be OS-, Language-, Toolkit-, and Transport-independent. Their SOAPScope sounds like an interesting tool. 11:32:24 AM

Yasser Shohoud's session, the Right Way to Build Web Services at Web Services DevCon, Day 2 Yasser asks: "Anyone here create WSDL by hand?" (About 5 people). That many would be surprising anywhere else :-) He's put together a schema for current weather. His web service will take a zip code and return the weather conditions. He's written this as hand-crafted WSDL, and he's generated a C# file with wsdl.exe. This is not a client class, but the web service itself. So, he started with a schema, wrote the WSDL, generated the web server class using wsdl.exe, fleshed out the implementation, and served up the hand-written WSDL. A better way of building web services? Yes or no? Lots of folks seem to think so. It may be a better way, but the tool support is not there. Why don't web service dev tools have a WSDL editor? Why do we start with implementation instead of the interface? Some third party WSDL-editing tools are mentioned, but he says that WSDL is only part of the problem. Complex web services have lots of files, lots of manual work to make stuff look seamless. In a nutshell: It's better to start with the interfaces, and the tools need to support programmers who want to work this way. 10:47:14 AM

Don Box's Keynote Web Services DevCon, Day 2. My notes are too big for the main page, so I've done them up as a story. (They are kind of rough and subject to change as I correct any errors I find in my notes.) 10:03:33 AM