sca-j message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: ISSUE 15: Java Implementations should be able to be Fully Configured with SCA Metadata
- From: "Barack, Ron" <ron.barack@sap.com>
- To: "OASIS Java" <sca-j@lists.oasis-open.org>
- Date: Thu, 18 Oct 2007 19:07:47 +0200
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]