Crudlets: Making Peace Between Extreme Jini and XML Viewpoints

As a follow-up to the ONJava feature, Jini as an Enterprise Solution, Dave Sag proposes Crudlets as a compromise to the extreme Jini and XML communities' perspectives, as evidenced by his use of Jini-Fascists and XML geeks. Crudlets is an open source architecture essentially based on an Apache Cocoon and XSP Tag Library that maps to seven fundamental events performed by Jini agents. It's his view that Crudlets should be a mutually beneficial architecture that combines Jini and XML. For commonality and simplicity, these two technologies are compatible as enterprise development alternatives to the complex, sometimes proprietary and expensive EJB and, at times, problematic JSP. Therefore, Jini and XML should be a happy medium that can appease both sides. Enjoy.

In December last year I attended the 5th Jini Community Meeting in Amsterdam. I was there to announce the opening of the source code to the Crudlet architecture that underpins the Risk2Risk's eRex Risk Trading Exchange. The Crudlet architecture is essentially an Apache Cocoon XSP TagLib, providing a set of XML tags that map to seven basic events that can be performed on any compliant JavaBean connected to a backend JavaSpace and ensemble of small Agents. Crudlet has core primitives such as a User and basic userAuthentication logic. As such it is an XML tag library providing the functions of an "application server". It is compatible with other XSP TagLibs such as standard sessions and so forth which makes it very flexible. We chose Jini services over EJBs because Jini's architecture is simpler, easier and ideal for a more component like, dare I say it, XP approach to development (see Jini as an Enterprise Solution).

So it was a surprise to get to the Jini conference and to discover such naked hostility to XML. Reactions as extreme as "That Microsoft thing" and XML = SOAP and "that's not Jini, that's just noise". Phew they did go on. A few years ago I had the very cool job of researching Jini and XML and nothing else for 2 months. I'd heard of both and had a vague idea of what they were about. Jini and Javaspaces in particular excited me because I had read David Gelertner's seminal "Mirror Worlds" years ago and so was a little awed to see him endorsing Jini. Suddenly so many things became possible. Service based architectures, ensemble systems, swarm logic, all those evolvable, anealing properties that make for truly adaptive, self improving software.

I used to doodle DTDs and example XML languages on my palm pilot on the bus to work. OrigameML is my favourite. XML is a powerful foundation as core to the world of computing as ASCII was and UNICODE now should be.

XML interested me because I could see the sense in defining a language to represent things, rather than in defining an abstract class or object. Tag languages are describing languages, not executed things. But of course they can describe things that are then executed. Many people I spoke with matched their utter distaste for XML with their Jini Isolationist policy. For them the pure world order will be Jini running on everything, going Borg on your microwave, light bulbs, implants and the ubiquitous networked toaster. Someone gave a great demo of a Jini enabled Volt Meter that was cool in a hardware nerdy way.

The thought that people may still be using browsers was "so last century". But we needed to deploy an Enterprise-strength peer-to-peer trading exchange without having to force our clients to run to their IT departments to install a client app on their desktops. Browsers were our best and only hope.

XSL is a very powerful tool for transforming XML documents, and XML documents are easy to spit down an SSL secured pipe. The Jini Security Model is still a while away for those of us billing by the hour and a way of getting from one Enterprise to another is an essential requirement for a realtime P2P application. This thought is mostly lost on the 'There can be only one" mindset of many of the hard core Jini developers with their "Highlander" style rhetoric.

XML can be usefully pgp encrypted and emailed. That is a core advantage. XML is a vessel for the essence of an object but not its behaviour. The Crudlet TagLib reflects that notion. It allows you to specify a JavaBean by its fully qualified pathname and, if that bean conforms to the Cudlet Interface, direct it to respond to seven events; Create, Retrieve, Update, Delete, Lifecycle, Exists and Template. The events repopulate the XML with a structure giving access to the various properties within the bean, as well as information such as a property's editor class and some hints as to what the property should be used for. Edit modes such as ROM (Read Only Mode) and so on add to the fine grain control the XSL stylesheet writer has over the final presentation of the resulting XML.

Jini's incredible capacity for modularity make it a cinch to develop small bits at a time on a 'whatever makes the most money for you the fastest' basis and by tight control over its interface you know that it will all hang together. That's enshrined in the SCSL (pronounced Scuzzle). Thou shalt not mess with the Interface and still call it Jini. And for good reason. Imagine if Lego said, okay everyone, you can all make Lego bricks and make the dots whatever shape you like.

So many very cool things are happening in the Jini department, it's mind-blowing. The Javawulf project was disclosed in December where they used Javaspaces to network together a room full of machines in an ad-hoc cluster, running generic worker-slaves. They then loaded the cluster with a full scale Boeing 737 and performed a complete Crack Stress Analysis on it at around 7 teraflops.

They drop bits of the whole model into the space in chunks and the worker-slaves pick 'em up, process 'em and drop the results back in a result space. The whole work unit can be wrapped in a transaction such that, if say the worker dies, the whole process can be safely aborted and the job is over when the job bag is empty. Add another machine and get more agents on the case. That's as linear scaling as you'll ever get and because the space and the agents are mutually self discovering across the network it is almost IT department free.

Jini is rushing headlong into the same space as the massive, unwieldy and problematic EJB dinosaurs posing as one-stop-shop application servers that use sleazy "big 5" consultants to pitch their Enterprise Solutions.

Jini's fundamental advantages are that it works consistently and reliably across unstable heterogeneous networks that have been secured behind a firewall. And that it is free, the source code is open, the licence is unrestrictive at one layer and tightly controlled at the root which keeps everything interoperable. Compare this to ORBs where they are only slightly different in their implementation of the CORBA spec.

