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
