Wow, this sounds very scary to me, speaking as someone who's company uses the Axis technology in their products. Please remember that Axis is now "real", not a research project.
How many API changes will this type of thing expose? Will I be able to use Axis 1.x (x >0) as a drop in replacement for 1.0? If not, then consider this a -0.5 on ripping the guts of Axis to do this. Why does Axis needs this functionality? (looking for a rationale, not flaming). -- Tom Jordahl Macromedia Server Development -----Original Message----- From: James M Snell [mailto:jasnell@;us.ibm.com] Sent: Wednesday, October 23, 2002 7:04 PM To: [EMAIL PROTECTED] 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
