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
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Java" <sca-j@lists.oasis-open.org>
- Date: Thu, 18 Oct 2007 15:51:42 +0100
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]