axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaliya Ekanayake" <jal...@opensource.lk>
Subject RE: [axis2] proposal for a milestone (M1) release
Date Tue, 30 Nov 2004 03:16:00 GMT
+1 For the M1 Release. 

Jaliya

-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk] 
Sent: Thursday, November 25, 2004 2:18 AM
To: axis-dev@ws.apache.org
Subject: [axis2] proposal for a milestone (M1) release

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.





Mime
View raw message