Hmm, my questions are simpler than I may have made them sound. From your original post, you say that you want to eliminate outbound and inbound wires and replace/merge them by/into a single wire attached to the source. Before the merge we used to have, from the perspective of a component C, an inbound wire per service it exposed and an outbound wire per reference it used. Each inbound wire had a set of inbound chains (one per opera- tion in the forward direction) and a number of callback outbound chain sets (one set per source component, and each group with one chain per callback operation). Similarly, each outbound wire had a set of outbound chains and a set of inbound chains. If a single wire is going to merge it all, are both sets of inbound chains and all sets of outbound chains going to be preserved? If not, what's the new structure that is going to be in place and how does it preserve the pre-exis- ting behavior? Like I said, this may be common knowledge and I may just have missed the explanation, in which case would someone point me to it?
On 2/12/07, Jim Marino <[EMAIL PROTECTED]> wrote:
>> I see two cases, managed and non-managed code. In the former, where >> the source is a component, there would be one set of chains (no >> distinction between inbound and outbound) attached to the source >> component. For non-managed code, it would be pretty much the same >> thing with the chains held in the proxy or CallableReference. > > > Apologies if this has been explained previously and is now common > knowledge (if so, could you point me at the explanation?). We've always had concepts of managed vs. non-managed code. The problem is the specs never made the distinction very well and confused the two in places. One of the main goals of the recent spec changes was to clarify this (hence the reintroduction of things like ComponentContext). The code is now in the 1.0 spec module but Jeremy also posted to the wiki on this. I'm not sure, though, if you are referring to this. > So is the idea that each chain has interceptors (say, databinding and > security) that are used for both incoming and outgoing messages? Is > there going to be a way to indicate to an interceptor which way is in > effect? I'm not following and probably missing something. I don't think this is any different than what we have today. There would be forward and callback chains associated with a Wire. If the interceptor needs to know if the invocation is a forward or callback invocation, it would be the job of the interceptor "builder" on the slave to provide it with that information (or have the builder instantiate different interceptors). There is a mail thread on interceptor builders from last week which covers the format for serializing a portable wire definition from master to slave. The idea is the definition would be created on the master and sent to the slave where interceptor builders would be responsible for creating interceptors according to some extensible wire definition information. > And would there be a way to indicate the order in each > direction? Maybe making the chain a doubly-linked list? > Could you explain a little further? I think the chain is exactly how we have it today except it is one as opposed to two chains for each direction. > >> >> A --------------\ >> |-----------------C >> B --------------/ >> >> I'm proposing we do the following: >> >> A --------------- >> C >> B --------------- >> >> In the approach connections would be: >> >> 1. Between components >> 2. From a transport to a component >> 3. From a component to a transport >> 4. From a transport to a transport > > > When you say transport, do you mean a composite reference and/or > service implementation for a given binding? I think of transport as what a binding provides a "link" to (not a composite reference or service since they may have multiple bindings). > Even with a single hop, a callback invocation handler at C would still > need to be able to choose between A and B depending on where the > forward call came from. How do you see it referring to the correspon- > ding wire when it needs to make the callback? It would be retrieved from the context, basically how it is today. We need to be careful here, though, about dealing with context cleanup on threads. Jim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
