Generic Work Context mechanism: Defined a generic mechanism for propagating contextual information during Work execution. The specification standardizes passing in security, transactional and other quality-of-service parameters from an EIS to a Java EE component during Work execution.

Security Work Context: Defined a standard contract that a resource adapter could employ to establish security information(established identity) while submiting a Work instance for execution to a WorkManager, and while delivering messages to message endpoints (MDBs) residing in the application server

Ease of Development: Dramatically simplify the development of resource adapters through extensive use of Java language annations, reducing the need to write redundant code and the need for a deployment descriptor, provide better programmatic defaults, etc.

Bean Validation: Defined how resource adapters could leverage the underlying Bean Validation support in Java EE to express their configuration validation requirements.

Added Features that enhance QoS and reliability around Connection Management, Work execution etc.

I had provided brief overviews of these features in previous blog entries and presentations. There are more articles/tutorials on the technology coming up in the next few weeks.

I would like to take this opportunity to thank all those who have helped in this version of the specification -- the expert group members of JSR 322, the spec-leads and EG members of related JSRs, the reference implementation (RI) and the technology compatibility kit (TCK) teams and all those from the community who had provided feedback and suggestions on the previous milestone drafts.

We had covered the features introduced in the earlier milestones of the
specification in this blog (see entries on early draft and public review).
Some of the changes and new features introduced in the PFD draft are:

Config property attributes: New attributes (See Section 5.3.7.6) have been introduced to configuration properties to indicate if they

support dynamic
updates: to indicate to the application server that
dynamically reconfiguring the config property is supported by the
resource adapter

are confidential:
to indicate that a particular configuration property is confidential,
so that deployment/runtime tools could use special visual aids denoting
confidentiality and not expose the values as plain text.

The original InflowContext interfaces have been renamed to
WorkContext or its equivalent, as the interfaces were not relevant only
during Message Inflow but during all Work processing. (See Ch.11 and 16)

Robust handling of error conditions during MessageEndpoint
creation and Work submission: Enhanced the MessageEndpoint creation
APIs to support timeouts and also enhanced the exceptions thrown by the
MessageEndpointFactory and WorkManager to handle retryable scenarios.
(See 13.3 and 10.3.3 for more details)

Provide guidelines on the relationship of the Connector
Architecture and other integration technologies such as Java Business
Integration (JBI) and Service Component Architecture (SCA). (See
Section 1.5)

Updated the ease of development annotations and contracts,
that were introduced in the Public Review draft of the
specification, to address feedback received. (See the change
history, Section I.1, for a list of changes and Ch. 18 for more details)

Misc updates and clarifications to the Connection and
Transaction Management chapters (see the change history, Section I.1
for a complete list of changes).

As always, we would like your feedback on the draft through the JSR comments alias jsr322-comments@jcp.org or in the comments section of this blog entry. Since this is the last milestone of the JSR before going final, please try to spend some time reading the new features introduced in this version of the specification, try out the reference implementation (details below) and provide your review comments and feedback through the alias above.

Jagadish, the lead of the Connectors technology reference implementation in GlassFish, has blogged recently about how a resource adapter can be built using the new metadata annotations introduced in the spec and demonstrates how the use of the EoD features could reduce the need for redundant boilerplate code and eliminate/reduce the need for XML deployment descriptors. Please also go through the Connectors 1.6 mail-connector sample that he has made available through the Java EE 6 Preview SDK to understand how these annotations could be used while developing a resource adapter.

Friday Dec 05, 2008

The JSR 322
expert group 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
time 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
comments alias
jsr-322-comments@jcp.org
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
configuration etc.

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
the technology.

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
spec are:

@Connector:
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
18.4.1]

@ConfigProperty:
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.

@ConnectionDefinition(s):
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).

@Activation:
designate a JavaBean as an ActivationSpec JavaBean

@AdministeredObject:
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.

JavaBean
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 5.3.7.5 in the spec for more information

Distributed
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
feature.

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

Thursday Aug 07, 2008

I am very happy to announce that the Early Draft of the JavaTM
EE Connector Architecture 1.6 specification is available now.
We started to work on an update to the earlier Connectors specification
(J2EE
Connector Architecture 1.5) in the Expert Group of JSR 322
in January this year. The Expert Group has been working very hard on
the Early Draft and we are looking forward to hear your feedback.
Please send your feedback and comments to jsr-322-comments@jcp.org.

