OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue 36: resolution proposal


At the last f2f [1] we decided on a direction for resolution of issue 36 
[2]. The direction was the following:

-----
Each C&I specifies (1) if a CT side file(s) is allowed (2) if 
introspection is allowed, (3) name and location of side files(s) (4) 
compatibility between introspected CT and side file(s), (5) how the 
effective CT of an implementation is derived. SCA Assembly only cares 
about the effective CT. Each implementation has an (effective) CT, 
specified by sca:ComponentType, how that is arrived at depends on the 
implementation type.
-----

Based on this direction, here is a proposal to resolve issue 36:

Currently, section 4.1 says the following -

-----
Component type represents the configurable aspects of an implementation. 
A component type consists of services that are offered, references to 
other services that can be wired and properties that can be set. The 
settable properties and the settable references to services are 
configured by a component which uses the implementation.  The component 
type is calculated in two steps where the second step adds to the 
information found in the first step. Step one is introspecting the 
implementation (if possible), including the inspection of implementation 
annotations (if available). Step two covers the cases where 
introspection of the implementation is not possible or where it does not 
provide complete information and it involves looking for an SCA 
component type file. Component type information found in the component 
type file must be compatible with the equivalent information found from 
inspection of the implementation. The component type file can specify 
partial information, with the remainder being derived from the 
implementation.

In the ideal case, the component type information is determined by 
inspecting the implementation, for example as code annotations. The 
component type file provides a mechanism for the provision of component 
type information for implementation types where the information cannot 
be determined by inspecting the implementation.

The component type is defined by a componentType element in the 
componentType file. The extension of a componentType file MUST be 
.componentType and its name and location depends on the type of the 
component implementation: the specifics are described in the respective 
client and implementation model specification for the implementation type.

[followed by the pseudo-schema and its explanation]
-----

Replace this with -

-----
Component type represents the configurable aspects of an implementation. 
A component type consists of services that are offered, references to 
other services that can be wired and properties that can be set. The 
settable properties and the settable references to services are 
configured by a component which uses the implementation.

An implementation type specification (for example, the WS-BPEL Client 
and Implementation Specification Version 1.1 [ref]) specifies the 
mechanism(s) by which the component type associated with an 
implementation of that type is calculated.

Since SCA allows a broad range of implementation technologies, it is 
expected that some implementation technologies (for example, the Java 
Client and Implementation Specification Version 1.1 [ref]) will allow 
for introspecting the implementation artifact(s) (for example, a Java 
class) to calculate the component type information. Others may not allow 
for introspection of the implementation artifact(s). In those cases 
where introspection is not allowed, SCA encourages the use of a SCA 
component type side file.

A component type side file is an XML file whose document root element is 
sca:componentType. An implementation type specification specifics 
whether introspection is allowed, side file is allowed, or both are 
allowed. The component type information derived through introspection is 
called 'introspected component type'. If both introspection and side 
file are allowed, the implementation type specification specifies how 
the introspected component type information and the side file 
information is combined/overridden to produced the 'effective component 
type'.  The extension of the componentType side file name MUST be 
.componentType. The name and location of componentType side file, if 
allowed, is specified by the implementation type specification.

If component type side file is not allowed for a particular 
implementation type, the effective component type and introspected 
component type are one and the same for that implementation type.

For the rest of this document, when the term 'component type' is used it 
refers to the 'effective component type'.

[followed by the pseudo-schema and its explanation]
-----

Comments?

-Anish
--

[1] 
http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/29733/SCA%20Assembly%20minutes%202008-09-30.html#d1e223
[2] http://www.osoa.org/jira/browse/ASSEMBLY-36


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]