cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mao <>
Subject Re: [Proposal] Supporting Multiple Endpoints on one Destination
Date Tue, 05 Dec 2006 09:13:05 GMT
Hi Dan,

> 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 
> really is a separate binding from the regular SOAP binding (which is 
> part of
> the reason I'm not happy about the current implementation).
I can not understand the conflicts between the current GET 
implementation and the one 'Multiple Endpoints on one Destination'.
Do you mean, it can not be done with the current  GET implementation? if 
that's the case, that's a problem. we need to fix this as soon as possible.
Previously i thought the problem is just the isGET in several interceptors.

How to understand HTTP GET is a separate binding from the SOAP binding?
You mean they have separate bindingFactory? But GET binding can not 
finish the job without the SOAP binding? and thus they must be pair 
presented in the chain? (Point 2: Supporting different bindings on the 
same URL)
And if that's correct, then the SOAP binding you mean we can call the 
SOAP POST binding, because it only support POST.
If you want to add GET function , you need another binding call SOAP GET 
binding. but the SOAP GET binding can not work properly alone, 'cause 
you have to add the SOAP POST binding.
make sense?
> 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
> interceptor.
> Granted that isn't 100% fleshed out, but I think the concept might work.
> Thoughts?
> - Dan

View raw message