+1! JAX-RPC imposes way too many constraints on a web services toolkit design.
On Fri, 11 Mar 2005 12:33:33 -0800, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > I'm not directly involved with the Axis2 development, but I personally > believe you're on the right track in setting the focus on a clean, > flexible, and performant core rather than on implementing particular > APIs. The APIs involved in the web services area are so complex and > detailed that they have a major impact on the design. I think this has > really hurt Axis1, where many of the inefficiencies appear to revolve > around the need to maintain compatibility with JAX-RPC and SAAJ. The > focus on APIs seems also to have caused the focus of Axis1 testing to be > on the TCK, rather than on a comprehensive set of usage tests. I suspect > this has a lot to do with the way bugs appear to get fixed in Axis1 but > then pop up again in the next release. > > I don't know how easy it will be to layer JAX-RPC, SAAJ, and the growing > crop of related APIs over the Axis2 core, especially since these > standards are still evolving. I suspect most users will just stay with > the core rather than trying to use the layered APIs anyway, though, > especially if your core provides fast and easy web services > implementations that are WSI-BP compliant. I think the real problem here > is that the Java standardization efforts in this area were simply > premature - IMHO we would all have been better served if Sun had simple > released the JAX-RPC RI as a tool rather than a standard. As it is now > we're probably stuck in a cycle like CMP Entity Beans, where it won't be > until 3.0 that we finally have the basis for doing things in a way that > really makes sense for users. > > - Dennis > > Dennis M. Sosnoski > Enterprise Java, XML, and Web Services > Training and Consulting > http://www.sosnoski.com > Redmond, WA 425.885.7197 > > > Ajith Ranabahu wrote: > > >Hi, > >A "shim DOM" is a DOM implementation on top of OM. This means that we > >will be able to build a DOM tree (DOM refers to w3c standard DOM) from > >a previously built OM tree. The reason for having such a shim DOM is > >to facilitate features such as WSS4J (which are written on pure DOM) > >About spec compliance. Well I do believe that specifications are > >important which ultimately allow our client/server to be > >interoperable. Just as you mentioned there will be lot of people who > >wish to try out axis using there own clients and spec compliance is > >specially important in this sense (to some level beyond the wire down > >to the API as well) > >We at Axis2 are not against specs at all :).What we believe is that > >the core needs to be "spec-neutral". No specification is assumed in > >the core. this is exactly what has been done in Geronimo which has a > >"non-J2EE-aware" core. So similarly we are developing a simple and > >fast core which has no built in support for any of the specifications, > >but such specification support can easily be layered upon. > > > >Hope this gives you some insight to the Axis2 way of looking at things :) > > > > > >On Fri, 11 Mar 2005 12:44:40 +0530, jayachandra <[EMAIL PROTECTED]> wrote: > > > > > >>Sry, forgot the [Axis2] prefix in the subject. > >>Resending with [Axis2] prefixed in the subject. > >> > >> > >> > >> > > > > > > > > > > >
