Explanation of recent commit, and random thoughts

[Sam Ruby <ru...@us.ibm.com>]

Current status: one can deploy the StockQuote application, invoke it, and
the server will send back the correct data - unfortunately without an
xsd:type, and the client seems to treat the result as null.

Prior to the previous commit, the server was trapping trying to invoke the
StockQuote application.  The reason was the classname was null and there
isn't much in the way of error checking at the moment.  The reason why
classname was null is that options were not being passed to the
AdminService.  The reason why options were not being passed is that
RPCParam did not serialize untyped XML that it had recorded.

I've roughed in the ability for an EventRecorder to output it's content to
a SerializationContext.  Alternately, I could have made
SerializationContext extend org.xml.sax.helpers.DefaultHandler and utilize
EventRecorder's ability to pump out SAX events, but the
SerializationContext looked like it already had similar methods designed
for a slightly different purpose.  Suggestions welcome.

====

Discussion topics (popping the stack - warning subsequent issues may
invalidate prior ones):

EventRecorders should contain balanced XML.  At the moment they seem to
have the end element but not the initial start element.

A DOM Node should be considered instead of EventRecorder - if we need to
record SAX events, we probably should do it in a standard manner, and there
already are considerably instance proofs of SAX to DOM and DOM to SAX.
Besides, obtaining the structured XML data as a DOM tree is a common use
case.

RPC Param shouldn't be used anyway to process a message.  We need to
identify the type of service earlier and handle appropriately.

With a stack of SAX content handlers, we shouldn't need a separate thread
for parsing.  A common SAX handler can delegate events to the SAX handler
at the top of the stack, which can push new handlers on the stack when it
encounters nested elements, or can pop itself off when done.

- Sam Ruby