Friday Dec 05, 2008

Connectors 1.6 Public Review available

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.
  • Integration with JSR 303: Bean Validation specification to handle validation requirements of configuration properties in various resource adapter JavaBeans.
  • Support for Distributed Work Processing and Work processing Hints
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

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