Axis question: what is the correct way to use Axis?

[ed]

Hello,

I am investigating creating webservices with axis.

I notice that you can just create a bean as a jws file and it will
generate the wsdl.... instant web services....

Yet, I see that many people are running wsdl2java -First creating the
WSDL to generate the java stubs BUT WHY would you do it this way as
opposed to writing your java first, and then exposing it as a service?
Seems very backward....

Ed

 

[Lew]

Hello,

I am investigating creating webservices with axis.

I notice that you can just create a bean as a jws file and it will
generate the wsdl.... instant web services....

Yet, I see that many people are running wsdl2java -First creating the
WSDL to generate the java stubs BUT WHY would you do it this way as
opposed to writing your java first, and then exposing it as a service?
Seems very backward....

Ed

Actually it's very forward. Starting from implementation to create
specification is what's backwards.

Trouble is, going Java -> WSDL ties you to the first implementation, and may
not be easily interoperable with non-Java Web service clients.

The WSDL is a specification for the Web service. Like an interface in Java, a
WSDL document defines the contract for the service. It should come first as a
concomitant to the design process.

Also, one can tune the WSDL to accord with the whims of different popular
environments, like .NET, which is most comfortable with certain conventions
about SOAP element names and the use of "document-literal" specification
rather than "RPC" modes. Then all possible expressions of the WSDL, be they
C#, Perl, Java or whatever, can play nicely together.

The tradeoff, as with just about all frameworks, is that the easy "wizard" way
builds in assumptions about the implementation but is easy, whereas the
trickier "developer" way gives more control at the expense of harder work.

I recommend starting all Web service implementation with a good WSDL, then
writing servers and clients to match, over generation of the WSDL by automatic
means from an implementation.

- Lew

 

[Mike Schilling]

Actually it's very forward. Starting from implementation to create
specification is what's backwards.

Trouble is, going Java -> WSDL ties you to the first implementation,
and may not be easily interoperable with non-Java Web service clients.

The WSDL is a specification for the Web service. Like an interface in
Java, a WSDL document defines the contract for the service. It should
come first as a concomitant to the design process.

Also, one can tune the WSDL to accord with the whims of different
popular environments, like .NET, which is most comfortable with
certain conventions about SOAP element names and the use of
"document-literal" specification rather than "RPC" modes. Then all
possible expressions of the WSDL, be they C#, Perl, Java or whatever,
can play nicely together.

Also, if someday you're going to create rev. 2 of the service without
breaking compatibility with the rev 1. clients, the XMLSchema in the WSDL
makes it clear how to do this compatibly (add optional elements and
attributes to existing types, create derived types using substitution
groups, etc.), while trying to modify Java in a way that produces compatible
WSDL is nearly hopeless.