Re: why Axis?

["Daniel F. Savarese" <df...@savarese.org>]

In message <00...@DELL850>, "Stan Jordan" writes:
>Every time I pick up a magazine, I see an article advising Java programmers
>to build Web Services via JAX-RPC and JAXM APIs.  The articles are complete
>with lotsa examples (but do not mention Axis).

As someone who wrote about JAXM and has been writing about XML/Web services
APIs, I'll make a few comments.  First, so-called "standard" APIs
coming out of the Java Community Process are subjects editors like to
see articles about, so you'll tend to see a lot of them.  Axis only
recently entered beta and editors don't like to publish material that
becomes outdated in the two months it takes for a submission to be
published, so that's why it probably hasn't been covered.  Now that Axis
is in beta, I plan to write my next column (won't be published until July)
on Axis because ... after having used JAXM extensively, I can certify that
JAXM is an absolute piece of garbage that should never have passed muster
(it barely did with a 7-6 vote).

>Where does Axis fit into this picture?  I don't want to sound rude, but why
>would I program with Axis, rather than using the JAX-RPC and JAXM APIs?

One big reason to use Axis is that as you encounter deficiencies in design
or functionality, you can bring them to light, discuss them, and submit
patches.  You can't do this with JAXM or JAX-RPC because not even the
source code is available to you.  JAX-RPC is much better designed than
JAXM, but it is oriented strictly at RPC functionality and doesn't provide
document-oriented SOAP manipulation functionality like JAXM's javax.xml.soap
package.  Axis doesn't (or eventually won't) limit you to any one model.
I'll let others go into more detail, but Axis is simply a more complete
solution.  JAXM should be avoided at all costs if you want to do
asynchronous messaging (e.g., asynchronous messaging endpoints must be
preconfigured before use; you cannot message to an arbitrary URL on the
fly, only predefined URI to URL mappings) or manipulate SOAP messages
on a fine-grained level.  javax.xml.soap does not interoperate with DOM
(which you need if you have a bunch of pre-existing DOM-based code)
beyond allowing you the entire content of a message to be set from
a javax.xml.transform.Source.  The only piecemeal message modification
supported is with the javax.xml.soap.Node derived classes.

>speculate beyond JAX-RPC and JAXM (to say, JAXB) that would be very cool.

Regarding JAXB, many people (including myself) have found that it's too
early to use it even though it looks very good so far (it's not expected
to be finalized until Q3 or Q4).  Forget about trying to make JAX-RPC or
JAXM play well with JAXB (eventually they'll have to play well together,
but I doubt they will until sometime in 2003).  Castor is a much more
productive investment of your time.

I haven't really justified my statements, but they come from the school
of hard knocks: trying to use the so-called standards and abandoning them
because of their inability to meet my application development requirements.

daniel

Re: why Axis?

[Peter Allday <pe...@cre.canon.co.uk>]

The other reason of course is that Axis is very easy to use.  I haven't used
JAXM or JAX-RPC so I can't compare, but we are doing interoperability
testing between different SOAP implementations (mainly .Net so far), and
have found it to be great.  An example.  If a .Net service is developed I
can just point the WSDL2Java at the .Net wsdl url, and hey presto I have a
working client.  I can also have a working server as well (if I choose that
option), and I only have to do the business logic part of the program as all
the SOAP message handling is done for me.

Basically, given a WSDL file, you can get both a client and a server written
and deployed in approx 5 mins. (This time obviously depends upon the
complexity of the business logic as stated previously)

That's why I'm using it anyway.

Peter
----- Original Message -----
From: "Stan Jordan" <sk...@worldnet.att.net>
To: <ax...@xml.apache.org>
Cc: "Daniel Savarese" <df...@savarese.org>
Sent: Thursday, March 21, 2002 1:55 AM
Subject: Re: why Axis?


