cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: [PROPOSAL] Unification of coloc and object bindings
Date Wed, 18 Apr 2007 18:10:01 GMT
(Sorry for the lag, this got lost in the inbox)

Re policies:  I can better see now how ws-addressing would be used on the
coloc case. My thinking is that most of the ws-addressing info would be
redundant as we are already explicitly specifying the operation. Also, for
most (all?) of the other policy information that could be asserted, it
wouldn't be applicable at the logical layer and would be irrelevant for the
co-loc approach. RM, MTOM, HTTP, etc assertions don't seem to have any
meaning for the colocated case.

I don't really understand the yoko example as I have no idea what an
IOP::ServiceContext is. But I guess the point is that anyone is stuffing in
metadata they might want to access that on the other side? i.e.
ReferenceParameters?

I'm not sure I understand how things like action/faultto/replyto should work
in the coloc case. What happens if someone specifies a ReplyTo, by which
they mean to address a reply to a very specific server - but coloc is
operational. It seems coloc would ignore this, no? But this would seem to be
badness.

If I'm not mistaken this is all stuff that needs to be addressed for either
approach, so I'm not trying to argue for any specific approach here. If
anything my point would be this could be dangerous, and I'm not sure what
the side effects should be. Hopefully you can enlighten me there. The only
way this would count as a point in the OB/LT camp is if we decided that it
was too dangerous and didn't want any policies asserted from the original
binding.

I see where you're coming from on this issue, but I still feel whats in the
coloc binding is not the best route to go. I do sympathize with some of the
ugliness of the approach of having an overriden binding though.

However I like the idea that we can fall back to explicitly configured OB
binding if we want as well - in this case the coloc interceptor would detect
such a binding and fall back to it. If no such binding existed, we would
create one. I also like the fact that both the server and client interact
with well defined endpoints - which means I can create different listeners
on those endpoints if I want and do some type of mediation. I don't know if
there is a way to make the coloc stuff use the LocalTransport but not the
ObjectBinding, but that would do a lot to mitigate my dislike of the current
approach.

I realize that these are all subjective opinions though and I'm not really
keen on extending this discussion much longer except to learn more about
more details of how WS-* stuff might interact (we can, but I think its
probably not worth the time at this point). I doubt I'm going to convince
anyone to change their minds at this point :-)

- Dan

On 4/16/07, Glynn, Eoghan <eoghan.glynn@iona.com> wrote:
>
>
>
> Thanks for the response Dan, some comments inline ...
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 14 April 2007 20:26
> > To: cxf-dev@incubator.apache.org
> > 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
> OB/LT.
>
> 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
> binding.
>
> Its a subtle distinction, but also a very real one with practical
> effects.
>
> 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
> effects:
>
> 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.
>
> Cheers,
> Eoghan
>
> > 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 <eoghan.glynn@iona.com> 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
> >
>



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

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