Hi Sebastien, thanks for that explanation. I get your point. For now I'd revert back those changes to 'Operation' and will figure out an alternative.
- Venkat On 8/10/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Venkata Krishnan wrote: > > 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, ... ). > > > > > I just responded to some of these in a response to Ant's email in the > same thread. I think I covered your questions there. > > All of this can probably be summarized as: > > If you're not convinced that Intent should point to interface/operation, > try to draw a parallel with how service/reference point to interface. > > or > > An intent configures a particular use of an interface/operation.... (so > it should point to that operation...) > > > 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. > > > > Because Databindings should not be doing this in the first place :) > > > 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 > > > > The models are currently using lists and I'd suggest to continue on the > same path. > > If you really wanted to switch the relationship around, I think you'd > have to come up with a new model object containing pointers to > interface, operation, and the list of intents that apply to it. Then try > to give a meaningful name to that object, if you can't find a good name > for it, maybe that's because it's just too artificial and does not > represent a real entity in the model but instead a disguised > relationship? ... which is simply represented at the moment as an Intent > -> Operation pointer.... I'll let you think about it :) > > > 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 > >> > >> > >> > -- > 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]
