users@jax-rpc.java.net

Re: WSDL generation

From: Sen, Puny <Punyanjan.Sen_at_SOFTWAREAGUSA.COM>
Date: Mon, 21 Oct 2002 12:42:56 -0600

Vishal,

I agree that it does make sense to make the WSDL the primary interface for
the Web Service (at the expense of a little convenience).

Thanks,
Puny

-----Original Message-----
From: Vishal Goenka [mailto:vgoenka_at_CAMPUSPIPELINE.COM]
Sent: Saturday, October 19, 2002 9:11 AM
To: JAXRPC-INTEREST_at_JAVA.SUN.COM
Subject: Re: WSDL generation


Here is another option to consider.

When you are generating WSDL from Java interfaces, you are stating
that "this WSDL defines the service implemented by the Java interfaces".

However, if you generate your Java interfaces from the WSDL, you will be
stating that "this Java interface implements the service defined by this
WSDL". So, depending upon your goals for implementing Web Services, you
could choose do the following:

1. Start with a Java interface.
2. Generate the WSDL file using wsdeploy (or xrpcc if you are stuck with
the old release of JAX-RPC)
3. Hand edit the WSDL file to change the names of the parameters to match
their friendly names (this will be a one time pain!)
4. Throw away your Java interfaces and parameter class definitions and
regenerate them from WSDL using wscompile.

The generated Java interfaces will have the right parameter names! Next time
you want to edit the interfaces, you can either edit WSDL directly (if
you are comfortable) or edit the generated Java interfaces, re-generate the
WSDL and merge the changes with your earlier WSDL.

The main point of this mechanism is to maintain the WSDL as the "definitive"
service definition, and not the Java interface definition. This is more work
in general than editing Java Interfaces, but if your goal is to define a
Web Service with a Java implementation as opposed to a WebService exposure
of your existing Java implementation, it may make sense.

There are a few other advantages and disadvantages of this approach.

Advantages:

Certain XML complex type definitions such as "Enumerations" translate well
from WSDL (actually XML schema) to Java, but never the other way round. If
you wanted to define an enumeration in Java, JAX-RPC will NOT convert it to
an enumeration in XML (in WSDL).

Disadvantage:

There is no way yet to document your WSDL and have the documentation be
generated in the generated Java sources so you can automatically generate
JavaDocs for your Java API binding!

Regards,
--Vishal


>Hi Punyanjan,
>
>The WSDL can not be generated from source files.
>
>Thanks for your interest in JAX-RPC.
>
>Regards,
>-Arun
>
>"Sen, Puny" wrote:
>>
>> Vishal,
>>
>> Thanks for the explanation.
>>
>> Is it possible to generate WSDL from the source files?
>>
>> Thanks,
>> Punyanjan
>>
>> -----Original Message-----
>> From: Vishal Goenka [mailto:vgoenka_at_CAMPUSPIPELINE.COM]
>> Sent: Thursday, October 17, 2002 7:24 AM
>> To: JAXRPC-INTEREST_at_JAVA.SUN.COM
>> Subject: Re: WSDL generation
>>
>> Punyanjan,
>>
>> wsdeploy uses the class files to generate the WSDL file, and the
parameter
>> names are not preserved in a class file.
>>
>> --Vishal
>>
>> On Wed, 16 Oct 2002 17:40:20 -0600, Sen, Puny
>> <Punyanjan.Sen_at_SOFTWAREAGUSA.COM> wrote:
>>
>> >Hi,
>> >
>> >When I generate a WSDL using wsdeploy, the parameters of my method are
>> >translated to "String1", "String2", etc. Is there a way to preserve the
>> >parameter names?
>> >
>> >Thanks,
>> >Puny Sen
>
>--
>=============================================
>There is only one me, I must live myself!
>There is only one today, I must live itself!
>=============================================
>http://members.tripod.com/~apgupta/index.html
>=============================================