WebServices - Axis
WebServices - Axis -

Notes from Axis Face-to-Face Meeting at Allaire, Newton, MA.

Date: 28 Feb 2001

Attendees:

Glen expressed some frustration at the lack of good tools that Apache provides for project management. The mailing list archives kind of bite, etc. SourceForge seems to have good tools for scheduling / task management / collaboration...

ACTION ITEM : Glen will email Sam and ask about the possibility of "co-locating" the project with SourceForge? Investigating other tools and solutions?

Waquar Sadiq from Vitria, a new member of the team, volunteered to be Project Manager for Axis! (applause applause)

Steve presented a short Powerpoint presentation to frame the meeting.

Axis 1.0 will be a serious product. As such, it will have:

Goals for the 1.0 release:

Support for requestor/provider/intermediary (one-way, initiated by either side); client notification. Support for request/response and the other 3 transmission primitives from WSDL

Glen : Don't think we should make the axis-user list until 0.9 or beta 1.0...

Issue : Migrating from Apache SOAP to Axis - should be easy, but how easy?

Waqar: We should be tracking ebXML as well as XMLP...

Testing/Process-related discussion...
The plan for the rest of today:

Requirements discussion

Discussion of metrics - some arguments as to whether it's a Handler or an API. Well, logging is an API, maybe metrics are as well...

ACTION ITEM: Glen will investigate JRun's metrics API and share with the group.

We need to have some kind of "Required header" parameter either in the WSDD or as an API in the Handler itself if we want "pre-flight" knowledge of required headers (and perhaps a default fault response)...

Big discussion about header handling - jukebox handler, there were worries that it's a security risk. Glen notes that the handlers that are in the jukebox's registry are limited, just like the handlers on a chain, you just don't need to call them all in order...doesn't seem like a risk.

Day 2

1 March 2001

Attendees: Agenda (wish list):

Code on BOTH client and Server looks like this?

Handler handler = Axis.getHandler(name1);
MessageContext mc = new MessageContext();
// set up MC properties, including target!
handler.invoke(mc);

Requirements review, continued

Streaming Parser Discussion

For reading in input, we use the PDOM model -
We have either a SAX event source or a pull parser underneath something that looks like JDOM.
In the SAX case:

  1. a thread starts processing the SAX event stream, and blocks until told to continue.
  2. When people ask for a particular element (i.e. getNextChild()), the parser thread unblocks, and runs the SAX event stream through, building up the JDOM object model, until it gets to the desired element/attribute/etc. Then it blocks again, and returns control to the getWhatever() API.

Sot the Message API gets: (or maybe JDOM gets the latter three)

getAsElement()
parseAsSAX(SAXHandler)
getAsXMLStream()
getAsByteStream()

Does getAsByteStream() terminate the option of doing anything else afterwards?

How do we test this? Metrics:
  1. Use PDOM, read first few elements, then stream rest to file
  2. Use JDOM, process first few elements, then write to file
  3. Stream bytes from file to file

do this for small (1K), medium (50K), and large (10 meg) files

On the output side, we should be able to setAsStream, and hand the element a stream which will eventually be pulled for content when someone does a getAsStream() on the whole doc. This means a proxy stream which clunks its way down the message, draining streams it encounters along the way.

Open question - is it easy/efficient to get a JDOM Element as a stream/string, as opposed to a whole doc? Looks like Element.getSerializedForm() isn't implemented yet?

Pull parser discussion - if possible, a real pull parser would avoid the multi-threading, and probably perform better than the SAX-based PDOM model. We'll look into this!

Project Participants: