axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ayers, Sam" <>
Subject RE: possible ways of creating WSDL file
Date Thu, 24 Mar 2005 12:37:02 GMT
I believe you are all correct, from different perspectives.  But, I believe one must take into
account the same lessons learned from "round-trip" engineering in software development.

1) If it is a new system, starting from scratch, and involving heterogeneous systems integration,
yes, it is best to focus on the interface early in the lifecycle, and perhaps design the WSDL
before coding.  After the WSDL is "roughed-in", use the round trip tools (wsdl2java) to maintain.

2) If the system involves extension of an existing legacy code base it is practical to "reverse
engineer" the interface from the code, starting with code and generating the wsdl.  Then,
you can maintain the wsdl by editing the wsdl, or by editing the code, and using the round-trip
tools to keep them in synch.

3) For expert developers who are relatively new to web services and SOAP (i.e. exactly the
audience we are trying to bring up to get on board) I believe writing WSDL from the get-go
is impossible.  You must start from code, generate the wsdl, then hopefully learn-by-doing
by examining the output wsdl, and maintaining it moving forward.  Insisting that expert developers
start by creating wsdl is somewhat akin to the round-trip engineering "paralysis by analysis".
 You'll end up spending large amounts of time trying to create and perfect the WSDL, while
in the end the project fails because you took too long analyzing and creating the interface.

So, I believe the answer is in "rapid iteration", i.e. successive approximation utilizing
both techniques, and choosing the right one at the right moment.  To insist on working WSDL
before a project begins, especially for legacy systems integration, is somewhat akin to following
the "waterfall model" of software development.  Instead, we need to be flexible, rapidly iterate,
and judiciously use all tools at our disposal.


-----Original Message-----
From: Anne Thomas Manes []
Sent: Wednesday, March 23, 2005 6:02 PM
Subject: Re: possible ways of creating WSDL file

In a better world, you have a XML Schema administration team (similar
to your DBA team) that is responsible for developing the schemas that
applications will communicate with. (Do your developers define their
own database schemas???)

When developers build services, they should be handed the schemas they
are supposed to use, and then map those schems to their code.

Developers should not generate WSDL from code.


On Wed, 23 Mar 2005 14:55:38 -0800, Tim K. (Gmane) <> wrote:
> In an ideal world I would agree with Anne. However, consider this
> scenario: you have a team of 10+ developers working on a server side API
> that follows the rules to allow it to be easily exposed as web services.
> The API has over 200+ methods total, distributed over 20+ modules. Each
> module would be exposed as a web service, hence 20+ WSDL files. The goal
> is to have the API on the server side look exactly the same as the API
> on the client side, so in theory an application built against the API
> could be run in process on the server or remotely via web services.
> Now, only a couple of these developers know anything about web services
> and even those developers are just getting their feet wet with web services.
> During the development cycle the API's can (slightly) change many times
> a day and everything needs to be recompiled/regenerated. I think it's
> unreasonable in this case to edit any generated WSDL files by hand. It's
> much more reasonable to just fire an ant task that starts with the
> server side java classes, generates the WSDL's and from those the client
> side stubs. This improves the development process a lot.
> I hope I'll live to see the day when the tools are good enough to
> achieve this task end to end. Obviously we are not there yet, but we are
> getting close.
> Btw, this is not an imaginary scenario, it's the cruel reality I live in
> every day.
> Tim
> Anne Thomas Manes wrote:
> > I strongly disagree with Sunil. WSDL First (TM) is the way to go.
> >
> > I think it's okay to use java2wsdl to generate a WSDL template to
> > start with, but you should always edit the generated WSDL.
> >
> > My recommendation is to use a WSDL editing wizard. Cape Clear provides
> > a free one (SOA Editor). Altova and Sonic provide commercial ones.
> >
> > Anne
> >
> >
> > On Wed, 23 Mar 2005 13:49:53 -0500, Soti, Dheeraj <> wrote:
> >
> >>Sunil,
> >>
> >>Will java2wsdl create the complex type hierarchies correctly? I have a complex
> >>class hierarchy (using inheritance and nested classes) and finally I ended up
> >>handcoding the wsdl from scratch. Did I miss something? I've also read some best
> >>practice articles talking about top down approach where u write your wsdl first
> >>and then proceed.
> >>
> >>Thanks
> >>
> >>Dheeraj
> >>
> >>-----Original Message-----
> >>From: Sunil Kothari []
> >>Sent: Wednesday, March 23, 2005 1:20 AM
> >>To:
> >>Cc:
> >>Subject: Re:possible ways of creating WSDL file
> >>
> >>I think of 3 ways of creating WSDL
> >>1) Using java2wsdl tool
> >>2) Using .jws facility
> >>3) Handcode WSDL
> >>
> >>I think 3) is error-prone and requires high level of understanding of
> >>WSDL. 2) is also not recommended for various reasons like
> >>a) No deployment descriptors are created
> >>b) WSDL is not persistent and prone to changes
> >>c) (This I am not sure) For overloaded methods this way of creation
> >>causes problems.
> >>
> >>I hope this helps.
> >>
> >>Sunil Kothari
> >>Valtech India
> >>
> >> Any Information contained or transmitted in this e-mail and / or
> >>attachments may contain confidential data, proprietary to Majoris
> >>Systems Pvt Ltd., and / or the authors of the information and is
> >>intended for use only by the individual or entity to which it is
> >>addressed. If you are not the intended recipient or email appears
> >>to have been sent to you by error, you are not authorised to access,
> >>read, disclose, copy, use or otherwise deal with it. If you
> >>have received this e-mail in error, please notify us immediately at
> >>mail to: and delete this mail from your records.
> >>
> >>This is to notify that Majoris Systems Pvt Limited shall have no
> >>liability or obligation, legal or otherwise, for any errors,
> >>omissions, viruses or computer problems experienced as a result of
> >>this transmission since data over the public Internet cannot be
> >>guaranteed to be secure or error-free.
> >>
> >
> >
Learn more about Paymentech's payment processing services at
THIS MESSAGE IS CONFIDENTIAL.  This e-mail message and any attachments are proprietary and
confidential information intended only for the use of the recipient(s) named above.  If you
are not the intended recipient, you may not print, distribute, or copy this message or any
attachments.  If you have received this communication in error, please notify the sender by
return e-mail and delete this message and any attachments from your computer.

View raw message