> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 18 April 2007 19:10 > To: [email protected] > Subject: Re: [PROPOSAL] Unification of coloc and object bindings > > (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.
Agreed MTOM and HTTP would make no sense as these are applicable only to elements that would be completely by-passed in the coloc case. Of the other standard policies, there's a possible case for allowing the logical aspects of WS-Security to run in logical phase, for example the inclusion of security tokens that don't depend on the payload format (e.g. the <wsse:UsernameToken>). That sort of logical/protocol partitioning probably wouldn't be straight-forward for the current WS-Security impl in CXF, which looks like its restricted to the protocol phase, as it delegates pretty much all the heavy-lifting to the (monolithic?) WSS4J WSHandler.doSenderAction() on the outbound leg and WSHandler.doReceiverAction() on the inbound. Note that I know almost nothing about WS-Security, so feel free to ignore the foregoing it makes no sense :) > 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? ServiceContexts are a CORBA mechanism for propagating contextual info within a request payload, and are somewhat analogous to SOAP headers. Basically the main point I was making is that there's no standard way of encoding WS-A headers when the CORBA binding is in use, so if a server exposed both SOAP and CORBA bindings in the WSDL, it would make sense to assert the Addressing policy *only for the SOAP binding*. So basically its just an example of where a policy that impacts on the logical phases might be reasonably asserted on the binding. I just mentioned ServiceContexts as a way that Yoko might be extended in the future to allow WS-A headers to be encoded in a non-standard way, but that's off on a tangent to the main discussion. I also pinged the Yoko folks earlier as what aspects of WS-A they currently support, and its pretty much limited to EPR usage, i.e. no WS-A properties on the wire currently. > 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. Well that's sort of what I meant by taking some care in the decoupled case. Rather than the decoupled ReplyTo/FaultTo being ignored in the coloc case, another possible approach would be to suppress the coloc dispatch if the logical WS-A interceptor detects a non-anonymous ReplyTo/FaultTo. > 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 guess the choice is between coloc inheriting the "logical aspects" (if any) of the policies asserted on the "real binging", and OB/LT potentially allowing an alternate set of policies to be asserted. The problem with the latter is that it would seem to require that the OB is expressed in the WSDL in some way, as the WSDL provides the primary policy attachment points. And I'm not sure exposing the OB in the WSDL is a great idea, as it would go against the objective of enabling an optimized form of in-process dispatch via config, without any changes to code or WSDL. > 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. Interesting idea, coloc over LT, but I'm not sure what it would buy us over the current coloc approach. Would it be motivated mainly by a desire to keep things consistent (so that a Conduit/Destination is used just like the remote case), or to address the potential duplication of code like the LocalConduit message property filtering? Cheers, Eoghan > 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 <[EMAIL PROTECTED]> wrote: > > > > > > > > Thanks for the response Dan, some comments inline ... > > > > > -----Original Message----- > > > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > > > Sent: 14 April 2007 20:26 > > > To: [email protected] > > > 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 <[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 > > > > > > > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog >
