Re: Build runtime wire/invocation chains for a composite hierarchy
On 4/26/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Ant, since I started to look at your sandbox work... what did you have in mind with Invoker.getInstance()? I've updated it a bit now though the class and method names still aren't very good, InvokerFactory is a way to get an implementation instance and an operation invoker instance. Should be createInstance instead of getInstance as well now that I look at it. That implementation-spi and implementation-spi-impl modules now works for implementation-crud and implementation-script and support properties and references. Not sure if its worth taking it much further now, or at least not till whats being discussed on this thread gets a bit further? ...ant
Re: Build runtime wire/invocation chains for a composite hierarchy
Comments inline. Raymond Feng wrote: Hi, Sebastien. I think we are pretty much on the same page but I used a not-so-clear term "RuntimeContext". I even have an interface named ReferenceBindingContextProvider, which is your "ReferenceBindingInvokerFactory", in my local workspace :-). For the service binding, I guess you're right. There is no need to have the service binding to provide an interceptor and the protocol-specific listener provided by the binding will dispatch the call to the promoted component service using an invocation chain. In addtion to the invoker factory, I think there are other things as well, for example, the service binding will provide the lifecycle support so that the binding can start/stop listening on the incoming message for the protocol. Thanks, Raymond Ok, cool. What I described here was also influenced by Ant's experiments in the sandbox under http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/SPI :) So it looks like we're converging. You're right we need to (optionally) manage the lifecycle of bindings and component implementation extensions. Could we just use our existing o.a.t.spi.Lifecycle interface for that? Ant, since I started to look at your sandbox work... what did you have in mind with Invoker.getInstance()? Thanks... - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 25, 2007 4:23 PM Subject: Re: Build runtime wire/invocation chains for a composite hierarchy ant elder wrote: This sounds like something I'm interested in, but I'm really struggling to understand what you're talking about in these two emails. What does "attach runtime context to the model so that the model can be used to drive the runtime behaviors" mean? What is MyContext? Could you describe this relating it to the existing classes and say which of those you want to change? ...ant On 4/25/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Continueing on this path, I propose the following way to attach runtime context to the model so that the model can be used to drive the runtime behaviors. 1) How is a runtime context is attached to the model? Let's assume the interface for the runtime context is "MyContext", then the model implementation can provide such a context in two ways: a) Implement "MyContext" interface directly, then the model object is an instance of MyContext and it can be cast to MyContext by the runtime. There is one thing not so nice is that we cannot have multiple inheritance and we can either use the base class for the model or the context, but not both. b) Implement a getter method to return MyContext, and the runtime can access it using reflection or a provider interface. This approach can take advantage of runtime context inheritance as MyContext is embedded. 2) How to build the invocation chain? Let's assume we have the wiring like this: ComponentA.reference1 w/ binding1 ---> ComponentB.service1 w/ binding1 For the reference side, the invocation chain will look like: Binding interceptor for reference1 over binding1 --> (binding protocol layer) For the service side, the invocation chain will look like: (binding protocol layer)...-->Binding interceptor for service1 over binding1--> Implementation interceptor for ComponentB If the binding is SCABinding, then for local interface or co-located remotable interface, the reference side can connect to the service side directly as: Binding interceptor for reference1 over binding1 -->Binding interceptor for service1 over binding1--> Implementation interceptor for ComponentB 3) The interfaces for runtime context: Please see the bottom of the wiki page at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy . Thanks, Raymond ----- Original Message ----- From: "Raymond Feng" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 24, 2007 11:58 AM Subject: Build runtime wire/invocation chains for a composite hierarchy > Hi, > > I'm trying to indentify all the paths of SCA component interactions which > require to have runtime wires/invocation chains. > > By the SCA spec, there are three cases for the wiring: > > 1) Component.Reference (A.ref1) --is wired to--> Component.Service > (B.svc1) > -- > 1.1) If both the service and reference are defined by non-composite > components, then the runtime wire is as simple as A.ref1-->B.svc1. > > 1.2) If the service is defined on a composite component, then it can be > further resolved to the orginal atomic component service following the > service promotion chain. > > For example, A.ref1 --> B.svc1 (B is implement
Re: Build runtime wire/invocation chains for a composite hierarchy
Hi, Sebastien. I think we are pretty much on the same page but I used a not-so-clear term "RuntimeContext". I even have an interface named ReferenceBindingContextProvider, which is your "ReferenceBindingInvokerFactory", in my local workspace :-). For the service binding, I guess you're right. There is no need to have the service binding to provide an interceptor and the protocol-specific listener provided by the binding will dispatch the call to the promoted component service using an invocation chain. In addtion to the invoker factory, I think there are other things as well, for example, the service binding will provide the lifecycle support so that the binding can start/stop listening on the incoming message for the protocol. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Wednesday, April 25, 2007 4:23 PM Subject: Re: Build runtime wire/invocation chains for a composite hierarchy ant elder wrote: This sounds like something I'm interested in, but I'm really struggling to understand what you're talking about in these two emails. What does "attach runtime context to the model so that the model can be used to drive the runtime behaviors" mean? What is MyContext? Could you describe this relating it to the existing classes and say which of those you want to change? ...ant On 4/25/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Continueing on this path, I propose the following way to attach runtime context to the model so that the model can be used to drive the runtime behaviors. 1) How is a runtime context is attached to the model? Let's assume the interface for the runtime context is "MyContext", then the model implementation can provide such a context in two ways: a) Implement "MyContext" interface directly, then the model object is an instance of MyContext and it can be cast to MyContext by the runtime. There is one thing not so nice is that we cannot have multiple inheritance and we can either use the base class for the model or the context, but not both. b) Implement a getter method to return MyContext, and the runtime can access it using reflection or a provider interface. This approach can take advantage of runtime context inheritance as MyContext is embedded. 2) How to build the invocation chain? Let's assume we have the wiring like this: ComponentA.reference1 w/ binding1 ---> ComponentB.service1 w/ binding1 For the reference side, the invocation chain will look like: Binding interceptor for reference1 over binding1 --> (binding protocol layer) For the service side, the invocation chain will look like: (binding protocol layer)...-->Binding interceptor for service1 over binding1--> Implementation interceptor for ComponentB If the binding is SCABinding, then for local interface or co-located remotable interface, the reference side can connect to the service side directly as: Binding interceptor for reference1 over binding1 -->Binding interceptor for service1 over binding1--> Implementation interceptor for ComponentB 3) The interfaces for runtime context: Please see the bottom of the wiki page at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy . Thanks, Raymond ----- Original Message - From: "Raymond Feng" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 24, 2007 11:58 AM Subject: Build runtime wire/invocation chains for a composite hierarchy > Hi, > > I'm trying to indentify all the paths of SCA component interactions which > require to have runtime wires/invocation chains. > > By the SCA spec, there are three cases for the wiring: > > 1) Component.Reference (A.ref1) --is wired to--> Component.Service > (B.svc1) > -- > 1.1) If both the service and reference are defined by non-composite > components, then the runtime wire is as simple as A.ref1-->B.svc1. > > 1.2) If the service is defined on a composite component, then it can be > further resolved to the orginal atomic component service following the > service promotion chain. > > For example, A.ref1 --> B.svc1 (B is implemented by another composite and > B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 --> C.svc1 > > 1.3) If the reference is defined on a composite component, then it can be > further resolved to the orginal atomic component reference following the > reference promotion chain. > > For example, A.ref1 --> B.svc1 (A is implemented by another composite and > A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 --> B.svc1 > > 2) Composite.Reference (Composite1.ref1) --promotes--> Component.Reference > (B.ref1) > --
Re: Build runtime wire/invocation chains for a composite hierarchy
ant elder wrote: This sounds like something I'm interested in, but I'm really struggling to understand what you're talking about in these two emails. What does "attach runtime context to the model so that the model can be used to drive the runtime behaviors" mean? What is MyContext? Could you describe this relating it to the existing classes and say which of those you want to change? ...ant On 4/25/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Continueing on this path, I propose the following way to attach runtime context to the model so that the model can be used to drive the runtime behaviors. 1) How is a runtime context is attached to the model? Let's assume the interface for the runtime context is "MyContext", then the model implementation can provide such a context in two ways: a) Implement "MyContext" interface directly, then the model object is an instance of MyContext and it can be cast to MyContext by the runtime. There is one thing not so nice is that we cannot have multiple inheritance and we can either use the base class for the model or the context, but not both. b) Implement a getter method to return MyContext, and the runtime can access it using reflection or a provider interface. This approach can take advantage of runtime context inheritance as MyContext is embedded. 2) How to build the invocation chain? Let's assume we have the wiring like this: ComponentA.reference1 w/ binding1 ---> ComponentB.service1 w/ binding1 For the reference side, the invocation chain will look like: Binding interceptor for reference1 over binding1 --> (binding protocol layer) For the service side, the invocation chain will look like: (binding protocol layer)...-->Binding interceptor for service1 over binding1--> Implementation interceptor for ComponentB If the binding is SCABinding, then for local interface or co-located remotable interface, the reference side can connect to the service side directly as: Binding interceptor for reference1 over binding1 -->Binding interceptor for service1 over binding1--> Implementation interceptor for ComponentB 3) The interfaces for runtime context: Please see the bottom of the wiki page at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy . Thanks, Raymond - Original Message - From: "Raymond Feng" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 24, 2007 11:58 AM Subject: Build runtime wire/invocation chains for a composite hierarchy > Hi, > > I'm trying to indentify all the paths of SCA component interactions which > require to have runtime wires/invocation chains. > > By the SCA spec, there are three cases for the wiring: > > 1) Component.Reference (A.ref1) --is wired to--> Component.Service > (B.svc1) > -- > 1.1) If both the service and reference are defined by non-composite > components, then the runtime wire is as simple as A.ref1-->B.svc1. > > 1.2) If the service is defined on a composite component, then it can be > further resolved to the orginal atomic component service following the > service promotion chain. > > For example, A.ref1 --> B.svc1 (B is implemented by another composite and > B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 --> C.svc1 > > 1.3) If the reference is defined on a composite component, then it can be > further resolved to the orginal atomic component reference following the > reference promotion chain. > > For example, A.ref1 --> B.svc1 (A is implemented by another composite and > A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 --> B.svc1 > > 2) Composite.Reference (Composite1.ref1) --promotes--> Component.Reference > (B.ref1) > - > If Composite1 is the top-level composite, and the B is a non-composite > component, then the runtime wire will be: B.ref1 --> Composite1.ref1 > > If Composite1 is used to implement a component A in Composite2, then we > need to futher check if A.ref1 is promoted or wired until we hit the end > of the promotion chain. The final target will be either a composite > reference or a component service that the out-most reference is wired to. > For example, if A.ref1 is wired to D.svc1 in Composite2, then the runtime > wire is B.ref1 --> D.svc1. If A.ref1 is promoted by Composite2.ref1, then > the runtime wire is B.ref1 --> Composite2.ref1. > > If B is a composite component, then we need to find out the final > component reference that B.ref1 promotes. For example, it promotes D.ref1, > then the runtime wire is D.ref1 --> C.ref1 >
Re: Build runtime wire/invocation chains for a composite hierarchy
Hi,
Let me try to get it straight. Basically I'm trying to figure out how the
runtime can use the assembly model to implement the SCA semantics, for
example, how to do the invocation when the component makes a call to the
proxy which represents a component reference.
Currently, the DeployerImpl and the builder framework walks though the model
and try to create runtime component/service/reference from the model and use
them to build interceptor chains to handle the component interactions. We
have found disadvantages of this approach as we build another "model" in
memory and completely throw away the assembly model.
a) redundancy (duplicate the information from the assembly model to the
runtime metadata)
b) missing information (no access to the assembly model from the runtime
metadata)
c) complexity (mixing the model resolution/nomalization with the invocation
handling code)
d) lack of dynamicity (changes in the model cannot be reflected in the
runtime metadata and it requires the "rebuild").
Given that now we havethe fully-configured and resolved model (with
reference/serivice promotion chain flattened), it should be possible to
leverage the model directly by adding/attaching some runtime actions to the
model. For example, the "implementation" would be responsible to contribute
an interceptor to handle the component implementation logic and the
"binding" could support the lifecycle to start/stop a listener to the
protocol layer. One example is as follows:
public class CRUDImplementation extends AbstractLifecycle implements
Implementation, ImplementationContext {
...
public Interceptor createInterceptor(Component model, Operation operation,
boolean isCallback) {
CRUDImplementation impl = (CRUDImplementation)
model.getImplementation();
CRUDTargetInvoker invoker = new CRUDTargetInvoker(operation, new
ResourceManager(impl.getDirectory()));
return invoker;
}
In this example, the CRUDImplementation not only implements the model
(Implementation), but also the runtime actions such as ImplementationContext
(to create the interceptor for the component) and LifeCycle (controls
lifecycle of the component).
Thanks,
Raymond
- Original Message -
From: "ant elder" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, April 25, 2007 3:34 PM
Subject: Re: Build runtime wire/invocation chains for a composite hierarchy
This sounds like something I'm interested in, but I'm really struggling to
understand what you're talking about in these two emails. What does
"attach
runtime context to the model so that the model can be used to drive the
runtime behaviors" mean? What is MyContext? Could you describe this
relating
it to the existing classes and say which of those you want to change?
...ant
On 4/25/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
Continueing on this path, I propose the following way to attach runtime
context to the model so that the model can be used to drive the runtime
behaviors.
1) How is a runtime context is attached to the model?
Let's assume the interface for the runtime context is "MyContext", then
the
model implementation can provide such a context in two ways:
a) Implement "MyContext" interface directly, then the model object is an
instance of MyContext and it can be cast to MyContext by the runtime.
There
is one thing not so nice is that we cannot have multiple inheritance and
we
can either use the base class for the model or the context, but not both.
b) Implement a getter method to return MyContext, and the runtime can
access
it using reflection or a provider interface. This approach can take
advantage of runtime context inheritance as MyContext is embedded.
2) How to build the invocation chain?
Let's assume we have the wiring like this: ComponentA.reference1 w/
binding1 ---> ComponentB.service1 w/ binding1
For the reference side, the invocation chain will look like:
Binding interceptor for reference1 over binding1 --> (binding
protocol
layer)
For the service side, the invocation chain will look like:
(binding protocol layer)...-->Binding interceptor for service1 over
binding1--> Implementation interceptor for ComponentB
If the binding is SCABinding, then for local interface or co-located
remotable interface, the reference side can connect to the service side
directly as:
Binding interceptor for reference1 over binding1 -->Binding interceptor
for
service1 over binding1--> Implementation interceptor for ComponentB
3) The interfaces for runtime context:
Please see the bottom of the wiki page at
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy
.
Thanks,
Raymond
----- Original Message -----
From: "Raymond Feng" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, April 24, 2007 11:58 AM
Subject: Build runtime wire/invocation chains for a composi
Re: Build runtime wire/invocation chains for a composite hierarchy
Raymond Feng wrote: Hi, I'm trying to indentify all the paths of SCA component interactions which require to have runtime wires/invocation chains. By the SCA spec, there are three cases for the wiring: 1) Component.Reference (A.ref1) --is wired to--> Component.Service (B.svc1) -- 1.1) If both the service and reference are defined by non-composite components, then the runtime wire is as simple as A.ref1-->B.svc1. 1.2) If the service is defined on a composite component, then it can be further resolved to the orginal atomic component service following the service promotion chain. For example, A.ref1 --> B.svc1 (B is implemented by another composite and B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 --> C.svc1 1.3) If the reference is defined on a composite component, then it can be further resolved to the orginal atomic component reference following the reference promotion chain. For example, A.ref1 --> B.svc1 (A is implemented by another composite and A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 --> B.svc1 2) Composite.Reference (Composite1.ref1) --promotes--> Component.Reference (B.ref1) - If Composite1 is the top-level composite, and the B is a non-composite component, then the runtime wire will be: B.ref1 --> Composite1.ref1 If Composite1 is used to implement a component A in Composite2, then we need to futher check if A.ref1 is promoted or wired until we hit the end of the promotion chain. The final target will be either a composite reference or a component service that the out-most reference is wired to. For example, if A.ref1 is wired to D.svc1 in Composite2, then the runtime wire is B.ref1 --> D.svc1. If A.ref1 is promoted by Composite2.ref1, then the runtime wire is B.ref1 --> Composite2.ref1. If B is a composite component, then we need to find out the final component reference that B.ref1 promotes. For example, it promotes D.ref1, then the runtime wire is D.ref1 --> C.ref1 3) Composite.Service (Composite1.svc1) --promotes--> Component.Service (A.svc1) --- The source will be the outmost service on the promotion chain. For example, if Composite2.svc1 promotes B.svc1 and B is implemented by Composite1, then it is Composite2.svc1. The target will be the innermost service on the promotion chain. For example, if A is implemented by Composite3 and Composite3.svc1 promotes C.svc1, then it is C.svc1. * Please note, due to the spec limitation, the composite service cannot promote a composite reference directly. Based on the above scenarios, it seems that we can create runtime wires using the following algorithm (assuming multiplicity = 1..1). The key is to get a final list of targets and selected bindings. 1) Runtime wire for references: For each of the references (r1) on non-composite components, find the outmost reference (r0) on the reference promotion chain. Then get the targets and selected bindings from r0. If SCA binding is used for a target, it can be further optimized to use the orginally promoted component service. The runtime wire should be created between the r1 and a target (either a component service with SCA binding or a reference binding) from r0. 2) Runtime wire for service promotions: For each of the service1 (s1) on non-composite components, find the outmost service (s0, can be the same as s1) on the service promotion chain. Create a runtime wire between the selected binding of s0 and the component that defines s1. (Can we assume that s1 is always local to s0?) The service/reference promotions make the picture complicated. I hope my thought makes sense. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The paths you have identified and the algorithm that you describe make sense to me, but I'm not sure that we actually need to create "runtime wires". My understanding is that references have bindings and target services are provided through bindings as well. To make a reference talk to a target service we just need to select the appropriate binding (assuming that the SCA binding can do a direct in-memory call when the target service is running in the same SCA contribution and runtime) and configure the reference with the endpoint of the target service (or /bindings/endpoints/targets when multiplicity > 1). Target and binding configuration can be overriden at multiple levels of composition, so a simple way to handle that is to recursively walk the nested compositions and propagate the relevant configuration to the innermost com
Re: Build runtime wire/invocation chains for a composite hierarchy
This sounds like something I'm interested in, but I'm really struggling to understand what you're talking about in these two emails. What does "attach runtime context to the model so that the model can be used to drive the runtime behaviors" mean? What is MyContext? Could you describe this relating it to the existing classes and say which of those you want to change? ...ant On 4/25/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, Continueing on this path, I propose the following way to attach runtime context to the model so that the model can be used to drive the runtime behaviors. 1) How is a runtime context is attached to the model? Let's assume the interface for the runtime context is "MyContext", then the model implementation can provide such a context in two ways: a) Implement "MyContext" interface directly, then the model object is an instance of MyContext and it can be cast to MyContext by the runtime. There is one thing not so nice is that we cannot have multiple inheritance and we can either use the base class for the model or the context, but not both. b) Implement a getter method to return MyContext, and the runtime can access it using reflection or a provider interface. This approach can take advantage of runtime context inheritance as MyContext is embedded. 2) How to build the invocation chain? Let's assume we have the wiring like this: ComponentA.reference1 w/ binding1 ---> ComponentB.service1 w/ binding1 For the reference side, the invocation chain will look like: Binding interceptor for reference1 over binding1 --> (binding protocol layer) For the service side, the invocation chain will look like: (binding protocol layer)...-->Binding interceptor for service1 over binding1--> Implementation interceptor for ComponentB If the binding is SCABinding, then for local interface or co-located remotable interface, the reference side can connect to the service side directly as: Binding interceptor for reference1 over binding1 -->Binding interceptor for service1 over binding1--> Implementation interceptor for ComponentB 3) The interfaces for runtime context: Please see the bottom of the wiki page at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy . Thanks, Raymond - Original Message - From: "Raymond Feng" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 24, 2007 11:58 AM Subject: Build runtime wire/invocation chains for a composite hierarchy > Hi, > > I'm trying to indentify all the paths of SCA component interactions which > require to have runtime wires/invocation chains. > > By the SCA spec, there are three cases for the wiring: > > 1) Component.Reference (A.ref1) --is wired to--> Component.Service > (B.svc1) > -- > 1.1) If both the service and reference are defined by non-composite > components, then the runtime wire is as simple as A.ref1-->B.svc1. > > 1.2) If the service is defined on a composite component, then it can be > further resolved to the orginal atomic component service following the > service promotion chain. > > For example, A.ref1 --> B.svc1 (B is implemented by another composite and > B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 --> C.svc1 > > 1.3) If the reference is defined on a composite component, then it can be > further resolved to the orginal atomic component reference following the > reference promotion chain. > > For example, A.ref1 --> B.svc1 (A is implemented by another composite and > A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 --> B.svc1 > > 2) Composite.Reference (Composite1.ref1) --promotes--> Component.Reference > (B.ref1) > - > If Composite1 is the top-level composite, and the B is a non-composite > component, then the runtime wire will be: B.ref1 --> Composite1.ref1 > > If Composite1 is used to implement a component A in Composite2, then we > need to futher check if A.ref1 is promoted or wired until we hit the end > of the promotion chain. The final target will be either a composite > reference or a component service that the out-most reference is wired to. > For example, if A.ref1 is wired to D.svc1 in Composite2, then the runtime > wire is B.ref1 --> D.svc1. If A.ref1 is promoted by Composite2.ref1, then > the runtime wire is B.ref1 --> Composite2.ref1. > > If B is a composite component, then we need to find out the final > component reference that B.ref1 promotes. For example, it promotes D.ref1, > then the runtime wire is D.ref1 --> C.ref1 > > 3) Composite.Service (Composite1.svc
Re: Build runtime wire/invocation chains for a composite hierarchy
Hi, Continueing on this path, I propose the following way to attach runtime context to the model so that the model can be used to drive the runtime behaviors. 1) How is a runtime context is attached to the model? Let's assume the interface for the runtime context is "MyContext", then the model implementation can provide such a context in two ways: a) Implement "MyContext" interface directly, then the model object is an instance of MyContext and it can be cast to MyContext by the runtime. There is one thing not so nice is that we cannot have multiple inheritance and we can either use the base class for the model or the context, but not both. b) Implement a getter method to return MyContext, and the runtime can access it using reflection or a provider interface. This approach can take advantage of runtime context inheritance as MyContext is embedded. 2) How to build the invocation chain? Let's assume we have the wiring like this: ComponentA.reference1 w/ binding1 ---> ComponentB.service1 w/ binding1 For the reference side, the invocation chain will look like: Binding interceptor for reference1 over binding1 --> (binding protocol layer) For the service side, the invocation chain will look like: (binding protocol layer)...-->Binding interceptor for service1 over binding1--> Implementation interceptor for ComponentB If the binding is SCABinding, then for local interface or co-located remotable interface, the reference side can connect to the service side directly as: Binding interceptor for reference1 over binding1 -->Binding interceptor for service1 over binding1--> Implementation interceptor for ComponentB 3) The interfaces for runtime context: Please see the bottom of the wiki page at http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Runtime+Component+Hierarchy. Thanks, Raymond - Original Message - From: "Raymond Feng" <[EMAIL PROTECTED]> To: Sent: Tuesday, April 24, 2007 11:58 AM Subject: Build runtime wire/invocation chains for a composite hierarchy Hi, I'm trying to indentify all the paths of SCA component interactions which require to have runtime wires/invocation chains. By the SCA spec, there are three cases for the wiring: 1) Component.Reference (A.ref1) --is wired to--> Component.Service (B.svc1) -- 1.1) If both the service and reference are defined by non-composite components, then the runtime wire is as simple as A.ref1-->B.svc1. 1.2) If the service is defined on a composite component, then it can be further resolved to the orginal atomic component service following the service promotion chain. For example, A.ref1 --> B.svc1 (B is implemented by another composite and B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 --> C.svc1 1.3) If the reference is defined on a composite component, then it can be further resolved to the orginal atomic component reference following the reference promotion chain. For example, A.ref1 --> B.svc1 (A is implemented by another composite and A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 --> B.svc1 2) Composite.Reference (Composite1.ref1) --promotes--> Component.Reference (B.ref1) - If Composite1 is the top-level composite, and the B is a non-composite component, then the runtime wire will be: B.ref1 --> Composite1.ref1 If Composite1 is used to implement a component A in Composite2, then we need to futher check if A.ref1 is promoted or wired until we hit the end of the promotion chain. The final target will be either a composite reference or a component service that the out-most reference is wired to. For example, if A.ref1 is wired to D.svc1 in Composite2, then the runtime wire is B.ref1 --> D.svc1. If A.ref1 is promoted by Composite2.ref1, then the runtime wire is B.ref1 --> Composite2.ref1. If B is a composite component, then we need to find out the final component reference that B.ref1 promotes. For example, it promotes D.ref1, then the runtime wire is D.ref1 --> C.ref1 3) Composite.Service (Composite1.svc1) --promotes--> Component.Service (A.svc1) --- The source will be the outmost service on the promotion chain. For example, if Composite2.svc1 promotes B.svc1 and B is implemented by Composite1, then it is Composite2.svc1. The target will be the innermost service on the promotion chain. For example, if A is implemented by Composite3 and Composite3.svc1 promotes C.svc1, then it is C.svc1. * Please note, due to the spec limitation, the composite service cannot promote a composite reference directly. Based o
Build runtime wire/invocation chains for a composite hierarchy
Hi, I'm trying to indentify all the paths of SCA component interactions which require to have runtime wires/invocation chains. By the SCA spec, there are three cases for the wiring: 1) Component.Reference (A.ref1) --is wired to--> Component.Service (B.svc1) -- 1.1) If both the service and reference are defined by non-composite components, then the runtime wire is as simple as A.ref1-->B.svc1. 1.2) If the service is defined on a composite component, then it can be further resolved to the orginal atomic component service following the service promotion chain. For example, A.ref1 --> B.svc1 (B is implemented by another composite and B.svc1 promotes C.svc1), then the runtime wire will be: A.ref1 --> C.svc1 1.3) If the reference is defined on a composite component, then it can be further resolved to the orginal atomic component reference following the reference promotion chain. For example, A.ref1 --> B.svc1 (A is implemented by another composite and A.ref1 promotes C.ref1), then the runtime wire will be: C.ref1 --> B.svc1 2) Composite.Reference (Composite1.ref1) --promotes--> Component.Reference (B.ref1) - If Composite1 is the top-level composite, and the B is a non-composite component, then the runtime wire will be: B.ref1 --> Composite1.ref1 If Composite1 is used to implement a component A in Composite2, then we need to futher check if A.ref1 is promoted or wired until we hit the end of the promotion chain. The final target will be either a composite reference or a component service that the out-most reference is wired to. For example, if A.ref1 is wired to D.svc1 in Composite2, then the runtime wire is B.ref1 --> D.svc1. If A.ref1 is promoted by Composite2.ref1, then the runtime wire is B.ref1 --> Composite2.ref1. If B is a composite component, then we need to find out the final component reference that B.ref1 promotes. For example, it promotes D.ref1, then the runtime wire is D.ref1 --> C.ref1 3) Composite.Service (Composite1.svc1) --promotes--> Component.Service (A.svc1) --- The source will be the outmost service on the promotion chain. For example, if Composite2.svc1 promotes B.svc1 and B is implemented by Composite1, then it is Composite2.svc1. The target will be the innermost service on the promotion chain. For example, if A is implemented by Composite3 and Composite3.svc1 promotes C.svc1, then it is C.svc1. * Please note, due to the spec limitation, the composite service cannot promote a composite reference directly. Based on the above scenarios, it seems that we can create runtime wires using the following algorithm (assuming multiplicity = 1..1). The key is to get a final list of targets and selected bindings. 1) Runtime wire for references: For each of the references (r1) on non-composite components, find the outmost reference (r0) on the reference promotion chain. Then get the targets and selected bindings from r0. If SCA binding is used for a target, it can be further optimized to use the orginally promoted component service. The runtime wire should be created between the r1 and a target (either a component service with SCA binding or a reference binding) from r0. 2) Runtime wire for service promotions: For each of the service1 (s1) on non-composite components, find the outmost service (s0, can be the same as s1) on the service promotion chain. Create a runtime wire between the selected binding of s0 and the component that defines s1. (Can we assume that s1 is always local to s0?) The service/reference promotions make the picture complicated. I hope my thought makes sense. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