> Daniel...
> Hoo-ahh.  Bravo.  You have shed very much light, and I am very much
obliged.
> Thank you, thank you, thank you!
> Stan
>
> ----- Original Message -----
> From: "Daniel F. Savarese" <df...@savarese.org>
> To: <ax...@xml.apache.org>
> Sent: Wednesday, March 20, 2002 6:05 PM
> Subject: Re: why Axis?
>
>
> >
> > In message <00...@DELL850>, "Stan Jordan"
writes:
> > >Every time I pick up a magazine, I see an article advising Java
> programmers
> > >to build Web Services via JAX-RPC and JAXM APIs.  The articles are
> complete
> > >with lotsa examples (but do not mention Axis).
> >
> > As someone who wrote about JAXM and has been writing about XML/Web
> services
> > APIs, I'll make a few comments.  First, so-called "standard" APIs
> > coming out of the Java Community Process are subjects editors like to
> > see articles about, so you'll tend to see a lot of them.  Axis only
> > recently entered beta and editors don't like to publish material that
> > becomes outdated in the two months it takes for a submission to be
> > published, so that's why it probably hasn't been covered.  Now that Axis
> > is in beta, I plan to write my next column (won't be published until
July)
> > on Axis because ... after having used JAXM extensively, I can certify
that
> > JAXM is an absolute piece of garbage that should never have passed
muster
> > (it barely did with a 7-6 vote).
> >
> > >Where does Axis fit into this picture?  I don't want to sound rude, but
> why
> > >would I program with Axis, rather than using the JAX-RPC and JAXM APIs?
> >
> > One big reason to use Axis is that as you encounter deficiencies in
design
> > or functionality, you can bring them to light, discuss them, and submit
> > patches.  You can't do this with JAXM or JAX-RPC because not even the
> > source code is available to you.  JAX-RPC is much better designed than
> > JAXM, but it is oriented strictly at RPC functionality and doesn't
provide
> > document-oriented SOAP manipulation functionality like JAXM's
> javax.xml.soap
> > package.  Axis doesn't (or eventually won't) limit you to any one model.
> > I'll let others go into more detail, but Axis is simply a more complete
> > solution.  JAXM should be avoided at all costs if you want to do
> > asynchronous messaging (e.g., asynchronous messaging endpoints must be
> > preconfigured before use; you cannot message to an arbitrary URL on the
> > fly, only predefined URI to URL mappings) or manipulate SOAP messages
> > on a fine-grained level.  javax.xml.soap does not interoperate with DOM
> > (which you need if you have a bunch of pre-existing DOM-based code)
> > beyond allowing you the entire content of a message to be set from
> > a javax.xml.transform.Source.  The only piecemeal message modification
> > supported is with the javax.xml.soap.Node derived classes.
> >
> > >speculate beyond JAX-RPC and JAXM (to say, JAXB) that would be very
cool.
> >
> > Regarding JAXB, many people (including myself) have found that it's too
> > early to use it even though it looks very good so far (it's not expected
> > to be finalized until Q3 or Q4).  Forget about trying to make JAX-RPC or
> > JAXM play well with JAXB (eventually they'll have to play well together,
> > but I doubt they will until sometime in 2003).  Castor is a much more
> > productive investment of your time.
> >
> > I haven't really justified my statements, but they come from the school
> > of hard knocks: trying to use the so-called standards and abandoning
them
> > because of their inability to meet my application development
> requirements.
> >
> > daniel
> >
> >
>
>

Re: why Axis?

[Stan Jordan <sk...@worldnet.att.net>]

Daniel...
Hoo-ahh.  Bravo.  You have shed very much light, and I am very much obliged.
Thank you, thank you, thank you!
Stan

----- Original Message -----
From: "Daniel F. Savarese" <df...@savarese.org>
To: <ax...@xml.apache.org>
Sent: Wednesday, March 20, 2002 6:05 PM
Subject: Re: why Axis?


>
> In message <00...@DELL850>, "Stan Jordan" writes:
> >Every time I pick up a magazine, I see an article advising Java
programmers
> >to build Web Services via JAX-RPC and JAXM APIs.  The articles are
complete
> >with lotsa examples (but do not mention Axis).
>
> As someone who wrote about JAXM and has been writing about XML/Web
services
> APIs, I'll make a few comments.  First, so-called "standard" APIs
> coming out of the Java Community Process are subjects editors like to
> see articles about, so you'll tend to see a lot of them.  Axis only
> recently entered beta and editors don't like to publish material that
> becomes outdated in the two months it takes for a submission to be
> published, so that's why it probably hasn't been covered.  Now that Axis
> is in beta, I plan to write my next column (won't be published until July)
> on Axis because ... after having used JAXM extensively, I can certify that
> JAXM is an absolute piece of garbage that should never have passed muster
> (it barely did with a 7-6 vote).
>
> >Where does Axis fit into this picture?  I don't want to sound rude, but
why
> >would I program with Axis, rather than using the JAX-RPC and JAXM APIs?
>
> One big reason to use Axis is that as you encounter deficiencies in design
> or functionality, you can bring them to light, discuss them, and submit
> patches.  You can't do this with JAXM or JAX-RPC because not even the
> source code is available to you.  JAX-RPC is much better designed than
> JAXM, but it is oriented strictly at RPC functionality and doesn't provide
> document-oriented SOAP manipulation functionality like JAXM's
javax.xml.soap
> package.  Axis doesn't (or eventually won't) limit you to any one model.
> I'll let others go into more detail, but Axis is simply a more complete
> solution.  JAXM should be avoided at all costs if you want to do
> asynchronous messaging (e.g., asynchronous messaging endpoints must be
> preconfigured before use; you cannot message to an arbitrary URL on the
> fly, only predefined URI to URL mappings) or manipulate SOAP messages
> on a fine-grained level.  javax.xml.soap does not interoperate with DOM
> (which you need if you have a bunch of pre-existing DOM-based code)
> beyond allowing you the entire content of a message to be set from
> a javax.xml.transform.Source.  The only piecemeal message modification
> supported is with the javax.xml.soap.Node derived classes.
>
> >speculate beyond JAX-RPC and JAXM (to say, JAXB) that would be very cool.
>
> Regarding JAXB, many people (including myself) have found that it's too
> early to use it even though it looks very good so far (it's not expected
> to be finalized until Q3 or Q4).  Forget about trying to make JAX-RPC or
> JAXM play well with JAXB (eventually they'll have to play well together,
> but I doubt they will until sometime in 2003).  Castor is a much more
> productive investment of your time.
>
> I haven't really justified my statements, but they come from the school
> of hard knocks: trying to use the so-called standards and abandoning them
> because of their inability to meet my application development
requirements.
>
> daniel
>
>

