Next in thread → Next in month →

Re: [sca-assembly] Issue 36: resolution proposal

From
Mike Edwards <>
Date
2008-10-28T10:32:28+00:00
ID
Thread
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 →