Sebastien, thanks for responding. I am still not convinced about Intent instances having links to things in the assembly model. I perceive the Policy module to be independent of any other SCA module (assembly, or interface, ... ).
Also when we are resovling or building the composites, it seems a bit odd to me to go after a PolicyRegistry and get the bunch of all Intents defined for a domain and then run thro each to find the operations that use it. Also I see that there are other decorations as well to the Operation that exists today - one of which is the databinding. So, why wouldn't intents and policy sets simply add on. However if you say that we share instances of Operations across interface definitions, then we probably need to store this map in the InterfaceDef.. or if the InterfaceDef instances are shared then we have look at the next higher level thing that is not shared to manage this information. Am I missing some point here ? - Venkat 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 > > > --------------------------------------------------------------------- > 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]
