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

Comments:

I used JCA 1.5 to create a connector for a client/server system over sockets using a proprietary protocol. I did not like the words used in the API, such as a "record". In my case records are request messages, and response messages. This makes my source code confusing to people trying to learn it.

Also I had to hack up my own way for synchronous messaging. When a client of the JCA connector asks for something I needed it to block until the response is received or a timeout, then return with the data. Why? So that I could use it in a web application.

Posted by Ryan de Laplante on September 05, 2008 at 03:12 PM IST #

The JCA 1.5 spec isn't missing that many features, but its failed to drum up the same amount of interest as other areas of JEE like EJB and JPA. Where every Tom, Dick and Harry is writing books and articles on EJBs etc, JCA has been skimmed over, or the available resources are lacking. This is kind of strange as JCA allows you to talk to things that aren't databases and message queues (albeit often these are enabled by means of resource adapters).

Hopefully the new spec will be clearer on how to write adapters that enlist transactions, and make the connection factory stuff less painful. Its all there in 1.5, just too tortured.

BTW Ryan you dont need to use all that javax.resource.cci (its the grimmest api i've ever tried to get my head around), the rest of the JCA stuff is the useful stuff.

Posted by Mark on September 05, 2008 at 05:49 PM IST #

I bought a book on JCA a couple years ago so that I could write my RA. It was the newest book and already out of date. I had to figure out the differences in ra.xml to get my adapter working. There needs to be an up to date book written on JCA.

Thanks for the tip about NOT using javax.resource.cci. I never considered creating my own API. I've been wanting to make some changes to clean my RA up a bit, and also wondering if it really should be written as a JBI component. I would like to see a page or chart that helps me compare and contract JCA with JBI to help me decide when to use which.

Posted by Ryan de Laplante on September 05, 2008 at 05:58 PM IST #

Ryan: Thanks for your comments. For your usecase, as Mark had suggested, you might want to look at using an SPI instead of CCI. The CCI defines a standard client API for application components and thereby enables
components to interact across heterogeneous EISs through a common client API. However not all resource adapters need to implement a CCI API. A domain-specific SPI is recommended in this case. For example JMS RAs (eg: http://genericjmsra.dev.java.net ) usually provide a JMS interface to their application components.

FWIW, I compiled some resources to get started on the capabilities provided by the Connectors spec today in answer to a forum question and it is available at: http://forums.java.net/jive/message.jspa?messageID=234194#234194
HTH.

Mark: Thanks for your comments. Yes, One of the areas we intend to address in this version of the specification is to bring in Java EE 5 style common programming model to ease development of resource adapters. This should turn up in the next drafts. We would love to hear your feedback on those drafts.

Posted by Sivakumar Thyagarajan on September 08, 2008 at 05:22 AM IST #

Is there an RSS I can link to in order to stay up to date on the spec progress (if its one of the aquarium announcements I'll already see it). For me JCA is the unsung hero of JEE, we've been working with resource adapters a lot. Seeing how the JSR group reasons might help my insight.

Like I said before, its not so much the spec, but also the coverage in terms of books etc. The only book I've got is the spec regurgitated (J2EE Connector Architecture and Enterprise Application Integration) which in itself is okay, but some other stuff around would be nice . For some reason EJB3 and JPA took the lime light, when in reality the possibilities provided by JCA are far greater.

Posted by Mark on September 09, 2008 at 03:05 PM IST #

Hi Mark: Unfortunately there are no RSS feeds to track JSR progress in the jcp.org site. You might want to use the following to track progress on this JSR.

- My blog. Entries that are tagged "connectors16_jsr322". The atom feed for only entries that are tagged "connectors16_jsr322" is at
http://blogs.sun.com/sivakumart/feed/entries/atom?cat=%2Fconnectors16_jsr322

- The Aquarium blog. Entries are tagged javaee6
http://blogs.sun.com/theaquarium/tags/javaee6.
Unfortunately, the aquarium uses tags instead of categories for javaee6 posts and I don't know how I can get an atom feed for only javaee6 tagged entries.

- You may want to join an OBSERVERs alias where we plan to send a notification of major drafts when it is published via the JSR site.

To subscribe to the observer alias for this JSR, send an email message to listserv@java.sun.com with the following text in the body of the message:

subscribe jsr-322-observers

HTH. Thanks for your kind words on the technology. I share the same gripe about the lack of good books on the technology :)

Posted by Sivakumar Thyagarajan on September 10, 2008 at 07:37 AM IST #

HI Sivakumar

I'll keep an eye on whats going on with the spec. One issue that keeps popping up when writing resource adapters, is that tighter integration with the java.util.conncurrent package would be nice..

If the workmanager returned an ExecuterService, release behaviour could be managed using completion services etc. Rather than release which seems to need manual invocation.

Another gripe with 1.5 is the Unavailable exception thrown on endpointActivation messageEndpointFactory.createEndpoint.. if endpointActivation is invoked, it seems reasonable to expect that the endpoint can be created. I know this isn't the case with all containers.

The mandatory ManagedConnectionFactory (MCF) and ManagedConnection (MC) also creates a bit if confusion (at least it confuses me).. Most of the time, the createConnectionFactory() method is the only method that gets used. Some default implementations could help here, and an interface thats not javax.resource.cci to implement to ensure that hand rolled connection factories and connections can be managed. If there is no MCF defined on the ra.xml then a default can be used, returning a connectionfactory instance from createConnectionFactory.

Mark

Posted by Mark on October 08, 2008 at 06:50 PM IST #

[Mark] I'll keep an eye on whats going on with the spec. One issue that keeps popping up when writing resource adapters, is that tighter integration with the java.util.conncurrent package would be nice..

[Siva] Yes, this would be useful. JSR 236 is already planning to address this at a platform level.

[Mark] Another gripe with 1.5 is the Unavailable exception thrown on endpointActivation messageEndpointFactory.createEndpoint.. if endpointActivation is invoked, it seems reasonable to expect that the endpoint can be created. I know this isn't the case with all containers.

[Siva] An UnavailableException may be thrown by the container to control the number of endpoints created. Were you trying to create endpoints as part of endpointActivation() method? If yes, Section 12.4.4. of Connectors 1.5 spec allows an AS to block or throw an endpointActivation at that time.

Please keep your comments coming. You could also send the comments to the JSR comments alias jsr-322-comments@jcp.org

Thanks
--Siva.

Posted by Sivakumar Thyagarajan on October 15, 2008 at 08:56 AM IST #

HI Sivakumar

The spec says.
"... a resource adapter may attempt to deliver messages during the
endpointActivation method call. It is up to the application server to decide
whether to allow message delivery before activation is completed. If the application
server chooses to prevent message delivery during endpoint activation, it may block
the createEndpoint method call until the activation is completed or throw an
UnavailableException."

This has resulted in some containers allowing the creation of message endpoints inside the endpointActivation method and others throwing an UnavailableException.. I can see the benefits of dedicating a work or timer task to handle this, but seems that life would be simplier if this were defined in a less optional manner.. Else folk like me have to rewrite to deploy to different platforms..

Mark

Posted by guest on October 17, 2008 at 11:32 AM IST #

Post a Comment:
Comments are closed for this entry.
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