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.
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