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
> [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
>
> David Chappell <[EMAIL PROTECTED]> 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
> > > [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)
> > --
> >
> > [attachment "chappell.vcf" deleted by James M Snell/Fresno/IBM]
--
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<a href="http://www.oreillynet.com/weblogs/author/207";>[weblog]</a>
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}