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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

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


Subject: [NEW ISSUE] Java Implementations should be able to be Fully Configured withSCA Metadata



Folks,

Belatedly, the first of the 2 issues that were discussed briefly at the F2F

RAISER:  Mike Edwards

TARGET: SCA Java Annotations and APIs specification

(but possibly also the SCA Assembly specification - TBD)

DESCRIPTION:

It should be possible, although not mandatory, for a Java Implementation to be fully configured with SCA-related metadata so that
such an implementation can be deployed to the SCA Domain without the need for any further configuration.

In the simplest case, the implication is that it should be possible to have a single Java class, marked with appropriate annotations,
which identifies its services, its references and its properties, but which also provides complete "default" values for all of these
aspects of its SCA component type:

- for a service, this would include its Binding and any binding parameters required to enable the SCA runtime to instantiate the
service with an appropriate endpoint address

- for a reference, this would include its Binding and any parameters required to identify a target service using that binding.
The target service could either be identified by SCA means (eg "componentName/serviceName") or by binding specific means
(eg HTTP URL for a Web service).

- for a property, this would imply a default value for the property

The services, references and the implementation itself may all be decorated with appropriate Intents and/or PolicySets.

With this approach, a specific type of "simple deployment" runtime is enabled.  The sort of runtime that would be possible
with this approach is one where the runtime watches a directory (and its subdirectories, if required) and looks for new
implementations being placed into the directory.  When a new implementation is placed in the directory, the runtime
spots its arrival, introspects the implementation and deploys the implementation to the SCA Domain, effectively
generating a new component at the Domain level, without needing any extra metadata, since the implementation
contains all that is required.



Note that these defaulted features of a Java implementation would be subject to the usual overriding rules of SCA and so when the
implementation artifact is used as the implementation of a component (at any level in the composition hierarchy) then the
configuration of the component can override any and all of the default configuration of the implementation, except for
absolute requirements stated via Intents (note that there is nothing new to SCA in this).


PROPOSAL:

The implications of this issue:

a) Add a section near the start of the specification that state the capability described above and its goals

b) Add a set of annotations and APIs that permit a Java implementation to specify any SCA metadata that is relevant
to deploying the implementation as a component in the SCA Domain without the need for any further metadata.
Examples of the metadata that cannot be specified today relates to Bindings and parameters of Bindings.
Separate Issue(s) should be brought forward to deal with the additional annotations and APIs that are required.



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:  mike_edwards@uk.ibm.com






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








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