cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: [PROPOSAL] Unification of coloc and object bindings
Date Sat, 14 Apr 2007 19:25:47 GMT

My preference would be to just migrate over the co-loc code to use the

One of the main advantages as stated by Eoghan is it's simplicity. I would
assert that from a user point of view, most people won't even inquire as to
the underlying details. And even if they do its really not that hard to say
"instead of a soap binding and http transport, we created an object binding
and local transport for the invocation." This is subjective opinion either
way though.

Now, if we bring in Policy to the mix, this complicates things and the user
does need to know what is happening. Yet it isn't exactly clear to me what
*SHOULD* happen. If I assert my MTOM, Security, Addressing, HTTP, or RM
policy on a SOAP Binding, should these be asserted in the co-loc case? (it
doesn't seem so.)

Are there any policies around that we would assert on a binding that we
would eventually would want to assert on both the co-loc and soap/http
case?  (I don't know of any at the moment, but there could be I suppose.)
Would there be cases where we want to assert different policies for the
co-loc case? What policies could you assert on a co-located case?

With the OB/LT approach I see a few advantages.

First, it simplifies things in the sense that we won't have multiple ways to
achieve the same use case. This would result in a moderate reduction of code
and also allow us to focus our efforts on just one approach. (less
documentation, fewer test cases, and less code).

While the "narrower" co-loc case may not need any extended features that the
OB/LT transport approach offers, I don't think thats the right way to look
at it. What is true is that both the OB/LT do need a very similar set of
functionality (dispatching to a service, ways to select the appropriate
operation on the server side, message filtering, etc), so it would seem
logical to standardize on that from my POV.

Second, we can use existing object bindings that the user has configured
during co-location detection. Lets say a user creates their own object
binding with its own settings and interceptors (maybe they want to track the
number of local invocations). If we set up the co-location detection
interceptor to use the OB/LT approach we can fall back on this existing
object binding if its created. Otherwise we can synthesize our own.

One other thing: the cost of using the local transport/objecting isn't
really any different than what the co-loc binding does now. We can create an
ObjectBinding/LocalDestination and then it will be cached for future

The one advantage of the way the co-loc code works right now seems to be
that it is more clear what Binding policies get asserted on. That doesn't
really seem like good enough reason to justify a second approach to me,
especially since such policy assertions are likely not to apply to the
co-located case. But obviously opinions differ in this area.

- Dan

On 4/12/07, Glynn, Eoghan <> wrote:
> 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

Dan Diephouse
Envoi Solutions |

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