Trying to solve the extensibility issues for implementations/bindings
described in ASSEMBLY-177 [1] the recent OASIS 1.1 schema updates
added a new <extensions> element to contracts (service, references,
componentService, componentReference, etc). The idea is that
extensions on contracts should we wrapped under the extensions
element.
Note that, we already had implemented support for extended attributes
and elements (XSD any) and the main use case for this is to allow
tooling to read and write semantically equal SCA XML artifacts (e.g
composite, sca-contribution.xml, etc)... Note that we currently treat
all elements without a registered processor as extended elements.
Well, trying to introduce this new behavior into our existent
extensibility support brings up a interesting scenario.
Consider the component definition below, when a JSON-RPC processor is
NOT available:
<component name="Catalog">
<implementation.java class="services.FruitsCatalogImpl"/>
<property name="currencyCode">USD</property>
<service name="Catalog">
<tuscany:binding.jsonrpc/>
</service>
</component>
With our current behavior, the json-rpc binding element would be
treated as an extensible element, and be written back as a child
element of service same as above.
If we introduce the new behavior, as service is part of contract, then
it should write all extension elements wrapped by an <extensions>
element, producing a semantically different model from what was read
from originally.
<component name="Catalog">
<implementation.java class="services.FruitsCatalogImpl"/>
<property name="currencyCode">USD</property>
<service name="Catalog">
<extensions>
<tuscany:binding.jsonrpc/>
</extensions
</service>
</component>
We need to find a good way to handle these different cases in our
runtime, and I was thinking about couple possibilities:
- One possibility would be to assume all "extensions" child
elements MUST have a processor registered, this would guarantee that
they will have a proper model and should be wrapped by an <extensions>
element when being written back. Regular XSD Any elements would be
handled by the generic processors, thus will produce generic
ExtensionImpl models and should not be wrapped by the <extensions>
element. (I'm trying this solution right now)
- Another way would be to handle them in separate extension lists.
Thoughts ? Other ideas ?
[1] http://www.osoa.org/jira/browse/ASSEMBLY-177
[2] https://issues.apache.org/jira/browse/TUSCANY-3452
--
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/
