The JSR 322
has been working hard on defining new features,
addressing comments from the public and improving the early
draft. We are happy to announce that the Public Review Draft document
is now available
off the JSR page
in JCP. This blog introduces some of the new
and noteworthy features that are part of this draft.
Given the short
between Public Draft and Proposed Final Draft, it would
be great if you could read the draft and send your feedback to the
expert group as soon as you can.
As mentioned above, this draft also addresses early draft related
comments that we received from the community and so we encourage you to
help us continue that effort by sending your review comments to the JSR
or in this blog.
Some of the major new features in the public review draft are:
- Ease of
Development (EoD) through use of metadata annotations,
optional deployment descriptor(ra.xml),better defaults, optional
- Integration with JSR 303: Bean Validation
specification to handle validation requirements of configuration
properties in various resource adapter JavaBeans.
- Support for Distributed
Work Processing and Work
A detailed changeset is listed in Appendix. I.1 of the specification.
Please refer to it while reviewing the changes.
Here is a brief overview of the new features:
- Ease of
Development through metadata annotations: Java
EE 5 brought in a huge
change in the enterprise application programming model
through the introduction of EoD enhancements such as the use of
metadata annotations, better defaults, removal of boilerplate code etc.
These improvements simplified component development to a great
extent while still retaining the richness and the power of
Since the Conectors
technology was not updated as part of Java EE 5, the ease with which
resource adapters can be developed has not improved since J2EE 1.4.
However, as Roberto points out, EoD is an ongoing
goal in Java EE 6
and improvements are made to the Connectors
spec as well.
The spec now defines (in Chapter 18) a simplified API for
development of resource adapters. The goal of the API was to simplify
the development of resource adapter implementations for programmers who
are just starting with resource adapters, or developing resource
adapters of small to medium complexity.Through the introduction of new metadata annotations, the specification
now reduces or completely eliminates the need to deal with a deployment
descriptor(ra.xml) in many cases.
The new annotations defined in the
specify that the JavaBean is a resource adapter JavaBean. Used to
provide metadata about the capabilities provided by the resource
adapter. It is optional to provide a JavaBean implementing the
ResourceAdapter interface. [However, there are scenarios where a
resource adapter may want to provide an implementation -- see Section
specifies to the application server, that the decorated property is a
configuration property for that JavaBean. Configuration Properties are
now auto-discoverable by the application server and hence need not
specified using the deployment descriptor.
defines a set of connection interfaces and classes pertaining to a
particular connection type (identical to the role played by the
connection-definition element in ra.xml).
designate a JavaBean as an ActivationSpec JavaBean
designates a JavaBean as an administered object.
Through the use of these
annotations and other improvements such as the auto-discovery of
configuration properties, the use of JSR 303 to express validation
constraints etc, we hope resource-adapter development would be radically
simplified. Please see Chapter 18 for more information on these
annotations and code samples on how then can be used.
[Please note: Metadata annotations and some new usecases
(Resource injection, definition of a component naming context (ENC) for
resource adapters etc) are still being actively discussed in the Expert
group and hence these interfaces must be considered as work-in-progress
and may go through changes in the next phases of the specification. --
We would also love to hear from the community on their thoughts on the
proposed annotations and EoD capabilities defined so far.]
As the reference implementation is developed, I will follow up with
more samples showcasing the use of annotations while building
connectors. So, stay tuned.
Validation: The Bean Validation (JSR 303)
specification is "defining a meta-data model and API for JavaBean
validation based on annotations, with overrides and extended meta-data
through the use of XML validation descriptors." The Connector spec now
allows its JavaBeans such as ResourceAdapter, ManagedConnectionFactory,
ActivationSpec, AdministeredObject and InteractionSpec to be decorated
with the Bean Validation constraint annotations. This now provides the
RA developer a richer and standard way of expressing their constraints
and also get the configuration of a JavaBean validated prior to use.
Please see Section 126.96.36.199 in the spec for more information
Work Processing: In deployment runtimes which span
multiple VMs/hosts, it is useful to have Work instances that were
submitted by a resource adapter to a local WorkManager to be
distributed to a different remote WorkManager, for reasons of
scaling, performance etc. The specification defines a mechanism to
allow such distributed Work processing. See Section 10.3.11 for more
information on this
processing hints: The specification also now enables a
resource adapter to pass quality-of-service metadata to the WorkManager
during the submission of a Work instance. The WorkManager
implementation of the application server may then use the specified
hints to control the execution of the Work instance. For those who
followed the InflowContext mechanism defined in the Early Draft, the
propagation of QoS hints is defined as a standard InflowContext,
HintsInflowContxt. See Section 11.7 for more information on this.