Next in thread →
Next in month →
Re: [sca-assembly] Issue 36: resolution proposal
Anish, Many thanks for preparing this. Your proposed text looks pretty good, but as often is the case, I can't resist tampering with the English a bit. There follows my suggested version of the new text: ------------------------------------------------------ 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 derived. 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]) allow for introspecting the implementation artifact(s) (for example, a Java class) to derive the component type information. Other implementation technologies 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. The implementation type specification defines whether introspection is allowed, whether a side file is allowed, or both are allowed. The component type information derived through introspection is called the 'introspected component type'. If both introspection and a side file are allowed, the implementation type specification specifies how the introspected component type information and the side file information are combined to produced the 'effective component type'. The effective component type is the component type metadata that is presented to the using Component for configuration. The extension of a componentType side file name MUST be .componentType. The name and location of a componentType side file, if allowed, is defined by the implementation type specification. If a 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'. ------------------------------------------------------ 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: OASIS Assembly <> Date: 28/10/2008 07:16 Subject: [sca-assembly] 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 --------------------------------------------------------------------- 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
Next in thread →
Next in month →