Opacity

In reference to my recent post on EPR`s, RefP`s, and MSDN2, Savas says that I might be forgetting about EPR opacity. I`ve read Savas` previous discussions of this topic on the WS-Addressing list. I didn`t feel prepared to disagree with them in that forum, but I`ll do so now. It`s not so much that I forgot about EPR opacity as I made a conscious decisions that it really didn`t apply in the scenarios I`m discussing.

Backing up a bit, EPR opacity is the principle that says that when I`m given an EPR, I shouldn`t look inside of it to gain any information about the thing to which it is referring. Opacity is a general characteristic of addressing mechanisms like URL`s or Win32 handles. In many cases, this is a very good thing because it keeps clients from making inappropriate optimizations and assuming responsibilities that are best left to the infrastructure. However, I don`t think it`s appropriate to use opacity as a general argument against algorithmically constructed addresses.

Algorithmically constructed addresses are a good thing, because they support address inferencing and improve resource discoverability. MSDN2 supports algorithmically constructed addresses for things like namespaces and classes. In their case, the algorithm is simple: if you want to get the documentation for namespace X, append the fully-qualified namespace name to http://msdn2.microsoft.com/library/ and you`re off and running. Once you know this simple algorithm, it`s very easy to pull out specific things without having to look them up in a directory. For example, I know that I can find information about CodeNamespaces at http://msdn2.microsoft.com/library/System.CodeDom.CodeNamespace. Microsoft didn`t have to publish a directory somewhere to tell me that address -- I was able to infer it from the pattern set forth by the MSDN2 team. As long as they don`t change the algorithm by which they construct their addresses, I can instantaneously tell you the help URL for any member of the .NET framework. This is damn useful (but, oddly enough, not a very good party trick).

Algorithmically constructed addresses are a very good way of taming large numbers of addressable entities. Even though MSDN2 help topics have both an opaque URL (http://msdn2.microsoft.com/library/b8a5e1s5/) and an algorithmically derived URL (http://msdn2.microsoft.com/library/System.Xml.XmlReader), I bet the vast majority of people access a help topic by it`s algorithmic name. Why Because when I`m acting as a service consumer, URL opacity works against me because it impedes discoverability. 

Granted, there are addresses that should be treated as opaque entities. If you send me a message and tell me to "ReplyTo this EPR", I stand a very good chance of breaking things if I get too smart and try to crack open that EPR. But if I`m sending you a message, I think it`s OK for me to use some smarts in determining what that Destination EPR looks like; at this point, I`m in control of that EPR and I can formulate it however I want to (admittedly, though, I might formulate an EPR that you`re not listening on!). And that`s why I don`t think the general principle of opacity applies here.