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/10/04 19:19:03 UTC
Adding intents and policy sets to JavaImplementation instances
Hi,
As I am extending policy support for implementations I realize that we have
trouble with aggregating intents and policysets in an JavaImplementation
instance. The reason for this is that JavaImplementation instances could be
reused in cases where two or more components provide services thro the same
implementation.
There is also a JIRA -
https://issues.apache.org/jira/browse/TUSCANY-1765that talks of this
problem with a nice example. The JIRA has a patch that
solves the issue to some extent and not entirely.
If JavaImplementaition instances are going to be reused when the same
implemenation is used by two or more components, then we need an alternative
to store the intents / policy sets so that they are unique for each
component. Take for example
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="CompositeX">
<component name="ComponentA" requires="managedTransaction.none">
<implementation.java class="test.DataServiceImpl" />
</component>
<component name="ComponentB" requires="managedTransaction.global">
<implementation.java class="test.DataServiceImpl" r/>
</component>
</composite>
Here there is going to be a single instance of JavaImplementation that will
be used for both components. But it happens that both these components have
different intents defined and these intents will be inherited by the
implementations. At the present moment I can only think of storing this
info in the Component but I am absolutely uncomfortable with this pollutes
the assembly model design for 'Component'. Any other ideas that folks can
suggest for this ?
Thanks
- Venkat
Re: Adding intents and policy sets to JavaImplementation instances
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
Thinking a bit further with this.. how about the following approach : -
- The Component model has additional fields called 'implPolicies' and
'implOpPolicies'. 'implPolicies' will capture the intents and policysets
directly defined on an implementation element that the component uses.
'implOpPolicies' is a map that is keyed on the implementation Operations.
If policies have been specified for specific operations in an implemenation,
such intents and policysets will be stored in this map against each
operation.
- Now the problem is, its the implementation processors that will read up
the intents and policysets defined on an implementation element. Would they
continue to read them up and store in the implemenation model ? Will we
then copy this into the component ? Or should we come up with some sort of
a 'context' object that we should be able to pass to the 'read' method of
stax processors whereby the stax processors may use information in the
context or may set some information into this context object ?
Thanks
- Venkat
On 10/9/07, Venkata Krishnan <fo...@gmail.com> wrote:
>
> Hi Sebastien,
>
> Please find my comments inline. Thanks.
>
> - Venkat
>
> On 10/9/07, Jean-Sebastien Delfino < jsdelfino@apache.org> wrote:
> >
> > Venkata Krishnan wrote:
> > > Hi,
> > >
> > > As I am extending policy support for implementations I realize that we
> > have
> > > trouble with aggregating intents and policysets in an
> > JavaImplementation
> > > instance. The reason for this is that JavaImplementation instances
> > could be
> > > reused in cases where two or more components provide services thro the
> > same
> > > implementation.
> > >
> > > There is also a JIRA -
> > > https://issues.apache.org/jira/browse/TUSCANY-1765that talks of this
> > > problem with a nice example. The JIRA has a patch that
> > > solves the issue to some extent and not entirely.
> > >
> > > If JavaImplementaition instances are going to be reused when the same
> > > implemenation is used by two or more components, then we need an
> > alternative
> > > to store the intents / policy sets so that they are unique for each
> > > component. Take for example
> > >
> > > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0 "
> > name="CompositeX">
> > > <component name="ComponentA" requires="managedTransaction.none">
> > > <implementation.java class="test.DataServiceImpl" />
> > > </component>
> > > <component name="ComponentB" requires="managedTransaction.global">
> > > <implementation.java class="test.DataServiceImpl" r/>
> > > </component>
> > > </composite>
> > >
>
>
> This is what I meant - to highlight the case where implementations inherit
> intent specified in it ancestor elements i.e. the component and composite
> elements.
>
> Are you sure that this is what you meant in the example? or did you mean:
> >
> > <component name="ComponentA">
> > <implementation.java class="test.DataServiceImpl" requires="
> > managedTransaction.none"/>
> > </component>
> > <component name="ComponentB">
> > <implementation.java class="test.DataServiceImpl" requires="
> > managedTransaction.global"/>
> > </component>
> >
> >
> > > Here there is going to be a single instance of JavaImplementation that
> > will
> > > be used for both components. But it happens that both these
> > components have
> > > different intents defined and these intents will be inherited by the
> > > implementations. At the present moment I can only think of storing
> > this
> > > info in the Component but I am absolutely uncomfortable with this
> > pollutes
> > > the assembly model design for 'Component'. Any other ideas that folks
> > can
> > > suggest for this ?
> > >
> > > Thanks
> > >
> > > - Venkat
> > >
> >
> > Intents and policySets specified in component/implementation should not
> > be stored in the Implementation model as they actually configure the
> > Component and not the Implementation (as reported in JIRA 1765).
>
>
> Yes and I understand your point. But the specs allows for intents and
> policysets to be specified directly against implementation elements. So
> when we load/read an implementation element from an SCDL it seems we have no
> other option but to store this information in the implementation model which
> is the only model object we are dealing with when reading up this element.
>
> Storing them in the Component model makes more sense to me, what wrong
> > with doing that?
>
>
> Well :), could we add one more field like 'implIntents' and
> 'implPolicySets' to capture the intents and policies specified for the
> implementation that this component uses ? I wonder how far we could go with
> this approach in case the specs decides to add more embellishments to the
> implementation element.
>
> By the way, we have the same issue with 'Operations' as well. We need to
> deal with intents that could be specified for Operations under
> implementation, services and reference elements.
>
> --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: Adding intents and policy sets to JavaImplementation instances
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Sebastien,
Please find my comments inline. Thanks.
- Venkat
On 10/9/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Venkata Krishnan wrote:
> > Hi,
> >
> > As I am extending policy support for implementations I realize that we
> have
> > trouble with aggregating intents and policysets in an JavaImplementation
> > instance. The reason for this is that JavaImplementation instances
> could be
> > reused in cases where two or more components provide services thro the
> same
> > implementation.
> >
> > There is also a JIRA -
> > https://issues.apache.org/jira/browse/TUSCANY-1765that talks of this
> > problem with a nice example. The JIRA has a patch that
> > solves the issue to some extent and not entirely.
> >
> > If JavaImplementaition instances are going to be reused when the same
> > implemenation is used by two or more components, then we need an
> alternative
> > to store the intents / policy sets so that they are unique for each
> > component. Take for example
> >
> > <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="CompositeX">
> > <component name="ComponentA" requires="managedTransaction.none">
> > <implementation.java class="test.DataServiceImpl" />
> > </component>
> > <component name="ComponentB" requires="managedTransaction.global">
> > <implementation.java class="test.DataServiceImpl" r/>
> > </component>
> > </composite>
> >
This is what I meant - to highlight the case where implementations inherit
intent specified in it ancestor elements i.e. the component and composite
elements.
Are you sure that this is what you meant in the example? or did you mean:
>
> <component name="ComponentA">
> <implementation.java class="test.DataServiceImpl" requires="
> managedTransaction.none"/>
> </component>
> <component name="ComponentB">
> <implementation.java class="test.DataServiceImpl" requires="
> managedTransaction.global"/>
> </component>
>
>
> > Here there is going to be a single instance of JavaImplementation that
> will
> > be used for both components. But it happens that both these components
> have
> > different intents defined and these intents will be inherited by the
> > implementations. At the present moment I can only think of storing this
> > info in the Component but I am absolutely uncomfortable with this
> pollutes
> > the assembly model design for 'Component'. Any other ideas that folks
> can
> > suggest for this ?
> >
> > Thanks
> >
> > - Venkat
> >
>
> Intents and policySets specified in component/implementation should not
> be stored in the Implementation model as they actually configure the
> Component and not the Implementation (as reported in JIRA 1765).
Yes and I understand your point. But the specs allows for intents and
policysets to be specified directly against implementation elements. So
when we load/read an implementation element from an SCDL it seems we have no
other option but to store this information in the implementation model which
is the only model object we are dealing with when reading up this element.
Storing them in the Component model makes more sense to me, what wrong
> with doing that?
Well :), could we add one more field like 'implIntents' and 'implPolicySets'
to capture the intents and policies specified for the implementation that
this component uses ? I wonder how far we could go with this approach in
case the specs decides to add more embellishments to the implementation
element.
By the way, we have the same issue with 'Operations' as well. We need to
deal with intents that could be specified for Operations under
implementation, services and reference elements.
--
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Adding intents and policy sets to JavaImplementation instances
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Hi,
>
> As I am extending policy support for implementations I realize that we have
> trouble with aggregating intents and policysets in an JavaImplementation
> instance. The reason for this is that JavaImplementation instances could be
> reused in cases where two or more components provide services thro the same
> implementation.
>
> There is also a JIRA -
> https://issues.apache.org/jira/browse/TUSCANY-1765that talks of this
> problem with a nice example. The JIRA has a patch that
> solves the issue to some extent and not entirely.
>
> If JavaImplementaition instances are going to be reused when the same
> implemenation is used by two or more components, then we need an alternative
> to store the intents / policy sets so that they are unique for each
> component. Take for example
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="CompositeX">
> <component name="ComponentA" requires="managedTransaction.none">
> <implementation.java class="test.DataServiceImpl" />
> </component>
> <component name="ComponentB" requires="managedTransaction.global">
> <implementation.java class="test.DataServiceImpl" r/>
> </component>
> </composite>
>
Are you sure that this is what you meant in the example? or did you mean:
<component name="ComponentA">
<implementation.java class="test.DataServiceImpl" requires="managedTransaction.none"/>
</component>
<component name="ComponentB">
<implementation.java class="test.DataServiceImpl" requires="managedTransaction.global"/>
</component>
> Here there is going to be a single instance of JavaImplementation that will
> be used for both components. But it happens that both these components have
> different intents defined and these intents will be inherited by the
> implementations. At the present moment I can only think of storing this
> info in the Component but I am absolutely uncomfortable with this pollutes
> the assembly model design for 'Component'. Any other ideas that folks can
> suggest for this ?
>
> Thanks
>
> - Venkat
>
Intents and policySets specified in component/implementation should not
be stored in the Implementation model as they actually configure the
Component and not the Implementation (as reported in JIRA 1765).
Storing them in the Component model makes more sense to me, what wrong
with doing that?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org