cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject [Proposal] Supporting Multiple Endpoints on one Destination
Date Sat, 02 Dec 2006 21:43:15 GMT
Hi All,
We've conveniently skirted around the issue of how to support multiple
endpoints on one Destination up to now. I'd like to take a minute to propose
some changes to support this.

What do I mean by multiple endpoints on one destination? Well there are two
use cases I'm thinking of.
1. Routing service: In this case I want to receive a message on one
Destination and based on some criteria (i.e. a Header or body content), I
want to be able to direct it to a particular service. This is handy for
versioning among other things.
2. Supporting different bindings on the same URL: Ideally it would be nice
to listen for both soap 1.1 and soap 1.2 messages on the same URL.
Additionally, this concept could be extended to HTTP GET as well. HTTP GET
really is a separate binding from the regular SOAP binding (which is part of
the reason I'm not happy about the current implementation).

Currently we have the ChainInitiationObserver which listens for messages on
a Destination. If it receives one it takes an Endpoint, adds the
interceptors from the endpoint, service, and binding to a new
interceptorchain. Then it dispatches the message.

Obviously we'd like to be able to delay service, and possibly binding
resolution for a while.

[Using a dummy service]
The easiest strategy for delaying service resolution that I can think of is
to create in a dummy service which has an interceptor which changes the
targeted service part way through invocation. Here's an example of how we
did that in XFire:

The Service for the router would in essence have no operations. It is just
there to provide some basic interceptors - like the soap binding
interceptors. We would then be able to add in an interceptor which did some
routing. Once it knew the correct service to route the message to, we would
do something like so:

exchange.put(Endpoint.class, destinationEndpoint);
exchange.put(Service.class, destinationService);

I don't know that this would all work immediately without other changes to
CXF, but I think in principle it could work. I haven't thought about how
people would configure this yet, other than actually wiring up the dummy
service themselves. We could definitely provide some nicer configuration and
provide a RoutingService out of the box.

[Another Strategy Using a Registry]
One other possibility would involve creating a service registry. In this
case we simply have a Destination associated with a Binding. Somewhere
during the binding invocation it does service resolution and looks up a
service from the registry based on a set of rules.

[Supporting different bindings]
This is a bit tricker I think. In the SOAP case our criteria for selecting
the appropriate binding would involve both the HTTP method and the message's
XML namespace.

The only way I can think of cleanly supporting this is to move the
resposibility of creating a MessageObserver to the Binding. So we might have
something like this:

Service service = ..; // the service
EndpointInfo endpointInfo = ...; // the endpoint I'm creating
Destination d = destinationFactory.getDestination(endpointInfo);
bindingFactory.addListener(binding, d);

In this case the bindingFactory would be responsible for managing multiple
endpoints on the same Destination. For the SOAP case it might say have a
SoapChainInitiationObserver which only adds an interceptor to select the GET
or POST version of the soap binding. Once it decides that it would then add
the correct binding's interceptors. If it still didn't know the correct
binding (i.e. soap 1.1 or soap 1.2) it would add an interceptor after the
stax interceptor to resolve the correct one. Or going even further we could
add logic to use the SOAPAction to search through all the services and their
operations to find the correct one.

We could even combine it with the service routing scenario. So if it didn't
know the correct endpoint to resolve, you could provide it via your own

Granted that isn't 100% fleshed out, but I think the concept might work.

- Dan

Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message