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

[Mark McKeown]

Hi Steve,

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


WSRF ISSUE 36 - "Consider optional binding to HTTP state transfer
protocol"

Proposed Recommendation: "The TC must not publish specifications
which prevent such a binding being defined. That said, a WSDL 2.0
Web method binding must be possible"


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

IMHO ATOM might be another good protocol for notification, again it
has different properties to JABBER.

cheers
Mark