Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Survival of the fittest Jini services, Part 3

Implement transactional Jini services

By Frank Sommers, JavaWorld.com, 10/19/01

In my last Jiniology article, I described distributed transactions that enable multiple Jini services to reliably coordinate their work to support a common objective: When services enroll in a transaction, they guarantee that any outcome agrees with a set of conditions, or invariables.

For example, an online bookstore, implemented as a Jini service, uses a credit card service for payment processing. By enrolling the credit card service in a transaction, a purchase guarantees that either the credit card is charged and the book ships, or that neither action takes place.

A transaction promises certain computation invariables that define the transaction's semantics. Jini lets you implement any transaction semantics. You can decide what guarantees cooperating services must provide, and implement your services according to those guarantees.

Regardless of specific invariables, you can use the Jini transaction coordinator to arrange your transaction's commitment, employing the two-phase commit protocol. In Part 2 of this series, I described how you use that coordinator as a client for the two-phase commit protocol. In this article, I will focus on techniques for writing transaction participant Jini services.

Read the whole "Survival of the Fittest Jini Services" series:

• Part 1. Ensure the quality of Web services in the age of calm computing
• Part 2. Use transactions to coordinate the reliable interaction of Jini services
• Part 3. Implement transactional Jini services

Jini, transaction monitors, and application servers

While Jini affords you the flexibility to implement any type of transaction semantics, you want to ensure that, at the minimum, transactions preserve your services' information integrity. To this effect, the Jini Transaction Specification describes a default transaction semantics, guaranteeing the ACID properties: atomicity, consistency, isolation, and durability.

As you shall see, you need the ACID properties to preserve the integrity of shared data. Most transaction processing systems -- including those used in many J2EE (Java 2 Platform, Enterprise Edition) application servers -- automatically enforce these guarantees. Commonly, you can enforce transaction semantics by maintaining containers in which objects can execute during transactions. You can then make these containers ensure transactional semantics for the objects they manage. A significant portion of a J2EE application server's code maintains container objects and their relationships to business-specific Java objects. At the price of increased system complexity, automating transaction management offers you convenience. This convenience is one reason for the success of transaction processing (TP) monitors, as well as J2EE application servers.

Most programmers are familiar with transaction processing in database management systems (DBMS) as well as application servers. Commercial DBMS products often provide an API for accessing transactions from client programs. In the JDBC (Java Database Connectivity) API, for example, the java.sql.Connection interface lets you control a transaction's commitment via the commit() and rollback() methods. When programming with JDBC, you don't have to know how the underlying DBMS guarantees a transaction's semantics -- the DBMS automates that task for the objects (records) it manages, and the API acts as a facade to that functionality.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.