cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <ning.ji...@iona.com>
Subject Re: [Proposal] Supporting Multiple Endpoints on one Destination
Date Tue, 05 Dec 2006 08:44:44 GMT
Hi Dan,
Please see the comments in the mail.

Dan Diephouse wrote:

> 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).
>
You means we need to build up a HTTP GET binding?
I think most useful case is that we can publish different versions of 
endpoints with one
destination (address). So the version of the endpoints' services will be 
transparent to the client. 

> 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.
>
I think the Dummy Service give us a great opportunities (by 
interceptors) to setup the routing policy.
By it will be litter complex for the user, because it will take some 
time to get familiar with the interceptor chains.
And the router interceptor just work with the DummyService?

> [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.

I have no ideal about it.  Maybe the detail binding can share an 
abstract binding
which just do the service resolution work from the service registry.
I think this way can't provider some kinds of flexibility to set up 
different routing policies
such as by  contents , by headers or by version.

>
> [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
>


Mime
View raw message