[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] [ISSUE 157] Make support for constrainingType anoptional compliance point - Proposal
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]