August 27, 2004
Back from vacation
I recently got back from travelling to a small island (Sonora) between Vancouver Island and the mainland of Canada. It was super relaxing and totally off the grid. Here's a picture as we left the harbor on the water tax.
Data Binding in Web Services
Often when using webservices you are confronted with a decision on how to bind the XML Schema you have into java. If you are starting with a WSDL you can either bind each complex type to a DOM or to a generated java class. Each method has its advantages and disadvantages. Fine-grained binding into java is nice if you are going to use each data type in the application, are satisfied with the default binding and are planning on writing a lot of java centric logic. Use DOM when you want to delegate to a different binding solution (say JAXB rather than using JAXB types) or you want to only use standard XML tools on the data types.
For example your method signature could be
Foo echo(Foo complexObj);
DOM echo (DOM complexXML);
Don Box has made the point that probably web service engines like Indigo should be in the business of routing, reliability and security and be out of the business of data binding. At first I thought this was wrong but then I realized it was a really nice factoring of the plumbing with the data types. Let the WebService engines deal with the messages and then delegate the type resolution and binding to a later stage.
August 26, 2004
XML has three basic patterns that I've seen:
- Configuration Data
- Data Description
- Programming Language/Scripting Tool
In Weblogic Server we use XML to describe our server configuration.
<Server> ... config data ... </Server>
XML can clearly be used to describe data and is often seen in rows
Ant is the best example of using XML for scripting.
August 25, 2004
What's new in the next version of WebLogic WebServices?
An interview I did for dev2dev.
Multi-Protocol Web Services
Most protocol processors like to process the headers and the bodies differently. If we look at HTTP, a very standard thing to do in your servlet engine is write a ServletFilter that processes the headers and routes the body without ever parsing the message. HTTP has a very nice separation of headers and body. This allows streaming filters to process the headers and not touch the body. Strangely enough SOAP starts to complicate this picture. If we were just passing XML then there is still a clear separation between the message body and the headers. However with SOAP over HTTP we get this strange behavior where you actually have to read the SOAP headers and then read the SOAP body.
Since SOAP is tag-delimited XML you don't even know if the body is well formed unless you parse the whole thing. And most parsing standars require you to parse the entire XML document (SAX/DOM). StAX is an exception to this rule.
So most SOAP processors have a very hard time doing what comes easy with HTTP (just looking at headers and passing along the body to do routing).
What went wrong with WebServices?
So what went wrong with web services? By this point we were supposed to be riding the ground swell of the huge wave. I've been working on web-services for about 4 years and watched the hype and heard all the promises. Initially the watchword was "don't make the mistakes of corba". But as the standards have grown we have repeated all the mistakes. I think there are three fundamental problems with WebServices:
- WSDL (too complex)
- Multi-protocol support
WSDL WSDL is just too complex and references XML Schema. These days people are just documenting there WebServices by hand and not using WSDL to describe them.
XML-Schema We just need to move to Relax-NG , enough said.
Return to HTTP I think the multi protocol step was a bad one. We should have defined Web Services as XML over HTTP and left it at that. Removing DTD's was a good thing and SOAP provides some nice extensibility but you are only ever going to interop with the basic SOAP/XML over HTTP. The move to multi-protocol support has led to the corbafication of web services.
August 24, 2004
Cool place to list your favorite books
XML is a bad transport for XML
In general XML is a bad transport for XML. Often when you transmit XML your first inclination is to use SOAP or Web Services. This has the funny effect of making a very inefficient transport for XML. Here is why: It's actually invalid to have certain characters in the Character Data section of XML. This means when the SOAP processor writes the XML characters of the document you want to pass into the SOAP body it has to check that there are no '<' and other inadmissable characters in the XML you are passing in the SOAP message. This leads to some slow processing.
August 23, 2004
Welcome to the blogosphere....
This is my first blog entry. I'm planning on blogging about technology I'm interested in as well as random facts in my life. In general I'm interested in XML, WebServices, Search and Collaborative Filtering.