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]

Reply via email to