alek blogs

Xydra: easy way to add Web Services to your portal

Xydra is a library that uses servlet to provide XHTML based WSDL invoker. Xydra servlet takes WSDL with XML Schema complex types as input, generates XHTML form to allow user to fill content of input message, gathers submitted input values and converts form name-value pairs into XML message that is sent it to Web Service and then finally displays result message.

One could ask: there are other WSDL invokers so what makes Xydra unique? Here is couple reasons:

• Xydra has pluggable data model and currently two backend to represent form and XML message content One is traditional name-value pairs that are structured into tree (called TreePath) and second that is based on Protege engine to use ontology describing web service to allow more reach constraints and relationship validation (called OntoBrew).
• It is very easy to customize Xydra look and feel: just save auto-generated XHTML page, modify it to your needs and tell Xydra to use this XHTML page as template. What makes it really easy is that template is a regular XHTML page that is used by Xydra processing engine (unsurprisingly called Diesel) to annotate it with runtime information.
• Xydra support complex types and generate nice XHTML form UI for arbitrarily nested XHTML forms.
• You get source code so you can improve it :-)

Sample installation is available online to test drive Xydra. It is open source so anybody can play with it, improve it, and give us feedback, patches are gladly accepted, we may even fix some bugs when reported (good bug report that contains all information necessary to reproduce problem and/or unit test greatly increases chances of getting problem fixed ...)

created Sun July 27, 2003 11:55 PM EST [2003/7/27 23:55 EST] permalink

Comparing XB1 to JDOM ...

This is mini review of "A Design Review of JDOM (A Conversation with Elliotte Rusty Harold, Part III)".

Let see how Xml Pull Builder a.k.a. XB1 (for more details on XB1 see its home page) compares to JDOM based on points raised in article.

A Short History of JDOM

Before we do this few word about XB1. XmlPull Builder Version 1 a.k.a. XB1 is lightweight document object model to represent XML tree that is implemented on to Common API for XML Pull Parsing and alpha version is in XPP3/MXP1.

JDOM Offers Many Convenience Methods

XB1 is currently rather modest API and do not have lot of methods (except for obvious overloading of methods) and that makes API quite simple (at least for now).

JDOM Allows Malformed Documents

XB1 implementation also allows creation of malformed documents or let put it this way: the implementation does not do extensive checks but XB1 API allows implementations that will do those checks (XB1 API is composed of interfaces). BTW: example with control characters is not good as XML allows to have control characters but escaped as numerical entities AFAIR ...

JDOM Ignores Setter Method Conventions

I do not see problem here: JDOM is not Java Bean and chaining methods may be sometimes convenient (but should not be overused). This looks like rather weak complaint ...

JDOM Uses Java Collections

XB1 goes one step even further and it uses Generics for even more natural iterators than mentioned NodeList (currently moving to use future java.lang SimpleIterator interface so idiomatic for(XmlElement el: node.elements()) will work in JDK 1.5) .

JDOM Uses Too Many Checked Exceptions

XB1 has only one exception (at least for now) and it is runtime exception for all reasons mentioned in the article and i woould add one more reason: RuntimeException makes it easier to integrate XB1 into existing code.

Will JDOM Remain Class-Based?

I agree that interface based API is more versatile as it allows to abstract form implementation and allow creating XML tree models directly from other data sources that XML event stream from parser (like databases)

Conclusion

I was disappointed that XPath integration (and good performance of it) was not mentioned. Also I would like to see some tests that compared memory footprint and how easy is to build partial tree: this is very easy with XML pull parsing but quite difficult with push parsing (in SAX it requires provide way to overwrite endElement() callback and in general is as much fun as writing SOAP deserializer with SAX). And as far as future of XML Tree APIs: I would like to see how easy is to annotate XML infoset items with additional information (needs for it emerges with data bindings and PSVI)

But after all what makes and breaks APIs is how programmers feel about them, and I feel good about XB1 when I am using it (nothing to do with the fact that I am author of it of course ..)

created Wed July 30, 2003 8:06 PM EST [2003/7/30 20:6 EST] permalink

This blog is about:
XML, Java, and everything else (or nothing ..)

Find more about
blog author

Blogroll:
Sam Ruby
Russell Beattie
Diego Doval
Joel on Software
and some (almost) harmless entertainment: The BileBlog

Projects::
MicroLogger
Xydra
WSIF
XmlPull API
XPP3/MXP1
XSOAP
XMessages

RSS
0.92 [validate]
2.0 [validate]

Filter Entries:
Life
Java
XML
Computing
Web Services