Sivakumar Thyagarajan's Blog
Thursday Aug 07, 2008
Connectors 1.6 Early Draft Specification now available!
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.
). 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.
So, for instance, if the
resource adapter uses the new Security Inflow contracts, deliveries to
Message Driven Beans (MDBs) could be made in the context of a security
identity [that is, MessageDrivenContext.getCallerPrinicipal()
and
MessageDrivenContext.isCallerInRole()
would returns values established
by the resource adapter/EIS].
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
- ClassLoading requirements for standalone resources adapters. Refer Section 19.3
Posted at 08:49PM Aug 07, 2008 by Sivakumar Thyagarajan in connectors16_jsr322 | Comments[9]
