Loading ...
Sorry, an error occurred while loading the content.

Re: MS's 4 endpoints

Expand Messages
  • mikeg@dulciana.com
    Matt, Indeed, the referenced section of the WSDL specification just means you can properly associate the binding clause with its corresponding operation
    Message 1 of 6 , Jul 17, 2001
    • 0 Attachment
      Matt,

      Indeed, the referenced section of the WSDL specification just means
      you can properly associate the binding clause with its corresponding
      operation clause.

      Remember WSDL is just a way of *describing* things.

      When it comes to the on-the-wire SOAP encoding, neither SOAPAction
      nor the namespace, nor endpoint URL are enough to distinguish
      overloaded operations. You need to look at the message itself.

      I believe this is what Idoox perform in their Java implementation.
      Viz.: locate "safe" implementation class using namespace (only);
      gather all the elements of the SOAP message; map the types to Java;
      perform a Java "reflection" lookup in order to find method
      implementation with matching signature; dispatch to the found method,
      else fault.

      Such server-side dispatching in other languages and environments may
      be more difficult, but it's an area I think is worth exploring. I
      posted some examples and suggestions on the whole topic of
      overloading and optional parameters to the Microsoft SOAP SDK
      newsgroup recently, which I can dig out if required.

      -Mike Glendinning (mikeg@...).

      --- In soapbuilders@y..., "Mike Deem" <mikedeem@m...> wrote:
      > I thought it was saying that the name attribute on the input/output
      > element in the binding would match the name attribute on the
      > input/output element in the portType. These names have to be unique
      > within a portType. If you don't specify these attributes, default
      values
      > are implied. However, these default values will not be unique in the
      > case of overloaded operation names. So, if you have overloaded
      operation
      > names, you MUST explicitly provide these names in order to satisfy
      the
      > uniqueness requirement.
      >
      > == Mike ==
      >
      > -----Original Message-----
      > From: Matt Long [mailto:mlong@p...]
      > Sent: Tuesday, July 17, 2001 10:19 AM
      > To: soapbuilders@y...
      > Cc: Mike Deem; 'Bob Cunnings'
      > Subject: RE: [soapbuilders] MS's 4 endpoints
      >
      > Here's where I was going with this.
      >
      > From WSDL 1.1 spec
      > [2.5]
      > An operation element within a binding specifies binding information
      for
      > the operation with the same name within the binding's portType.
      Since
      > operation names are not required to be unique (for example, in the
      case
      > of overloading of method names), the name attribute in the operation
      > binding element might not be enough to uniquely identify an
      operation.
      > In that case, the correct operation should be identified by
      providing
      > the *name* attributes of the corresponding wsdl:input and
      wsdl:output
      > elements.
      >
      > My confusion over this statement in the spec is that if
      > wsdl:input/wsdl:output name attributes match in the portType and
      > binding, it still does not resolve the identical operation names.
      > Meaning, the identical operation names are "unique" in the wsdl
      based
      > upon in/out name attributes, but one could not resolve the distinct
      > operation based on soap request as the only information that can be
      > passed from the request is SOAPAction and endpointURI. This, of
      course,
      > leads to the assumption that unique SOAPAction (for overloaded
      > operations) is required to resolve overloaded operations.
      >
      > Yes/No/Maybe...thoughts?
      >
      > -Matt
      >
      >
      >
      >
      >
      > > -----Original Message-----
      > > From: Mike Deem [mailto:mikedeem@m...]
      > > Sent: Monday, July 16, 2001 2:59 PM
      > > To: soapbuilders@y...
      > > Subject: RE: [soapbuilders] MS's 4 endpoints
      > >
      > >
      > > Also, I believe that there is a distinction between the name by
      which
      > > the message is know inside a WSDL document and any the element
      names
      > > used in any given serialization of that message.
      > >
      > > In other words, if I wanted to reference the message from
      > > within a WSDL
      > > document, I would use the name "tns:echoFloatRequest" where tns
      > > corresponds to the target namespace of the WSDL document, even
      though
      > > the element <echoFloat> is used in the serialization of that
      message.
      > >
      > > == Mike ==
      > >
      > >
      > > -----Original Message-----
      > > From: Bob Cunnings [mailto:cunnings@l...]
      > > Sent: Monday, July 16, 2001 1:53 PM
      > > To: soapbuilders@y...
      > > Subject: Re: [soapbuilders] MS's 4 endpoints
      > >
      > > Hello,
      > >
      > > As far as the "wrapper element" of an RPC call is concerned, I
      > > think the governing section of the WSDL 1.1 spec is 3.5 [1]
      > > where it states that the invocation request "wrapper element"
      name
      > > is to be identical to the operation name... the names of the
      <input>
      > > and <output> elements in the WSDL doc aren't relevant as far as
      > > the wire representation is concerned.
      > >
      > > This harmonizes with SOAP section 7.1 [2] which makes a point
      > > of stating that the name of the invocation response "wrapper
      > > element" is not significant.
      > >
      > > Am I understanding the question properly?
      > >
      > > RC
      > >
      > > [1] http://www.w3.org/TR/wsdl#_soap:body
      > > [2] http://www.w3.org/TR/SOAP/#_Toc478383533
      > >
      > > > 4 Microsoft endpoints are different WSDL descriptions in
      > > the portType
      > > for
      > > > echoFloat. If I send a method "echoFloat" at all endpoints
      > > the return
      > > > output wrapper element is "echoFloatResponse" for
      > > MSTK2.0,Remoting,.NET Beta
      > > > 2.0, but ATL is "echoFloat"
      > > >
      > > > WSDL 2.4.5 (below) states that ..."If the name attribute is not
      > > specified on
      > > > the input or output messages of a request-response or
      > > solicit-response
      > > > operation, the name defaults to the name of the operation with
      > > > "Request"/"Solicit" or "Response" appended, respectively. ...
      > > >
      > > > Given this
      > > > 1) Should Not MS TK2.0 and .NET Beta 2.0 only accept
      > > "echoFloatRequest"
      > > > since the name attribute is omitted, i.e., faulting
      on "echoFloat"
      > > > 2) Should not Remoting only accept "echoFloatRequest" since the
      name
      > > > attribute is present and *is* "echoFloatRequest", i.e.,
      faulting on
      > > > "echoFloat"
      > > > 3) Should not ATL being send a response of
      > > "echoFloatResponse" instead
      > > of
      > > > "echoFloat", since the name attribute is omitted.
      > > >
      > > > Thoughts?
      > > >
      > > > -Matt
      > > >
      > > >
      > > > MS SOAP TK 2.0
      > > > <operation name="echoFloat" parameterOrder="inputFloat">
      > > > <input message="wsdlns:Server.echoFloat" />
      > > > <output message="wsdlns:Server.echoFloatResponse" />
      > > > </operation>
      > > >
      > > > Remoting
      > > > <operation name="echoFloat">
      > > > <input name="echoFloatRequest"
      > > message="ns0:InteropService.echoFloatInput"
      > > > />
      > > > <output name="echoFloatResponse"
      > > > message="ns0:InteropService.echoFloatOutput" />
      > > > </operation>
      > > >
      > > > .NET Beta 2
      > > > <operation name="echoFloat">
      > > > <input message="s2:echoFloatSoapIn" />
      > > > <output message="s2:echoFloatSoapOut" />
      > > > </operation>
      > > >
      > > > ATL
      > > > <operation name="echoFloat">
      > > > <input message="s0:echoFloatIn" />
      > > > <output message="s0:echoFloatOut" />
      > > > </operation>
      > > >
      > > > 2.4.5 Names of Elements within an Operation
      > > > The name attribute of the input and output elements
      > > provides a unique
      > > name
      > > > among all input and output elements within the enclosing port
      type.
      > > >
      > > > In order to avoid having to name each input and output
      > > element within
      > > an
      > > > operation, WSDL provides some default values based on the
      operation
      > > name. If
      > > > the name attribute is not specified on a one-way or notification
      > > message, it
      > > > defaults to the name of the operation. If the name attribute is
      not
      > > > specified on the input or output messages of a request-response
      or
      > > > solicit-response operation, the name defaults to the name of the
      > > operation
      > > > with "Request"/"Solicit" or "Response" appended, respectively.
      > > >
      > > > Each fault element must be named to allow a binding to specify
      the
      > > concrete
      > > > format of the fault message. The name of the fault element is
      unique
      > > within
      > > > the set of faults defined for the operation
      > > >
      > > >
      > > > ----------------------------------------------------------------
      -
      > > > This group is a forum for builders of SOAP implementations
      > > to discuss
      > > implementation and interope
      > > rability issues. Please stay on-topic.
      > > >
      > > > To unsubscribe from this group, send an email to:
      > > > soapbuilders-unsubscribe@y...
      > > >
      > > >
      > > >
      > > > Your use of Yahoo! Groups is subject to
      > > http://docs.yahoo.com/info/terms/
      > > >
      > >
      > >
      > >
      > >
      > > -----------------------------------------------------------------
      > > This group is a forum for builders of SOAP implementations to
      discuss
      > > implementation and interoperability issues. Please stay on-topic.
      > >
      > > To unsubscribe from this group, send an email to:
      > > soapbuilders-unsubscribe@y...
      > >
      > >
      > >
      > > Your use of Yahoo! Groups is subject to
      > > http://docs.yahoo.com/info/terms/
      > >
      > >
      > >
      > > -----------------------------------------------------------------
      > > This group is a forum for builders of SOAP implementations to
      > > discuss implementation and interoperability issues. Please
      > > stay on-topic.
      > >
      > > To unsubscribe from this group, send an email to:
      > > soapbuilders-unsubscribe@y...
      > >
      > >
      > >
      > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
    Your message has been successfully submitted and would be delivered to recipients shortly.