You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by jayachandra <ja...@gmail.com> on 2005/03/11 08:04:58 UTC
two small doubts
Guys!
What is 'shim' DOM thing that is being talked about these days. Is it
a DOM implementation hooked over StAX rather than the conventional SAX
(as done in Xerces etc.) ???
One more doubt is...
if we are going to be so averse against JAXRPC+SAAJ compliance as they
stand to date, then we *might* have difficulty later when trying to
sell Axis2 in the industry. People would be interested to kick the
tyres using testclients that are written using SAAJ programming model
than learning to create a SOAP request using just OM projected APIs.
For those who take the extra little effort in learning the new thing,
obviously results will be more quick. But if that's the only choice we
offer then we might loose on quite a good number.
Even I agree that it's the on-the-wire compliance that's more
important, but at least on the client side, API compliance too is
something that can't be overlooked.
JC
Re: [Axis2] Fwd: two small doubts
Posted by Srinath Perera <he...@gmail.com>.
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
<ch...@opensource.lk> 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 <ja...@gmail.com>
> > wrote:
> > >
> > >
> > >>Sry, forgot the [Axis2] prefix in the subject.
> > >>Resending with [Axis2] prefixed in the subject.
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >
>
>
Re: [Axis2] Fwd: two small doubts
Posted by Anne Thomas Manes <at...@gmail.com>.
+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 <dm...@sosnoski.com> 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 <ja...@gmail.com> wrote:
> >
> >
> >>Sry, forgot the [Axis2] prefix in the subject.
> >>Resending with [Axis2] prefixed in the subject.
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
>
RE: [Axis2] Fwd: two small doubts
Posted by Eran Chinthaka <ch...@opensource.lk>.
+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 <ja...@gmail.com>
> wrote:
> >
> >
> >>Sry, forgot the [Axis2] prefix in the subject.
> >>Resending with [Axis2] prefixed in the subject.
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
Re: [Axis2] Fwd: two small doubts
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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 <ja...@gmail.com> wrote:
>
>
>>Sry, forgot the [Axis2] prefix in the subject.
>>Resending with [Axis2] prefixed in the subject.
>>
>>
>>
>>
>
>
>
>
>
Re: [Axis2] Fwd: two small doubts
Posted by Ajith Ranabahu <aj...@gmail.com>.
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 <ja...@gmail.com> wrote:
> Sry, forgot the [Axis2] prefix in the subject.
> Resending with [Axis2] prefixed in the subject.
>
>
--
Ajith Ranabahu
[Axis2] Fwd: two small doubts
Posted by jayachandra <ja...@gmail.com>.
Sry, forgot the [Axis2] prefix in the subject.
Resending with [Axis2] prefixed in the subject.
---------- Forwarded message ----------
From: jayachandra <ja...@gmail.com>
Date: Fri, 11 Mar 2005 12:34:58 +0530
Subject: two small doubts
To: axis-dev@ws.apache.org
Guys!
What is 'shim' DOM thing that is being talked about these days. Is it
a DOM implementation hooked over StAX rather than the conventional SAX
(as done in Xerces etc.) ???
One more doubt is...
if we are going to be so averse against JAXRPC+SAAJ compliance as they
stand to date, then we *might* have difficulty later when trying to
sell Axis2 in the industry. People would be interested to kick the
tyres using testclients that are written using SAAJ programming model
than learning to create a SOAP request using just OM projected APIs.
For those who take the extra little effort in learning the new thing,
obviously results will be more quick. But if that's the only choice we
offer then we might loose on quite a good number.
Even I agree that it's the on-the-wire compliance that's more
important, but at least on the client side, API compliance too is
something that can't be overlooked.
JC
--
-- Jaya