+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
> [EMAIL PROTECTED]
> (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 [EMAIL PROTECTED]
>
> > To: [EMAIL PROTECTED]
> > 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
> > [EMAIL PROTECTED]
> > (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
> > [EMAIL PROTECTED]
> > 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 [EMAIL PROTECTED]
>
> > To: [EMAIL PROTECTED]
> > 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
> > [EMAIL PROTECTED]
> > (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 <[EMAIL PROTECTED]> 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)
--
begin:vcard
n:Chappell;Dave
tel;cell:617-510-6566
tel;work:781-999-7099
x-mozilla-html:FALSE
url:www.sonicsoftware.com
org:Sonic Software Corp. <BR><IMG SRC="http://www.sonicsoftware.com/media/general/logos/sonic_logo1.gif"; VSPACE="10">
adr:;;14 Oak Park;Bedford;MA;01730;USA
version:2.1
email;internet:[EMAIL PROTECTED]
title:vice president & chief technology evangelist
fn:Dave Chappell
end:vcard
![http://www.sonicsoftware.com/media/general/logos/sonic_logo1.gif"](http://www.sonicsoftware.com/media/general/logos/sonic_logo1.gif"){kind=link}