Re: [sca-assembly] Re: [ASSEMBLY-88] Proposal discussion

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:  

From:
Anish Karmarkar <>

To:
Mike Edwards/UK/IBM@IBMGB

Cc:
OASIS Assembly <>

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.  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>

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>

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

</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>

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.  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?

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.

</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:  

> 

> 

> From:                
 Mike Edwards/UK/IBM@IBMGB

> To:                
 "OASIS Assembly" <>

> 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:  

> 

> 

> 

> 

> 

> ------------------------------------------------------------------------

> 

> /

> /

> 

> /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