[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Re: [ASSEMBLY-88] Proposal discussion
Comments inlined below.
-Anish
--
Mike Edwards wrote:
>
> Folks,
>
> Good debate - and the right debate too.
>
> Comments inline
>
> Yours, Mike.
>
> Strategist - Emerging Technologies, SCA & SDO.
> Co Chair OASIS SCA Assembly TC.
> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
> Email: mike_edwards@uk.ibm.com
>
>
> From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
> To: Mike Edwards/UK/IBM@IBMGB
> Cc: OASIS Assembly <sca-assembly@lists.oasis-open.org>
> Date: 25/11/2008 08:20
> Subject: Re: [sca-assembly] Re: [ASSEMBLY-88] Proposal discussion
>
>
> ------------------------------------------------------------------------
>
>
>
> At the risk of rehashing the same discussions from OSOA, allow me to
> disagree.
>
> The reason I opened this issue was because I noticed that <component> is
> not required to have an implementation element. I.e., it can be
> implementation independent. The whole reason for creating
> constrainingType was because componentType (unfortunately choice of
> name)
> *<mje>*
> *Well, I did try to get the name changed to "implementationInfo" but did
> not *
> *get support for that.... ;-)*
> *</mje>*
> is specific to an implementation and *cannot* be shared across
> implementations. This lead to creation of three elements: component,
> constrainingType and componentType, that look very very similar
> syntactically, but serve very different purposes. I'm looking to see if
> we can simplify this *without* removing the functionality that is
> currently provided.
>
> Sharing is critical here.
> *<mje>*
> *Well, sharing between what and what?*
> *You seem to indicate the need to share between one implementation and
> another*
> *implementation.*
>
> *I take a different view. The "sharing" is between an Assembler
> building some*
> *composition and a developer building some component implementation. The*
> *Assembler, like an architect, lays down a pattern that the developer
> must follow.*
>
> *If there are 2 or more implementations that follow the same pattern, it
> is because *
> *they both refer to the same pattern laid down in the composite.
But they don't. There is nothing in the implementation that refers to
the pattern. The pattern is only captured in a composite that uses the
implementation. constrainingType allows one to have a pointer in the
composite (and restrict its shape) and have a pointer in the
implementation and declare what shape it conforms to.
> If you
> really want*
> *a single file containing the pattern, then that can be achieved through
> a composite*
> *file containing a single component containing the pattern, which can be
> used by*
> *include (etc), although personally I doubt that this approach will get
> used much.*
> *</mje>*
I don't understand how this will work. How can the implementation say
that it conforms to a particular pattern?
What I would like to see is declarations made by the implementations and
composites (and CT side files) that can be enforced/checked by the
runtime -- which is what we have right now.
Your proposal does not allow a developer to say the shape(s) that the
implementation conforms to and does not allow a assembler to create a
shape and hand it to developers for implementations.
> It is the usual type-instance difference. You
> want the constrainingType (or something similar) to be created once and
> used by multiple implementations.
> *<mje>*
> *This is *absolutely* possible with my proposal - so as an assembler I
> can lay out*
> *my component requirements and then get 1 implementation in Java today
> and another*
> *implementation in BPEL tomorrow (and one in PHP the day after...).*
> *</mje>*
I must not have groked the proposal correctly. Examples would help.
The way I understand it, the shape is part of the SCDL file per your
proposal. The implementation pointed to is also part of the same SCDL
file. The shape specified is associated with a particular
implementation. It is not independent of the implementation.
If I have two scdl files each containing a different implementation
technology (for that matter this would be true even if it is the same
implementation technology, or even the same implementation artifact), I
have to repeat (and inline) the same shape information in each of the
scdl file. With no information available to say that the shape is
actually the same in both cases.
> If you cared about the shape and not
> about a specific implementation technology then this allows you to
> choose implementations based on the shape and have the SCA runtime
> validate/enforce the shape for you.
> *<mje>*
> *My proposal gives this capability to the assembler*
I don't see how.
One, the assembler has to repeat the shape information for every
instance of use. Unlike the write-once-use-everywhere model, this is a
write-multiple-times-and-keep-your-fingers-crossed model.
Two, you cannot look at the CT of an implementation and figure out if it
matches the shape you have in mind unless you can do the mental
gymnastics of figuring out all the rules of compatibility defined by SCA
for every property, service and reference in that CT.
> *</mje>*
> BTW, one thing missing in your
> proposal is the ability to specific the constrainingType on a
> componentType side file (and by extension in an annotation), which is
> currently allowed (although the constrainingType section does not
> specify this).
> *<mje>*
> *If there really is a requirement to extend this to componentType side
> files (and I*
> *have doubts about the need for that), then a simple @constrained
> attribute on the*
> *componentType could be used, with semantics matching those of
> @constrained*
> *on the <component/>.*
> *</mje>*
I believe this capability already exists in the schema (wrt
constrainingType).
If the semantics match those of the component, and given the fact that
there can be only one CT per implementation, it would defeat the
purpose. The purpose being: an implementation should be allows to signal
that it conforms to a particular shape or shapes -- but may provide
additional things in conformance with the optionality clause.
>
> The solution that I had in mind was to make sca:component a GED and
> allow that to be reused as a constraining type when it does not contain
> the <implementation> element. This would not remove the constrainingType
> attribute, but allow us to remove the constrainingType GED.
> *<mje>*
> *This idea is more directed at supporting a different functionality
> altogether.
Not really. This is the functionality that *is* currently supported by
constrainingType. The proposal you have is providing a different
functionality, which I don't quite get.
> It is not*
> *sharing between assembler and developer, but rather to provide sharing
> across the*
> *composites that the assembler is creating (ie componentA and componentB
> are*
> *supposed to share a pattern). Is this important?*
Yes. Reusable shape files is critical.
>
> *As for making a component a GED, this raises the concern about having
> to make*
> *a reference to a component a QName rather than the current URI, with
> all the hassles*
> *that include processing brings. I feel very uncomfortable about that
> direction.*
I think this is a fair criticism. I had not realized this impact of
making it a GED.
You are quite right that this would require us to include a
'targetNamespace' attribute on the 'component' element and restrict its
use only when it is the root element. Little ugly. I don't like it either.
> *</mje>*
>
> Comments?
>
> -Anish
> --
>
> Mike Edwards wrote:
> >
> > Folks,
> >
> > I was somewhat surprised by some of the reaction to the proposal made
> > below to resolve issue 88 in the TC call yesterday.
> >
> > I take the view that the proposal gives the functionality required by a
> > designer at minimal cost and
> > is in fact considerably simpler than the current design involving a
> > separate data structure in a separate file.
> >
> > My view is that the functionality that is required here is that the
> > assembler - the creator of composites in a top-down scenario -
> > can restrict what a developer ("implementation creator") is able to do,
> > so that a particular composition "does what it says on
> > the tin" - and no more.
> >
> > It seems to me that the simple marking I propose does exactly this - and
> > with minimal effort.
> >
> > A point was made that by having a separate file contain the data
> > structure used for constraining, that this could be reused, seems
> > far from the reality of the development experience for the assembler and
> > is not a feature that is likely to get much use. Frankly,
> > it is much easier to copy the configuration of a component from one
> > place to another, if that is required, than it is to point each
> > component to a shared file. And I note that in the case where a shared
> > file is used, it is STILL necessary to lay out the contents
> > of the component structure in order to perform the actual configuration
> > of that component - so there is still real duplication that
> > just gets in the way of the assembler.
> >
> > So I argue that a separate "constrainingType" file is actually an
> > unnecessary overhead of little benefit. The proposal below
> > gives the assembler all the real control that is necessary - and at
> > minimum cost.
> >
> >
> > If true sharing IS required, then it is more obvious to use the
> > <include/> capability and reuse the complete definition of a
> > component which is structured for reuse (eg - all services declared,
> > references declared but left unwired). This is more
> > meaningful than sharing some constrainingType file.
> >
> >
> > Yours, Mike.
> >
> > Strategist - Emerging Technologies, SCA & SDO.
> > Co Chair OASIS SCA Assembly TC.
> > IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> > Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
> > Email: mike_edwards@uk.ibm.com
> >
> >
> > From: Mike Edwards/UK/IBM@IBMGB
> > To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
> > Date: 18/11/2008 15:10
> > Subject: [sca-assembly] [ASSEMBLY-88] Possible
> duplicate functionality
> > offered by constrainingType and component - proposed resolution
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> >
> > This is a proposal to resolve Issue 88.
> >
> > Summary:
> > - remove constrainingType from the specification
> > - add an attribute to <component/> called @constrained which is a
> > boolean value with a default of "false"
> >
> > - a <component/> with constrained=false is just like a component today -
> > no changes
> > - a <component/> with constrained=true requires its implementation to
> > follow rules similar to those for
> > constrainingType - namely:
> >
> > "When the component using an implementation has @constrained=true the
> > implementation's component type
> > MUST contain all the services, references and properties explicitly
> > declared by the component. The component’s
> > references and services can have interfaces specified and can have
> > intents specified - the implementation's
> > service interfaces must be the same or a superset and its reference
> > interfaces must the the same or a subset, while
> > any intents present in the componentType must match those declared by
> > the component.. An implementation MAY
> > contain additional services, additional optional references
> > (multiplicity 0..1 or 0..n) and additional optional properties
> > beyond those declared by the component, but MUST NOT contain additional
> > non-optional references
> > (multiplicity 1..1 or 1..n) or additional non-optional properties (a
> > property with mustSupply=true). (and any such references
> > will not be wired and any such properties will not be configured by the
> > component). Any services in the componentType
> > which are not also declared by the component cannot be wired or promoted"
> >
> > I believe that this allows a component to control what its
> > implementations MUST look like, which is the idea behind
> > constrainingType.
> >
> > Detailed changes:
> >
> >
> >
> > Yours, Mike.
> >
> > Strategist - Emerging Technologies, SCA & SDO.
> > Co Chair OASIS SCA Assembly TC.
> > IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> > Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
> > Email: mike_edwards@uk.ibm.com
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > /
> > /
> >
> > /Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU/
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
>
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]