Re[2]: why Axis?

[Alex Krotov <to...@yahoo.com>]

Hello Daniel,

Thank for your review, it saved my time by not learning "garbage"
standarts.
As for JAXB, I'd add that it would be possibly helpful if it'd supports XML
Schema - Beans mapping.


-- 
Best regards,
 Alex                            mailto:tornos_itanius@yahoo.com

> In message <00...@DELL850>, "Stan Jordan" writes:
>>Every time I pick up a magazine, I see an article advising Java programmers
>>to build Web Services via JAX-RPC and JAXM APIs.  The articles are complete
>>with lotsa examples (but do not mention Axis).

> As someone who wrote about JAXM and has been writing about XML/Web services
> APIs, I'll make a few comments.  First, so-called "standard" APIs
> coming out of the Java Community Process are subjects editors like to
> see articles about, so you'll tend to see a lot of them.  Axis only
> recently entered beta and editors don't like to publish material that
> becomes outdated in the two months it takes for a submission to be
> published, so that's why it probably hasn't been covered.  Now that Axis
> is in beta, I plan to write my next column (won't be published until July)
> on Axis because ... after having used JAXM extensively, I can certify that
> JAXM is an absolute piece of garbage that should never have passed muster
> (it barely did with a 7-6 vote).

>>Where does Axis fit into this picture?  I don't want to sound rude, but why
>>would I program with Axis, rather than using the JAX-RPC and JAXM APIs?

> One big reason to use Axis is that as you encounter deficiencies in design
> or functionality, you can bring them to light, discuss them, and submit
> patches.  You can't do this with JAXM or JAX-RPC because not even the
> source code is available to you.  JAX-RPC is much better designed than
> JAXM, but it is oriented strictly at RPC functionality and doesn't provide
> document-oriented SOAP manipulation functionality like JAXM's javax.xml.soap
> package.  Axis doesn't (or eventually won't) limit you to any one model.
> I'll let others go into more detail, but Axis is simply a more complete
> solution.  JAXM should be avoided at all costs if you want to do
> asynchronous messaging (e.g., asynchronous messaging endpoints must be
> preconfigured before use; you cannot message to an arbitrary URL on the
> fly, only predefined URI to URL mappings) or manipulate SOAP messages
> on a fine-grained level.  javax.xml.soap does not interoperate with DOM
> (which you need if you have a bunch of pre-existing DOM-based code)
> beyond allowing you the entire content of a message to be set from
> a javax.xml.transform.Source.  The only piecemeal message modification
> supported is with the javax.xml.soap.Node derived classes.

>>speculate beyond JAX-RPC and JAXM (to say, JAXB) that would be very cool.

> Regarding JAXB, many people (including myself) have found that it's too
> early to use it even though it looks very good so far (it's not expected
> to be finalized until Q3 or Q4).  Forget about trying to make JAX-RPC or
> JAXM play well with JAXB (eventually they'll have to play well together,
> but I doubt they will until sometime in 2003).  Castor is a much more
> productive investment of your time.

> I haven't really justified my statements, but they come from the school
> of hard knocks: trying to use the so-called standards and abandoning them
> because of their inability to meet my application development requirements.

> daniel


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com