Wrappers supporting old interfaces is good :-)
-Dug
James M Snell/Fresno/IBM@IBMUS on 10/25/2002 12:13:48 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: [IMPORTANT!] Proposed Axis Async Development Plan
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
