The two-step process is actually necessary to delineate server-side stuff
and client-side stuff. In fact, there are three broad steps really:
1. Generate WSDL from the classes - interface generation.
2. Generate WSDD and server-side skeletons from the WSDL - deployment
   description.
3. Generate client stubs from the WSDL - client-side work.

Of these, #3 is optional, of course - do it only if your customer wants it.

Logically, #1 and #2 could be combined, but Axis doesn't, presumably because
the "intermediate" step of producing a WSDL is a valuable exercise in
itself. However, the WSDL generated here is essentially discarded because
the "true" WSDL is the one generated on demand after deploying the WSDD. A
bit wasteful perhaps, but no real complaint here.

However, Axis combines #2 and #3, which is confusing. #2 clearly generates
server-side artifacts, whereas #3 clearly generates client-side artifacts.
As I said, it's annoying, but not paralysing.

Anand

On Tue, 16 Nov 2004, Joe Plautz wrote:

: I'll try and be more positive next time. I was trying to be impartial
: ;-) I do agree that the developer doesn't have to deal much with the
: WSDD. Using the ant axis tasks should be a best practice. It does
: automate a lot of stuff that doesn't need to be dealt with. I would
: actually go farther and say that it would be nice to be able to go from
: class to WSDD in one easy step. Create your business classes, generate
: the WSDD, deploy. I think the step of generating the WSDL from the class
: and then generating the server side "clutters" the process up a little
: bit. It's another source of potential error.
:
: Anand Natrajan wrote:
: > I agree with Joe's analysis overall, but I would be a bit more positive
: > about approach #2. In this approach, you generate a Java class and use that
: > you deploy your service. That's Joe's preferred approach and mine as well.
: >
: > However, the developer really doesn't have to diddle with WSDDs... or even
: > WSDLs for that matter. The Ant task for generating them - wsdl2java - isn't
: > that hard, and once learnt, it's dead easy to retain. In fact, here it is,
: > for posterity. ((:
: >         <axis-wsdl2java
: >             output="${wsdl.build.dir}"
: >             url="${wsdl.build.dir}/${wsdlName}.wsdl"
: >             serverside="true">
: >             <mapping namespace="urn:${wsdlName}"
: >                 package="com.abc.ws.stubs"/>
: >             <mapping namespace="urn:APICommon"
: >                 package="com.abc.api.common"/>
: >         </axis-wsdl2java>
: > This snippet assumes your common classes, e.g., data structures, are in the
: > com.abc.api.common package, and you want to give them a namespace of
: > APICommon. Everything else is pretty straightforward.
: >
: > The above task makes classs-to-WSDL-to-WSDD generation really easy. The
: > developer has to deal with Java and Ant alone, not WSDDs and WSDLs. The only
: > gripe I have with this process is that Axis's wsdl2java insists on putting
: > _client-side_ stubs in the same directory as _server-side_ WSDDs. There's no
: > getting around that because both get generated in the same task. Annoying,
: > but we can live with it.
: >
: > Anand
: >
: > On Tue, 16 Nov 2004, Joe Plautz wrote:
: >
: > : Funny you should ask this question.
: > :
: > : When I asked it about 6 months ago it spawned a week long thread that,
: > : in my opinion never reached a conclusion. But, this is what I gathered
: > : from it. There are three schools of thought when it comes to creating
: > : Axis web services. 1) Start with a WSDL and generate your code from
: > : that. 2) Start with a class and generate a WSDL so that you can generate
: > : the WSDD. 3)Start with a JWS or message service that accepts a string
: > : and parse it with Castor or some other xml binding engine. Remember each
: > : one has it's own specific merits and drawbacks.
: > :
: > : 1) The WSDL approach; you start with a WSDL and it is rather simple to
: > : create. Plus, it's the one location where you define your service. And
: > : then everything gets generated. The drawback comes in when you add
: > : future functionality, you end up regenerating things over and over
: > : again. And if you've added any functionality to any of the generated
: > : classes outside of the impl class, you have to be careful when doing
: > : your generation, it will get over written.
: > :
: > : 2) The class approach; you start with a class, I don't think there is an
: > : easier starting point for java developers. You create your code and
: > : expose it to the world using the WSDD's. The drawback of this is
: > : generating the WSDD's. WSDD's are a little bit more complicated than
: > : WSDL's. You could create them by hand, but it's more prone to error. And
: > : to generate them you have to be pretty comfortable in ant, it can be
: > : very hackish.
: > :
: > : 3) The String approach; I've never attempted using this approach but
: > : there is a relatively popular article that recommends this. If you are
: > : heavily invested into Castor or some other framework, I see the merits
: > : of implementing this approach. Also, you theoretically could get by with
: > : exposing only one service. The drawbacks of this, you're adding another
: > : layer to an increasingly complex puzzle. Axis does all of the parsing
: > : for you already, why add another layer?
: > :
: > : I couldn't tell you which technique is the most popular, I would say
: > : that the WSDL and Class approaches are the most common and are split
: > : fairly evenly. The people that I've have personally run into have used
: > : the class approach exclusively. But, some of them were exposing EJB's so
: > : take that with a grain of salt.
: > :
: > : As for books/documentation, keep waiting for an Axis specific book. None
: > : exist show what you can really do with this technology. Most just
: > : explain the architecture. One thing I have noticed though, version 1.2
: > : documentation is way better than version 1.1.
: > :
: > : For tools, Mindreef SoapScope, is an excellent testing tool. Reads in
: > : and validates WSDL's. You can also test the service by inputing data
: > : into a form. I use this all the time. Cape Clear has a WSDL tool that
: > : I've used a couple times. Very easy to create a WSDL from scratch.
: > :
: > : Axis is an excellent tool. It does have a lot of power in it and can be
: > : used in just about any way you wish. But, like EJB and other distributed
: > : technologies they need to be used where appropriate. Deciding where it's
: > : appropriate is something that comes with experience not reading it from
: > : somewhere.
: > :
: > : Have a great day,
: > : Joe Plautz
: > :
: > : [EMAIL PROTECTED] wrote:
: > : >
: > : > Thanks, Nikki.
: > : >
: > : > We have a standard of complying to Basic Profile 1.0, for
: > : > interoperability but, on top of that, I'm looking for generally accepted
: > : > good ways of doing stuff during development of web services servers and
: > : > clients. Beyond BP 1, are there useful ways to structure WSDL and type
: > : > definitions, are there any deployment tips, are there any patterns for
: > : > common problems in web services, tips on building and testing, and so
: > : > on. I've seen this sort of stuff for languages and technologies in the
: > : > past and, no doubt, best practices will emerge on web services, in the
: > : > future. Quite a good, thin, book of Java is "Java with Style" (or some
: > : > such title). It would be nice to have something like that for web
: > : > services, but, until then, if anyone has produced anything in this vein,
: > : > that would be great.
: > : >
: > : > Thanks for the links. I was aware of them but don't think they have
: > : > anything specific on best practice, though some of the information might
: > : > prove useful for a best practices guide.
: > : >
: > : > Cheers,
: > : > Tony
: > : >
: > : >
: > : >
: > : >
: > : > Hi Tony
: > : >
: > : > Not sure what you're after in particular,
: > : >
: > : > For W3C's efforts in this area see links from http://www.w3.org/2002/ws/
: > : > For OASIS efforts see  http://www.oasis-open.org/specs/index.php
: > : >
: > : > For Axis there is the userguide, this list & if you search the archives 
of
: > : > this list for "books" you may find other helpful references.
: > : >
: > : > HTH
: > : > Nikki
: > : >
: > : > --On Tuesday, November 16, 2004 11:41:41 +0000 [EMAIL PROTECTED] wrote:
: > : >
: > : >  >
: > : >  > Does no one have, or have knowledge of, any best practice in the web
: > : >  > service arena?
: > : >  >
: > : >  > I'm looking for a set of hints and tips, rather than a 800 page book.
: > : >  >
: > : >  > Tony
: > : >  >
: > : >  >
: > : >  >
: > : >  > Does anyone know of a published set of best practices, both for web
: > : >  > services in general and Axis in particular?
: > : >  >
: > : >  > I've scoured the Net and found a few bits and pieces, but I'm 
looking for
: > : >  > something more substantial (though not *too* substantial).
: > : >  >
: > : >  > Tony
: > : >  >
: > : >
: > : >
: > : >
: > : > ----------------------
: > : > NJ Rogers, Technical Researcher
: > : > (Semantic Web Applications Developer)
: > : > Institute for Learning and Research Technology (ILRT)
: > : > Email:[EMAIL PROTECTED]
: > : > Tel: +44(0)117 9287096 (Direct)
: > : > Tel: +44(0)117 9287193 (Office)
: > : >
: > : >
: > :
: > .
: >
:

Reply via email to