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

[Steve Loughran]

Mark McKeown wrote:

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

WS-I BP doesnt actually fix interop at the SOAP level, because they 
completely dodged the whole question of which subset of XSD to 
recommend, so java can still happily reject xsd:unsignedLong, .NET can 
handle nillables differently, and end users suffer.

Maybe, just maybe, the new XSD best practises WG will fix this.


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

My WSRF impl rejects any incoming message without a WS-Address, which I 
believe is a requirement, so implicitly all GET soap reqs fail.

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

I'd actually consider the option of sending notifications back over 
alternate transports than HTTP. That is, you may send a message over 
HTTP(S), but you subscribe with an address that uses XMPP. That way your 
messages will route through firewalls using the existing jabber relay 
infrastructure, and make it to you, wherever your laptop happens to be 
at the time.

That is the special case of notificiations, which have two extra needs
  -sent from a server to a recipient that may be behind a firewall
  -the delay between subscription and message means that a mobile 
recipient cannot know what its network address will be in the future, 
even if the firewall is not an issue (ignoring dynamic dns registries)

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

Its the thing at the far end that doesnt recognise your XSD, as opposed 
to the things in the middle :)