netzooid

Thanks to the help of Hani Suleiman and Hiram Chirino, I got an XFire JMS transport working yesterday (having zero JMS knowledge the day before). Check it out if you’re at all interested in a reliable transport for SOAP. I’ll try and get some docs up in the next couple days which shows how to use ActiveMQ’s Spring configuration and XFire’s Spring configuration together.

As a sidenote, let me add that Active MQ rocks! Not only is it “crazy fast” as James says, its “crazy easy” too. I was to embed it into a test case with about 5 lines of code. Definitely check it out if you have a need.

Davanum Srinivas:

Verisign has graciously initiated the process for donating TSIK to Apache. As part of the process, we started discussions on legal aspects and found that any one who implements WS-Security needs licenses from IBM and Microsoft. Note that this does not only affect TSIK incubation, but also the existing Apache WSS4J project.

This is no good, no good at all…

Reading David Chappell’s latest newsletter:

To understand why a service-oriented world implies an explicit role for access, think about why these different parts of an application exist at all. Arguably the biggest reason is that each uses a different abstraction, and so crossing from one to another requires mapping between these abstractions. For example, moving between data and logic typically requires translating from relations to objects. This translation—restructuring data from tables into objects and mapping from SQL types to programming language types—is a well-understood, if still painful, problem.

[Image reproduced here from David Chappell’s website]

Why the objects in this diagram? Why don’t be build services just over the database? An XML database with XQuery translating back and forth to different services seems like an interesting combination to me.

XFire’s new service model and channel features are something I’ve been meaning to write about for a while (this post prompted me to get off my behind – although I’m sure its not quite what the author had in mind). Warning: Currently this stuff in only in CVS and does not have a lot of documentation. With that said, we’re doing a release soon and I’m starting to work on documentation.

Message Channels

The best way to grok channels is to look at some code.

LocalTransport transport = new LocalTransport();
Channel channel1 = transport.createChannel("urn:xfire:local:Peer1");
channel1.open();

Channel channel2 = transport.createChannel("urn:xfire:local:Peer2");
channel2.setEndpoint(new DocumentEndpoint());

// Document to send
Element root = new Element("root");
root.appendChild("hello");
Document doc = new Document(root);

MessageContext context = new MessageContext();

OutMessage msg = new OutMessage("urn:xfire:local:Peer2");
msg.setSerializer(new DocumentSerializer());
msg.setBody(doc);

channel1.send(context, msg);
Thread.sleep(1000);

channel1.send(context, msg);
Thread.sleep(1000);

channel1.close();
channel2.close();

What happens here is we’re using the LocalTransport to send messages to another channel. Each channel has a unique uri (not url) which identifies them. In this example, the DocumentEndpoint receives messages on the channel and prints them to stdout for us to see. This is all completely stream based so we don’t have to passing around documents if we don’t want to, keeping memory low.

public class DocumentEndpoint
    implements ChannelEndpoint
{
    public void onReceive(MessageContext context, InMessage msg)
    {
        StaxBuilder builder = new StaxBuilder();
        try
        {
            Document doc = builder.build(msg.getXMLStreamReader());

            System.out.println(doc.toXML());
        }
        catch (XMLStreamException e)
        {
            e.printStackTrace();
        }
    }
}

Upon running this you’ll see this come out on your console:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><root>hello</root></soap:Body></soap:Envelope>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><root>hello</root></soap:Body></soap:Envelope>

This is really handy for just sending messages across the wire, routing them around, using as a soap stack base :-), etc. Right now we have local, http, and xmpp support in cvs. JMS support is coming Real Soon Now.

I’ll also be working with a student in the Google summer of code program to implement Reliable Messaging over top of this. One can see how easy it would be. Just create a new ReliableMessagingChannel which wraps an existing transport and sends/resends messages as needed.

Alcholix seems like a neat way to meet people (via Chando Thota). However, living in a very midwesty place there don’t seem to be many nearby bloggers who have registered with feedmap. I put up a list of local bloggers on the left – there are only 22 registered. So if you live in Michigan, register!

The WSDL as the Offshore Contract

From my head: “This is crazy enough that it just might work!”

Complain all you want, but the fact of my life is that I work in both the object and XML worlds. Eventually XML needs to turn into objects and vice versa. This guide explores what the mismatch entails and methods to handle it.

What is the mismatch? I see a three fundamental parts:

1. Transfer: Some XML concepts which don’t map to OO concepts (xsi:nil, xs:any, Faults != exceptions, etc).
2. Versioning: OO software has no versioning concept. This makes our lives really really hard sometimes – when we depend on different versions of the same library for example. XML is much more powerful in this respect. Different versions can happily coexist in the same document.
3. Independence: Our service contract most likely needs to evolve independent of our internal model. However, they are definitely closely related.

DTOs
The most prominent method of handling XML/object conversions is the Data Transfer Objects pattern. The concept is that you have a set of objects which are either created from your contract or are used to generate your contract. You then write glue code which transfers from one object domain (web service) to the other (your internal objects).

DTOs have the advantage in that they’re easy to work with and are often more familiar to the developer than XML/XSD/WSDL.

I see two types of DTOs in use – unified and versioned.

Unified DTO: With a unified DTO pattern, only one set of DTOs is ever used for all versions of your service. The toolkit would be responsible for handling different xml versions magically.

Versioned DTO: The versioned DTO pattern takes this a step further and creates a new set of DTO objects for each schema/WSDL version. This makes its easier on the toolkit when handling schema evolution at the cost of more code to maintain.

DTOs suffer from problems with #1, although the concept mismatch can be minimal depending on how much of xml schema you’re using (i.e. don’t allow nillable schema types on java/C# primitives because an int can’t be null! ). Toolkits such as XMLBeans which handle 99.99% of XML schema can be helpful in this area.

Contract First Development
Some proponents argue that writing our contract first (WSDL and XSD) is necessary for XML nirvana. Usually in this case DTOs are generated from the schema, however you may also just work with the documents as well (see below).

When combined with DTOs this is a double edged sword with respect to XML/object transfer. It helps by ensuring that you use the XML concepts which are best suited to the problem – not the concepts your toolkit happens to support. On the other hand, it may create issues for people consuming your service because you may inadvertently use concepts which don’t work well with other toolkits. This is still an issue currently, although it will become less of a problem in the future as toolkits such as JAXB 2.0 and .NET 2.0 increase their schema support.

Contract first also ensures that your internal model develops independently and gives you a lot of freedom over schema versioning.

Code First
Because of the issues associated with matching XML concepts to OO concepts, some people have called for code first development. The toolkit is then responsible for making sure the code is to XML concepts nicely. It also has the added convenience of being much easier for the OO developer who doesn’t know XML schema very well.

Sidetrack: DTOs and Annotations
When using annotations to control your object/XML conversion: beware. You are limited to the versioned DTO pattern only. Toolkits such as JAXB 2.0 and .NET will really only allow you to map one object to one xml schema.

Working with Documents
Working with documents can be another supposed nirvana of XML. DOM, XQuery, XPath, XSLT, and other XML technologies can be very helpful in processing your documents. I find that this is mostly helpful when your desired output is also XML (i.e. for an XML database). They certainly help with versioning and independence because you have very fine grained control over what happens.

However this doesn’t help you all that much with the transfer problem. In the end you may just be relegated to writing the glue code by hand.

Other solutions

• Don’t use objects. If you believe this to be true, this guide isn’t for you. Sometimes this is right, but a lot of the world is still trapped in OO programming.
• Don’t use XML: Once again, if you believe this, get out of here. XML isn’t right for all cases, but this guide is for the cases where it is right.
• XPath/Object mapping – You could use XPath expressions to match up XML elements to objects and their properties. I have yet to see a really robust implementation of this.

• Has a ton of reverb
• Sounds like it could sometimes be from the ‘80s
• Is nothing revolutionary or new, but highly enjoyable none-the-less
• Lacks anything like their first album, Parachutes
• Has a lot of guitars
• Has some cool parts with an organ

For those ambitious students who are looking for a summer project with a little bit of monetary gain, I would like to draw attention to two projects which I have listed.

1. WS-Security for XFire: WS-Security is a specification to allow portions of SOAP messages to be encrypted. This project would involve adding support for WS-Security to XFire via Apache’s WSS4J library. The challenge would be integrating the two in a way that performs well and is friendly to the end developer. A demonstration of interopability with another SOAP stack would be required as an end goal.

2. WS-ReliableMessaging for XFire: Reliable Messaging provides a reliable communication layer over unreliable channels (such as UDP). With the adoption of Reliable Messaging in MS’s Indigo, this spec is hard to ignore any longer. A demonstration of interopability with another SOAP stack would be required as an end goal.

Why you should choose my projects:

• SOAP is fun, interesting, and challenging
• You’ll learn a lot because I’m going to spend a lot of time working with you.
• I’ll learn a lot (maybe more?) because I’m going to spend a lot of time working with you.
• XFire is the best Java SOAP stack out there! (but I’m biased)
• The projects are both very challenging, yet approachable.

So please contact me if you’re interested!

Tim Ewald

…I reject the notion that XML-centric design requires new languages and / or runtimes. It’s not that those things wouldn’t be useful, it’s just that they aren’t required. If vendors applied more creativity to solving the problems without reinventing the specs, languages, platforms, etc. and if developers were realistic about the extent to which it is possible or even desirable to hide XML, we would get to a much better place without starting over yet again.

I still haven’t seen any good way to deal with these issues. One intriguing example was a TIBCO General Interface demo from Jon Udell. There they dragged and dropped xml schema elements on to the objects they wanted them bound to.

Pointers to examples of creativity in this problem space are welcome.