[ogsa-wg] RE: latest ws-naming draft (Re: [ogsa-naming-wg] One more thing)

[Mark McKeown]

Hi Tom,

> TomM suggested using the wsa::Address as the name, I understand his argument
> as being that with the WSDL binding for WS-Addressing you can include the
> service part of the WSDL into the wsa:Metadata of the EPR, the service part
> may contain a number of network endpoints indicating that the WS-Resource is
> available at a number of locations.
> From 'Web Services Addressing 1.0 - WSDL Binding' [4]:
>
> "In particular, embedding a WSDL service component description MAY be used
> by EPR issuers to indicate the presence of alternative addresses and
> protocol bindings to access the referenced endpoint."
>
> In this case the wsa:Address could be a URN (or URI that is not an actual
> network location) and the client could look to the wsa:Metadata to find the
> actual network location of the WS-Resource. Quoting Tom[5]:
>
> "Let me be very clear about this an EPR does not have a 1 to 1
> correspondence with a protocol and binding address.  It MUST be true that an
> EPR can support multiple protocols and their associated addresses."
>
> I am not sure I agree, the WS-Addressing WSDL binding uses "MAY" when
> discussing including WSDL components in the EPR, there is no obligation.
> <trm>probably should not have capitalized MUST.  The important aspect of
> that statement is 'can support'</trm>
>
> I think most services will only use one transport protocol so I think this
> feature will not be used often - even if a service does use more than one
> transport/port there is no requirement to advertise this in the EPR.
> <trm>yes, that is what the 'MAY' means wrt requirement to advertise.  I am
> puzzled why you think that most services will use only one transport
> protocol.  Certainly there are a few to choose from, SOAP/HTTP, SOAP/JMS,
> SOAP/BEEP and clearly the separation of protocol handlers from service
> implementation is a good thing.</trm>

The reasons why I think that most people will only use one
transport protocol when they come to implement a service
are as follows:

1) Most people only use one transport at the minute -
HTTP.

2) The extra effort to support more than one tranpsort
protocol - debugging etc

3) The interoperability issues - only now with WS-I
Basic Profile do we understand how to use HTTP + SOAP.

4) I think when people design systems they will choose
protocols that best match the requirements of their
application. Each of the different transport protocols
have different properties, for example if I use SMTP
I can do multicast eg.

<wsa:EndpointReference>
  <wsa:Address>mailto:ogsa-wg at ggf.org</wsa:Address>
</wsa:EndpointReference>

Replacing SMTP with HTTP for this application would probably
break it.

5) The "transport" protocols are leaking into the
WS-* layer - you can now have Web Services that support
the HTTP GET operation. (If your WSRF implementation
doesn't use ReferenceParameters you might be able to
use a HTTP GET to retrieve the ResourceProperties document
using the HTTP caching support for optimization)


I think it is basically an "end-to-end" issue[1], when
building a distributed application the developer needs
to have an understanding of properties of all layers
of his system. For example when signing a SOAP message
you should put a ttl value into the message - this
value depends on how long you think it will take the
message to arrive, a function of the underlying
transport protocol. I think SOAP and WS-* has all the
ingredients to build "end-to-end" systems (eg if your
transport layer doesn't encrypt messages turn on WS-Security,
if your tranpsort layer does do reliable message delivery
turn on WS-ReliableMessaging etc) but I still think that
a developer needs to understand his transport protocol and
choose the best one for the job.


>
> Also there is no transport bindings available for WS-Addressing - for
> example the SOAP bindings tells us to take the wsa:Address element and put
> it into the wsa:To element in the SOAP header but does not tell us what to
> do with it with regards to the transport protocol (eg most people use the
> wsa:Address element to create a RequestURI which they set as the POST HTTP
> Header when using HTTP - this issue has been raised with the W3C TAG[6]).
> <trm>I wonder what their solution will be.....</trm>
>
> Quoting WS-Addressing:
>
> "A Web service endpoint is a (referenceable) entity, processor, or resource
> to which Web service messages can be addressed. Endpoint references convey
> the information needed to address a Web service endpoint."
>
> To me there is a strong emphasis on singlar.
>
> <trm>Do me a favor; Define endpoint.  That argument has been raging
> forever.... </trm>

I guess should be a question for the WS-Addressing working group...

cheers
Mark

[1] http://mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf