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.
Comments (6)
Another reason to do this would be to enable a consumer that uses multiple services to make intelligent decisions about which specific service instance to use, e.g. by comparing the host portions of URIs and minimize the number of servers to talk to.
Posted by Stefan Tilkov | January 16, 2005 5:51 AM
Posted on January 16, 2005 05:51
"If the application got the failing EPR from some other application, perhaps as part of some message, then what?"
I have actually not ever thought about it any further, but somehow I have made an implicit assumption that this (returning EPRs in service responses) would be an anti-pattern, due to the issue(s) that you described in your blog entry.... It's entirely true that some sort solution is needed for lookup services or guaranteeing any sort of SLA will be extremely hard.
Posted by Joose Niemistö | January 17, 2005 6:54 AM
Posted on January 17, 2005 06:54
What does the Post Office do in this case? It sends the message back to you with NO LONGER AT THIS ADDRESS stamped on the front. It's not the responsibility of the addressing mechanism itself to handle failure.
Maybe what we need is something analogous to the post offices "change of address" cards -- something that would simultaneously forward a message to the new address while returning a message back to the sender informing them that the address has changed. But that's a higher-order construct for manipulating addresses, not a fundamental component of the address itself. As such, I don't think it belongs in the EPR.
Hrm...WS-Redirection. Wouldn't Mark Baker get a kick out of that :)
Posted by Steve Maine | January 18, 2005 6:45 PM
Posted on January 18, 2005 18:45
Hi Steve, I wonder, if an EPR can contain multiple addresses, and I can see the point there, what would be the difference between an EPR and the WSDL service construct? Since you advocated earlier that dependence on WSDL is not a problem, couldn't EPR be replaced by reusing WSDL Service element and extending it with whatever is currently in an EPR, except for wsa:To which would be replaced by wsdl:endpoint elements?
Posted by Jacek Kopecky | January 27, 2005 10:12 AM
Posted on January 27, 2005 10:12
Hi Jacek, if an EPR were to change to support multiple addresses, then hopefully there'd be little difference between that and a WSDL service element, at least in terms of the information they can carry. However, when I advocated earlier that WSDL dependence is not a problem, I was stating my own view. There's a large group out there who tend to avoid WSDL and instead stick with just the lower layers. Forcing a WSDL-based solution to this problem isn't going to fly, as WS-MessageDelivery proved. I think addressing is so fundamental that it has to be solved below the WSDL level if we have any hope of interoperability.
Posted by Steve Vinoski | January 27, 2005 11:29 AM
Posted on January 27, 2005 11:29
I'm kind of leaning towards a solution (the status quo from a quick look at the eds' copy) where an EPR has only exactly one address (because packaging of multiple endpoints, for any reason, can be done above that level), in which case maybe it might make a lot of sense to replace WSDL's enpoint by an EPR.
Even if an EPR does have more endpoints, it does in fact make sense, as you write, not to make it WSDL dependent, but in this case WSDL could adopt EPR for its service construct.
In any case, since WSDL hasn't left LC yet, now is the time to try and coordinate this. I don't like to have different reusable constructs that do the same thing. 8-)
Unfortunately I can't be on WS-Addr WG, but I am on WSDL WG and I hope to observe WS-Addr in Boston.
Posted by Jacek Kopecky | January 27, 2005 11:51 AM
Posted on January 27, 2005 11:51