Middleware Matters

Doug Lea, Werner Vogels, and I are guest editing a special issue of IEEE Internet Computing on Asynchronous Middleware and Services. I suspect more than a few of you out there might know a little something about this topic! Submissions are due June 1, and selected articles will be published in the Jan/Feb 2006 issue. See the IC website for our complete call for papers and for author guidelines. We look forward to receiving your submissions.

In the current WS-Addressing specification, endpoint references (EPRs) are capable of holding only a single service address. In fact, the name "endpoint reference" implies this -- it's a reference to a single endpoint. One question implied by this design is fairly obvious: what do you do when the address indicated by an EPR fails?

If the application using the failed EPR originally retrieved it from some sort of lookup or directory service, then presumably the app can go back, do another lookup, and get a new or different EPR. This assumes that the service that the EPR refers to is available at multiple endpoints and also that the service advertised its multiple EPRs in the directory service. It also assumes that the directory service is capable of storing multiple EPRs under a single service name or description, and also that it hands out the EPRs in some kind of round robin, random, or other fashion such that calling applications won't get the same EPR each time they ask. That's a lot of assumptions.

If the application got the failing EPR from some other application, perhaps as part of some message, then what? Unless the returned message has somehow accounted for the possible failure of the EPRs it contains and has provided multiple EPRs for each service endpoint such that the app can try each one, then the app is stuck with a failing EPR, and it won't be able to reach that service at all.

One might argue that the machinery for high availability lies "below" the address contained within an EPR, such that EPRs need not account for these types of failures. For example, the same approaches used to distribute load across multiple web servers could be used to try to ensure that at least one instance of the service is alive and ready at the endpoint indicated by the EPR. This is indeed one viable approach, but it should not be the only possible one.

I think this is another reason to allow endpoint references or service references to contain information for multiple endpoints. A composite endpoint reference could refer to a single logical service, but hold physical addresses for multiple endpoints, such that an application encountering a failure using one such physical address could go back to the same EPR and try a different address. Allowing this alleviates the need for other machinery either above or below the EPR level to ensure service availability. The current EPR design, however, forces you to use some other approach to allow for such availability.

My newest Internet Computing column is now available (PDF). This time around, I talk about reflection, which of course has been around for ages but has recently been growing in popularity because of the flexibility it affords, even though using it often means more complicated code. Comments on the column welcome, as always.