I also have not found the experience of working with web services and
apache axis a pleasurable one.
I'm glad my project has been put on hold because the learning curve is
so steep. Here's a few issues I have had:
1. Initially I started out using the Sun reference implementation and
installed the extensions to my Sun ONE instance. This had performance
and memory implications on the server. I switched to Apache Axis instead.
2. The whole arena of web services is compliated because of so many
changes over so little time. I found a few tutorials on the net but if
they were in 2002 you never knew if it was the right way to do things now.
3. The Apache axis docs were pretty bad. Its not geared towards learning
the way to use axis, more a reference. I had no idea how to add axis to
an existing application. I did it in the end becasue some helpful guy
had made available a minimal app that you could use to start from on his
blog (why doesn't the main site provide this?). The 1.3 download has
docs for 1.2.
4. The touted tool support is a double-edged sword because you need to
know what they are doing to enable debugging but you don't have enough
knowledge at a low level. For instance, when i tried the upgrade from
1.2-->1.3 by replacing the axis jar, my ant tasks failed
(wsdl2java/java2wsdl) . I had no idea where to begin to solve this.
Overall I'd say that dealing with the underlying servlet code and xml
libraries would have been easier to use and easier to understand. I feel
that Apache Axis and maybe even web services in general is
over-engineered and more compilcated than the alternative implementation
(dealing with servlets and xml).
Implementation A
1. code a servlet to transfer xml.
2. Use something like JDOM to create/read/update the xml.
3. Use web container functionality such as session timeout, user
management and ssl. Done it before many times....
Implementation B
1. Learn Apache Axis and add to your app.
2. Work out how to use and intergrate the tools into your build process.
3. Learn the myriad ways to do everything such as security and transfer
modes and rpc and filters and exceptions etcetcetc(and then watch them
change).
A is easier when you have to get the job done.
Perhaps I'm missing the point. Its when the functionality you need is
much more advanced that it pays back the approach. However, if it can't
satisfy simple requirements then i think its a failure becuase no-one is
going to jump into the complicated stuff when they are first starting out.
Sorry for the rant but i thought I should give some feedback.
Rakesh
Srinath Perera wrote:
Hi Todd;
Are referring to Call/MEPClient API or Generated Stubs. We do not
force you to use the OM* API unless you need XML level support. You
can use the generated Stubs and Client s and work with out seen a
OMElement at all.
Q) are you happy with Axis1.x API? what you had there and missing at Axis2
If it is good architecturally .. we can fix the client API If only
you can provide constructive comments. Remember lot of developers has
different opinions about it .. some quite opposite.
Tell us
1) Exactly in detail what are the problems?
2) What your expected scenarios .. with example may be
3) Suggestions to how to fix current API
If you do, we can discuss and improve Axis2, if you arguments are
reasonable we love to make the fixes. On the other hand if the Xfire
serve you better please go for it.
If you comment please be constructive ..random opinions do not help anybody!!
Thanks
Srinath
On 12/15/05, Todd Orr <[EMAIL PROTECTED]> wrote:
The more I learn about Axis2, the less appealing it is. It seems to be giant
leap backwards. Why is coding using OMElement (and the other OM... objects)
a better approach than deploying a POJO? This is a huge pain. Not to mention
the deployment issues that I've already run into. Based on the documentation
I feel as though Axis2 is a step forward architecturally, but extremely weak
in user friendliness. For this reason I've been finding myself more
interested in XFire. It has many features of Axis2, yet is extremely easy to
create Web services with. Why would the Axis2 team go in this
anti-productivity direction?
