Re: [sca-assembly] [ISSUE 157] Make support for constrainingType anoptional compliance point - Proposal

[David Booz <booz@us.ibm.com>]

Anish,
I know you probably won't see this before the telecon today, but I wanted to at least record my thoughts in response to the assertion that an optional constrainingType devalues the feature itself.

It may be true that optionality devalues the feature, but that still misses my main point. I have become convinced that constrainingType is too fine grained to be of significant value (regardless of its optionality in the spec). The value that I am starting to see in templating is in the ability to capture an assembly of components as the template. For lack of a better term, I will call these things implementation templates. At the moment, I am imagining them being captured by something that looks like a composite file. ConstrainingType would allow us to capture the shape of the component that will use one of these templated implementations, but it doesn't do anything to capture the implementation template itself which I believe is where the true value lies. Implementation templates could also be thought of as an aggregation of componentTypes, but that is a somewhat limited perspective because I can imagine implementation templates that would include component implementations as well (i.e. no need for constrainingType). Implementation templates also allow for more powerful capabilty in that they could include some configuration (like wire and policy) that go beyond what constrainingType can do today as a standalone entity. This is what I mean when I say that there are other templating ideas.

Since I don't want to delay the specs trying to specify these implementation templates in this first release, the only step I think we need to take is to loosen the spec on compliance to constrainingType. Given what I said above, constrainingType seems like it would fit in with some of the use cases for implementation templates. That might be true, but it might also turn out to be something that's only used in corner cases or not used at all. In the face of what I see as a much more important templating idea (what I've called implementation templates above), I think we need to be cautious to not back ourselves into a corner by needing to support constrainingType into the future. I am simply being defensive and trying to "protect against the downside" to borrow a term from investing. If constrainingType turns out to be an important facet of implementation templates, then by all means let's require conformance. But until we have our hands around these ideas, I urge caution.

I hope this helps.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Anish Karmarkar ---09/29/2009 02:19:59 AM---The issue [1] states: "I'd like to assert that there may be many different ways to capture the

From:	Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:	Mike Edwards <mike_edwards@uk.ibm.com>
Cc:	OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date:	09/29/2009 02:19 AM
Subject:	Re: [sca-assembly] [ISSUE 157] Make support for constrainingType an optional compliance point - Proposal

---

The issue [1] states:
"I'd like to assert that there may be many different ways to capture the 
top down design of a component or more importantly the design of a set 
(or assembly) of components."

No doubt, top-down can be accomplished in variety of ways that go beyond 
the SCA Assembly spec. But IIRC, the discussion around those ways has 
always been about creating some kind of template that the assembler is 
going to later edit to fill in details. I think there is a significant 
difference between non-deployable/non-conformant templates and "typing" 
support in SCA runtimes. The current design of constrainingType provides 
a way for the top-down designer to design a contract that is enforced by 
the runtime. There is a significant value in that. I understand that 
taking the optional route is sometimes (always?) a nice compromise in a 
design-by-committee venue, but I think in this case, it significantly 
reduces the value of the feature. In the same sense that making 
recursive composition optional would undermine the value of that feature.

Even though I don't like the proposal, I do have a question about it:
Why does the proposal make it OK to ignore constrainingType when not 
supported? I would have thought that it would be the opposite. 
constrainingType is part of the contract, if the runtime doesn't support 
it, it should reject the artifact that contains it rather than ignore it 
and break the contract.

Thanks.

-Anish
--

[1] http://www.osoa.org/jira/browse/ASSEMBLY-157

Mike Edwards wrote:
> 
> Folks,
> 
> Here is a proposal to resolve Issue 157:
> 
> http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/34342/sca-assembly-1.1-spec-cd03-Rev2%2BIssue157.pdf 
> 
> http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/34341/sca-assembly-1.1-spec-cd03-Rev2%2BIssue157.doc 
> 
> 
> 
> 
> 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