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 James M Snell <ja...@us.ibm.com> on 2002/10/25 20:38:26 UTC
Re: [IMPORTANT!] Proposed Axis Async Development Plan
Ok.. so now how about the development plan? :-) I'd like to start
working on getting this stuff into the main branch. Phase 1 can be done
in the main branch without affecting any of the existing code. All of the
work would be done in the org.apache.axis.ime package which could be
excluded from the build.
- James Snell
IBM Emerging Technologies
jasnell@us.ibm.com
(559) 587-1233 (office)
(700) 544-9035 (t/l)
Programming Web Services With SOAP
O'Reilly & Associates, ISBN 0596000952
Have I not commanded you? Be strong and courageous.
Do not be terrified, do not be discouraged, for the Lord your
God will be with you whereever you go. - Joshua 1:9
David Chappell <ch...@sonicsoftware.com> wrote on 10/25/2002 10:40:00
AM:
> +1 to that.
> Dave
> James M Snell wrote:
> >
> > Possible interim solution: one of the utility classes would be a
wrapper
> > around the new version of AxisEngine that implements Handler. The
wrapper
> > interface would have the same signature as the current version but
would
> > use the new stuff under the covers. Users would then be given the
option
> > of migrating to the new interfaces vs. using the old version.
> >
> > - James Snell
> > IBM Emerging Technologies
> > jasnell@us.ibm.com
> > (559) 587-1233 (office)
> > (700) 544-9035 (t/l)
> > Programming Web Services With SOAP
> > O'Reilly & Associates, ISBN 0596000952
> >
> > Have I not commanded you? Be strong and courageous.
> > Do not be terrified, do not be discouraged, for the Lord your
> > God will be with you whereever you go. - Joshua 1:9
> >
> > Doug Davis/Raleigh/IBM@IBMUS wrote on 10/25/2002 08:51:03 AM:
> >
> > > Again - AxisEngine will be called by Axis users ("users" in the
broader
> > > sense of the term meaning anyone who wants to write code to work
with
> > > Axis). I know of quite a few people who write their own servlets,
> > > providers and transports - I believe you're talking about changing
> > _their_
> > > interfaces.
> > > -Dug
> >
> > >
> > > James M Snell/Fresno/IBM@IBMUS on 10/25/2002 11:39:15 AM
> >
> > > Please respond to axis-dev@xml.apache.org
> >
> > > To: axis-dev@xml.apache.org
> > > cc:
> > > Subject: Re: [IMPORTANT!] Proposed Axis Async Development Plan
> >
> > >
> > > The proposed changes ARE internal to Axis. They change the
interfaces
> > to
> > > the AxisEngine, Provider and Transport objects which, from the end
users
> > > point of view, will be hidden behind things like the Call object and
the
> > > Servlet, etc. Existing handlers will not need to be modified, just
the
> > > things we typically refer to as "pivots". There are still handlers
and
> > > chains.
> >
> > > - James Snell
> > > IBM Emerging Technologies
> > > jasnell@us.ibm.com
> > > (559) 587-1233 (office)
> > > (700) 544-9035 (t/l)
> > > Programming Web Services With SOAP
> > > O'Reilly & Associates, ISBN 0596000952
> >
> > > Have I not commanded you? Be strong and courageous.
> > > Do not be terrified, do not be discouraged, for the Lord your
> > > God will be with you whereever you go. - Joshua 1:9
> > >
> > > Doug Davis/Raleigh/IBM@IBMUS
> > > 10/25/2002 05:23 AM
> > > Please respond to axis-dev
> >
> > >
> > > To
> > > axis-dev@xml.apache.org
> > > cc
> >
> > > bcc
> >
> > > Subject
> > > Re: [IMPORTANT!] Proposed Axis Async Development Plan
> >
> > >
> > > In some of your notes you've stated that the new messaging pattern
you
> > > want
> > > to do is strictly internal and yet this note would seem to imply
> > > otherwise.
> > > Now that 1.0 has shipped we all know that we must be very careful
with
> > > what
> > > APIs we change but that isn't limited to just the client-side, that
> > > includes ALL interfaces. I'm not against any of these changes I
just
> > want
> > > to remind people that the freedom we enjoyed up until recently is
now,
> > to
> > > some extent, gone. And related to this is the necessity to keep it
> > simple
> > > - never assume that any API will remain hidden from an Axis user. If
> > Axis
> > > provides some plug-point then you have to assume that it will be
used,
> > and
> > > used often - so it needs to be done in such a way that
non-axis-dev'ers
> > > can
> > > use it w/o going to the axis-dev mailing list for help. On the
phone
> > call
> > > the other day I heard a few people remark that "xxxx was only going
to
> > be
> > > used by a small set of people" - that worries me a little because
> > > believing
> > > that allows you to ignore the KISS principle and could hurt us in
the
> > long
> > > run. One of the really nice things about Axis is that when you look
at
> > > what's at its core, its really just a few very simple concepts:
Handlers
> > > and Chains (that's what I see anyway) - and it would be a shame if
we
> > lost
> > > that. So, please it simple.
> > > -Dug
> >
> > >
> > > James M Snell/Fresno/IBM@IBMUS on 10/23/2002 07:04:29 PM
> >
> > > Please respond to axis-dev@xml.apache.org
> >
> > > To: axis-dev@xml.apache.org
> > > cc:
> > > Subject: [IMPORTANT!] Proposed Axis Async Development Plan
> >
> > >
> > > On the phone call today, we discussed the fact that the Internal
Message
> > > Exchange proposal represents a significant change to the Axis
internals
> > > and should ideally be broken up so that it can be incrementally
> > > introduced into the code. Here's my proposal for how to break up
the
> > > work.
> >
> > > Phase 1: Interfaces, Thread Management and Helper classes.
> > > This work can be done without touching any existing Axis code. This
> > > essentially means taking my prototype, tweaking and fine tuning it.
> > > Phase 2: Transport modifications.
> > > This would involve taking all of the current Axis transports and
> > > migrating them over to use the new MessageExchange interfaces
(rather
> > than
> > > invoke)
> > > This would require changing all of the code that directly uses
> > > Transports.
> > > The end result would be a synchronous axis engine capable of using
> > > async transports
> > > Phase 3: Provider modifications
> > > This would involve taking all of the current Axis providers and
> > > migrating them over to use the new MessageExchange interfaces
(rather
> > than
> > > invoke)
> > > This would require changing all of the code that directly uses
> > > Providers
> > > The end result would be a synchronous axis engine capable of using
> > > async providers
> > > Phase 4: AxisEngine/AxisClient/AxisServer modifications
> > > This would involve migrating the AxisEngine to use the
MessageExchange
> > > interface (rather than invoke)
> > > This would require changing all of the code that directly uses the
> > > AxisEngine
> > > The end result would be an async axis engine but the Client API that
> > > sits on top of the engine would still be synchronous
> > > Phase 5: Client API modifications
> > > This would involve changing or augmenting the Call object so that it
> > > could take advantage of the async engine capabilities
> > > Phase 6: WSDL2Java/Java2WSDL changes
> >
> > > * At the end of each phase, we could theoretically have a point
release
> > on
> > > the code if there are other fixes/etc that need to go out.
> > > * I would conservatively set an initial target for Phase 6
Completion at
> > > 3/4 months.
> > > * I would also posit that Phase 6 completion would represent a major
> > > release of the code given the significant new functionality that
would
> > be
> > > introduced.
> >
> > > I will continue to serve as a coordinator for this effort.
> >
> > > Please vote to approve or provide feedback if you think the plan
needs
> > > tweaking/further development.
> >
> > > - James Snell
> > > IBM Emerging Technologies
> > > jasnell@us.ibm.com
> > > (559) 587-1233 (office)
> > > (700) 544-9035 (t/l)
> > > Programming Web Services With SOAP
> > > O'Reilly & Associates, ISBN 0596000952
> >
> > > Have I not commanded you? Be strong and courageous.
> > > Do not be terrified, do not be discouraged, for the Lord your
> > > God will be with you whereever you go. - Joshua 1:9
> --
> Sonic Software - Backbone of the Extended Enterprise
> --
> David Chappell <ch...@sonicsoftware.com> Office: (781)999-7099
> Mobile: (617)510-6566
> Vice President and Chief Technology Evangelist, Sonic Software
> co-author,"Java Web Services", (O'Reilly 2002)
> "The Java Message Service", (O'Reilly 2000)
> "Professional ebXML Foundations", (Wrox 2001)
> --
>
> [attachment "chappell.vcf" deleted by James M Snell/Fresno/IBM]
Re: [IMPORTANT!] Proposed Axis Async Development Plan
Posted by David Chappell <ch...@sonicsoftware.com>.
I'm all for it. Given that the wrapper class issue works for everyone,
and we can isolate the work as layed out, are there any more objections?
Dave
James M Snell wrote:
>
> Ok.. so now how about the development plan? :-) I'd like to start
> working on getting this stuff into the main branch. Phase 1 can be done
> in the main branch without affecting any of the existing code. All of the
> work would be done in the org.apache.axis.ime package which could be
> excluded from the build.
>
> - James Snell
> IBM Emerging Technologies
> jasnell@us.ibm.com
> (559) 587-1233 (office)
> (700) 544-9035 (t/l)
> Programming Web Services With SOAP
> O'Reilly & Associates, ISBN 0596000952
>
> Have I not commanded you? Be strong and courageous.
> Do not be terrified, do not be discouraged, for the Lord your
> God will be with you whereever you go. - Joshua 1:9
>
> David Chappell <ch...@sonicsoftware.com> wrote on 10/25/2002 10:40:00
> AM:
>
> > +1 to that.
> > Dave
>
> > James M Snell wrote:
> > >
> > > Possible interim solution: one of the utility classes would be a
> wrapper
> > > around the new version of AxisEngine that implements Handler. The
> wrapper
> > > interface would have the same signature as the current version but
> would
> > > use the new stuff under the covers. Users would then be given the
> option
> > > of migrating to the new interfaces vs. using the old version.
> > >
> > > - James Snell
> > > IBM Emerging Technologies
> > > jasnell@us.ibm.com
> > > (559) 587-1233 (office)
> > > (700) 544-9035 (t/l)
> > > Programming Web Services With SOAP
> > > O'Reilly & Associates, ISBN 0596000952
> > >
> > > Have I not commanded you? Be strong and courageous.
> > > Do not be terrified, do not be discouraged, for the Lord your
> > > God will be with you whereever you go. - Joshua 1:9
> > >
> > > Doug Davis/Raleigh/IBM@IBMUS wrote on 10/25/2002 08:51:03 AM:
> > >
> > > > Again - AxisEngine will be called by Axis users ("users" in the
> broader
> > > > sense of the term meaning anyone who wants to write code to work
> with
> > > > Axis). I know of quite a few people who write their own servlets,
> > > > providers and transports - I believe you're talking about changing
> > > _their_
> > > > interfaces.
> > > > -Dug
> > >
> > > >
> > > > James M Snell/Fresno/IBM@IBMUS on 10/25/2002 11:39:15 AM
> > >
> > > > Please respond to axis-dev@xml.apache.org
> > >
> > > > To: axis-dev@xml.apache.org
> > > > cc:
> > > > Subject: Re: [IMPORTANT!] Proposed Axis Async Development Plan
> > >
> > > >
> > > > The proposed changes ARE internal to Axis. They change the
> interfaces
> > > to
> > > > the AxisEngine, Provider and Transport objects which, from the end
> users
> > > > point of view, will be hidden behind things like the Call object and
> the
> > > > Servlet, etc. Existing handlers will not need to be modified, just
> the
> > > > things we typically refer to as "pivots". There are still handlers
> and
> > > > chains.
> > >
> > > > - James Snell
> > > > IBM Emerging Technologies
> > > > jasnell@us.ibm.com
> > > > (559) 587-1233 (office)
> > > > (700) 544-9035 (t/l)
> > > > Programming Web Services With SOAP
> > > > O'Reilly & Associates, ISBN 0596000952
> > >
> > > > Have I not commanded you? Be strong and courageous.
> > > > Do not be terrified, do not be discouraged, for the Lord your
> > > > God will be with you whereever you go. - Joshua 1:9
> > > >
> > > > Doug Davis/Raleigh/IBM@IBMUS
> > > > 10/25/2002 05:23 AM
> > > > Please respond to axis-dev
> > >
> > > >
> > > > To
> > > > axis-dev@xml.apache.org
> > > > cc
> > >
> > > > bcc
> > >
> > > > Subject
> > > > Re: [IMPORTANT!] Proposed Axis Async Development Plan
> > >
> > > >
> > > > In some of your notes you've stated that the new messaging pattern
> you
> > > > want
> > > > to do is strictly internal and yet this note would seem to imply
> > > > otherwise.
> > > > Now that 1.0 has shipped we all know that we must be very careful
> with
> > > > what
> > > > APIs we change but that isn't limited to just the client-side, that
> > > > includes ALL interfaces. I'm not against any of these changes I
> just
> > > want
> > > > to remind people that the freedom we enjoyed up until recently is
> now,
> > > to
> > > > some extent, gone. And related to this is the necessity to keep it
> > > simple
> > > > - never assume that any API will remain hidden from an Axis user. If
> > > Axis
> > > > provides some plug-point then you have to assume that it will be
> used,
> > > and
> > > > used often - so it needs to be done in such a way that
> non-axis-dev'ers
> > > > can
> > > > use it w/o going to the axis-dev mailing list for help. On the
> phone
> > > call
> > > > the other day I heard a few people remark that "xxxx was only going
> to
> > > be
> > > > used by a small set of people" - that worries me a little because
> > > > believing
> > > > that allows you to ignore the KISS principle and could hurt us in
> the
> > > long
> > > > run. One of the really nice things about Axis is that when you look
> at
> > > > what's at its core, its really just a few very simple concepts:
> Handlers
> > > > and Chains (that's what I see anyway) - and it would be a shame if
> we
> > > lost
> > > > that. So, please it simple.
> > > > -Dug
> > >
> > > >
> > > > James M Snell/Fresno/IBM@IBMUS on 10/23/2002 07:04:29 PM
> > >
> > > > Please respond to axis-dev@xml.apache.org
> > >
> > > > To: axis-dev@xml.apache.org
> > > > cc:
> > > > Subject: [IMPORTANT!] Proposed Axis Async Development Plan
> > >
> > > >
> > > > On the phone call today, we discussed the fact that the Internal
> Message
> > > > Exchange proposal represents a significant change to the Axis
> internals
> > > > and should ideally be broken up so that it can be incrementally
> > > > introduced into the code. Here's my proposal for how to break up
> the
> > > > work.
> > >
> > > > Phase 1: Interfaces, Thread Management and Helper classes.
> > > > This work can be done without touching any existing Axis code. This
> > > > essentially means taking my prototype, tweaking and fine tuning it.
> > > > Phase 2: Transport modifications.
> > > > This would involve taking all of the current Axis transports and
> > > > migrating them over to use the new MessageExchange interfaces
> (rather
> > > than
> > > > invoke)
> > > > This would require changing all of the code that directly uses
> > > > Transports.
> > > > The end result would be a synchronous axis engine capable of using
> > > > async transports
> > > > Phase 3: Provider modifications
> > > > This would involve taking all of the current Axis providers and
> > > > migrating them over to use the new MessageExchange interfaces
> (rather
> > > than
> > > > invoke)
> > > > This would require changing all of the code that directly uses
> > > > Providers
> > > > The end result would be a synchronous axis engine capable of using
> > > > async providers
> > > > Phase 4: AxisEngine/AxisClient/AxisServer modifications
> > > > This would involve migrating the AxisEngine to use the
> MessageExchange
> > > > interface (rather than invoke)
> > > > This would require changing all of the code that directly uses the
> > > > AxisEngine
> > > > The end result would be an async axis engine but the Client API that
> > > > sits on top of the engine would still be synchronous
> > > > Phase 5: Client API modifications
> > > > This would involve changing or augmenting the Call object so that it
> > > > could take advantage of the async engine capabilities
> > > > Phase 6: WSDL2Java/Java2WSDL changes
> > >
> > > > * At the end of each phase, we could theoretically have a point
> release
> > > on
> > > > the code if there are other fixes/etc that need to go out.
> > > > * I would conservatively set an initial target for Phase 6
> Completion at
> > > > 3/4 months.
> > > > * I would also posit that Phase 6 completion would represent a major
> > > > release of the code given the significant new functionality that
> would
> > > be
> > > > introduced.
> > >
> > > > I will continue to serve as a coordinator for this effort.
> > >
> > > > Please vote to approve or provide feedback if you think the plan
> needs
> > > > tweaking/further development.
> > >
> > > > - James Snell
> > > > IBM Emerging Technologies
> > > > jasnell@us.ibm.com
> > > > (559) 587-1233 (office)
> > > > (700) 544-9035 (t/l)
> > > > Programming Web Services With SOAP
> > > > O'Reilly & Associates, ISBN 0596000952
> > >
> > > > Have I not commanded you? Be strong and courageous.
> > > > Do not be terrified, do not be discouraged, for the Lord your
> > > > God will be with you whereever you go. - Joshua 1:9
>
> > --
> > Sonic Software - Backbone of the Extended Enterprise
> > --
> > David Chappell <ch...@sonicsoftware.com> Office: (781)999-7099
> > Mobile: (617)510-6566
> > Vice President and Chief Technology Evangelist, Sonic Software
> > co-author,"Java Web Services", (O'Reilly 2002)
> > "The Java Message Service", (O'Reilly 2000)
> > "Professional ebXML Foundations", (Wrox 2001)
> > --
> >
> > [attachment "chappell.vcf" deleted by James M Snell/Fresno/IBM]
--
Sonic Software - Backbone of the Extended Enterprise
--
David Chappell <ch...@sonicsoftware.com> Office: (781)999-7099
Mobile: (617)510-6566
Vice President and Chief Technology Evangelist, Sonic Software
co-author,"Java Web Services", (O'Reilly 2002)
"The Java Message Service", (O'Reilly 2000)
"Professional ebXML Foundations", (Wrox 2001)
--