After speaking with Glyn, I think (my opinion only) perhaps the language used to describe what he wants to do was a bit to strong. Basically, while functional, Axis suffers from a lack of a strong architectural backbone that makes it somewhat difficult for someone just coming into the project to understand and therefore help to maintain and evolve the code. The implementation of Axis, in my opinion and in the opinion of a number of others with whom I've discussed this topic, has been done in a fairly adhoc manner, with too much coupling between the various subsystems and not enough attention paid to creating a code base that not only implements the proper functionality but also adheres to tried and true architectural design principals. Glyn's intent, which I applaud, is to provide nothing more than a set of architectural recommendations for how to improve the maintainability and structure of the Axis code POST 1.0.
A note that Sam sent out refers to an email that sets a precendence for this (http://www.x180.net/Mutterings/Apache/rules.html). If y'all haven't read it, I suggest you do. Essentially what Glyn would like to do is set up a sandbox that can be used to experiment with various architectural improvements for Axis 2.0. Most of those improvements may (and I stress MAY) begin to migrate their way into the code in an evolutionary way as work on Axis 2.0 begins. Some MAY require a revolutionary change (if the proposals are in fact adopted by the axis dev team) but that'll be dealt with when the appropriate time comes. That said, however, prior to the 1.0 release, we really do need all available hands looking at finishing up the 1.0 release. - James M Snell/Fresno/IBM Web services architecture and strategy Internet Emerging Technologies, IBM 544.9035 TIE line 559.587.1233 Office 919.486.0077 Voice Mail [EMAIL PROTECTED] 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 wherever you go. - Joshua 1:9 Please respond to [EMAIL PROTECTED] To: <[EMAIL PROTECTED]> cc: Subject: Re: Axis Re-architecture ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 13, 2002 12:26 PM Subject: Re: Axis Re-architecture > On Thu, 13 Jun 2002, Glyn Normington wrote: > > > Costin: I'm aiming more at a radical re-architecting rather than a > > re-factoring. My goal is not primarily to preserve the current function as > > some of this is there by accident of the current structure. > > I was afraid of that... > > If I remember corectly, axis is a 're-architecting' of xml-soap. What > makes you think the next one will be the right one ? And when does it > stop, I assume someone else will start re-architecting your version > when it's almost ready ( by that time is very likely it'll be > close to a real product, i.e. with all the compromises and complexities). One of my favourite books on system design is "How buildings learn, by Stuart Brandt". Its core premise is that old buildings either survive because their purpose is frozen (churches, cathedrals), or because they were reworked during their life. Unless you can guarantee that purpose is frozen forever, flexible is best. And even the fixed function cathedrals are really hacks with things like flying buttresses in to hold up the sides. > I totally agree axis has become too complex, it's hard for new people > to contribute, etc. There are some amazing ideas in it, and a lot > of the normal complexity that you find in any project that matures > and has more than one contributor. > > But IMHO the only way to fix this is the hard way - starting with > the existing system and cutting the crap, create a set of simpler > interfaces and remove interdependencies, etc. > > At least that's my experience with several 're-architecture' attemtps, > including Axis itself. It all looks wonderfull on paper and the first > draft, and it repeats most of the errors and gets all the complexity > of the original ( because of natural evolution ). yup. > > The only way to get to a simple and modular system is to start with > a real system and refactor it continuously, based on the features and > code that gets added. Maybe a good tactic is post1.0 to pick a really unwiedly bit of the system and redesign it. One can prepare for this in the pre-1.0 timeframe by writing all the unit tests that refactoring needs, these will benefit both releases -steve
