Hi Jitu,
I would send my detail feedback for your proposal by Sep 11th.
But to mention the earlier proposal was given thinking in mind the
flexibility to support any transport/protocol and URL value that the user
would like to, at least from the point of generating a wsdl file.
JDK is currently restricted to the four URLs that we have in the
HTTPbinding.java invariable of what transport we use.While doing the
Command-line operation as well we would need the specific URL, that are
currently being fetched from the HTTPBinding.java
Thanks and Regards,
Jayashree V
From: Jitendra Kotamraju <Jitendra.Kotamraju_at_Sun.COM>
To: dev_at_jax-ws.dev.java.net
Cc: dev_at_metro.dev.java.net
Date: 30/08/2008 07:37
Subject: Re: SOAP/JMS binding tool changes
wsgen shows the following usage:
-wsdl[:protocol] generate a WSDL file. The protocol is
optional.
Valid protocols are soap1.1 and Xsoap1.2,
the default
is soap1.1. Xsoap1.2 is not standard and
can only be
used in conjunction with the -extension option
The known values for "protocol" are "soap1.1", "Xsoap1.2"(we don't want
the user to give a big lexical value of the binding). This value is
converted to BindingID. To support other bindings like SOAP/JMS binding,
it would be good to have an extension that converts the "protocol" to
BindingID. Also when there is an extension of this type in the
classpath, it would be nice to reflect those values in the usage.
I am thinking in the following lines:
abstract class WsGenProtocolExtension {
// "protocol" value in -wsd[:protocol] option of wsgen
abstract String getProtocol()
// will be called when {_at_link #getProtocol()} matches the
// "protocol" value in -wsdl[:protocol] command line option
// Use BindingID.parse(String lexical) to create the BindingID
abstract BindingID getBindingID()
}
Jitu
Jitendra Kotamraju wrote:
> * I think SOAP/JMS binding still needs to be found by BindingIDFactory
> extension. One can write JMSBindingIDFactory that knows how to create
> BindingID from SOAP/JMS binding lexical values. This BindingID, say
> JMSBindingID works for both SOAP1.1 and SOAP 1.2 versions.
>
> * We could add a method to BindingID that gives the transport
> attribute for the soap binding in the WSDL. The default implementation
> would return http transport attribute. This means the existing
> BindingID impl wouldn't break. JMSBindingID would provide its own
> implementation for this method. WSDLGenerator uses this method while
> generating WSDL
>
> String getTransport() {
> // Based on SOAPVersion return the correct transport attribute
> return SOAP_HTTP_TRANSPORT or SOAP12_HTTP_TRANSPORT;
> }
>
> * I suggest that we add these extensions to the trunk and also create
> a JMS binding commons project in jax-ws-commons.dev.java.net
>
> * I will send more feedback about the wsgen command line options later
> this week.
>
> Jitu
>
> On Aug 20, 2008, at 9:56 AM, Jitendra Kotamraju wrote:
>
>> I am attaching the design document from IBM developers regarding
>> SOAP/JMS binding. I respond with my feedback later today.
>>
>> thanks,
>> Jitu
>>
>> <IBMJAXWSRequirement12June08.doc>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
>> For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net