Re: Build runtime wire/invocation chains for a composite hierarchy
On 4/26/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ 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
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: tuscany-dev@ws.apache.org 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 on the above scenarios, it seems that we can create runtime wires using the following algorithm (assuming
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: tuscany-dev@ws.apache.org 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
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 component
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: tuscany-dev@ws.apache.org 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
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]
