Tuesday Dec 22, 2009

Java EE 6 and GlassFish v3 virtual seminar replays available -- Connectors 1.6 overview talk

As you might have seen in the recent Aquarium post, the session replays and slide-sets of the talks in the Java EE 6 and GlassFish v3 virtual seminar is now available (registration required for access. registration is free). The replay for the technical overview session on Connectors 1.6 (in slide-cast form) is also made available as part of this set. This talk highlights the new features, discussed in an earlier post, in Java EE Connector Architecture 1.6 (JSR 322).

The slides of the JavaOne talk on Connectors 1.6 are also now available at slideshare and embedded below.

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

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

About

sivakumart

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today