cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject [PROPOSAL] Unification of coloc and object bindings
Date Thu, 12 Apr 2007 17:36:37 GMT


Folks,

As you may have noticed, Ajay just merged a new co-located binding
(rt/bindings/coloc), which adaptively provides an optimized dispatch
path when the target endpoint exists in the local process space.

You may also have noticed DanD's recent commit of an object binding
(rt/bindings/object) and improved local transport which, while
originally intended to cover a different use-case, could also be used in
the co-located scenario.       

So I wanted to kick around a few ideas about unifying these two modules
in such a way that retains the best aspects of both. First let me state
what I think are the pros and cons of each. 

Coloc is the simpler at a conceptual level ... it just detects if the
protocol and transport layers are unnecessary and if so by-passes these
completely by weaving a direct interceptor chain from the end of the
"client-side" logical phase to the start of the "server-side" logical
phase, and back again. So basically it diverts around the binding and
port described in the physical contract as realized by the WSDL or
whatever. This simplicity comes at the cost of a fixed "bridge point",
i.e. the corresponding logical phases on either side. 

The OB/LT approach on the other hand trades some extra complexity for
flexibility, by potentially also traversing user interceptors in phases
later than logical on the client-side (or prior to logical on
server-side). For example, say the user has an interceptor in a stream
phase, that doesn't actually manipulate streams at all, which they
specifically want to be included in the optimized form of dispatch. This
comes at the cost of some extra complexity in terms of the user
understanding what's going on under the hood. Instead of just completely
bypassing the unnecessary real binding (e.g. SOAP), this would be
replaced with a different binding, i.e. the object binding interceptors.
Similarly the transport layer used in the remote case (e.g. HTTP) would
be replaced with another, i.e. the local transport. Similarly an
under-the-hood activation of a LocalDestination would be required when
the application does an explicit Endpoint.publish("http://...", myImpl)
or some-such. Of course, there ain't no such thing as a free lunch, and
this extra complexity is warranted if its really required. 

Note that the extra flexibility is absolutely required in the primary
target use-case for the object binding, i.e. the wider use-case of
dynamic routing scenarios. My assertion that is that the flexibility
isn't _necessarily_ required in the narrower coloc use-case. 

Personally I can see a lot of merit in both approaches and would like to
see the best aspects of each retained. The way I'd see this being done
would be as follows:

1. The default mode would be to use the coloc approach, in the sense of
completely bypassing the binding and transport. This will I think suit
the majority of users and provide a simple conceptual model, i.e. avoid
questions like "wait a minute, I asserted the Addressing policy on the
SOAP binding in the WSDL, but this may be replaced by an object binding
at runtime ... does this mean a different set of binding-level policies
are used?", or "what's this LocalDestination I see popping up in the
logs, I didn't order one of those" ... etc.

2. An advanced option would be to allow the user choose via
configuration exactly which phases should be run. This would suit
advanced users who understand the CXF Phase architecture sufficiently to
deliberately deploy a non-stream-manipulating interceptor into a stream
phase. So for example they might want to ensure that an interceptor
responsible for measuring the transport-level latency is run as close to
the wire as possible, but also ensure that another non-logical
interceptor that does say compression isn't run at all (as clearly its
not needed in the colocated case).

The beauty of the above proposal in my view is that the user only incurs
the cost (in terms of complexity) of using the object binding and local
transport, when it actually pays off with some flexibility that *they
want and need*.   

Note that in both approaches, the user must consciously enable the
specialized form of dispatch (by adding an interceptor to the configured
chain), so this feature is never foisted on them. 

Also the detection that the opimitized path is valid would be adaptive
in both cases. So if the target endpoint pops up the local process
space, we get to take advantage of a more direct invocation route,
whereas if it subsequently migrates away to another container, the
runtime transparently reverts back the normal route (e.g. via SOAP over
HTTP).

Other differences between coloc & OB that don't depend on the distinct
approaches taken, such as coloc's more complete fault handling, could
easily be leveraged in both cases.

Thoughts?

Cheers,
Eoghan

Mime
View raw message