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: http://xfire.codehaus.org/Service+Router 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 interceptor. Granted that isn't 100% fleshed out, but I think the concept might work. Thoughts? - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
