On 8/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Venkata Krishnan wrote: > > Hi, > > > > The Assembly Specs and the PolicyFramework specs allows for intents > > and policysets to be specified on Operations. > > > > To implement this I'd expect that the Operation interface support > > methods to hold a set of required intents and policysets. This also > > seems in sync with the schema definition for Operation. > > > > However in the existing code this has been modeled as an Intent > > instance having a list of operations over which the intent could > > apply. Similarly a PolicySet instance has a list of operations to > > which the policyset applies. Is there any specific reason for > > modeling it this way? > > > > I am in progress with changes that change this to what I have > > mentioned in the second paragraph of this mail. If I am heading in > > the wrong direction, could somebody shout please. > > > > Thanks > > > > - Venkat > > > > > > The "Intent -> operations" relationship was modeled like this > intentionally. > > Here's why: > > If you're talking about o.a.t.interfacedef.Operation, then I don't think > it can hold intents. Operation represents a business method/operation on > a business interface, potentially used in multiple Services or > References... with different sets of intents. > > The <operation> element in SCA assembly XML does not represent the > actual operation on the business interface, it is just the syntax used > to group the intents that apply to a given operation, within the context > of a particular service or reference. > > So basically we need to represent the association: > a set of intents -> a set of operations in the context of a particular > service/reference > > There's basically two ways to represent this: > a) In an intent, list the business operations that the intent applies to > or > b) Invent a new object representing an "operation used within the > context of a reference/service", pointing to the actual operation + > listing the intents > > The assembly model being a logical model it does not have to follow the > convolutions of the particular XML syntax, and it seems to me that (a) > is more logical than (b). At least it'll allow us to easily find which > operations a particular intent (and the corresponding interceptors) > applies to. > > Hope this helps. > > -- > Jean-Sebastien
I'm not sure i follow this (though i've barely skimmed over the policy specs so thats no surprise) >From those (a) and (b) above why is (a) more logical? I'd have thought you'd be more likely to be processing a particular Operation instance and be interested in what intents apply to it, and less interested in finding all the operations in a system that use a particular intent. The bit about an Operation instance potentially being used in multiple Services or References with different intents is interesting. Are Operations really shared like this? I've not checked all the code but don't we copy/clone Operations specifically so that doesn't happen? The data binding is also attached to the Operation and that can be different for each Service / Reference so that would also be be a problem if the Operations are shared. ...ant