The purpose of the Java EE Connector Architecture 1.6 specification is
to address some areas in the earlier specification, where further
support has been requested by the developer/user community and the
expert group. Some of the important features that are being planned to
be addressed in this release include:

Generic
Inflow Context: a mechanism for enabling a resource
adapter to provide additional contextual information while a Work
gets
executed by the application server's WorkManager

Security
Inflow: enabling a resource adapter to propagate security
identity information during Work execution and delivery to
MessageEndpoints(MDBs)

General
improvements to the specification: in the areas of
handling connection failures, inbound and outbound configuration
consistency, better configuration property processing (ability to
specify better validation rules etc) and clarifications around the
classloading of standalone resource adapters.

Focus on
ease-of-development of resource adapters. Aligning with
common programming
model of Java EE by defining helper classes and
annotations for the Connector API wherever applicable.

As a general reminder, since we're still relatively early in the
process, the exact feature set is subject to change (for instance, the
contracts have already gone through a lot of change since our JavaOne
2008 BoF presentation a couple of months ago ).

Here is a brief overview of the features that have been discussed and
made it to the early draft. This is not a comprehensive list and so
please see the Change History (Section I.1) for more information on all
the changes made to the specification, in this early draft.

Generic
Inflow Context: Certain Enterprise Information System
(EIS) integration usecases requires the propagation of contextual
information from the EIS to the application server. For example, a
resource adapter may want to flow-in Security context information, (or
in the case of an EIS that deals with conversational messaging,
correlation information that might be necessary to recreate a
conversational session state in the container) from the EIS to the
application server during inbound message
delivery. The resource adapter may also want to run a particular Work
instance in the context of the "flown-in" Security
information.

The Generic Inflow Context
is a new system contract that enables a resource adapter to
control the execution context of a Work instance that it has submitted
to the WorkManager for execution. The Generic inflow contract provides
the mechanism for a resource adapter to augment the runtime context of
a Work instance with additional contextual information flown-in from
the EIS.

Inflow Contexts for
propagating in transaction and security information from the EIS into
the application server during the execution of a Work instance have now
been standardised via the TransactionInflowContext
and
SecurityInflowContext
interfaces. An application server must support
both these inflow contexts and therefore a portable resource adapter
can assume an application server’s support for both these inflow
contexts. Since the Inflow Context contract has been defined to be
generic and
extensible, the Connectors specification or other Profiles may define
additional context types in the future.

For more information on
this new system contract, its API and an illustrative example of how a
resource adapter can pass in (say) Transactional information along with
a Work instance during Work submission, please refer "Chapter 11.
Generic Inflow" of the Early
Draft.

Security
Inflow Context: It is critical, in EIS integration
scenarios, that all interactions between an application server and
resource adapter are secure.To achieve end-to-end application security,
it is important that all activities that a Work instance performs,
including delivering messages to a MessageEndpoint (MDB) happens in the
context of an established identity.

The Security Inflow
Context is a new standard contract that enables a resource adapter to
control and establish security information during the execution of a
Work instance. This contract provides a mechanism to support the
execution of a Work instance in the context of an established identity.
It also supports the propagation of user information/Principal
information from an EIS to a MessageEndpoint(MDB) during Message Inflow.

For more information on
this new system contract, its API and an illustrative example of how
(say) a XMPP resource adapter can deliver a message with appropriate
security information, please refer "Chapter 16. Security Inflow" of the
Early Draft.

Other changes:
In addition to the two new changes discussed above, a suite of new
features/changes have also been discussed in the early draft. A few of
them are:

a definition of minimum set of requirments that must
besupported by a compliant Java EE Connectors Architecture 1.6
container within an implementation of any subset of the Java EE Full
Profile (like a
Web Profile). Refer Section 3.5

an ability to specify the transaction support level of a
resource adapter at runtime. Refer Section 7.13

We presented an overview of the updates currently being discussed in a BoF session in this year's JavaOne. Thanks to everyone who attended the session and for the interesting discussion during and after the session.

I received a few requests for the slides that we used in BoF 5634, and so I have made them available here (pdf). We are working on producing an early draft of the specification and it should be posted in the JSR home page in a few weeks. So, please stay tuned and let us know your feedback.