Runtime bring-up and next steps
I've finished the final piece to bringing up the base standalone runtime which Jeremy has been working on to support the SCA 1.0 client APIs. This mostly involved externalizing autowire from CompositeComponent to an AutowireResolver which is called after the model is loaded. This had the side-effect of simplifying the runtime as the connector no longer needs to deal with the autowire case (autowires will resolve to absolute URIs). I have also removed the process for connecting artifacts from CompositeComponent to Deployer. Below are a few more changes I plan to work on over the next few days: - I plan to continue refactoring Component to simplify and cleanup the interface. This will hopefully result in little difference between atomic and composite components. - I would like to eliminate the need for outbound and inbound wires, having the connector create a single Wire which is attached to a source. In this scenario, targets will not have wires but will continue to supply TargetInvokers to sources. This will tie in directly with Meeraj's work on the physical component builders and wire reconstitution on slaves. It will also further serve to simplify the connect phase. As we do this, we will need to revisit the SPI for WirePostProcessors. Following on Meeraj's physical builder work, policy and wire processing will need to be done on the master against the model and a portable representation of the wire sent to slaves where it will be constituted. We will need something akin to an InterceptorBuilder which will be responsible for helping to constitute a wire on the slave by supplying interceptors. Thoughts? - Integrate the autowire changes with Meeraj's federation work which will give us support for federated/distributed autowire across an SCA Domain (as well as supporting more of the SCA autowire semantics). Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime bring-up and next steps
Hi Jim, Comments inline. On 2/11/07, Jim Marino <[EMAIL PROTECTED]> wrote: I've finished the final piece to bringing up the base standalone runtime which Jeremy has been working on to support the SCA 1.0 client APIs. This mostly involved externalizing autowire from CompositeComponent to an AutowireResolver which is called after the model is loaded. This had the side-effect of simplifying the runtime as the connector no longer needs to deal with the autowire case (autowires will resolve to absolute URIs). I have also removed the process for connecting artifacts from CompositeComponent to Deployer. Below are a few more changes I plan to work on over the next few days: - I plan to continue refactoring Component to simplify and cleanup the interface. This will hopefully result in little difference between atomic and composite components. - I would like to eliminate the need for outbound and inbound wires, having the connector create a single Wire which is attached to a source. In this scenario, targets will not have wires but will continue to supply TargetInvokers to sources. This will tie in directly with Meeraj's work on the physical component builders and wire reconstitution on slaves. It will also further serve to simplify the connect phase. As we do this, we will need to revisit the SPI for WirePostProcessors. Following on Meeraj's physical builder work, policy and wire processing will need to be done on the master against the model and a portable representation of the wire sent to slaves where it will be constituted. We will need something akin to an InterceptorBuilder which will be responsible for helping to constitute a wire on the slave by supplying interceptors. Thoughts? Not sure what the intended approach is here. I would think that inbound chains for targets would still be needed, where would those live now, in the single wire at the source? Would that also preserve the bridging interceptors at the source wire? Perhaps I am not understanding, but at some point we used to have a similar approach where (at least some of) the chains were co-located in a single wire, but that had to be undone to allow multiple sets of callback source chains at an inbound wire. Could you elaborate on how this would work with a single wire? - Integrate the autowire changes with Meeraj's federation work which will give us support for federated/distributed autowire across an SCA Domain (as well as supporting more of the SCA autowire semantics). Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime bring-up and next steps
Hi Jim, Is there a short write-up on all this somewhere? There might be one on the cwiki that I am not able to find. I have been trying to cut and paste from several email and add the snippets to the 'in porgress' architecture document, but it is not clear how the pieces come together. Does bring up of runtime include a successful run of iTest? Thanks, Haleh On 2/10/07, Jim Marino <[EMAIL PROTECTED]> wrote: I've finished the final piece to bringing up the base standalone runtime which Jeremy has been working on to support the SCA 1.0 client APIs. This mostly involved externalizing autowire from CompositeComponent to an AutowireResolver which is called after the model is loaded. This had the side-effect of simplifying the runtime as the connector no longer needs to deal with the autowire case (autowires will resolve to absolute URIs). I have also removed the process for connecting artifacts from CompositeComponent to Deployer. Below are a few more changes I plan to work on over the next few days: - I plan to continue refactoring Component to simplify and cleanup the interface. This will hopefully result in little difference between atomic and composite components. - I would like to eliminate the need for outbound and inbound wires, having the connector create a single Wire which is attached to a source. In this scenario, targets will not have wires but will continue to supply TargetInvokers to sources. This will tie in directly with Meeraj's work on the physical component builders and wire reconstitution on slaves. It will also further serve to simplify the connect phase. As we do this, we will need to revisit the SPI for WirePostProcessors. Following on Meeraj's physical builder work, policy and wire processing will need to be done on the master against the model and a portable representation of the wire sent to slaves where it will be constituted. We will need something akin to an InterceptorBuilder which will be responsible for helping to constitute a wire on the slave by supplying interceptors. Thoughts? - Integrate the autowire changes with Meeraj's federation work which will give us support for federated/distributed autowire across an SCA Domain (as well as supporting more of the SCA autowire semantics). Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime bring-up and next steps
Hi, Comments inline On Feb 12, 2007, at 8:01 AM, haleh mahbod wrote: Hi Jim, Is there a short write-up on all this somewhere? There might be one on the cwiki that I am not able to find. Yes, there have been a bunch of mails posted to the list on these topics over the last couple of weeks. I mentioned in a response to Raymond's thread on the architecture description he added to the wiki that I would try to make updates when I have some time, hopefully in the next few days. If someone also wants to make a pass based on changes from last week and over the weekend, I'm also happy to help answer questions. I have been trying to cut and paste from several email and add the snippets to the 'in porgress' architecture document, but it is not clear how the pieces come together. Could you post questions to the ML and I will try to answer them? Does bring up of runtime include a successful run of iTest? I was specifically referring to the standalone runtime but it appears Jeremy also has the itest plugin working with the really neat ability to run a JUnit test as a component. This looks like a big improvement over the old SCATestCase, particularly since it is closer to the 1.0 APIs (we discussed doing this a while back). I'll let Jeremy comment more on it... Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime bring-up and next steps
On Feb 12, 2007, at 9:46 AM, Jim Marino wrote: On Feb 12, 2007, at 8:01 AM, haleh mahbod wrote: Does bring up of runtime include a successful run of iTest? I was specifically referring to the standalone runtime but it appears Jeremy also has the itest plugin working with the really neat ability to run a JUnit test as a component. This looks like a big improvement over the old SCATestCase, particularly since it is closer to the 1.0 APIs (we discussed doing this a while back). I'll let Jeremy comment more on it... I went to work on the proposal for updating the itest framework and have the basic framework going. There is a smoketest in the runtime model that basically brings up a test component and calls it. I've started porting the samples from M2 to the 1.0 spec, starting with ones that do not use any extensions. I created a new core- samples module for this. I've managed to itest the calculator with the plugin. The launcher and webapp runtime these use don't work yet as they need the contribution stuff Luciano is working on - I had to hack local deployment into the itest plugin to be able to run things. Until then, I'm going to start migrating the old itest to 1.0 using the plugin to test them. If it seems to work well, I'll add doco to the plugin to generate the typical mini-site. We could also use a hack similar to the one I used in itest to deploy composites locally for the standalone and webapp environments - I can give pointers if anyone is interested (see MavenEmbeddedRuntime#deployTestScdl). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime bring-up and next steps
The itest framework is very neat and easy to use now. Good job! Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Monday, February 12, 2007 10:40 AM Subject: Re: Runtime bring-up and next steps On Feb 12, 2007, at 9:46 AM, Jim Marino wrote: On Feb 12, 2007, at 8:01 AM, haleh mahbod wrote: Does bring up of runtime include a successful run of iTest? I was specifically referring to the standalone runtime but it appears Jeremy also has the itest plugin working with the really neat ability to run a JUnit test as a component. This looks like a big improvement over the old SCATestCase, particularly since it is closer to the 1.0 APIs (we discussed doing this a while back). I'll let Jeremy comment more on it... I went to work on the proposal for updating the itest framework and have the basic framework going. There is a smoketest in the runtime model that basically brings up a test component and calls it. I've started porting the samples from M2 to the 1.0 spec, starting with ones that do not use any extensions. I created a new core- samples module for this. I've managed to itest the calculator with the plugin. The launcher and webapp runtime these use don't work yet as they need the contribution stuff Luciano is working on - I had to hack local deployment into the itest plugin to be able to run things. Until then, I'm going to start migrating the old itest to 1.0 using the plugin to test them. If it seems to work well, I'll add doco to the plugin to generate the typical mini-site. We could also use a hack similar to the one I used in itest to deploy composites locally for the standalone and webapp environments - I can give pointers if anyone is interested (see MavenEmbeddedRuntime#deployTestScdl). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime bring-up and next steps
Hi, In the latest calculator sample, it demonstrates the usage of itest where we define a harness composite as follows: http://www.osoa.org/xmlns/sca/1.0"; xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"; name="CalculatorTestHarnessComposite"> scdlResource="META-INF/sca/default.scdl"/> name="calculatorService">CalculatorServiceComponent I think we might be able to further simplify this by introspecting the test cases to create such a harness composite. For example, we can create a Junit component if the base class is org.junit.TestCase and use autowire to resolve the references to the services being tested. Does it make sense? Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Monday, February 12, 2007 10:40 AM Subject: Re: Runtime bring-up and next steps On Feb 12, 2007, at 9:46 AM, Jim Marino wrote: On Feb 12, 2007, at 8:01 AM, haleh mahbod wrote: Does bring up of runtime include a successful run of iTest? I was specifically referring to the standalone runtime but it appears Jeremy also has the itest plugin working with the really neat ability to run a JUnit test as a component. This looks like a big improvement over the old SCATestCase, particularly since it is closer to the 1.0 APIs (we discussed doing this a while back). I'll let Jeremy comment more on it... I went to work on the proposal for updating the itest framework and have the basic framework going. There is a smoketest in the runtime model that basically brings up a test component and calls it. I've started porting the samples from M2 to the 1.0 spec, starting with ones that do not use any extensions. I created a new core- samples module for this. I've managed to itest the calculator with the plugin. The launcher and webapp runtime these use don't work yet as they need the contribution stuff Luciano is working on - I had to hack local deployment into the itest plugin to be able to run things. Until then, I'm going to start migrating the old itest to 1.0 using the plugin to test them. If it seems to work well, I'll add doco to the plugin to generate the typical mini-site. We could also use a hack similar to the one I used in itest to deploy composites locally for the standalone and webapp environments - I can give pointers if anyone is interested (see MavenEmbeddedRuntime#deployTestScdl). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime bring-up and next steps
On Feb 12, 2007, at 12:18 PM, Raymond Feng wrote: Hi, In the latest calculator sample, it demonstrates the usage of itest where we define a harness composite as follows: http://www.osoa.org/xmlns/sca/1.0"; xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"; name="CalculatorTestHarnessComposite"> name="calculatorService">CalculatorServiceComponent I think we might be able to further simplify this by introspecting the test cases to create such a harness composite. For example, we can create a Junit component if the base class is org.junit.TestCase and use autowire to resolve the references to the services being tested. Does it make sense? Something like that, yep. We would need to distinguish unit tests from integration ones (which test plugins like surefire do through name patterns), and there's a question if the main composite should be d or used as an implementation. But the less the user has to do the better. -- Jeremy FWIW and IIRC, 1.0 supports autowire for composites so adding @autowire="true" on the composite should be enough to remove all the reference definitions. I don't think that's implemented yet though. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime bring-up and next steps
FWIW and IIRC, 1.0 supports autowire for composites so adding @autowire="true" on the composite should be enough to remove all the reference definitions. I don't think that's implemented yet though. I plan to get on that ASAP. With the autowire move to the resolver, it should be easy to implement. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime bring-up and next steps
Hi Ignacio, Comments inline. Jim - I would like to eliminate the need for outbound and inbound wires, having the connector create a single Wire which is attached to a source. In this scenario, targets will not have wires but will continue to supply TargetInvokers to sources. This will tie in directly with Meeraj's work on the physical component builders and wire reconstitution on slaves. It will also further serve to simplify the connect phase. As we do this, we will need to revisit the SPI for WirePostProcessors. Following on Meeraj's physical builder work, policy and wire processing will need to be done on the master against the model and a portable representation of the wire sent to slaves where it will be constituted. We will need something akin to an InterceptorBuilder which will be responsible for helping to constitute a wire on the slave by supplying interceptors. Thoughts? Not sure what the intended approach is here. I would think that inbound chains for targets would still be needed, where would those live now, in the single wire at the source? 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. This should simplify the connector a bit more and allow us to fit in with the master allocation process described by Meeraj. For example, a WireDefinition will be marshalled to a slave node where it will be reconstituted. Would that also preserve the bridging interceptors at the source wire? We would just need the non-blocking variant. There would be no need for the synchronous form. If a wire changes, the assembly will be mutated on the master and a diff (probably of just the wire) sent to the slave. Perhaps I am not understanding, but at some point we used to have a similar approach where (at least some of) the chains were co-located in a single wire, but that had to be undone to allow multiple sets of callback source chains at an inbound wire. Could you elaborate on how this would work with a single wire? I think I'm proposing something different to what we had before, essentially collapsing the distinction between inbound and outbound wires. For example, what we currently have is: 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 We won't need to have multiple hop wires with the "local" binding anymore (e.g. component-->reference-->service-->component) since they can be optimized as point-to-point communications (e.g. component-- >component) on the master. The connector would be responsible for just creating wires, populating it with interceptors, and obtaining a target invoker from the target. Callback wires would just be associated on the source side and set as context as it is today. Jim This is not that much different from what we have today in that we are collapsing OutboundWire and InboundWire. Callback - Integrate the autowire changes with Meeraj's federation work which will give us support for federated/distributed autowire across an SCA Domain (as well as supporting more of the SCA autowire semantics). Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime bring-up and next steps
Hi Jim, More comments/questions inline. On 2/12/07, Jim Marino <[EMAIL PROTECTED]> wrote: Hi Ignacio, Comments inline. Jim >> - I would like to eliminate the need for outbound and inbound wires, >> having the connector create a single Wire which is attached to a >> source. In this scenario, targets will not have wires but will >> continue to supply TargetInvokers to sources. This will tie in >> directly with Meeraj's work on the physical component builders and >> wire reconstitution on slaves. It will also further serve to simplify >> the connect phase. As we do this, we will need to revisit the SPI for >> WirePostProcessors. Following on Meeraj's physical builder work, >> policy and wire processing will need to be done on the master against >> the model and a portable representation of the wire sent to slaves >> where it will be constituted. We will need something akin to an >> InterceptorBuilder which will be responsible for helping to >> constitute a wire on the slave by supplying interceptors. Thoughts? > > > Not sure what the intended approach is here. I would think that > inbound > chains for targets would still be needed, where would those live > now, in > the single wire at the source? 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?). 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? And would there be a way to indicate the order in each direction? Maybe making the chain a doubly-linked list? This should simplify the connector a bit more and allow us to fit in with the master allocation process described by Meeraj. For example, a WireDefinition will be marshalled to a slave node where it will be reconstituted. > Would that also preserve the bridging > interceptors at the source wire? We would just need the non-blocking variant. There would be no need for the synchronous form. If a wire changes, the assembly will be mutated on the master and a diff (probably of just the wire) sent to the slave. > Perhaps I am not understanding, but at some point we used to have a > similar approach where (at least some of) the chains were co-located > in a single wire, but that had to be undone to allow multiple sets of > callback source chains at an inbound wire. Could you elaborate on > how this would work with a single wire? I think I'm proposing something different to what we had before, essentially collapsing the distinction between inbound and outbound wires. For example, what we currently have is: 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? 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? We won't need to have multiple hop wires with the "local" binding anymore (e.g. component-->reference-->service-->component) since they can be optimized as point-to-point communications (e.g. component-- >component) on the master. The connector would be responsible for just creating wires, populating it with interceptors, and obtaining a target invoker from the target. Callback wires would just be associated on the source side and set as context as it is today. Jim This is not that much different from what we have today in that we are collapsing OutboundWire and InboundWire. Callback > > - Integrate the autowire changes with Meeraj's federation work which >> will give us support for federated/distributed autowire across an SCA >> Domain (as well as supporting more of the SCA autowire semantics). >> >> Jim >> >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Runtime bring-up and next steps
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]
Re: Runtime bring-up and next steps
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]
Re: Runtime bring-up and next steps
On Feb 14, 2007, at 7:59 AM, Ignacio Silva-Lepe wrote:
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?
Sorry, maybe I didn't explain clearly enough in previous posts. Both
sets of chains will be preserved. Source components will contain the
wires to a target and targets will no longer have incoming wires. The
Allocator on the master will build up a WireDefinition which will be
marshalled to a slave. The WireDefinition will contain a set of
InterceptorDefinitions which InterceptorBuilders will use to
constitute a Wire. The WireDefinition will also contain source and
target URIs. Hence, the Wire will contain both forward and callback
invocation chains. This will mean the Connector can change to the
following:
public interface Connector {
void connect(WireDefinition wd) throws WiringException;
}
As the Connector has a reference to a ComponentManager, it will be be
able to look up source and target, dispatch to InterceptorBuilders
based on a QName, build forward and callback chains for the wire, and
attach the wire to the source. Meeraj has already checked in
WireDefinition as well as posted on the marshalling format, so it may
be worth checking that out.
Jim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
