savas parastatidis

W3C WS-Addressing WG

It was about time!

The W3CWS-Addressing WG has been formed. Good luck to Mark who’s chairing it! This spec and SOAP are, to my mind, the most important in the WS world.

Remember… It’s all about the message.

5 responses to “W3C WS-Addressing WG”

  1. Mark Baker
    You know I respect your opinion, so what do you see in WS-Addressing that I don’t? What does it do that URIs can’t (other than the auxilliary stuff like Reply-To)? I suppose I can see the value in having the powerhouse/cornerstone duo of a transfer protocol and identification mechanism, but I think that’s HTTP and URIs, not SOAP and WS-Addr.
  2. Savas Parastatidis
    Mark, this is a very good question. Thanks. I don’t think I’ve ever explained why I see WS-Addressing as an important spec. You see, in my view of a service-oriented architecture there is always the possibility (and a good practice for that matter) to have asynchronous exchange of messages. You cannot depend on the underlying transport mechanism to correlate messages. WS-Addressing gives us this ability (RelatesTo). Also, you can do 3rd party delivery, as you pointed out (ReplyTo). So, I see WS-Addressing as an important specification for building the kind of service-oriented applications using asynchronous message exchanges that I have in mind. I don’t agree with the way it’s used in WS-RF and WS-Transfer as a pointer for resources. That is indeed the equivalent of URIs albeit in an HTTP-neutral world.
  3. Mark Baker
    Ok, so we’re mostly in synch with the value of Relates-To, Reply-To, etc.., great. But my understanding is that most Web services proponents would say that the big contribution of WS-Addressing is EPRs. What’s your view on those vs. URIs?
  4. Savas Parastatidis
    I have mixed feelings about EPRs. When they are used to identify resources (i.e., they play the role of network-wide pointers), I don’t like them. This because they imply a resource-centric or object-based view of the architecture. We no longer send messages to services but, instead, to resources. At the same time, though, EPRs can be used really nicely as in specifications like WS-Eventing. There, when you subscribe, you give an EPR, which may contain additional information. The source of the notifications still thinks that it sends messages to a receiving service. It’s obliged by WS-Addressing to also include the reference properties and parameters into the messages but the view of the architecture does not change. We are still thinking in terms of service to service communication. That’s good. In the same specification we also see the bad example of how WS-Addressing could be (mis)used. A subscription-resource is addressed. The message is no longer addressed to the service but, instead, to that resource. It’s only in this situations we can really say that WS-Addressing is used in a similar manner to a URI (albeit in a transport neutral manner). However, we are now in a differnet architecture. Jim and I have been advocating for the use of URIs as one of the many ways one could name resources in service-to-service conversations. But that’s a different discussion 🙂
  5. Mark Baker
    Ok, great, thanks. Keep in mind though, that services are also resources, so it seems your preference isn’t so much for services over resources, it’s for stateless resources over stateful ones. 😎