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 <[EMAIL PROTECTED]> 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 <[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?