EJBs can't be multi-threaded where as almost any object can become a Jini service. EJBs are overly complex, expensive to build, serve and maintain, largely proprietary objects.

Jini's raw cost benefits and time to market advantages are what will power it into the corporate arena.

Jini-fascists argue that because Jini is so cool, it will take over the world. That it will bring to fruition David Gelertner's vision of a universal 'tuple-space' where gazillions of tiny software agents pluck little notes at their own whim, or the whim of their controller. And do things to them like match them, or record them, or archive them, or simply watch them.

Jini-fascists argue that XML is all about defining standards and is a clumsy way to represent anything. They are right on both counts but that's not really important, as XML done properly is about defining ways of describing things and permitting a common code base to map that Human Readable text into a Java or C++ (and others) binary object as required. Java's ability to define an interface and then cast a serialised object into being an instance of that interface, and thus being able to run that data's methods is it's power. XML is a Human Readable serialisation system. It's an established W3C standard. My mom used to claim that the WHO was a commie plot. And the WCC. Similarly I spoke with Jini-fascists who argued fervently that XML was a Microsoft plot to rule the world. Possibly it is, but as William Gibson said, "The Street finds its own uses for things."

On the other hand XML geeks are a curious and very academic band, the hobbits under the bridge of the information superhighway. Reading DTDs for EBXML for example would kill most thinking people. It takes a special mind to be able to digest these incredibly detailed specifications. You can't readily inherit from one XML document to another without transforming it somehow so they can get very large, unreadable and unwieldy. It's this clumsiness and perceived myopia that the Jini people object to.

The real truth of the matter is that you can hire designers with HTML and perhaps some XSL experience for much less than Java programmer. Most Java programmers can pick up XSP and XSL in a few days, even though many of them are a little challenged in the user interface department.

We needed a convenient way of spitting our business logic into XML and thus using XSL and Cocoon, to generate web pages in real time. Of course we soon realised that a better way was to get the XML to know how to request the bits it needs.

We could have done the same thing with JSP. Tomcat supports JSP fine, so why complicate everything with XML? The reason was one of Separation of Powers. Much like the separation of Church, Policy and Enforcement enshrined in the Westminster System, there are very good reasons why you wish to keep a loosely coupled underlying architecture apart from JavaBeans which describe the business logic and user interface support classes. Equally you wish to keep these layers apart from the presentation of the information, and again you wish to perform very selective modifications to that presentation based on the dynamic content exposed by introspection of the underlying beans. The beans serve as vessels carrying primitive objects into the wide open JavaSpace. In our instance we used the basic Outrigger implementation of the JavaSpaces interface but in theory it is 100% interchangeable with other implementations such as j-space.

JSP solutions are notorious for their capacity to feature creep until a clean front end architecture becomes a morass of quick Java hacks to overcome, or override shortcomings in a bunch of proprietary objects. Presentation and application logic gets hopelessly intertwined because the alternatives are disciplined work. JSP is not a standard, no matter what anyone says, and every time I hear people are using it my skin crawls, akin to when I hear that people still use Perl.

Web browsers are of course stateless and so is the connection between the JavaBean and the JavaSpace. In our model the Primitive is matched on a Primary Key much like a database, but if retrieved by an agent of course its methods come with it because it is a real object requested by something that knows what it can do in advance. The Beans provide a software layer that controls access to the Primitives.

The Crudlet interface specifies a method called performCRUDAction, which takes as a Parameter a CRUDEvent. The event carries a structure called a BeanDetail, containing slots for any conforming Bean's properties. The BeanDetail in turn carries a CRUDMode which indicates the mode of use of the Bean. In this instance the following code is part of the UserAuthenticationBean.

public boolean performCRUDAction(CRUDEvent evt){

// if a retrieve of this bean with a properly set username and password is
// successful in returning something from the space, then it authenticated.

switch (crudMode) {
case CRUDMask.RETRIEVE: {

Serializable primaryKey = ((CrudletEntry) primitive).getPrimaryKey();
((CrudletEntry) primitive).makeNullTemplate();
((CrudletEntry) primitive).setPrimaryKey(primaryKey);

space.CRUDPerformed(evt);
break;
}
default: {
Messenger.debug("This is NOT a Valid CRUD Action.");
break;
}
}
return true;
}

That's about it, sans some adminsitrivial code such as try-catches. If the matching user was retrieved from the space by space.CRUDPerformed then off you go. Business logic can be slotted into that switch statement allowing manipulation of the User primitive that is returned from the space.

Agents that happen to report to web browsers can do so by conforming to the standard Servlet API. The Crudlet tags give you a structure for short-cutting the process of Servlet development by using Apache Cocoon as an enclosing Servlet, wrapping a page object generated by the content of the supplied XML.

Agents that send email messages dropped in to the space can use an XSL stylesheet to format the message, or not as they see fit.

By striving for commonality and simplicity both XML and Jini are mutually compatible tools and will be as long as designers resist learning to write software, and people still demand customised printed reports. I agree that the day may well come when Jini will render XML redundant, but the great thing about XML is that it is a forward compatible language. A style sheet can turn an XML file into a Jini service as easily as a child can strap itself into a VR MechWarrior Suit.

Cocoon and Tomcat are released under the Apache Free Licence, Jini is released under the SCSL, and Crudlet is due for release under a localised variant of the SCSL. Crudlet represents a mapping between XML and the JavaSpaces API that accounts for the statelessness of the interaction without adding to the overall complexity of the Interfaces. It was developed as part of Risk2Risk's "eRex" web based Facultative Reinsurance Trading Facility which went live on the morning of 1 Feb 2001.

Dave Sag is a skilled Object Modeler and Software Designer, using Java as well as other programming environments.

Return to ONJava.com.