In my previous blog entry I began a discussion of multi-port web service references. Read that first if you haven't already done so, otherwise the following might not make sense.
There are at least four approaches to dealing with this problem:
- Augment the EPR with additional optional port information. One way to do this is to add an abstract property (using WS-Addressing specification terminology) for additional ports. This would essentially amount to including WSDL port information by value in the EPR.
- Standardize a policy assertion that could convey additional optional port information within an EPR. Sanjiva came up with this possibility, based presumably on WS-Policy. This might work, but suffers from the problem that WS-Policy is not an actual standard and so can't be referenced from the WS-Addressing standard. (Over in his blog, Sanjiva also discusses the somewhat related failed attempt to add service references to WSDL 2.0.)
- Create a separate structure that can hold one or more EPRs. "Multi-port EPR" is a bit of a misnomer, since "endpoint" and "port" are somewhat synonymous. This approach leaves the existing EPR as it is, and creates a separate container capable of holding them. This container would hold information for a service's multiple ports by value, and could be passed around. It's thus almost identical to a WSDL service element.
- Use WS-MetadataExchange (WS-MEX) instead. With this approach, a consumer uses a service's advertised EPR to retrieve the service's metadata, which in turn contains additional port information. From talking to Don, I believe this is the approach Microsoft takes.
What it ultimately comes down to is whether you can pass the multiple port information around by value, or you pass a reference that can be used to indirectly obtain info about other ports. The "by value" approach is reminiscent of CORBA interoperable object references (IORs), which long ago proved the viability and usefulness of having a reference structure that can hold connectivity details for any number of protocols and transports. And no, the fact that I mentioned the IOR doesn't imply that I'm trying to turn web services into distributed objects. I'm not. All I'm talking about here is service references, and I mention the IOR because it's conceptually similar to what I'm looking for from WS-Addressing.
Approach 4 listed above would of course work, but it suffers from a couple of drawbacks. First, it requires network operations to retrieve the port information, which may be fairly expensive. Second, it's not a good approach for existing legacy services that can't be rebuilt and redeployed to support WS-MEX. You could introduce a separate WS-MEX service process for such services, but that just adds management and provisioning overhead within a production system. Because of these limitations, at IONA we use an approach similar to WS-MEX only when absolutely necessary. I still therefore prefer an approach more like 1 or 3 above.
Stay tuned, still more to follow.