dev@jax-ws.java.net

Re: SOAP/JMS binding tool changes

From: Jitendra Kotamraju <Jitendra.Kotamraju_at_Sun.COM>
Date: Wed, 08 Oct 2008 14:10:11 -0700

Jitendra Kotamraju wrote:
> Jayashree Viswanathan wrote:
>>
>> Hi,
>>
>> I think there is a complexity in using the bindingID in all the
>> places is to create a bindingID by implementing the abstract method
>> createEncoder. For Instance if we use Soap1.1 protocol itself, there
>> has to be another encoder created , which is already implemented
>> through.I still doubt if this complexity is required at user end to
>> support another transport ex.,JMS on same protocol SOAP.Please let me
>> know your suggestions on this.
> We have utility methods on Codecs to create the SOAP codec. So that
> shouldn't be a problem. We can add some more, if needed
>
> Codecs.create(binding,
> Codecs.createSOAPEnvelopeXmlCodec(binding.getSOAPVersion()));
>
> I think it is better to create a project on jax-ws-commons to see if
> everything is covered. Let me do that.
Just added a jax-ws-commons project. See JMSBindingID impl in the
following link :
https://jax-ws-commons.dev.java.net/source/browse/jax-ws-commons/trunk/jms-binding/jaxws-jms/src/main/java/org/jvnet/jax_ws_commons/jms/JMSBindingID.java?rev=713&view=markup

once you do "mvn install", a test case is run and that produces a WSDL.
Once I do the changes for BindingID#getTransport() it will generate
wsdl:binding/soap:binding[@tranport] attribute correctly for SOAP1.1/JMS
binding id.

I think we can add the extension WsGenProtocolExtension to RI and add an
implementation to it in the commons project. Then we will know we can
validate the proposed extensions.

Jitu
>
> Jitu
>>
>> I agree with your WsGenProtocolExtension, which serves the purpose of
>> providing the details similar to the NewAbstracclass mentioned in
>> earlier.Though while using Wsgen,at the command-line, I think there
>> still has to be a transport validation made, after protocol
>> validation.So the WsGenProtocolExtension.java might need methods like
>> getTransport() again or we need to obtain the same from the bindingID
>> using the getBindingID() method.
>>
>> Also in Wsimport which has not been discussed yet, there will be a
>> lexical value that we get from the WSDL file which needs to be
>> tolerated, based on if it is supported by say plugin implementation
>> class .So I think we need some methods like ,
>>
>> boolean validateURL(String SOAP_BINDING_TRANSPORT)
>>
>> in the abstract class.
>>
>> Please let me know your thoughts on these as well.
>>
>> Thanks and Regards,
>> Jayashree V
>>
>>
>> From: Jayashree Viswanathan/India/IBM
>> To: dev_at_jax-ws.dev.java.net
>> Date: 30/08/2008 09:17
>> Subject: Re: SOAP/JMS binding tool changes
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>