You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Mark I. Dinges" <mi...@gmail.com> on 2007/03/09 16:26:39 UTC
requires and policySets attribute support
Another person and I are starting to add support for requires and
policySets attributes to the various elements in the model. One possible
direction we are considering is to have those model objects that
support requires and policySets attributes extend the
PolicyAttachableModel object. To this object a method would be added to
handle extracting the requires and policySets attributes and would save
them. Another option would be to have an instance of a
PolicyAttachableModel object in each of the model objects that support
the requires and policySets attributes. Does the community have a
preference for either of these options or have a suggestion for another
option? During the build phase the attributes would be processed from
the model. This is where the reduction and checking for conflicts would
take place. Methods would be added to AbstractSCAObject to add/get
intents and policsySets.This would make it so that the various
implementations of the model would inherit them.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: requires and policySets attribute support
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Mark I. Dinges wrote:
> When processing the intents at each level and putting them into the
> model. Would it be a better idea to push them the whole way down to
> the operation model object or to leave them at the various levels in
> the model and have the merge of the intents performed later?
>
> Jean-Sebastien Delfino wrote:
>> Mark I. Dinges wrote:
>>> I was going to start working on the annotation processing for
>>> @Requires. Has anyone started working on it yet? Looking at the
>>> current processing of the DataType annotation, it looks like we want
>>> to create a PolicyJavaInterfaceProcessor class and register it with
>>> the JavaInterfaceProcessorRegistryImpl. This way it will be call
>>> during the introspection of the Java implementation.
>>> PolicyJavaInterfaceProcessor would handle the @Requires and
>>> @PolicySets annotations. Initial implementation will only handle the
>>> @Requires. Any suggestions, comments, or recommendations?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>> I don't think that anyone has started to work on this, so Thanks for
>> volunteering :)
>>
>> What you describe sounds good to me. I suggest to implement this in a
>> self contained policy annotation support module as it'll make it
>> easier to integrate.
>>
>> You may want to check the Intent class as I'm not sure it's in sync
>> yet with the SCA 1.0 spec.
>>
>> You'll need to handle both interfaces and implementation classes,
>> which both can have @Requires. I would expect @Requires on a Java
>> implementation class and its interfaces to translate to Intent
>> metadata in the ComponentType model describing the implementation.
>>
>> A Java interface can also be specified in a service or reference for
>> a particular component (independent of the implementation class and
>> the interfaces it implements). You may have to handle that too and
>> translate @Requires to Intent metadata in the Component model
>> describing the particular component (somehow refining the Intents
>> specified on the implementation). This is something to investigate as
>> I couldn't find a clear description of the behavior in this case in
>> the SCA Java C&I spec.
>>
>> Let us know if you run into any issues or questions.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Mark,
I would suggest to start with a model as an accurate representation of
the input assembly (without pushing intents down to the operation level,
and also without trying to reconcile intents at the constrainingType,
componentType, implementation, component, composite level), and defer
the determination of the intents at each concrete operation level to a
later point, to the runtime build phase for example. This will avoid
duplication of the intent info at each level and will give you the
ability to determine the actual intents with all the info from the
various places (the 5 levels I listed above) in hand, later.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: requires and policySets attribute support
Posted by "Mark I. Dinges" <mi...@gmail.com>.
When processing the intents at each level and putting them into the
model. Would it be a better idea to push them the whole way down to the
operation model object or to leave them at the various levels in the
model and have the merge of the intents performed later?
Jean-Sebastien Delfino wrote:
> Mark I. Dinges wrote:
>> I was going to start working on the annotation processing for
>> @Requires. Has anyone started working on it yet? Looking at the
>> current processing of the DataType annotation, it looks like we want
>> to create a PolicyJavaInterfaceProcessor class and register it with
>> the JavaInterfaceProcessorRegistryImpl. This way it will be call
>> during the introspection of the Java implementation.
>> PolicyJavaInterfaceProcessor would handle the @Requires and
>> @PolicySets annotations. Initial implementation will only handle the
>> @Requires. Any suggestions, comments, or recommendations?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> I don't think that anyone has started to work on this, so Thanks for
> volunteering :)
>
> What you describe sounds good to me. I suggest to implement this in a
> self contained policy annotation support module as it'll make it
> easier to integrate.
>
> You may want to check the Intent class as I'm not sure it's in sync
> yet with the SCA 1.0 spec.
>
> You'll need to handle both interfaces and implementation classes,
> which both can have @Requires. I would expect @Requires on a Java
> implementation class and its interfaces to translate to Intent
> metadata in the ComponentType model describing the implementation.
>
> A Java interface can also be specified in a service or reference for a
> particular component (independent of the implementation class and the
> interfaces it implements). You may have to handle that too and
> translate @Requires to Intent metadata in the Component model
> describing the particular component (somehow refining the Intents
> specified on the implementation). This is something to investigate as
> I couldn't find a clear description of the behavior in this case in
> the SCA Java C&I spec.
>
> Let us know if you run into any issues or questions.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [Spec related] @Requires on interfaces specified in component services, was: requires and policySets attribute support
Posted by scabooz <sc...@gmail.com>.
Hi Sebastien,
I don't see any other replies, and I feel like I'm being tricked in
some way....
First, let me say that this could be more clearly described. However,
there is a precedent in the WSDL extension for @requires. It is
described in section 1.5.4 of the assembly spec. When applied to
this case, you get:
Use of the @requires annotation in this example is the same as:
<service name="CustomerInfoService" requires="confidentiality.message">
<interface.java interface="CustomerInfo"/>
</service>
So the answer is yes.
Dave
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Thursday, March 15, 2007 2:44 AM
Subject: [Spec related] @Requires on interfaces specified in component
services, was: requires and policySets attribute support
> [snip]
> Jean-Sebastien Delfino wrote:
>>
>> You'll need to handle both interfaces and implementation classes, which
>> both can have @Requires. I would expect @Requires on a Java
>> implementation class and its interfaces to translate to Intent metadata
>> in the ComponentType model describing the implementation.
>>
>> A Java interface can also be specified in a service or reference for a
>> particular component (independent of the implementation class and the
>> interfaces it implements). You may have to handle that too and translate
>> @Requires to Intent metadata in the Component model describing the
>> particular component (somehow refining the Intents specified on the
>> implementation). This is something to investigate as I couldn't find a
>> clear description of the behavior in this case in the SCA Java C&I spec.
>>
>> Let us know if you run into any issues or questions.
>>
>
> Could anyone working on this particular aspect of the policy and Java C&I
> spec help shed some light on the use case I outlined above? What happens
> if I do the following:
>
> <component name="CustomerInfoComponent">
> <service name="CustomerInfoService">
> <interface.java interface="CustomerInfo"/>
> </service>
> <implementation.java class="CustomerInfoImpl"/>
> </component>
>
> @Requires(CONFIDENTIALITY.MESSAGE)
> interface CustomerInfo {
> ... retrieveCustomer(...);
> }
>
> class CustomerInfoImpl implements CustomerInfo {
> ... retrieveCustomer(...);
> }
>
> Does this make the confidentiality/message policy intent effective for
> service CustomerInfoService or not?
>
> Thanks
>
> --
> 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
[Spec related] @Requires on interfaces specified in component services,
was: requires and policySets attribute support
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Jean-Sebastien Delfino wrote:
>
> You'll need to handle both interfaces and implementation classes,
> which both can have @Requires. I would expect @Requires on a Java
> implementation class and its interfaces to translate to Intent
> metadata in the ComponentType model describing the implementation.
>
> A Java interface can also be specified in a service or reference for a
> particular component (independent of the implementation class and the
> interfaces it implements). You may have to handle that too and
> translate @Requires to Intent metadata in the Component model
> describing the particular component (somehow refining the Intents
> specified on the implementation). This is something to investigate as
> I couldn't find a clear description of the behavior in this case in
> the SCA Java C&I spec.
>
> Let us know if you run into any issues or questions.
>
Could anyone working on this particular aspect of the policy and Java
C&I spec help shed some light on the use case I outlined above? What
happens if I do the following:
<component name="CustomerInfoComponent">
<service name="CustomerInfoService">
<interface.java interface="CustomerInfo"/>
</service>
<implementation.java class="CustomerInfoImpl"/>
</component>
@Requires(CONFIDENTIALITY.MESSAGE)
interface CustomerInfo {
... retrieveCustomer(...);
}
class CustomerInfoImpl implements CustomerInfo {
... retrieveCustomer(...);
}
Does this make the confidentiality/message policy intent effective for
service CustomerInfoService or not?
Thanks
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: requires and policySets attribute support
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Mark I. Dinges wrote:
> I was going to start working on the annotation processing for
> @Requires. Has anyone started working on it yet? Looking at the
> current processing of the DataType annotation, it looks like we want
> to create a PolicyJavaInterfaceProcessor class and register it with
> the JavaInterfaceProcessorRegistryImpl. This way it will be call
> during the introspection of the Java implementation.
> PolicyJavaInterfaceProcessor would handle the @Requires and
> @PolicySets annotations. Initial implementation will only handle the
> @Requires. Any suggestions, comments, or recommendations?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
I don't think that anyone has started to work on this, so Thanks for
volunteering :)
What you describe sounds good to me. I suggest to implement this in a
self contained policy annotation support module as it'll make it easier
to integrate.
You may want to check the Intent class as I'm not sure it's in sync yet
with the SCA 1.0 spec.
You'll need to handle both interfaces and implementation classes, which
both can have @Requires. I would expect @Requires on a Java
implementation class and its interfaces to translate to Intent metadata
in the ComponentType model describing the implementation.
A Java interface can also be specified in a service or reference for a
particular component (independent of the implementation class and the
interfaces it implements). You may have to handle that too and translate
@Requires to Intent metadata in the Component model describing the
particular component (somehow refining the Intents specified on the
implementation). This is something to investigate as I couldn't find a
clear description of the behavior in this case in the SCA Java C&I spec.
Let us know if you run into any issues or questions.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: requires and policySets attribute support
Posted by "Mark I. Dinges" <mi...@gmail.com>.
I was going to start working on the annotation processing for @Requires.
Has anyone started working on it yet? Looking at the current processing
of the DataType annotation, it looks like we want to create a
PolicyJavaInterfaceProcessor class and register it with the
JavaInterfaceProcessorRegistryImpl. This way it will be call during the
introspection of the Java implementation. PolicyJavaInterfaceProcessor
would handle the @Requires and @PolicySets annotations. Initial
implementation will only handle the @Requires. Any suggestions,
comments, or recommendations?
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: requires and policySets attribute support
Posted by haleh mahbod <hm...@gmail.com>.
thanks
On 3/9/07, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Mar 9, 2007, at 9:44 AM, haleh mahbod wrote:
>
> > What happens in a single node case? Will the controller always be
> > present?
>
> A single-VM or runtime physical topology is just a degenerate case of
> the distributed one. In other words, the controller and slave will
> happen to be in the same runtime.
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: requires and policySets attribute support
Posted by Jim Marino <jm...@myromatours.com>.
On Mar 9, 2007, at 9:44 AM, haleh mahbod wrote:
> What happens in a single node case? Will the controller always be
> present?
A single-VM or runtime physical topology is just a degenerate case of
the distributed one. In other words, the controller and slave will
happen to be in the same runtime.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: requires and policySets attribute support
Posted by Jeremy Boynes <jb...@apache.org>.
On Mar 9, 2007, at 9:44 AM, haleh mahbod wrote:
> What happens in a single node case? Will the controller always be
> present?
Yes - just co-located with its sole runtime.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: requires and policySets attribute support
Posted by haleh mahbod <hm...@gmail.com>.
What happens in a single node case? Will the controller always be present?
On 3/9/07, Jim Marino <jm...@myromatours.com> wrote:
>
>
> On Mar 9, 2007, at 8:07 AM, Jeremy Boynes wrote:
>
> > Subclassing in the model makes sense to me.
> >
> > I don't think anything would need to be added to AbstractSCAObject
> > - by the time we get to the runtime all of the intents and
> > policySets should have been processed and converted into wires with
> > the necessary interceptors.
> Just to add a little more detail in terms of the ongoing federation
> work...In the SCA Domain, there will be a "controller" and "slave"
> nodes. The controller will be responsible for performing a number of
> tasks, including construction of of wire definitions and allocation
> of components to slave nodes in the SCA Domain. The controller will
> be responsible for constructing wire definitions, including target
> resolution and designation of interceptor types. The designation of
> interceptor types would include policy.
>
> After this process, component and wire definitions are sent to the
> appropriate slave where they are "built" into runtime artifacts.
>
> To start off, I'd take a look at some of the policy model we
> currently have (incomplete) and we can iterate from there.
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: requires and policySets attribute support
Posted by Jim Marino <jm...@myromatours.com>.
On Mar 9, 2007, at 8:07 AM, Jeremy Boynes wrote:
> Subclassing in the model makes sense to me.
>
> I don't think anything would need to be added to AbstractSCAObject
> - by the time we get to the runtime all of the intents and
> policySets should have been processed and converted into wires with
> the necessary interceptors.
Just to add a little more detail in terms of the ongoing federation
work...In the SCA Domain, there will be a "controller" and "slave"
nodes. The controller will be responsible for performing a number of
tasks, including construction of of wire definitions and allocation
of components to slave nodes in the SCA Domain. The controller will
be responsible for constructing wire definitions, including target
resolution and designation of interceptor types. The designation of
interceptor types would include policy.
After this process, component and wire definitions are sent to the
appropriate slave where they are "built" into runtime artifacts.
To start off, I'd take a look at some of the policy model we
currently have (incomplete) and we can iterate from there.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: requires and policySets attribute support
Posted by Jeremy Boynes <jb...@apache.org>.
Subclassing in the model makes sense to me.
I don't think anything would need to be added to AbstractSCAObject -
by the time we get to the runtime all of the intents and policySets
should have been processed and converted into wires with the
necessary interceptors.
--
Jeremy
On Mar 9, 2007, at 7:26 AM, Mark I. Dinges wrote:
> Another person and I are starting to add support for requires and
> policySets attributes to the various elements in the model. One
> possible direction we are considering is to have those model
> objects that support requires and policySets attributes extend the
> PolicyAttachableModel object. To this object a method would be
> added to handle extracting the requires and policySets attributes
> and would save them. Another option would be to have an instance of
> a PolicyAttachableModel object in each of the model objects that
> support the requires and policySets attributes. Does the community
> have a preference for either of these options or have a suggestion
> for another option? During the build phase the attributes would be
> processed from the model. This is where the reduction and checking
> for conflicts would take place. Methods would be added to
> AbstractSCAObject to add/get intents and policsySets.This would
> make it so that the various implementations of the model would
> inherit them.
>
> ---------------------------------------------------------------------
> 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