mult.ifario.us

Boris Lublinsky, a fellow Chicagoan and WS-guy, has an overview article in this month's Business Integration Journal. I assume that the second part will be out next month.

Update: I thought about this a little bit more (and did some experimentation), and some of what I said below is wrong. See a more recent entry for an update.

You never know which SAX you're going to get. For example, on my PowerBook, I get the version from the 1.4.2 JDK by default, and that (according to the source, at least) is SAX 2.0r2pre. Using Xerces 2.6.2, I get SAX 2.0.1.

The difference is an IllegalStateException if a NamespaceSupport instance is used incorrectly, but proper hygeine ensures portable (and correct) behavior. A short digression on how SAX deals with namespaces is in order.

No matter how you set the SAX namespace properties, if namespaces are enabled, you'll get startPrefixMapping and endPrefixMapping events. The startPrefixMapping events occur immediately before a startElement event, and endPrefixMapping events occur immediately after a endElement event. The startPrefixMapping and endPrefixMapping events don't necessarily occur in a particular order or in a nested pattern. (By the way, you care about prefix mappings separately from element and attribute names if you're working with QNames in attribute values or element content, e.g., in many XML schema-typed documents.)

In a nutshell, the guideline for NamespaceSupport is:

Namespaces should only be declared on a fresh stack frame. Specifically, the order of operations for a NamespaceSupport instance is declarePrefix invocations, processName (or other) invocations, and finally pushContext.

Here's why. If you put some code like this in your ContentHandler implementation:

private NamespaceSupport _nss;

public void startPrefixMapping(String prefix, String uri)
    throws SAXException
{
  _nss.declarePrefix(prefix,uri);
}

You'll be pushing namespace bindings onto the current stack frame within the NamespaceSupport instance, and all of this will happen before the startElement event.

SAX 2.0r2pre was more permissive, but SAX 2.0.1 "locks" the NamespaceSupport instance once it is used to resolve a name through the processName() method. So, if you call pushContext() too soon and someone calls processName(), the stack frame will be "locked" when the next startPrefixMapping event shows up, resulting in an IllegalStateException. Thus, in the code for the startElement event, the last thing to touch the NamespaceSupport should be _nss.pushContext() to create a fresh frame for the next round of startPrefixMapping events.

This is perfectly reasonable, since adding prefix bindings might change the way a qualified name's parts would resolve.

By the way, you don't really need to pay attention to the endPrefixMapping events unless you want to check up on the parser or event generator. Instead, just implement the endPrefixMapping method with an empty body and ensure that a _nss.popContext() is the last thing in the endElement implementation that touches the NamespaceSupport.

I came across a FileNotFoundException inside a File.createTempFile() call in an otherwise thoroughly tested piece of code running in a fresh Tomcat (5.0.19) today, and I had to scratch my head for a moment. It turned out that the file that did not exist was the directory specified by the java.io.tmpdir property! The setting was Tomcat-specific but not created explicitly by Tomcat. (Baaaaad kitty...) I arrived at and tested this conclusion without the use of a debugger, but the only way to catch it otherwise would have been to actually step through the innards of the method in the File class.

I'm surely not the first person to stumble on this one, but I didn't find it in the Tomcat changelog or bug database. So I filed a bug report.

Update: Rémy Maucherat pointed out that Tomcat's temporary directory is there when the distribution is unpacked, so while I can affirm that the code runs outside of Tomcat without deleting /tmp, $CATALINA_HOME/temp is getting deleted at some point.

Thus, this is more of a generic troubleshooting consideration than something specific to Tomcat:

The JVM makes no guarantees that the directory specified by java.io.tmpdir exists, and a FileNotFoundException inside a File.createTempFile() call may be attributable to a missing temporary working directory.

The important thing for people to realize is that both individually and collectively, the WS-* specifications are a work in progress. Wwork is ongoing by vendors, by end-users, by thought leaders, to figure out what is important (i.e., useful) through a mixture of implementation and experimentation.

A new specification should be looked at as a proposed experiment. The experiment should be based on a set of well-considered hypotheses and motivated by practical experiences. The history of the accepted standards in the space (e.g., the evolution of SOAP from the initial proposal to the refinements outlined by the WS-I Basic Profile) bears this out, and other experiments (e.g., BPEL4WS 1.1 becoming WS-BPEL 2.0) are being tempered by implementers and collective discussion. The questions in my mind are not so much about establishing the fundamental and forever immutable tenets of Web Services — always an impossible task for any effort — but rather about ensuring that the experiments that we are investing in are properly conceived, controlled, and executed.

An early draft review of the JSR-208 a.k.a. JBI (Java Business Integration) is available for download. In a nutshell:

"JBI seeks to address this problem [vendor-specific integration soup] by creating a standards-based architecture for integration solutions, allowing third-party components to be assembled by the end user."

The key high-level constructs of JBI are:

• An environment is a container that provides a normalized WSDL-based messaging service ("NMS"), deployment, (re)configuration, deployment, and management.
• A service engine ("SE") is a "business logic driver". (This is where WS-BPEL fits into JBI.)
• A binding component ("BC") is a bridge between the internal normalized messaging service of the JBI environment and external protocols such as HTTP or JMS.

In terms of a WS-BPEL process living in a JBI environment, the process would be deployed in a SE that can execute WS-BPEL processes againt the NMS, and the concrete bindings for partnerLinks would be BC implementations.

One of the reasons that I'm excited about JBI is a little bit selfish: the portable runtime container that we built for PXE is similar to a JBI environment, so we've already been working in these terms for over a year... PXE will be available as a JBI component as soon as there are implementations that can host it.

Yesterday, I put together a RNC schema for the legacy version of BPEL, a.k.a. BPEL4WS 1.1. After writing a few processes, I've made some corrections, and I've also put together a RNC schema that matches the current (September 2, 2004) commitee draft XML schema.

Emacs with nxml-mode has become my XML editor of choice, thanks to real-time validation and context-sensitive editing features. The price of the elegance and utility is that nxml-mode requires a Relax NG compact syntax ("RNC") schema, and most of the documents that I work with are defined by XML Schema.

So, with the intention of using Emacs as an editor for WS-BPEL, I put together a RNC schema for the legacy version of WS- BPEL, a.k.a., BPEL4WS 1.1. You can download the schema from here. The schema comes without the 14.3 "enhancements" to assignment enabled, but there is a comment that explains how to make the one-line change needed.

This was my first outing with the RNC syntax, and after a quick skim over the tutorial, the terseness of the syntax is agreeable. For writing RNC, David Rosenborg's rnc-mode was helpful, and nxml-mode will "validate" RNC documents when it loads them. (To specify a schema for a document, use C-cC-s.)

I now have the following in my .emacs:

(setq auto-mode-alist
      (cons '("\.\(xml\|xsl\|rng\|xhtml\|bpel\)\'" . nxml-mode)
	    auto-mode-alist))

and it works like a charm. As a bonus, some of the little differences between Relax NG and XML Schema allow the RNC version performs some validation that the XML Schema is not able to, e.g., knowing the various legal attribute combinations versus all possible attribute combinations on a <bpel:from>.