RE: [sca-bpel] ISSUE 24: BPEL C&I spec needs to define howeffective CT is synthesized

[Michael Rowley <michael.rowley@activevos.com>]

Proposal: Remove section 2.5 Component Type Side Files.

Introspection must be used.  If someone wants to modify what is generated, they can wrap it in a composite file.

Michael


-----Original Message-----
From: Michael Rowley [mailto:michael.rowley@activevos.com]
Sent: Thursday, October 30, 2008 1:11 PM
To: OASIS BPEL
Subject: Re: [sca-bpel] ISSUE 24: BPEL C&I spec needs to define how effective CT is synthesized


http://www.osoa.org/jira/browse/BPEL-24

Anish Karmarkar wrote:
> Title: BPEL C&I spec needs to define how effective CT is synthesized
>
> Target: BPEL C&I spec
>
> Description:
> Assembly TC resolved issue 36 [1] with the following resolution:
>
> -----
> 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 that 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 might 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, both
> are
> allowed or some other mechanism specifies the CT.
> The component type information derived through introspection is
> called the 'introspected component type'. In any case, the implementation
> type specification specifies how multiple sources of information
> are combined to produce 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'.
> -----
>
> This puts requirements on C&I wrt defining whether side files are
> allowed, how they interact with introspected CT and how effective CT
> is synthesized. We need to define these things in the C&I.
>
> Proposal:
>
> None at this point.
>
>
> [1] 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
>

---------------------------------------------------------------------
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