On Dec 12, 2007 12:10 AM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > My understanding is that the bindings represent the configured endpoints: > reference bindings are for outbound while service bindings are for > inbound. > When a source reference is wired to a target service, we need to make sure > they are compatible in terms of interface contract and intent/policy.
+1 > > > To me, there might be two types of wires. One type is to wire components > in > the same composite and the other is to wire components from different > composites in the same SCA domain. For the first type, it's fairly static > as > the composite is probably the basic unit for update. It makes sense to > match I agree that you could consider wiring within a composite to be fairly static. We have to be careful though as a reference could have wires to both "local" composite based services and "remote" domain based services. So we cannot consider a reference to be either local or remote just the wires that it gives rise to. > > the bindings upfront. But for the second type, composites join and leave > the > SCA domain dynamically, it's very hard to keep the matched binding in > sync. > Is it even wise to attempt to resolve the bindings? Should we consider a > SCA > domain level service as the match-maker whenever the reference is used to > make an outbound invocation? Not sure I understand the last sentence. Let me say a little about how this could operate... The domain has full view of all of the composites that are currently active, i.e. it knows what the domain level composite looks like. Importantly it also knows about the two important events that affect the domain level composite. AddToDomainLevelComposite and RemoveFromDomain LevelComposite. On these two events it is able to look across all services and references in the domain and perform the same matching process as happens within each composite. Well it could if it knew the original set of bindings for each reference. During this process it also knows which references are being updated as a result of this process so it can pass any updates that result off to the appropriate nodes if composites have been started. So I don't think in this process the assembly model recognizes any material difference between composite and domain level wires. The difference is the process through at which they are created. Let's consider the other approach we mentioned. Whenever the domain level composite is changed the domain level composite is rebuilt along with all of the composites it includes. I'm sure changes could be made to the current code to make this work in terms of building the model of the world that the domain knows about. It would remove a requirement to store the original bindings for references as the process for resolving references and services from the domain level down would resolve references in a single pass. The downside of this approach is it's difficult to tell what has changed. We could approach this in a number of ways. Keep the old model and compare against the new to determine changes. Pass each composite off to the node that is running it and have it determine what has changed (this is what happens at the moment on a limited basis in that only the composites that are known to have changed are sent out). The brute force approach could be taken where a the node is restarted based on the changed composite but this sounds a bit heavy handed to me in as much that services could become unavailable in the event that small (or no) changes are made to the composites that the node is running. Regards Simon > > Thanks, > Raymond > > ----- Original Message ----- > From: "Simon Laws" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Tuesday, December 11, 2007 2:25 PM > Subject: Re: Binding target information > > > > On Dec 11, 2007 5:46 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > > > >> Hi, Simon. > >> > >> We went through a similar discussion before. The result is documented > at > >> > >> > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Multiple+bindings+and+reference+multiplicity > >> . > >> Can you check if it helps? > >> > >> Thanks, > >> Raymond > >> > >> ----- Original Message ----- > >> From: "Simon Laws" <[EMAIL PROTECTED]> > >> To: <[email protected]> > >> Sent: Tuesday, December 11, 2007 8:30 AM > >> Subject: Re: Binding target information > >> > >> > >> > On Dec 11, 2007 3:11 PM, Mike Edwards > >> > <[EMAIL PROTECTED]> > >> > wrote: > >> > > >> >> Simon, > >> >> > >> >> One of the questions here is whether the representation of the > targets > >> >> needs to mirror the alternate ways in which a target can be defined > by > >> >> the SCDL. > >> >> > >> >> For example: > >> >> > >> >> a) The target(s) can be defined by the @target attribute on the > >> >> reference. Each target can potentially use any one of the bindings > >> >> defined for the reference (which is used depends on the binding(s) > >> >> attached to each target service). > >> >> > >> >> b) The target can be defined by the @uri attribute on the binding > (or > >> by > >> >> equivalent binding-specific data in other attributes or child > elements > >> >> of the binding). These targets are specific to the binding (and > >> >> typically there is only one per declared binding) > >> >> > >> >> While it is reasonable to envision the first type of reference being > >> >> attached to the reference, I don't see that it is a good idea to > >> >> attach > >> >> the second type of reference to the reference - the second type are > >> >> clearly attached to a particular binding instance. (Consider the > case > >> >> where a reference has 2 binding.ws bindings attached, each with its > >> >> own > >> >> target defined in the @uri attributes, but where other aspects of > the > >> >> binding (eg policies) differ between the bindings. > >> >> > >> >> While the target uri's may be technically interchangeable, in > reality > >> >> they have to be tied to the binding they are declared on - for > >> >> example, > >> >> one target may be within our business and require a low level of > >> >> security applid, while a second target may be outside our business > and > >> >> require a high level of security applied. > >> >> > >> >> How do you think this plays out in the code? > >> >> > >> >> > >> >> Yours, Mike. > >> >> > >> >> Simon Laws wrote: > >> >> > When processing references at the domain level I need to know the > >> name > >> >> of > >> >> > the target service which each reference binding is associated with > >> >> > so > >> >> that I > >> >> > can match the binding with the service name when the service > >> >> > endpoint > >> >> > is > >> >> > made available or is moved or removed. As a work around I set the > >> >> binding > >> >> > name to the target service name in the case that target services > >> cannot > >> >> be > >> >> > resolved locally. Not ideal! . > >> >> > > >> >> > I would like to propose that we add this information into the base > >> >> binding > >> >> > model. For example, > >> >> > > >> >> > public interface Binding extends Base { > >> >> > > >> >> > Service getTargetService(); > >> >> > void setTargetService(Service service); > >> >> > > >> >> > The other thing that this could help us sort out is the > >> >> OptimizableBinding. > >> >> > This holds target service information. With the changes made to > take > >> >> > the > >> >> > majority of the domain logic out of the SCA binding I could get > away > >> >> with > >> >> > just knowing the target service. > >> >> > > >> >> > We do still have to be able to clone bindings (another feature of > >> >> > OptimizableBinding) in the case where there is more than one > target. > >> If > >> >> I > >> >> > understand it correctly the assembly model follows what you see in > >> >> composite > >> >> > XML, For example, > >> >> > > >> >> > <component name="SomeComponent"> > >> >> > <implementation.java class="my.ComponentImpl"/> > >> >> > <reference name="ref" target="TargetService1 > >> >> > TargetService2"> > >> >> > <binding.ws/> > >> >> > <binding.jsonrpc/> > >> >> > </reference> > >> >> > </component> > >> >> > > >> >> > Leads to a model that looks something like > >> >> > > >> >> > Component > >> >> > Reference > >> >> > Targets > >> >> > TargetService1 > >> >> > TargetService2 > >> >> > Bindings > >> >> > binding.ws > >> >> > binding.jsonrpc > >> >> > > >> >> > With the obvious fun involved in working out which binding is > >> >> > associated > >> >> > with which target. If they both want to use the same binding it > has > >> to > >> >> be > >> >> > cloned. Have I got this right? If so should we make bindings > >> generally > >> >> > cloneable? > >> >> > > >> >> > Simon > >> >> > > >> >> > >> >> > --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > >> >> Two points then some examples... > >> > > >> > 1) There are other cases also as the target could be specified using > >> > autowire or wireByImpl. > >> > 2) The runtime code is interesting at the moment in as much as the > >> service > >> > resolution process gives rise to the reference binding list from the > >> input > >> > composite being replaced by a list of bindings that represent > resolved > >> > connections to target services. > >> > > >> > A) > >> > > >> > <component name="SomeComponent"> > >> > <implementation.java class="my.ComponentImpl"/> > >> > <reference name="ref" target="TargetService1 TargetService2"> > >> > <binding.ws/> > >> > <binding.jsonrpc/> > >> > </reference> > >> > </component> > >> > > >> > may give rise to > >> > > >> > reference > >> > targets > >> > TargetService1 > >> > TargetService2 > >> > bindings > >> > binding.ws > >> > uri="http://localhost:8080/TargetService1";<http://binding.ws/> > >> > binding.ws > >> > uri="http://localhost:8080/TargetService2";<http://binding.ws/> > >> > > >> > This is where the effect is slightly odd. The result is right but we > >> loose > >> > the original list of bindings from the reference. > >> > > >> > B) > >> > <component name="SomeComponent"> > >> > <implementation.java class="my.ComponentImpl"/> > >> > <reference name="ref"> > >> > <binding.ws uri="TargetService1"/ <http://binding.ws/>> > >> > <binding.jsonrpc uri="TargetService2"/> > >> > </reference> > >> > </component> > >> > > >> > may give rise to > >> > > >> > reference > >> > targets > >> > ? not sure if targets should be here > >> > bindings > >> > binding.ws > >> > uri="http://localhost:8080/TargetService1";<http://binding.ws/> > >> > binding.jsonrpc > >> > uri="http://localhost:8080/TargetService2";<http://binding.ws/> > >> > > >> > But I can't see that the code does this at the moment although I > >> > haven't > >> > actually tried it to prove that it doesn't work. > >> > > >> > C) > >> > <component name="SomeComponent"> > >> > <implementation.java class="my.ComponentImpl"/> > >> > <reference name="ref" > > >> > <binding.ws > >> > uri="http://localhost:8080/TargetService1";<http://binding.ws/> > >> > / <http://binding.ws/>> > >> > </reference> > >> > </component> > >> > > >> > may give rise to > >> > > >> > reference > >> > targets > >> > bindings > >> > binding.ws > >> > uri="http://localhost:8080/TargetService1";<http://binding.ws/> > >> > > >> > > >> > D) > >> > <component name="SomeComponent"> > >> > <implementation.java class="my.ComponentImpl"/> > >> > <reference name="ref" target="TargetService1 TargetService2"> > >> > <binding.ws uri="TargetService3"/ <http://binding.ws/>> > >> > <binding.jsonrpc uri="TargetService4"/> > >> > </reference> > >> > </component> > >> > > >> > This may give rise to the runtime model > >> > > >> > reference > >> > targets > >> > TargetService1 > >> > TargetService2 > >> > bindings > >> > binding.ws > >> > uri="http://localhost:8080/TargetService1";<http://binding.ws/> > >> > binding.ws > >> > uri="http://localhost:8080/TargetService2";<http://binding.ws/> > >> > > >> > E) > >> > > >> > <component name="SomeComponent" autowire="true"> > >> > <implementation.java class="my.ComponentImpl"/> > >> > <reference name="ref" > > >> > <binding.ws/> > >> > <binding.jsonrpc/> > >> > </reference> > >> > </component> > >> > > >> > may give rise to > >> > > >> > reference > >> > targets > >> > ? would be handy to know the autowired target names > >> > bindings > >> > binding.ws > >> > uri="http://localhost:8080/TargetService1";<http://binding.ws/> > >> > binding.ws > >> > uri="http://localhost:8080/TargetService2";<http://binding.ws/> > >> > > >> > > >> > I don't know what happens with wire by impl but again it would seem > >> useful > >> > if the target list included the names of services from the sca domain > >> that > >> > have been wired. > >> > > >> > So not sure if this answers your question. > >> > > >> > Regards > >> > > >> > Simon > >> > > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> Hi Raymond. > > > > Thanks for pointing me back to that. I think maybe I'm only coming to > > appreciate the significance of this by working through this again from > the > > domain point of view. I have to admit that I had forgotten the detail in > > your matrix. When I looked at the wiki a while ago I didn't cotton on to > > the > > fact that the "Normalized/Component Reference" column is actually all > that > > is stored in the assembly model and that the original component > reference > > binding information is not available after each composite has initially > > been > > built. > > > > From the domain point of view that's a little inconvenient as it means > we > > would have to rebuild the domain completely each time something changes > so > > that you are starting with a clean slate, i.e. you have access to the > > original bindings for matching purposes. If I drop a new wire into the > > domain I can't simply go and match potential references to services as > the > > bindings may no longer be a complete set. Actually it would work the > first > > time but not if I dropped in another wire for the same reference. The > > wires > > must be present before the reference is built so the complete set of > > required bindings can be determined. > > > > So this is teasing out two points > > > > 1. Lack of original binding list once composites are built. We wouldn't > > need > > this if we were to rebuild the whole domain on each change but we would > > have > > to change the assembly builders to allow the domainLeveComposite to be > > built > > in one go as the original binding list is gone once a composite is > built. > > The code currently doesn't treat includes correctly so it won't work as > > is. > > > > 2. My original point. No generic way to find the target name for a > > binding. > > It's difficult to quickly identify the binding that satisfies a > particular > > target so any operations to update bindings in a reference after it's > been > > built are problematic.We could maybe ignore for now the scenario where > > someone rewires a reference in a domain. However I am currently updating > > reference bindings to complete endpoint information as I don't know the > > endpoint information until a composite has been started in a node. > > > > Regards > > > > Simon > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
