1.I was mainly taken by surprise by the OMElement approach that is explained in the user guide's own implementation ( http://ws.apache.org/axis2/userguide.html#Web_Services_Using_Axis2). If this is a special case, then it shouldn't be the only one in the user guide. I didn't find anywhere that I could just deploy a POJO (with minimal metadata in the wsdd) as I can with Axis1.
1.1 Perhaps number 1 is completely wrong. If so, the documentation needs to point this out. If my experience thus far is unfair it is because the documentation is incomplete (expected early in the project) at a minimum, and from my personal experience it is misleading (unacceptable).
2. I feel as though the need to work with WSDLs directly is a failing of the implementation (whichever implementation). Ideally the situation should be that there are times in unusual circumstances that you might need to work with the WSDL directly. The majority of Web service deployments should be as simple as providing metadata via XML or annotations that handle the type of things that you would need to alter the WSDL for. It seems that Axis2 is no further away from this than Axis1 ever was. If anything it further perpetuates this anti-productive vein of thought. The documentation is rife with references and how-tos relating to WSDL2Java. This is backwards thinking and it permeates both Axis1 and 2 users/developers. I work with objects. We all, as Java developers, work with objects. Java developers are most productive when working with objects, in general. I'm not trying to start a flame war on this subject, but whenever I hear, "oh you need to edit the WSDL to do this or that" I cringe. It's not that I can't. It's that I shouldn't have to. If you think I'm wrong, look at ejb2 vs ejb3 in regards to the various xml files. Same story, different project. Even then, I contend that ejb deployment descriptors are easier to work with than WSDLs.
3. JRS-181 is awesome. After using XFire's implementation, I do not know if I will be able to go back to a non-annotated world.
4. Poor "out of the box" support for other frameworks (eg Spring). I would like to be able to manage my Web services like any other bean in a webapp. I'm sure if I hack away I can manage to put something specific to my project together, but then there will be hundreds of homegrown implementations that no one body has knowledge of or is responsible for. Axis2 does not live in a vacuum. There's a lot of frameworks out there. It'd be nice if the project recognized and supported this idea.
5. Weird deployment model. I guess that having a JEEish packaging scheme is a good thing. However, I've lost all the benefits of creating a war of my own for my services. I can no longer specify my own url-mappings without editing the axis2.war, which is not in my source control (and shouldn't be). This new approach is incompatible with my company's build scripts. Automating the build seems to be a hassle. I do not even see a nice way to do this - explode the war, build and deploy my aar files to the exploded war, then repackage? Ugh.
What I do like about Axis2 is the architecture. The underlying architecture is very clearly defined. The pluggable modules give me a reasonable amount of hope that as specs (WS-AtomicTransactions!!!) are implemented, I will only have to drop them into my deployment. This is the strongest case I see for Axis2 right now. The documentation regarding this architecture is reasonably thorough and explains the why's and the how's satisfactorily.
I do not mean to bash Axis2. This is my experience for better or worse.
On 12/15/05, Rakesh Patel <
[EMAIL PROTECTED]> wrote:
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?
>>
>>
>>
>
>
>
