axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: [axis2] proposal for a milestone (M1) release
Date Wed, 24 Nov 2004 20:44:29 GMT
I'd add my +1 with a condition that we have a good test harness to go with it :)

-- dims

On Thu, 25 Nov 2004 02:18:05 +0600, Sanjiva Weerawarana
<> wrote:
> Hi Guys,
> I'd like to propose that we do a milestone release of Axis2 ASAP, say
> around year-end.
> Motivation: While I was out at ApacheCon a few weeks ago I found out
> that there are now at least 4 *new* open source SOAP impl projects
> that have recently started. Their primary motivation: Axis1 doesn't
> cut it for the raw XML-centric, performance-focused base SOAP processing
> they want to do. I'm convinced we can do a milestone release that
> meets most of those requirements with what we've got now.
> Features:
> (1) OM interfaces supporting the base SOAP Infoset (i.e., without MTOM)
> (2) OM implementation
> (3) Engine supporting
>     - "phased handlers" architecture complete
>     - burnt-in concepts of WS-Addressing, suitably abstracted to make
>       sure system can run with or without WS-Addressing headers
>     - ability to deploy modules consisting of one or more handlers
>       slotting into various phases
>     - servlet HTTP transport
>     - native HTTP transport (use code from SimpleAxisServer?)
>     - support for ReplyTo style redirection even for HTTP cases
>     - hot deployment of services
>     - no service isolation
>     - no data binding
> (4) Programming model for service implementors
>     - Only Java code supported
>     - For WSDL 1.1 request-response style operations:
>         - Blocking:
>             Option 1: OM doFoo (OM)
>                 (Basically take in an OM and produce an OM. This is good
>                  for anyone who just wants the payload to play with and
>                  wishes to produce a payload to ship out.)
>             Option 2: MC doFoo (MC)
>                 (Basically take in the whole message context and produce
>                  an MC .. which is the programming model for a handler
>                  too I guess!)
>         - Non-blocking:
>             void startDoFoo (MC)
>                 (App gets the message and when its ready to send the
>                  response (using the same thread or another thread or
>                  whatever), uses the client API to send it. Note: Method
>                  may return without having completed the response writing.
>     - For WSDL 1.1 input-only style operations:
>         - void doFoo (OM)
>         - void doFoo (MC)
>                 (App can consume just the payload or the full MC.)
> (5) Programming model for clients
>     - Blocking and non-blocking programming models (sync/async)
>     - Details TBD
> (6) Deployment descriptor for services: service.xml (as discussed in Wiki)
> (7) Deployment descriptor for engine: engine.xml (as discussed in Wiki (?))
> (8) Deployment descriptor for modules: module.xml (as discussed in Wiki)
> (9) Packaging/directory hierarchy for engine: as discussed in Wiki
> (10) Design docs, architecture docs, user guide update sufficiently to
>     allow people to play with the M1 release.
> IMO we're nearly there already. The OM interfaces have stabilized
> now, except for MTOM and data binding stuff. There are several protos
> of the engine with phased handlers. The deployment stuff exists with
> ability to compute handler chains etc..
> Before the next milestone I'd like to carefully evaluate whether the
> engine can re-use code from the Geronimo core kernel - which offers
> a code management framework, a class loading structure and the GBean
> approach for writing IOC (inversion of control == cool these days ;-))
> style code. However, that can wait for the next milestone.
> Note that doing an M1 release does not mean that anything is frozen.
> It just signals to the world that the Axis2 community is alive and
> that its heart is beating. (I view it as something like a working
> draft produced by a W3C working group.) If people find the function
> and performance provided by the milestone useful (or not useful)
> that'll be good feedback to us.
> What does everyone think? If there's general consensus I'll nominate
> Srinath for the release manager job :-). We don't need a formal
> release plan for a milestone, but since this is the first milestone
> I'd like to document our objectives and do the release when we get
> there .. rather than do it ad hoc-ly.
> Obviously I'm +1 for doing an M1 release with the above features.
> Sanjiva.

Davanum Srinivas -

View raw message