You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Todd Orr <to...@gmail.com> on 2005/12/15 08:16:50 UTC
axis2 impressions
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?
Re: axis2 impressions
Posted by iksrazal <ik...@gmail.com>.
Em Quinta 15 Dezembro 2005 15:14, o Nathaniel Auvil escreveu:
> Can you email me with how you got axis2 to work from wsdl? I have two open
> Jira items on this as it blows up on my wsdl. The first problem is due to
> schema imports. So i eliminated the schema imports and now i get a schema
> exception from XMLBeans. This schema works fine with Axis 1.2.1 and is
> valid XML according to XMLSpy.
>
> <quote>
>
> > Its open-source, feel free to document it. I personally needed a
> > WSDL2Java ant
> > task with axis2, and once I figured it out how to do it I was invited to
> > document it, which I did. I personally found the OMElement approach easy
> > enough to undersatand to get started without wsdl.
> > </quote>
We're going to need a little more info then it 'blows up' to help ;-) .
First, its got to be more than just valid xml, its got to be a valid wsdl.
Google for the 'free as in beer' soa editor from cape clear.
The XMLBean issue I think you have is documented here:
http://ws.apache.org/axis2/CodegenToolReference.html
There's also a sample wsdl and code. The sample is a little rough - I've been
making a transition from 'rpc encoded' to doc / lit . Nevertheless, it is a
fully working sample.
HTH,
iksrazal
Re: axis2 impressions
Posted by Nathaniel Auvil <na...@gmail.com>.
Can you email me with how you got axis2 to work from wsdl? I have two open
Jira items on this as it blows up on my wsdl. The first problem is due to
schema imports. So i eliminated the schema imports and now i get a schema
exception from XMLBeans. This schema works fine with Axis 1.2.1 and is
valid XML according to XMLSpy.
<quote>
> Its open-source, feel free to document it. I personally needed a WSDL2Java
> ant
> task with axis2, and once I figured it out how to do it I was invited to
> document it, which I did. I personally found the OMElement approach easy
> enough to undersatand to get started without wsdl.
> </quote>
Re: axis2 impressions
Posted by Chathura Herath <ch...@gmail.com>.
Dear Todd,
Thank you for the feedback we do appreciate it so pls keep it comming.
I have included some comments regarding some things with significance
that you have pointed out
1)
The reason for having the OMElement instead of the POJO is axis2
engine is based on the StaX API. At least for me OM looks nicer than
meddling with the StAX events. So OMElement has very good advantages
(very much beyond simple easyness) than you might comprehend. Problem
with POJO is that it cannot be serialisable directly to the stax and
we don't have a such typemapping mechanism now. There are ways to fix
this if you can write a Serialiser that push stax events.
1.1)
Bad documentation!!! Well it isn't the best but it gives an
understanding for many. Help with documentation is always warmly
welcomed.
2) Well Java2WSDL tool is on the way. Understand this we haven't reach
the Version 1.0 mark yet. So we are not calling this a finish product
and there are things to finish.
3)I personally would like to get the annotations but there are other
prorities in the SOAP processing model that we need to fill up.
The expectations of the different users of Axis2 is different, but we
try to prioratise the most general user requirement.
Thanks
Chathura
P.S. Btw, I am (as a an Axis2 developper) not interested in promisses
that you are going to keep in a hypothedical opensource product that
you are gonna release.
On 12/15/05, Todd Orr <to...@gmail.com> wrote:
>
> > Its open-source, feel free to document it.
>
> I've been having trouble even being able to come up with an implementation
> to prove that it can be done. I cannot sell my boss on R&D to hack through
> the internals to figure out exactly what is happening. I've only been
> allocated time to compare and contrast alternative implementations. All
> frameworks should understand that their end users (me) are not always in the
> position to do the research and documentation for them. If I had that kind
> of time, I'd start my own open source projects. I've got lots of things I
> want to do for the community too. I just have a demanding job. I know that
> the Axis team also have jobs too. The difference is that I am not open
> sourcing a project for general consumption. It's a much appreciated effort -
> don't get me wrong.
>
> > Its open-source, feel free to document it. I personally needed a WSDL2Java
> ant
> > task with axis2, and once I figured it out how to do it I was invited to
> > document it, which I did. I personally found the OMElement approach easy
> > enough to undersatand to get started without wsdl.
> >
> > Digging deeper you'll find the Call interface still there.
>
> The call interface is not really what I'm talking about. I prefer writing a
> POJO that has no knowledge that it is a Web service endpoint. I have done
> this with Axis1.
>
> > WSDD is IMHO far inferior to the services.xml / aar / hot deployment
> approach,
> > and one of the reasons I moved to axis2.
>
> Agreed.
>
> > ...I actually spent my first 2 years doing web services without wsdl. When
> it
> > became a requirement I cringed. After a few weeks I started to like it.
> >
>
> I have nothing against WSDL. I work with them now in Axis1. The problem is
> not one of expertise or developer knowledge. It is an issue of necessity and
> developer ramp up. There is very little (any?) information in a WSDL that
> couldn't be maintained in a more straight forward metadata language
> (annotations, service.xml?). The best Web service implementation should
> alleviate this headache. It's not a matter of how hard or easy it is. It
> just shouldn't be there if the framework went the extra mile for the
> developer.
>
> > Then use XFire and be happy. I haven't got to JRS-181 - all in due time.
>
> Understandable.
>
> >
> http://marc.theaimsgroup.com/?l=axis-dev&m=112866697704950&w=2
>
> I've already attempted to use this. Besides the fact that it doesn't address
> my issue with homegrown implementations, it doesn't work. I've deployed it
> to my axis2 installation via the Web interface and in is faulty.
>
> > I would say novel and clever instead of weird.
>
> I might say divergent from known standards and applications. I never used
> AdminClient anyhow. I dropped the axis jars into my webapp, configured my
> web.xml and was off and running. All the while my company's build scripts
> worked flawlessly. That's expected, standards based behavior.
>
> > You could start by documenting alternatives to
> > OMElement - my guess is that if its good it'll get accepted. Just file a
> jira
> > when you're ready.
>
> Honestly, I want to help out. In an ideal world I wouldn't have to go to
> work all day and participate in my family at night. It's just not feasible.
> If my company ever releases a software product for general consumption, I
> will work to ensure that the complaints I have risen here do not happen in
> regards to my product. That's a promise I can keep.
>
>
> On 12/15/05, iksrazal <ik...@gmail.com> wrote:
> > As someone who has worked alot with axis 1.x and axis2, allow me to put my
> 2
> > cents in...
> >
> >
> > Em Quinta 15 Dezembro 2005 13:49, o Todd Orr escreveu:
> > > You're right. Random comments are not helpful. In general, however,
> Axis1
> > > was far easier to get a working app up with.
> > >
> > > 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.
> >
> > Its open-source, feel free to document it. I personally needed a WSDL2Java
> ant
> > task with axis2, and once I figured it out how to do it I was invited to
> > document it, which I did. I personally found the OMElement approach easy
> > enough to undersatand to get started without wsdl.
> >
> > Digging deeper you'll find the Call interface still there.
> >
> > WSDD is IMHO far inferior to the services.xml / aar / hot deployment
> approach,
> > and one of the reasons I moved to axis2.
> >
> > >
> > > 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.
> >
> > WSDL is a major fact in web services development - I don't see it as a
> being
> > "unusual circumstances" at all. The OMElement stuff allows you to avoid
> wsdl
> > just like Call.invoke () can. WSDL has a lot of power behind it. It may be
> > difficult now, but with a little effort learning it soon it won't be.
> >
> > If you want to work with objects, then Complex Types and WSDL should be a
> > natural fit. Once I learned how to use java.util.List with wsdl to
> represent
> > my data, along with my customs types, there was no turning back.
> >
> > I've actually even used EJB with WSDL together - alot. There are a lot of
> > files to touch, buts its only hard for a few days and then its easy. Then
> > again, wsdl is not mandatory.
> >
> > I actually spent my first 2 years doing web services without wsdl. When it
> > became a requirement I cringed. After a few weeks I started to like it.
> >
> > >
> > > 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.
> >
> > Then use XFire and be happy. I haven't got to JRS-181 - all in due time.
> >
> > >
> > > 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.
> >
> > There is support for spring - I'm a dedicated, happy user of spring.
> >
> >
> http://marc.theaimsgroup.com/?l=axis-dev&m=112866697704950&w=2
> >
> > I personally use the ObjectFactory approach as we have an existing app.
> I'd
> > like to see Spring documented but not too many people have been asking for
> > it.
> >
> > >
> > > 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.
> >
> > I would say novel and clever instead of weird. I guess I find just
> plopping an
> > aar in WEB-INF/services to be superior over wsdd and AdminClient. The
> whole
> > mar approach for Handlers is a big step in the right direction for me.
> >
> > >
> > > 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.
> >
> > That's fine. These type of discussions take advantage of the open source
> model
> > - if done constructively. You could start by documenting alternatives to
> > OMElement - my guess is that if its good it'll get accepted. Just file a
> jira
> > when you're ready.
> >
> > iksrazal
> >
> > >
> > > On 12/15/05, Rakesh Patel <rakesh.mailgroups@gmail.com > 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 <to...@gmail.com> 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?
> >
>
>
--
Chathura Herath
http://www.bloglines.com/blog/chathurah
Re: axis2 impressions
Posted by Todd Orr <to...@gmail.com>.
>
> Its open-source, feel free to document it.
I've been having trouble even being able to come up with an implementation
to prove that it can be done. I cannot sell my boss on R&D to hack through
the internals to figure out exactly what is happening. I've only been
allocated time to compare and contrast alternative implementations. All
frameworks should understand that their end users (me) are not always in the
position to do the research and documentation for them. If I had that kind
of time, I'd start my own open source projects. I've got lots of things I
want to do for the community too. I just have a demanding job. I know that
the Axis team also have jobs too. The difference is that I am not open
sourcing a project for general consumption. It's a much appreciated effort -
don't get me wrong.
Its open-source, feel free to document it. I personally needed a WSDL2Java
> ant
> task with axis2, and once I figured it out how to do it I was invited to
> document it, which I did. I personally found the OMElement approach easy
> enough to undersatand to get started without wsdl.
>
> Digging deeper you'll find the Call interface still there.
The call interface is not really what I'm talking about. I prefer writing a
POJO that has no knowledge that it is a Web service endpoint. I have done
this with Axis1.
WSDD is IMHO far inferior to the services.xml / aar / hot deployment
> approach,
> and one of the reasons I moved to axis2.
Agreed.
...I actually spent my first 2 years doing web services without wsdl. When
> it
> became a requirement I cringed. After a few weeks I started to like it.
>
I have nothing against WSDL. I work with them now in Axis1. The problem is
not one of expertise or developer knowledge. It is an issue of necessity and
developer ramp up. There is very little (any?) information in a WSDL that
couldn't be maintained in a more straight forward metadata language
(annotations, service.xml?). The best Web service implementation should
alleviate this headache. It's not a matter of how hard or easy it is. It
just shouldn't be there if the framework went the extra mile for the
developer.
Then use XFire and be happy. I haven't got to JRS-181 - all in due time.
Understandable.
http://marc.theaimsgroup.com/?l=axis-dev&m=112866697704950&w=2
I've already attempted to use this. Besides the fact that it doesn't address
my issue with homegrown implementations, it doesn't work. I've deployed it
to my axis2 installation via the Web interface and in is faulty.
I would say novel and clever instead of weird.
I might say divergent from known standards and applications. I never used
AdminClient anyhow. I dropped the axis jars into my webapp, configured my
web.xml and was off and running. All the while my company's build scripts
worked flawlessly. That's expected, standards based behavior.
You could start by documenting alternatives to
> OMElement - my guess is that if its good it'll get accepted. Just file a
> jira
> when you're ready.
Honestly, I want to help out. In an ideal world I wouldn't have to go to
work all day and participate in my family at night. It's just not feasible.
If my company ever releases a software product for general consumption, I
will work to ensure that the complaints I have risen here do not happen in
regards to my product. That's a promise I can keep.
On 12/15/05, iksrazal <ik...@gmail.com> wrote:
>
> As someone who has worked alot with axis 1.x and axis2, allow me to put my
> 2
> cents in...
>
>
> Em Quinta 15 Dezembro 2005 13:49, o Todd Orr escreveu:
> > You're right. Random comments are not helpful. In general, however,
> Axis1
> > was far easier to get a working app up with.
> >
> > 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.
>
> Its open-source, feel free to document it. I personally needed a WSDL2Java
> ant
> task with axis2, and once I figured it out how to do it I was invited to
> document it, which I did. I personally found the OMElement approach easy
> enough to undersatand to get started without wsdl.
>
> Digging deeper you'll find the Call interface still there.
>
> WSDD is IMHO far inferior to the services.xml / aar / hot deployment
> approach,
> and one of the reasons I moved to axis2.
>
> >
> > 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.
>
> WSDL is a major fact in web services development - I don't see it as a
> being
> "unusual circumstances" at all. The OMElement stuff allows you to avoid
> wsdl
> just like Call.invoke() can. WSDL has a lot of power behind it. It may be
> difficult now, but with a little effort learning it soon it won't be.
>
> If you want to work with objects, then Complex Types and WSDL should be a
> natural fit. Once I learned how to use java.util.List with wsdl to
> represent
> my data, along with my customs types, there was no turning back.
>
> I've actually even used EJB with WSDL together - alot. There are a lot of
> files to touch, buts its only hard for a few days and then its easy. Then
> again, wsdl is not mandatory.
>
> I actually spent my first 2 years doing web services without wsdl. When it
> became a requirement I cringed. After a few weeks I started to like it.
>
> >
> > 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.
>
> Then use XFire and be happy. I haven't got to JRS-181 - all in due time.
>
> >
> > 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.
>
> There is support for spring - I'm a dedicated, happy user of spring.
>
> http://marc.theaimsgroup.com/?l=axis-dev&m=112866697704950&w=2
>
> I personally use the ObjectFactory approach as we have an existing app.
> I'd
> like to see Spring documented but not too many people have been asking for
> it.
>
> >
> > 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.
>
> I would say novel and clever instead of weird. I guess I find just
> plopping an
> aar in WEB-INF/services to be superior over wsdd and AdminClient. The
> whole
> mar approach for Handlers is a big step in the right direction for me.
>
> >
> > 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.
>
> That's fine. These type of discussions take advantage of the open source
> model
> - if done constructively. You could start by documenting alternatives to
> OMElement - my guess is that if its good it'll get accepted. Just file a
> jira
> when you're ready.
>
> iksrazal
>
> >
> > On 12/15/05, Rakesh Patel <ra...@gmail.com> 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 <to...@gmail.com> 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?
>
Re: axis2 impressions
Posted by iksrazal <ik...@gmail.com>.
As someone who has worked alot with axis 1.x and axis2, allow me to put my 2
cents in...
Em Quinta 15 Dezembro 2005 13:49, o Todd Orr escreveu:
> You're right. Random comments are not helpful. In general, however, Axis1
> was far easier to get a working app up with.
>
> 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.
Its open-source, feel free to document it. I personally needed a WSDL2Java ant
task with axis2, and once I figured it out how to do it I was invited to
document it, which I did. I personally found the OMElement approach easy
enough to undersatand to get started without wsdl.
Digging deeper you'll find the Call interface still there.
WSDD is IMHO far inferior to the services.xml / aar / hot deployment approach,
and one of the reasons I moved to axis2.
>
> 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.
WSDL is a major fact in web services development - I don't see it as a being
"unusual circumstances" at all. The OMElement stuff allows you to avoid wsdl
just like Call.invoke() can. WSDL has a lot of power behind it. It may be
difficult now, but with a little effort learning it soon it won't be.
If you want to work with objects, then Complex Types and WSDL should be a
natural fit. Once I learned how to use java.util.List with wsdl to represent
my data, along with my customs types, there was no turning back.
I've actually even used EJB with WSDL together - alot. There are a lot of
files to touch, buts its only hard for a few days and then its easy. Then
again, wsdl is not mandatory.
I actually spent my first 2 years doing web services without wsdl. When it
became a requirement I cringed. After a few weeks I started to like it.
>
> 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.
Then use XFire and be happy. I haven't got to JRS-181 - all in due time.
>
> 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.
There is support for spring - I'm a dedicated, happy user of spring.
http://marc.theaimsgroup.com/?l=axis-dev&m=112866697704950&w=2
I personally use the ObjectFactory approach as we have an existing app. I'd
like to see Spring documented but not too many people have been asking for
it.
>
> 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.
I would say novel and clever instead of weird. I guess I find just plopping an
aar in WEB-INF/services to be superior over wsdd and AdminClient. The whole
mar approach for Handlers is a big step in the right direction for me.
>
> 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.
That's fine. These type of discussions take advantage of the open source model
- if done constructively. You could start by documenting alternatives to
OMElement - my guess is that if its good it'll get accepted. Just file a jira
when you're ready.
iksrazal
>
> On 12/15/05, Rakesh Patel <ra...@gmail.com> 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 <to...@gmail.com> 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?
Re: axis2 impressions
Posted by iksrazal <ik...@gmail.com>.
Em Quinta 15 Dezembro 2005 14:11, o Todd Orr escreveu:
> > We build with maven and have a simple goal that iterates through the
> > project's
> > dependencies and copies them all into the lib folder of the axis2 webapp.
> > Another goal removes them. This is pretty easy to do and frees you from
> > having to worry about modifying the axis2 war file.
>
> We use JBoss4 and Ant. In our environment, we would still have to alter the
> deployed war unless we either built axis2 each time, or un/re-packaged the
> war each time. This situation is less than ideal. Even if this is a
> headache for my release engineer and therefore is mitigated to one
> resource, it still pales in comparison the to developer productivity
> drawbacks stated.
I don't get it. Got your own war? in your war ant task put another dir under
WEB-INF called services. Build a jar with an aar extension and plop it in.
Move the axis2.xml file into your WEB-INF. What's so hard about that? Took
me an hour or so with a bigger than average project and a 1000 line
build.xml .
As stated - call me strange but I feel more productive with axis2.
Being constructive, I'd give some hints with your build.xml if you need it.
Also as stated, its just new to you. Soon it won't be if you spend a little
effort. I personally feel I've gained from axis2. Give it a shot and then
decide.
iksrazal
>
> On 12/15/05, Alex Artigues <aa...@picturemarketing.com> wrote:
> > > 5....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.
> >
> > We build with maven and have a simple goal that iterates through the
> > project's
> > dependencies and copies them all into the lib folder of the axis2 webapp.
> > Another goal removes them. This is pretty easy to do and frees you from
> > having to worry about modifying the axis2 war file.
> >
> > --Alex
Re: axis2 impressions
Posted by Todd Orr <to...@gmail.com>.
>
> We build with maven and have a simple goal that iterates through the
> project's
> dependencies and copies them all into the lib folder of the axis2 webapp.
> Another goal removes them. This is pretty easy to do and frees you from
> having to worry about modifying the axis2 war file.
We use JBoss4 and Ant. In our environment, we would still have to alter the
deployed war unless we either built axis2 each time, or un/re-packaged the
war each time. This situation is less than ideal. Even if this is a headache
for my release engineer and therefore is mitigated to one resource, it still
pales in comparison the to developer productivity drawbacks stated.
On 12/15/05, Alex Artigues <aa...@picturemarketing.com> wrote:
>
> > 5....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.
>
> We build with maven and have a simple goal that iterates through the
> project's
> dependencies and copies them all into the lib folder of the axis2 webapp.
> Another goal removes them. This is pretty easy to do and frees you from
> having to worry about modifying the axis2 war file.
>
> --Alex
>
>
Re: axis2 impressions
Posted by Alex Artigues <aa...@picturemarketing.com>.
> 5....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.
We build with maven and have a simple goal that iterates through the project's
dependencies and copies them all into the lib folder of the axis2 webapp.
Another goal removes them. This is pretty easy to do and frees you from
having to worry about modifying the axis2 war file.
--Alex
Re: axis2 impressions
Posted by Todd Orr <to...@gmail.com>.
You're right. Random comments are not helpful. In general, however, Axis1
was far easier to get a working app up with.
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 <ra...@gmail.com> 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 <to...@gmail.com> 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?
> >>
> >>
> >>
> >
> >
> >
>
Re: [Axis2] axis2 impressions
Posted by Eran Chinthaka <ch...@opensource.lk>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi guys,
Let me give simple inputs for this discussion, but I'm not gonna
intervene. ;-)
Let me thank all of you, who were very contructive and enthusiastic to
improve axis2, the project of all of us. I agree there is still some
room for improvements in Axis2, especially in client api and
documentations. To tell you the truth, we have allocated next couple
of weeks to improve major documentations and client api.
During ApacheCon hackathon we did some internal refactorings, as a
first step towards this.
Documentation :
As I always say, this project does not belong only to the developers.
As users we want your support as well. I personally thank iksrazal for
coming forward and providing us with good documentation whenever
required. As Jim mentioned, we developers are not good tech writers
(at least me). So if possible, please help us in that. If you can look
at axis2 and provide us with feedback, and come up with some good
documentation, we really appreciate it. And I personally take the
responsibility to publish them, if they are of good quality.
Please remember that our aim is to provide what users want with users
support. I agree that we can not achieve 100% satisfaction, but we
need to satisfy at least a majority of them. Most of the develepors we
have in Axis2 have experience in writing more than 4-5 soap stacks. So
we believe in their experiences as well.
So please help us in improving docs, providing docs in un covered
areas, etc.,
Client API :
Todd, if you feel like our client api is not good enough, please come
up with a good proposal. We are more than happy to discuss that.
Client api is what most users will be working with and these days
couple of our guys are working hard to improve it. Here also, please
tell us what you want.
Regarding XFire and SOAP stacks :
Each and every soap stack has its pros and cons. I accept that we need
to compete, but we axis2 people are trying our level best to provide
the most useful features. We do not have the mind set of providing
features, simply XFire or other stack has it. We prioritise the
features implementations depending on the user feed back and from our
expert's experiences. So in this process, some features which majority
of the users feel critical may not be critical for some users, which
is unavoidable. So please bear with us. Rememeber one of the
motivations behind Axis2 is to implement new technologies related to
web services. If some thing is getting delayed, please feel free to
come and help us.
Let me remind you one last important thing. Personally I feel really
comfortable with the features Axis2 provides and Axis2 is not inferior
in any means compared to Indigo or any other SOAP stack. So I don't
think any one has problems with Axis2 architecture and its features.
Criticize us, comment and appreciate us. Whatever it is we appreciate it.
Thanks again for all the comments.
- -- Chinthaka
Jim Azeltine wrote:
> This is my third attempt at diving into the use of an open source
> product, and on the whole it has been good. I am always impressed
> that these individuals will put all the time into these projects,
> even though nobody will ever pay them anything for their work. One
> thing that I have learned is that it is NOT a good idea to try to
> implement a newly released project. I have been paying attention to
> the "direction of the breeze" when it comes to Axis 2, but I would
> not even consider trying to implement it in a production
> environment. It is still too "green" for me. On to the constructive
> criticism! 8) (not version specific)
>
> Rakesh Patel <ra...@gmail.com> wrote:
>
>>> I also have not found the experience of working with web
>>> services and apache axis a pleasurable one.
>
> Aside from the frustration factor that is usually present with the
> use of open source projects, I find most of the experience
> pleasurable. The main source of frustration seems to be related to
> the state of the project (how long it has been since release), and
> the state of the documentation.
>
> Rakesh Patel <ra...@gmail.com> wrote:
>
>>> 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.
>
> In most cases, an excellent software developer does not make an
> excellent documentation writer. I could not agree more with the
> statement about the docs not being geared for learning. I would
> guess that most of us who are on the hook to deliver a working
> project have uttered quite a few "oaths" while trying to solve a
> problem using the Axis docs. I find that most of the time, I end up
> doing some "creative" googling to try to find an example of
> something that works. Trying to figure it out by looking through
> the Axis docs is fine some of the time, but not always. For me, if
> you give me a working example (not just a disconnected snippet), I
> can morph it into what I need. I once was responsible for writing
> some training documentation many years ago, and I was told to
> "write it so that an 18 year old girl who just got out of high
> school will understand it". I was puzzled by this and questioned my
> boss, because we had no 18 year old girls in the organization. He
> said "But we could, and that is what you have to shoot for. Don't
> make any assumptions about what people know. If they do already
> know about something, they will skim right over it!". That has
> stuck with me all these years, and I always keep it in mind. There
> are definately NOT enough examples, and they should be closely
> linked (both literally and figuratively) to the docs. Pointing
> people to the Architecture Guide does almost no good at all. It is
> WAY too high level. The User Guide should be geared towards someone
> who knows nothing about Axis, and lead them through from start to
> finish on each of the major concepts that need to be understood in
> order to effectively use Axis. This needs to include links to ready
> to run functional examples that stand by themselves.
>
> Rakesh Patel <ra...@gmail.com> wrote:
>
>>> 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).
>
> The main reason I was told to use Axis in the first place was
> because of the tools, and that it was supposed to be easy to create
> and deploy web services. On the surface, and at the beginning, this
> appears to be true, but then you start having difficulties when you
> get further down the road. Then you start digging into the docs to
> figure things out... If you are prepared for a long ramp-up before
> you get to stability (for your own Axis based project), then you
> will do ok. If you are not, then it is probably best to buy
> something, so you can (hopefully) get support, and resolve your
> issues. Even paid support is not perfect. In some cases, open
> source list support is better than paid support, if someone knows
> about or has dealt with a problem, and you get lucky in that they
> read and reply before your deadline looms. 8)
>
> Rakesh Patel <ra...@gmail.com> wrote:
>
>>> 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.
>
> This is so true! That is why Axis appears to be a good choice in
> the beginning. But the problem is that unless you are willing to
> spend the time to get a really good understanding of SOA, SOAP, and
> web services technology, it is almost guaranteed the you will have
> a difficult time.
>
> Srinath Perera wrote:
>
>>> 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. If you comment please be constructive ..random
>>> opinions do not help anybody!!
>
> One of the reason why there are problems getting things fixed in a
> support group like this is because people are looking for help, and
> may be needing it fast! I recently saw a case where someone posted
> an issue in the evening, and said they needed to have it fixed by
> morning! This is a stretch. If the right individual just happens to
> check, an has the time to come up with a good response, you are
> very lucky. In most cases you MUST assume it will take several days
> for the solution to get seen by someone and responded to. This
> leads to people getting upset, prbably because they need to get the
> damn thing working! Under these conditions, it is sometimes
> difficult to be civil and constructive.
>
>
> Jim Azeltine Sr. Software Engineer SAIC
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFDowU+jON2uBzUhh8RAlNqAJ4sSuSiXDuvZ7m7ykVUAV6Jr4telwCgnkmi
QYVR7Q0ZyuKxSuFqfT+JHrQ=
=i84r
-----END PGP SIGNATURE-----
Re: axis2 impressions
Posted by Jim Azeltine <ja...@sbcglobal.net>.
This is my third attempt at diving into the use of an open source product, and on the whole it has been good. I am always impressed that these individuals will put all the time into these projects, even though nobody will ever pay them anything for their work. One thing that I have learned is that it is NOT a good idea to try to implement a newly released project. I have been paying attention to the "direction of the breeze" when it comes to Axis 2, but I would not even consider trying to implement it in a production environment. It is still too "green" for me.
On to the constructive criticism! 8) (not version specific)
Rakesh Patel <ra...@gmail.com> wrote:
>> I also have not found the experience of working with web services and
>> apache axis a pleasurable one.
Aside from the frustration factor that is usually present with the use of open source projects, I find most of the experience pleasurable. The main source of frustration seems to be related to the state of the project (how long it has been since release), and the state of the documentation.
Rakesh Patel <ra...@gmail.com> wrote:
>> 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.
In most cases, an excellent software developer does not make an excellent documentation writer. I could not agree more with the statement about the docs not being geared for learning. I would guess that most of us who are on the hook to deliver a working project have uttered quite a few "oaths" while trying to solve a problem using the Axis docs. I find that most of the time, I end up doing some "creative" googling to try to find an example of something that works. Trying to figure it out by looking through the Axis docs is fine some of the time, but not always. For me, if you give me a working example (not just a disconnected snippet), I can morph it into what I need.
I once was responsible for writing some training documentation many years ago, and I was told to "write it so that an 18 year old girl who just got out of high school will understand it". I was puzzled by this and questioned my boss, because we had no 18 year old girls in the organization. He said "But we could, and that is what you have to shoot for. Don't make any assumptions about what people know. If they do already know about something, they will skim right over it!". That has stuck with me all these years, and I always keep it in mind.
There are definately NOT enough examples, and they should be closely linked (both literally and figuratively) to the docs. Pointing people to the Architecture Guide does almost no good at all. It is WAY too high level. The User Guide should be geared towards someone who knows nothing about Axis, and lead them through from start to finish on each of the major concepts that need to be understood in order to effectively use Axis. This needs to include links to ready to run functional examples that stand by themselves.
Rakesh Patel <ra...@gmail.com> wrote:
>> 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).
The main reason I was told to use Axis in the first place was because of the tools, and that it was supposed to be easy to create and deploy web services. On the surface, and at the beginning, this appears to be true, but then you start having difficulties when you get further down the road. Then you start digging into the docs to figure things out...
If you are prepared for a long ramp-up before you get to stability (for your own Axis based project), then you will do ok. If you are not, then it is probably best to buy something, so you can (hopefully) get support, and resolve your issues. Even paid support is not perfect. In some cases, open source list support is better than paid support, if someone knows about or has dealt with a problem, and you get lucky in that they read and reply before your deadline looms. 8)
Rakesh Patel <ra...@gmail.com> wrote:
>> 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.
This is so true! That is why Axis appears to be a good choice in the beginning. But the problem is that unless you are willing to spend the time to get a really good understanding of SOA, SOAP, and web services technology, it is almost guaranteed the you will have a difficult time.
Srinath Perera wrote:
>> 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.
>> If you comment please be constructive ..random opinions do not help anybody!!
One of the reason why there are problems getting things fixed in a support group like this is because people are looking for help, and may be needing it fast! I recently saw a case where someone posted an issue in the evening, and said they needed to have it fixed by morning! This is a stretch. If the right individual just happens to check, an has the time to come up with a good response, you are very lucky. In most cases you MUST assume it will take several days for the solution to get seen by someone and responded to. This leads to people getting upset, prbably because they need to get the damn thing working! Under these conditions, it is sometimes difficult to be civil and constructive.
Jim Azeltine
Sr. Software Engineer
SAIC
Re: axis2 impressions
Posted by Rakesh Patel <ra...@gmail.com>.
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 <to...@gmail.com> 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?
>>
>>
>>
>
>
>
Re: axis2 impressions
Posted by Srinath Perera <he...@gmail.com>.
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 <to...@gmail.com> 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?
>