cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: [PROPOSAL] Unification of coloc and object bindings
Date Mon, 16 Apr 2007 13:28:31 GMT

Thanks for the response Dan, some comments inline ...

> -----Original Message-----
> From: Dan Diephouse [] 
> Sent: 14 April 2007 20:26
> To:
> Subject: Re: [PROPOSAL] Unification of coloc and object bindings
> Hola,
> My preference would be to just migrate over the co-loc code 
> to use the OB/LT.
> 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.

The conceptual difficulty I envisage is not so much that users won't
understand the idea of swapping out SOAP/HTTP and replacing this with

Its more that they'll be more confused/concerned by the possible
side-effects, e.g. will the same policies be in force etc., than they
would be in the case of a complete diversion around the "real binding". 

To sum up what I'm saying, auto-magical replacement of X with Y is
likely to be more conceptually problematic than a dynamic short-cut
around X.

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

My understanding is that asserting a policy on a binding is not limited
to specifying requirements that are met solely within the capabilities
of the *binding itself*. In plain terms, that the asserted policy
doesn't _just_ tell the binding how to work.

Instead a binding-level policy may specify a requirement that will be
met by capabilities both within *and* without the binding. In plain
terms, such an assertion indicates how things should work *over-all*
when this particular binding is in use, as opposed to any other possible

Its a subtle distinction, but also a very real one with practical

Take for example the WS-A layer, which is realized as a pair of
interceptors, one logical and the other specific to the SOAP binding.
When the Addressing the policy is asserted (at any level) the result is
that both the interceptors are injected into the chain. For a coloc
dispatch only the logical interceptor is traversed, and this caches the
WS-A properties in the message. Now the protocol-level interceptors are
never traversed, but that's OK, since the WS-A properties don't needed
to be encoded/decoded to/from SOAP headers ... instead they are directly
available from the message to the server-side code (logical
interceptors/handlers and the servant via the injected
WebServiceContext). So the purely logical aspect of WS-A should still be
able to provide a meaningful function (though we'd have to exercise some
care in the decoupled case).

So when would something like the Addressing policy be asserted on the
binding level? (as opposed to on say the service on any other policy
attachment point) Well take for example a server exposing both SOAP and
CORBA bindings. AFAIK there isn't a mechanism in the CXF/Yoko CORBA
binding to carry WS-A headers, so it would make sense to assert the
Addressing policy only on the SOAP binding. 

OK, maybe Yoko could be extended to inject the WS-A properties into an
IOP::ServiceContext or some-such, but hopefully people will get the
general point I'm making. 

So in general I think where a policy asserted on the binding has *both*
logical and protocol-specific aspects, then the former should continue
to operate in the colocated case.  

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

I'm not sure we'd want to go down that route of asserting policies
specifically on a "coloc binding", as this would probably require the
"coloc binding" being manifest in some form in the WSDL (as the policies
would normally be attached to WSDL elements).

The whole point of coloc is to avoid using any binding, so I think it
would be confusing to have to represent it in some way in the WSDL as
some sort of place-holder pseudo-binding. It would also mitigate against
the goal of allowing coloc to be enabled without any change to the
application code, including the WSDL.  

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

Well hopefully the code could be structured so that most if not all of
the common logic is shared.

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

Actually I'm beginning to question the general usefulness of the
potential of OB/LT to traverse non-logical user interceptors (in the
optimized in-process dispatch case).

I think this is potentially confusing even to non-novice users,
particularly the aspect of an interceptor running in a phase where a
particular content type is normally available (e.g. DOM elements or SAAJ
instance in the protocol phases). But of course this content type would
not be available in the local dispatch case, which has a number of

1. the interceptor is very limited in what it can actually achieve,
beyond what could have been done anyway in a logical interceptor 

2. the interceptor must be coded defensively to gracefully handle the
case where the expected content type is missing, not rocket science but
also not a pattern followed by all the "stock" interceptors, many of
which either just assume that the content will always be there or else
fail nosily if its not (e.g. by throwing a fault).

So I'm thinking this OB/LT flexibility really is an advanced feature,
and that coloc style of local dispatch will suffice for a large majority
of users. Though of course I still think the OB/LT is very useful for
covering its primary use-case.

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

Yep agreed, the performance should come out roughly the same as it's
pretty much the same code being executed, except distributed across a
couple of interceptors and the local transport direct dispatch mode, as
opposed to being condensed into a single interceptor.

> 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.
> Regards,
> - 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
> |

View raw message