Re: SOAP/JMS binding tool changes

From: Jayashree Viswanathan <vjayashree_at_in.ibm.com>
Date: Wed, 24 Sep 2008 23:10:18 +0530

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.

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@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@Sun.COM>
To:	dev@jax-ws.dev.java.net
Cc:	dev@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 {@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@jax-ws.dev.java.net >> For additional commands, e-mail: dev-help@jax-ws.dev.java.net > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@jax-ws.dev.java.net > For additional commands, e-mail: dev-help@jax-ws.dev.java.net > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@jax-ws.dev.java.net For additional commands, e-mail: dev-help@jax-ws.dev.java.net