||Friday, October 11, 2002
Clemens Vasters' The XML Web Services X-Files: Tales from the
at Web Services DevCon,
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:
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,
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.
Keith Ballinger's talk on .NET Web Service Security Support
at Web Services DevCon,
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)
- 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!
Eugene Kuznetsov's talk on Network Infrastructure Requirements for Web
at Web Services DevCon,
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.
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
- 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)
Tim Ewald's session, Building Web Services with System.XML
at Web Services DevCon,
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.
- 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.
- dispatch messages
- generate WSDL
- marshal parameters
Code and presentation available here.
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).
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
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
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.
Yasser Shohoud's session, the Right Way to Build Web Services at Web Services DevCon,
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
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
A better way of building web services? Yes or no? Lots of folks seem to
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
In a nutshell: It's better to start with the interfaces, and the tools need to support programmers who want to work this way.
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.)
© Copyright 2002 Brian Jepson.