ant elder wrote:
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
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
