Sanjiva, Srinath, Dims, >That is indeed my own personal opinion .. that JAX-RPC sucks :-). I will write something about this soon. The architecture of Axis2 was designed to enable both me and JAX-RPC fanatics to live in harmony; so the base core does not have any JAX-RPC stuff as Srinath said, but it can be layered on easily.
Thanks everyone for your responses - I definitely see the context within which Axis2 development has been progressing. I think that capturing the philosophy and design decisions behind Axis2 is very important. Food for thought: I've observed that Java developers are often very conscious of SOAP toolkit integration points with their back-end code. The move to Doc/Literal SOAP Services has (ironically) increased anxiety about such integration points, primarily because XSD->Java data binding always seems to be toolkit specific. Java developers, in my experience, resist incorporating WSDL2Java generated code into their applications when there are long term concerns about switching SOAP platforms/toolkits. I've seen development teams embrace Axis 1.x "MSG style" and go hands on the DOM to alleviate these worries (heavens help our performance and scalability). JAX-RPC 2.0 promises to make this situation better, and I personally am looking forward to seeing implementations for this very reason. Deltas from it (whether they be value additions or limitations) will be important for development teams shopping for platforms/toolkits. Granted, I'm approaching Java based Web Service development from this particular perspective - there are definitely others, and I'm just beating my particular drum. We Java guys sure do like to argue, don't we? One language - fifty ways to do the same thing. Some days I think the .NET-heads have it right - you do it Microsoft's way or not at all. Then I remember that it would all have to run on IIS, and I feel better. :) Regards, -Jon
smime.p7s
Description: S/MIME cryptographic signature
