Hi All; let me add something too, becouse I has been a BIG user of OM as I wrote the most of code that glaue the engine and OM.
OM is more or less the DOM IN API, only differance I feel is it has Iterators rather than lists. But the concepts just hold. Somebody who wrote code on DOM can wrote code on the OM pretty quickly. If they need to replace the jax-rpc impl with the API intact then it is tough, but IMO Axis2 presents enough new things for jusitfy the bit of work! Thanks Srinath On Sat, 12 Mar 2005 13:31:33 +0600, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > > > +1. I think Denis you made the point very clear. > > Anyway, if we talk about the Axiom API, we tried to make it very much > developer friendly. It was one of the requirements as well. I very well, > know that Jdom is very easy to use. So I also wanted AXIOM to have something > like that. > > Anyway, when I was defining the SOAP specific API for AXIOM, I got a lot > from the SAAJ API. So I don't think the learning effort will be very > difficult. > > Anyway, the existing API is very user friendly and we think that any API can > be layered on top of it. But if one uses the provided API we make sure its > fast and efficient. So this enables to get the best of both ends. > > Anyway, we are happy to welcome comments about the API. Rather it is for you > all. So if you feel like changing adding , etc., you are mostly welcome. > Let's try to develop a spec neutral good api for Axis2, so that no one will > be hurt. > > Thankx > -- Eran Chinthaka > > > > 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. > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > >
