Java EE Connector Architecture [JCA] – An overview

Overview:
Java EE Connector Architecture (JCA) is a Java-based technology solution for connecting application servers and enterprise information systems (EIS) as part of enterprise application integration (EAI) solutions. While JDBC is specifically used to connect Java EE applications to databases, JCA is a more generic architecture for connection to legacy systems (including databases). JCA was developed under the Java Community Process as JSR 16 (JCA 1.0) and JSR 112 (JCA 1.5). As of 2006[update], the current version of JCA is version 1.5.

JCA and J2EE:
J2EE Version 1.3 required application servers to support Version 1.0 of the J2EE Connector Architecture (JCA).

Contracts:
The J2EE Connector Architecture defines a standard for connecting a compliant application server to an EIS. It defines a standard set of system-level contracts between the J2EE application server and a resource adapter. The system contracts defined by Version 1.0 of the J2EE Connector Architecture are described by the specification as follows:

  • Connection management
    Connection management enables an application server to pool connections to the underlying EIS and enables application components to connect to an EIS. This leads to a scalable application environment that can support a large number of clients requiring access to an EIS.
  • Transaction management
    Transaction management enables an application server to use a transaction manager to manage transactions across multiple resource managers. This contract also supports transactions that are managed internal to an EIS resource manager without the necessity of involving an external transaction manager.
  • Security management
    Security management provides support for a secure application environment that reduces security threats to the EIS and protects valuable information resources managed by the EIS.

The additional system contracts defined by Version 1.5 of the J2EE Connector Architecture are described by the specification as follows:

  • Life cycle management
    Life cycle management enables an application server to manage the life cycle of a resource adapter. This contract provides a mechanism for the application server to bootstrap a resource adapter instance during its deployment or application server startup, and to notify the resource adapter instance during its undeployment or during an orderly shutdown of the application server.
  • Work management
    Work management enables a resource adapter to do work (monitor network endpoints, call application components, and so on) by submitting work instances to an application server for execution. The application server dispatches threads to execute submitted work instances. This allows a resource adapter to avoid creating or managing threads directly, and allows an application server to efficiently pool threads and have more control over its run time environment. The resource adapter can control the transaction context with which work instances are executed.
  • Transaction inflow management
    Transaction inflow management enables a resource adapter to propagate an imported transaction to an application server. This contract also allows a resource adapter to transmit transaction completion and crash recovery calls initiated by an EIS, and ensures that the Atomicity, Consistency, Isolation and Durability (ACID) properties of the imported transaction are preserved.
  • Message inflow management
    Message inflow management enables a resource adapter to asynchronously deliver messages to message endpoints residing in the application server independent of the specific messaging style, messaging semantics, and messaging infrastructure used to deliver messages. This contract also serves as the standard message provider pluggability contract that allows a wide range of message providers (Java Message Service (JMS), Java API for XML Messaging (JAXM), and so on) to be plugged into any J2EE compatible application server with a resource adapter.

The article is taken from Wikipedia. See the license terms.

Technology Review – Spring Framework In Java [Detailed Version]

The Spring Framework is an open source application framework for the Java platform and .NET Framework (Spring.NET).

The first version was written by Rod Johnson who released the framework with the publication of his book Expert One-on-One J2EE Design and Development in October 2002. The framework was first released under the Apache 2.0 license in June 2003. The first milestone release, 1.0, was released in March 2004, with further milestone releases in September 2004 and March 2005. The Spring 1.2.6 framework won a Jolt productivity award and a JAX Innovation Award in 2006. The current version is 2.5.6.

The core features of the Spring Framework can be used by any Java application, but there are extensions for building web applications on top of the Java Enterprise platform. Although the Spring Framework does not impose any specific programming model, it has become popular in the Java community as an alternative to, replacement for, or even addition to the Enterprise JavaBean (EJB) model.

SpringSource was purchased for $420m by VMware in August 2009.

Modules

The Spring Framework comprises several modules that provide a range of services:

  • Inversion of Control container: configuration of application components and lifecycle management of Java objects
  • Aspect-oriented programming: enables implementation of cross-cutting routines
  • Data access: working with relational database management systems on the Java platform using JDBC and object-relational mapping tools
  • Transaction management: unifies several transaction management APIs and coordinates transactions for Java objects
  • Model-view-controller: an HTTP and Servlet-based framework providing hooks for extension and customization
  • Remote Access framework: configurative RPC-style export and import of Java objects over networks supporting RMI, CORBA and HTTP-based protocols including web services (SOAP)
  • Batch processing: a framework for high-volume processing featuring reusable functions including logging/tracing, transaction management, job processing statistics, job restart, skip, and resource management
  • Authentication and authorization: configurable security processes that support a range of standards, protocols, tools and practices via the Spring Security sub-project (formerly Acegi).
  • Remote Management: configurative exposure and management of Java objects for local or remote configuration via JMX
  • Messaging: configurative registration of message listener objects for transparent message consumption from message queues via JMS, improvement of message sending over standard JMS APIs
  • Testing: support classes for writing unit tests and integration tests

Inversion of Control container

Central to the Spring Framework is its Inversion of Control container, which provides a consistent means of configuring and managing Java objects using callbacks. The container is responsible for managing object lifecycles: creating objects, calling initialization methods, and configuring objects by wiring them together.

Objects created by the container are also called Managed Objects or Beans. Typically, the container is configured by loading XML files containing Bean definitions which provide the information required to create the beans.

Objects can be obtained by means of Dependency lookup or Dependency injection. Dependency lookup is a pattern where a caller asks the container object for an object with a specific name or of a specific type. Dependency injection is a pattern where the container passes objects by name to other objects, via either constructors, properties, or factory methods.

In many cases it’s not necessary to use the container when using other parts of the Spring Framework, although using it will likely make an application easier to configure and customize. The Spring container provides a consistent mechanism to configure applications and integrates with almost all Java environments, from small-scale applications to large enterprise applications.

The container can be turned into a partially-compliant EJB3 container by means of the Pitchfork project. The Spring Framework is criticized by some as not being standards compliant.[who?] However, SpringSource doesn’t see EJB3 compliance as a major goal, and claims that the Spring Framework and the container allow for more powerful programming models.
Aspect-oriented programming framework

The Spring Framework has its own AOP framework which modularizes cross-cutting concerns in aspects. The motivation for creating a separate AOP framework comes from the belief that it would be possible to provide basic AOP features without too much complexity in either design, implementation, or configuration. The SpAOP framework also takes full advantage of the Spring Container.

The Spring AOP framework is interception based, and is configured at runtime. This removes the need for a compilation step or load-time weaving. On the other hand, interception only allows for public or protected method execution on existing objects at a join point.

Compared to the AspectJ framework, Spring AOP is less powerful but also less complicated. Spring 1.2 includes support to configure AspectJ aspects in the container. Spring 2.0 has more integration with AspectJ; for example, the pointcut language is reused.

Spring AOP has been designed to make it able to work with cross-cutting concerns inside the Spring Framework. Any object which is created and configured by the container can be enriched using Spring AOP.

The Spring Framework uses Spring AOP internally for transaction management, security, remote access, and JMX.

Since version 2.0 of the framework, Spring provides two approaches to the AOP configuration:

* schema-based approach.
* @AspectJ-based annotation style.

The Spring team decided not to introduce new AOP-related terminology; therefore, in the Spring reference documentation and API, terms such as aspect, join point, advice, pointcut, introduction, target object (advised object), AOP proxy, and weaving all have the same meanings as in most other AOP frameworks (particularly AspectJ).

Data access framework

Spring’s data access framework addresses common difficulties developers face when working with databases in applications. Support is provided for all popular data access frameworks in Java: JDBC, iBatis, Hibernate, JDO, JPA, Oracle TopLink, Apache OJB, and Apache Cayenne, among others.

For all of these supported frameworks, Spring provides these features:

  • Resource management – automatically acquiring and releasing database resources
  • Exception handling – translating data access related exception to a Spring data access hierarchy
  • Transaction participation – transparent participation in ongoing transactions
  • Resource unwrapping – retrieving database objects from connection pool wrappers
  • Abstraction for BLOB and CLOB handling

All these features become available when using Template classes provided by Spring for each supported framework. Critics say these Template classes are intrusive and offer no advantage over using (for example) the Hibernate API directly.[who?] In response, the Spring developers have made it possible to use the Hibernate and JPA APIs directly. This however requires transparent transaction management, as application code no longer assumes the responsibility to obtain and close database resources, and does not support exception translation.

Together with Spring’s transaction management, its data access framework offers a flexible abstraction for working with data access frameworks. The Spring Framework doesn’t offer a common data access API; instead, the full power of the supported APIs is kept intact. The Spring Framework is the only framework available in Java which offers managed data access environments outside of an application server or container.

While using Spring for transaction management with Hibernate, the following beans may have to be configured

  • DataSource like com.mchange.v2.c3p0.ComboPooledDataSource or org.apache.commons.dbcp.BasicDataSource
  • SessionFactory like org.springframework.orm.hibernate3.LocalSessionFactoryBean
  • HibernateProperties like org.springframework.beans.factory.config.PropertiesFactoryBean
  • TransactionManager like org.springframework.orm.hibernate3.HibernateTransactionManager

Other configurations

  • AOP configuration of cutting points using <aop:config>
  • Transaction semantics of AOP advice using <tx:advice>

Transaction management framework

Spring’s transaction management framework brings an abstraction mechanism to the Java platform. Its abstraction is capable of:

  • working with local and global transactions (local transaction does not require an application server)
  • working with nested transactions
  • working with transaction safepoints
  • working in almost all environments of the Java platform

In comparison, JTA only supports nested transactions and global transactions, and requires an application server (and in some cases also deployment of applications in an application server).

The Spring Framework ships a PlatformTransactionManager for a number of transaction management strategies:

  • Transactions managed on a JDBC Connection
  • Transactions managed on Object-relational mapping Units of Work
  • Transactions managed via the JTA TransactionManager and UserTransaction
  • Transactions managed on other resources, like object databases

Next to this abstraction mechanism the framework also provides two ways of adding transaction management to applications:

  • Programmatically, by using Spring’s TransactionTemplate
  • Configuratively, by using metadata like XML or Java 5 annotations

Together with Spring’s data access framework — which integrates the transaction management framework — it is possible to set up a transactional system through configuration without having to rely on JTA or EJB. The transactional framework also integrates with messaging and caching engines.

Model-view-controller framework

The Spring Framework features its own MVC framework, which wasn’t originally planned. The Spring developers decided to write their own web framework as a reaction to what they perceived as the poor design of the popular Jakarta Struts web framework[5], as well as deficiencies in other available frameworks. In particular, they felt there was insufficient separation between the presentation and request handling layers, and between the request handling layer and the model.

Like Struts, Spring MVC is a request-based framework. The framework defines strategy interfaces for all of the responsibilities which must be handled by a modern request-based framework. The goal of each interface is to be simple and clear so that it’s easy for Spring MVC users to write their own implementations if they so choose. All interfaces are tightly coupled to the Servlet API. This tight coupling to the Servlet API is seen by some as a failure on the part of the Spring developers to offer a high-level abstraction for web-based applications. However, this coupling makes sure that the features of the Servlet API remain available to developers while offering a high abstraction framework to ease working with said API.

The DispatcherServlet class is the front controller of the framework and is responsible for delegating control to the various interfaces during the execution phases of a HTTP request.

The most important interfaces defined by Spring MVC, and their responsibilities, are listed below:

  • HandlerMapping: selecting objects which handle incoming requests (handlers) based on any attribute or condition internal or external to those requests
  • HandlerAdapter: execution of objects which handle incoming requests
  • Controller: comes between Model and View to manage incoming requests and redirect to proper response.
  • View: responsible for returning a response to the client
  • ViewResolver: selecting a View based on a logical name for the view (use is not strictly required)
  • HandlerInterceptor: interception of incoming requests comparable but not equal to Servlet filters (use is optional and not controlled by DispatcherServlet).
  • LocaleResolver: resolving and optionally saving of the locale of an individual user
  • MultipartResolver: facilitate working with file uploads by wrapping incoming requests

Each strategy interface above has an important responsibility in the overall framework. The abstractions offered by these interfaces are sufficiently powerful to allow for a wide set of variations in their implementations. Spring MVC ships with implementations of all these interfaces and together offers a powerful feature set on top of the Servlet API[neutrality disputed]. However, developers and vendors are free to write other implementations. Spring MVC uses the Java java.util.Map interface as a data-oriented abstraction for the Model where keys are expected to be string values.

The ease of testing the implementations of these interfaces is one important advantage of the high level of abstraction offered by Spring MVC. DispatcherServlet is tightly coupled to the Spring Inversion of Control container for configuring the web layers of applications. However, applications can use other parts of the Spring Framework—including the container—and choose not to use Spring MVC.

Because Spring MVC uses the Spring container for configuration and assembly, web-based applications can take full advantage of the Inversion of Control features offered by the container.
Remote access framework

Spring’s Remote Access framework is an abstraction for working with various RPC-based technologies available on the Java platform both for client connectivity and exporting objects on servers. The most important feature offered by this framework is to ease configuration and usage of these technologies as much as possible by combining Inversion of Control and AOP.

The framework also provides fault-recovery (automatic reconnection after connection failure) and some optimizations for client-side use of EJB remote stateless session beans.

Spring provides support for these protocols and products out of the box:

  • HTTP-based protocols
    o Hessian: binary serialization protocol, open-sourced and maintained by CORBA-based protocols
    o RMI (1): method invocations using RMI infrastructure yet specific to Spring
    o RMI (2): method invocations using RMI interfaces complying with regular RMI usage
    o RMI-IIOP (CORBA): method invocations using RMI-IIOP/CORBA
  • Enterprise JavaBean client integration
    o Local EJB stateless session bean connectivity: connecting to local stateless session beans
    o Remote EJB stateless session bean connectivity: connecting to remote stateless session beans
  • SOAP
    o Integration with the Apache Axis web services framework

Apache CXF provides integration with the Spring Framework for RPC-style exporting of object on the server side.

Both client and server setup for all RPC-style protocols and products supported by the Spring Remote access framework (except for the Apache Axis support) is configured in the Spring Core container.

There is alternative open-source implementation (Cluster4Spring) of a remoting subsystem included into Spring Framework which is intended to support various schemes of remoting (1-1, 1-many, dynamic services discovering).

Batch Framework

Spring Batch is a framework for batch processing that provides reusable functions that are essential in processing large volumes of records, including:

  • logging/tracing
  • transaction management
  • job processing statistics
  • job restart
  • skip
  • resource management

It also provides more advanced technical services and features that will enable extremely high-volume and high performance batch jobs through optimization and partitioning techniques.

[Source: Wikipedia. Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply.]

Java Technology – Hibernate [With Tutorial Link]

Hibernate is an object-relational mapping (ORM) library for the Java language, providing a framework for mapping an object-oriented domain model to a traditional relational database. Hibernate solves object-relational impedance mismatch problems by replacing direct persistence-related database accesses with high-level object handling functions. The Hibernate 2.1 framework won a Jolt Award in 2005.

Hibernate is free as open source software that is distributed under the GNU Lesser General Public License.

Hibernate’s primary feature is mapping from Java classes to database tables (and from Java data types to SQL data types). Hibernate also provides data query and retrieval facilities. Hibernate generates the SQL calls and relieves the developer from manual result set handling and object conversion, keeping the application portable to all supported SQL databases, with database portability delivered at very little performance overhead.

Mapping:
Mapping Java classes to database table is accomplished through the configuration of an XML file or by using Java Annotation. When using an XML file, Hibernate can generate skeletal source code for the persistence classes. This is unnecessary when annotation is used. Hibernate can use the XML file or the annotation to maintain the database schema.

Facilities to arrange one-to-many and many-to-many relationships between classes are provided. In addition to managing association between objects, Hibernate can also manage reflexive associations where an object has a one-to-many relationship with other instances of its own type.

Hibernate supports the mapping of custom value types. This makes the following scenarios possible:

* Overriding the default SQL type that Hibernate chooses when mapping a column to a property
* Mapping Java Enum to columns as if they were regular properties
* Mapping a single property to multiple columns

Persistence:
Hibernate provides transparent persistence for Plain Old Java Objects (POJOs). The only strict requirement for a persistent class is a no-argument constructor, not compulsorily public. Proper behavior in some applications also requires special attention to the equals() and hashCode() methods.

Collections of data objects are typically stored in Java collection objects such as Set and List. Java Generics can be used in Java 5 and higher. Hibernate can be configured to lazy load associated collections. Lazy loading is the default as of Hibernate 3.

Related objects can be configured to cascade operations from one to the other. For example, a parent such as an Album object can be configured to cascade its save and/or delete operation to its child Track objects. This can reduce development time and ensure referential integrity. A dirty checking feature avoids unnecessary database write actions by performing SQL updates only on the modified fields of persistent objects.

Hibernate Query Language(HQL):
Hibernate provides a SQL inspired language called Hibernate Query Language (HQL) which allows SQL-like queries to be written against Hibernate’s data objects. Criteria Queries are provided as an object-oriented alternative to HQL.

Integration:
Hibernate can be used both in standalone Java applications and in Java EE applications using servlets or EJB session beans.

Entities and components:
In Hibernate jargon, an entity is a stand-alone object in Hibernate’s persistent mechanism which can be manipulated independently of other objects. In contrast, a component is subordinate to other entities and can be manipulated only with respect to other entities. For example, an Album object may represent an entity but the Tracks object associated with the Album objects would represent a component of the Album entity if it is assumed that Tracks can only be saved or retrieved from the database through the Album object.

History:
Hibernate was developed by a team of Java software developers around the world led by Gavin King. JBoss, Inc. (now part of Red Hat) later hired the lead Hibernate developers and worked with them in supporting Hibernate.

The current version of Hibernate is Version 3.x. This version has new features like a new Interceptor/Callback architecture, user defined filters, and JDK 5.0 Annotations (Java’s metadata feature). Hibernate 3 is now a certified implementation of the JPA 1.0 specification via a wrapper for the Core module which provides conformity with the JSR 220 JPA standard.

Application programming interface:

The Hibernate API is provided in the Java package org.hibernate.

org.hibernate.SessionFactory interface
References immutable and threadsafe object creating new Hibernate sessions. Hibernate-based applications are usually designed to make use only of a single instance of the class implementing this interface (often exposed using a singleton design pattern).

org.hibernate.Session interface
Represents a Hibernate session i.e. the main point of the manipulation performed on the database entities. The latter activities include (among the other things) managing the persistence state (transient, persisted, detached) of the objects, fetching the persisted ones from the database and the management of the transaction demarcation.

A session is intended to last as long as the logical transaction on the database. Due to the latter feature Session implementations are not expected to be threadsafe nor to be used by multiple clients.

(This article is taken from Wikipedia. All text is available under the terms of the GNU Free Documentation License)

———

A nicely written Java Hibernate Tutorial is available here.