Whats Next for JCA?

What’s Next for the Java EE
Connector Architecture
Sivakumar Thyagarajan (Oracle), Jesper
Pedersen (RedHat), Fred Rowe (IBM)
BOF 7904 – JavaOne San Francisco 2013

The following is intended to outline our general product direction. It is intended
for information purposes only, and may not be incorporated into any contract.
It is not a commitment to deliver any material, code, or functionality, and should
not be relied upon in making purchasing decisions. The
development, release, and timing of any features or functionality described for
Oracle’s products remains at the sole discretion of Oracle.

Program Agenda
 Introduction of panel members
 Brief review of Connectors 1.7
 Ideas for Connectors.next
 Feedback from you

Program Agenda

Java EE Connector Architecture
Overview

Evolution of the Technology
 Outbound Communication
– Connection management (lifecycle, pooling, sharing)
– Security Contracts
– Exporting transaction and security context to EIS
Connectors 1.0 (JSR #16 - 2001)

 Inbound messaging
– Bi-directional asynchronous integration with EISs
– Import transaction context from EIS
 JMS provider pluggability
 Lifecycle management
 Work management
Connectors 1.5 (JSR #112 - 2003 – J2EE 1.4)

 Generic work context contracts
 Security context inflow during message delivery and work submission
 Standalone connector container environment
 Ease of Development (EoD)
Connectors 1.6 (JSR #322 – 2009 – Java EE 6)

 Maintenance Release #1 of JSR 322
 Richer inbound message delivery
– Component namespace availability during endpointActivation
– Obtain name and class of MessageEndpoint during delivery
 EoD: Resource definition annotations
– @ConnectionFactoryDefinition
– @AdministeredObjectDefinition
 Clarified CDI behavior for managed artifacts
Connectors 1.7 (Maint. Rel of JSR #322 – 2013 – Java EE 7)

Program Agenda

Ideas for Connectors.next
 Planning is getting started
 Inputs
– What we couldn’t complete in 1.7
– Requests from technology implementers, users and the community
 The following are potential ideas for a future Connectors.next
technology update
 Please feel free to comment/ask questions

1.8 vs. 2.0
 1.8
– Limited scope (batched message delivery)
– Preserve SPI compatibility
 2.0
– Change existing architecture
– Revamped SPI

Alignment with Other Java EE Technologies
 Concurrency Utilities for Java EE
– Align Work Manager to provide a uniform work submission model in the
platform?
 CDI
– Expand support for the injection of managed objects?
– Define an environment naming context for resource adapter modules?
Concurrency Utilities for Java EE, CDI

Enhanced Messaging
 Ability to correlate inbound and outbound messaging to support
conversational protocols
– Possible today, but requires co-ordination between the resource adapter
and the message endpoint developers
Support for stateful conversational protocols

Profiles
 Application servers required to implement support for a wide-range of
usecases
– Transaction modes: NoTransaction, LocalTransaction, XA
– Connectivity: Inbound, Outbound, both
 Simplify implementation of Connectors through the introduction of
Profiles
– Outbound NoTx, Outbound Tx, Inbound, Full
 Challenge is to maintain deployment compatibility of RARs
Technology subset for different usecases

Java EE Connector Architecture 2.0
Jesper Pedersen
Red Hat

 Change the existing architecture
But keep the overall concepts
 Apply modern programming approach
Use generics
Support JSR-330 injection
 Simplify concepts
Clear separation of SPI contracts
Remove the notion of a “common” client interface

 New architecture
Only have the vendor implement the required contracts
 NoTransaction
 LocalTransaction
 XATransaction
Provide marker interfaces for contracts
 javax.jca.spi.client.Connection
 javax.jca.spi.client.ConnectionFactory
 javax.jca.spi.management.AdministeredObject
Remove unused / “deprecated” functionality
 LogWriter – replaced by java.util.logging
 Common Client Interface (CCI)

 Support JSR-330 for injection
BootstrapContext
ResourceAdapter
TransactionSynchronizationRegistry
WorkManager
XATerminator
Validator

 BootstrapContext
Add Validator

 ConnectionManager
Allow the resource adapter to destroy ManagedConnection's
 boolean
destroyManagedConnections(ManagedConnectionFactory, Subject, C
onnectionRequestInfo)
 Lazy ConnectionManager
Allow the resource adapter to tell when it doesn't need the
ManagedConnection

 Batch message inflow
Multiple messages per transaction
boolean beginBatch(javax.transaction.xa.XAResource)
boolean endBatch()
 TransactionalMessageEndpoint
Extends MessageEndpoint
setRollbackOnly()
setTransactionTimeout(int)

 Statistics
Provide statistics interface
 ResourceAdapter
 ManagedConnectionFactory
 Admin Object
 Management
Provide management interface
 ResourceAdapter
 ManagedConnectionFactory
 Admin Object
Metadata of which methods should be exposed

 Conclusion
Simpler architecture – clear what to do
Easier to get started – only do what is needed
Use of modern approaches – do it easier
 Most importantly
Java EE Connector Architecture 1.x maps on to Java EE Connector
Architecture 2.0
You will be able to deploy your old .rar archives
 Developed under Java Community Process (JCP)
We value your feedback !
And get involved :)

Program Agenda

Resources
 Connector 1.7 JSR page (download the final specification)
– http://www.jcp.org/en/jsr/detail?id=322
 Join the connector-spec project (Work on Specification, expert group
and user mailing lists, issue tracker)
– http://connector-spec.java.net
 Try out the new Connectors 1.7 sample (traffic-eis) released as part of
the Java EE 7 Tutorial
– http://docs.oracle.com/javaee/7/tutorial/doc/

Thank You!

Graphic Section Divider

Whats Next for JCA?

More Related Content

What's hot

Viewers also liked

Similar to Whats Next for JCA?

Recently uploaded

Whats Next for JCA?