You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Venkata Krishnan <fo...@gmail.com> on 2007/08/09 14:37:06 UTC
Intent and Policy attachments on Operations
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Intent and Policy attachments on Operations
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 8/9/07, Jean-Sebastien Delfino <js...@apache.org> 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
>
Here's a few more thoughts.
First with respect to interface/operation sharing:
- Interfaces are shared by multiple services/references (i.e. two
services can share the same Java interface and therefore the same
JavaInterface model object)
- Operations belong to interfaces so they are shared as well
- Similarly (to help illustrate my point), implementations are shared by
multiple components
The code which has recently been checked in, which starts to tie intents
to an interface will break as soon as two services use the same
interface with different polices.
Now what's the most logical way to represent policies?
- My understanding is that policies are used to express configuration of
services, references and implementations. They are similar to
service/reference bindings (which configure protocols used to talk to an
interface), or component declarations (which configure properties of an
implementation). They configure the QOS to use when to talk through an
interface or to a component implementation.
How are we representing service/reference bindings and components today?
- Services/references (+ the binding they contain) logically point to
interfaces, the service/reference effectively do, the binding does not
need to do it explicitly and duplicate that relationship because it's
contained in a service/reference
- Component declarations point to implementations
Following the same pattern...
- Intents and policysets should point to interfaces, like a binding an
intent does not need to point explicitly point to the interface because
it's known from the service/reference that contains it, but it needs to
distinguish which operation it applies to.
If you're still not convinced or have a better way to represent the
intent <-> operation relationship, maybe you should try for yourself and
come up with a set of model interfaces that represent the correct
containment and cardinalities, and we can take a look then.
Finally, about Databindings, it's funny that you mention that, because I
spent some time in that space the last two days (trying to load them
dynamically) and realized that they are currently tied to an interface /
operation. That's not right either as it will prevent using two
different databindings for the same shared (XSD) type. We might get
lucky with Java types as all usages of a Java type will use the same
databinding (as it's determined by the Java class itself), but for XSD
types, we need to fix that and untie the DataBinding from the DataType
definition.
So basically, same issue with DataBindings, they should not be tied to
the interface/operation either :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Intent and Policy attachments on Operations
Posted by ant elder <an...@gmail.com>.
On 8/9/07, Jean-Sebastien Delfino <js...@apache.org> 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
Re: Intent and Policy attachments on Operations
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <js...@apache.org> 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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Intent and Policy attachments on Operations
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Intent and Policy attachments on Operations
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Intent and Policy attachments on Operations
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org