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