Donnerstag, 13. März 2003

First look at WS-Addressing

WS-Addressing, which gives us a lightweight mechanism to communicate references to endpoints, is, in my view and contrary to what the spec itself explicitly says, yet another nail in the coffin of WSDL. That's because it essentially overrides the <wsdl:service/> element for any scenario, in which the message contract shall be applicable to several different or changing endpoints or intermediaries (in other words: any endpoint that wants to support transport-independent redirection/routing)

WS-Addressing is also a good choice for configuring proxies. You typically develop using a "development cloud" of a web service and not using the actual production endpoint references. If you use WS-Addressing endpoint references as part of your configuration infrastructure, you can flip back and forth between a development and production clouds without recompiles and do so in a standard way now. Until this morning, we had no standard way of expressing this; now we do and that means that framework code for proxies can be written that allows dynamic switching. The roadmap document promises a WS-EndpointResolution spec to further formalize this.

Completing the picture

So, here we have it. A web service UDDI registration (or LDAP entry) should really have three technical entries: A message contract description (WSDL for the time being), a policy description (WS-Policy) and a qualified set of endpoint references (WS-Addressing). The policy refers to the capabilities of the service (WS-Transactions, WS-Security, WS-ReliableMessaging, ...). As per the roadmap, I expect this composition to be expressed using the upcoming WS-MetadataExchange.

For a routed infrastructure on top of registries, you can have then local registries with local WS-Addressing endpoint references that identify endpoints which themselves will use "regional" or "global" registries to find further hops. For a routed infrastructure with dynamic reconfiguration, you can send something like WS-Referral-encapsulated WS-Addressing references around that will update routers. I expect that we will see adjustments to WS-Referral and WS-Routing to eliminate current overlaps with WS-Addressing. The message contract will never have to change, the policies are according to the requirements of specific endpoints and the endpoint defintions you use may vary depending on who, where and how connected you are. 

Today should be a very happy day in Web services land.


1:19:21 PM      comments []

WS-ReliableMessaging and WS-Addressing are public!

WS-ReliableMessaging: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/wsrmspecindex.asp?frame=true
WS-Addressing: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/wsaddressingspecindex.asp?frame=true

Here's BEA's, TIBCO's, IBM's and Microsoft's take on how to do reliable messaging on web services. There are more than subtle differences compared to the "WS-Reliability" spec by NEC, Sun, Oracle, etc: WS-ReliableMessaging is extensible, takes WS-Security and WS-Policy into account and it does not have (less is sometime more) any specific transport bindings -- and it's routable (read on).

I will likely write about a couple of observations later, but here's a little "reading guide" for a single sentence in section 3.1 saying "There MUST be no more than one <Sequence> element in any message". That language is a bit confusing an could be worded a bit better, because what it really says, when read having SOAP 1.2's "role" or SOAP 1.1's "actor" model present in your mind is indeed "There MUST be no more than one <Sequence> element targeted at one role in any message".

That's because in the presence of roles, all headers become technically "invisible" to any but the targeted role and there is indeed never more than one <Sequence> element existing in the message as far as a certain role is concerned. It'd be helpful if the language was a bit clearer there, but SOAP actually takes care of enabling roles for this, even in the presence of that sentence.

Why are roles relevant? Because this now enables reliable delivery in the presence of routing intermediaries, which want to establish reliable links between them. If you have A->B->C->D with reliable messaging being used for the end-to-end connection A->D and the hop B->C shall be individually outfitted with reliable messaging for purposes of optimization, you can do that by specifying roles on an additional <Sequence> that applies to B and C.


12:34:18 PM      comments []