Message API

[James Snell <js...@lemoorenet.com>]

Ok, here are the three interfaces that I'd like to propose as the Axis
Message API.  I've got a DOM-based SOAP implementation of this API 95% done,
but I'm going to hold off on posting any implementation code until we get a
better idea of which parser implementation we want to go with.

Here are the goals for I was trying for:

   1. 100% Protocol agnostic.  In other words, this API doesn't matter if
it's being used to read SOAP, XP, etc.  It defines that a Message as a
Header, a Body and optionally Attachments. Axis would ship with a SOAP
implementation of this API to allow Axis to process SOAP Messages.

   2. 100% Parser implementation agnostic.  There are no dependencies on
DOM, SAX, or any other parser implementation in the API itself (although
specific implementations of the API may force requirements on a particular
parser or type of parser).  You'll notice that this API doesn't even require
that the underlying message be XML at all.

   3. Simplicity. This API is as simple as I could possibly make it.  3
interfaces is not too bad no?


A couple of things that you won't see in this API:

   1. The encoder/decoder architecture.  Once we figure out exactly how to
do this, I'll add the methods for decoding/encoding MessageElements into
native Java Classes, etc.

   2. MessageReader/MessageWriter.  After implementing these, I came to the
determination that while they were useful, they did not add enough value to
justify modifying the existing paradigm.  The single Message Class worked
just as well.

As usual, I await your rants/criticisms/praises/etc.

- James

CVS

[James Snell <js...@lemoorenet.com>]

Would anybody happen to know why I suddenly can't make any changes to the
CVS tree? Whenever I check anything out everything is marked read-only and I
get some kind of unspecified error when I try to commit anything.

- James

BasicHandler, handler options

[James Snell <js...@lemoorenet.com>]

Another modification needed:

There is currently a bit of a mismatch between the way handler configuration
parameters are set up in WSDD and the way they currently work in the
codebase.  There are basically two problems:

1. Scoped Parameters:

    When Steve and I designed WSDD, we had assumed that all handler
parameters had a defined scope.  Given the following example:

        <deployments xmlns="http://xml.apache.org/axis/wsdd">
            <serviceConfiguration name="Some_Service">
                <parameter
name="serviceParm">Some_Parameter_Value</parameter>
                <flow flowType="request">
                    <parameter
name="flowParm">Some_Parameter_Value</parameter>
                    <chain>
                        <parameter
name="chainParm">Some_Parameter_Value</parameter>
                        <handler id="myHandler">
                            <parameter
name="handlerParm">Some_Parameter_Value</parameter>
                        </handler>
                    </chain>
                </flow>
            </serviceConfiguration>
        </deployments>

    Each of the defined parameters could be scoped as:

    serviceParm -> Service Scope, applies to the entire service
    flowParm -> Flow Scope, applies to the entire flow
    chainParm -> Chain Scope, applies to the entire chain
    handlerParm -> Handler Scope, applies to the individual handler

    All "downstream" elements in the serviceConfiguration should have access
to read all inscope "upstream" parameters.  That is, the "myHandler" handler
should be able to use the following:

    getOption("handlerParm")
    getOption("chainParm")
    getOption("flowParm")
    getOption("serviceParm")

    As is stands now, "myHandler" is only able to return the value of the
"handlerParm" parameter.

    Please let me know if that made any sense or not ;-)

2. The second issue is that Parameters in WSDD have the notion of being
"locked" or not.  The value of a "locked" parameter cannot be modified at
runtime while a service is being invoked.  Rather, a locked parameters value
can only be changed during deployment or configuration of the service.  The
value of unlocked parameters may be modified at any time.  Currently, all
configuration parameters can be modified at any time.