You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2004/11/24 21:18:05 UTC
[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.
Re: [axis2] proposal for a milestone (M1) release
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Oh yes of course! I forgot that cruicial part .. absolutely, a solid
test harness is critical.
Sanjiva.
----- Original Message -----
From: "Davanum Srinivas" <da...@gmail.com>
To: <ax...@ws.apache.org>
Sent: Thursday, November 25, 2004 2:44 AM
Subject: Re: [axis2] proposal for a milestone (M1) release
> 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
> <sa...@opensource.lk> 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 - http://webservices.apache.org/~dims/
>
Re: [axis2] proposal for a milestone (M1) release
Posted by Srinath Perera <he...@gmail.com>.
+1 for the proposal, the solid test cases are must.
Srinath
On Wed, 24 Nov 2004 15:44:29 -0500, Davanum Srinivas <da...@gmail.com> wrote:
> 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
>
>
> <sa...@opensource.lk> 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 - http://webservices.apache.org/~dims/
>
Re: [axis2] proposal for a milestone (M1) release
Posted by Davanum Srinivas <da...@gmail.com>.
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
<sa...@opensource.lk> 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 - http://webservices.apache.org/~dims/
M1 and AXIS2 moularization [Re: [axis2] proposal for a milestone
(M1) release
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>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.
>
>
sounds good. +1
>Features:
>(1) OM interfaces supporting the base SOAP Infoset (i.e., without MTOM)
>(2) OM implementation
>
>
i think MTOM *should* be included. MTOM and data binding are important
if you want to integrate AXIS2 into bigger frameworks.
i would like also to make AXIS2 even early prototype very modular so if
somebody is happy to program WS simply as XML over HTTP they should be
able to take OM and fire their XML docs through HTTP to their heart's
content (and my content!)
to do this i propose to split source code into set of modules compiled
in order of their dependency: OM compile first, WSDL (depends on ON),
handlers (depends on WSDL and OM) and so and dependencies enforced by
having build output go to different classes dirs. - this way by doing
build one can check that no hidden dependencies were introduced - for
example consider this:
<target name="common" depends="init">
<javac srcdir="${src_common}" destdir="${build_common}" debug="on" source="1.4">
<classpath refid="common_libraries"/>
</javac>
</target>
<target name="client" depends="common">
<mkdir dir="${build_client}"/>
<javac srcdir="${src_invoker}" destdir="${build_client}" debug="on" source="1.4">
<classpath refid="common_libraries"/>
</javac>
<target name="server" depends="common">
<mkdir dir="${build_server}"/>
<javac srcdir="${src_processor}" destdir="${build_server}" debug="on" source="1.4">
<classpath refid="common_libraries"/>
</javac>
http://www.extreme.indiana.edu/viewcvs/~checkout~/xsul/java/build.xml
you can see that targets client and server depend on common target and
they do not share destdir and only depend on common_libraries there is
no danger that client and server code becomes intermingled (of source
there are possible exceptions and can be easily controlled by order of
build and by fine tuning classpath and destdir)
this is to avoid current situation that is in AXIS1: when you compile
you have one huge javac - currently i believe something like over 700
classes are compiled at once, all interdependencies leaving no hope for
anybody to create client version of AXIS or lean subset ... and in
scratch/prototype1 there is already 150 java classes ...
how does my proposal sound to you?
thanks,
alek
>(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.
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
RE: [axis2] proposal for a milestone (M1) release
Posted by Jaliya Ekanayake <ja...@opensource.lk>.
+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.
RE: [axis2] proposal for a milestone (M1) release
Posted by Ias <ia...@hotmail.com>.
Just a couple of thoughts from this proposal:
1. SAAJ NG (probably 1.3)
If I can whithin my winter vacaction, I hope to deliver SAAJ NG API and impl
based on Axis 2 core in this release.
2. JAX-RPC 2.0 with JAXB 2.0
I also wish to add JAX-RPC 2.0 + JAXB 2.0 API and impl, which enable you to
create a (simple) web service with annotations.
The priority is SAAJ NG first :-)
Thanks,
Ias
P.S. Of couse, +1 for the proposal.
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
> Sent: Wednesday, November 24, 2004 8:18 PM
> 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.
>
>