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.
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
invocations.
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 <[EMAIL PROTECTED]> 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
http://envoisolutions.com | http://netzooid.com/blog
