Electronic Commerce, Part Two: Building a Transaction

Print-friendly Version

Articles Index

A transaction is the bridge between the server-side and client-side electronic commerce applications.

In Part One you learned about the CassetteControl class and Java Commerce Messages (JCMs), which are the basic building blocks in the transaction. The next step is to learn how the transaction is built by understanding what a cassette contains and how commerce Beans are implemented. In Part Three you learn what is involved in making cassette interoperations secure.

Review: How a Purchase Transaction Works

Electronic transactions span a wide range of operations including ATM transfers, bill paying, mortgage maintenance, loan origination, and financial planning--just to name a few. This series concentrates on a generic purchase operation to help you learn the basic concepts and apply them to other types of operations.

When a shopper selects Pay on the merchant server to finalize a purchase transaction, the web server transmits the appropriate JCM from the server site to the JCC framework installed on the user's machine. Upon receipt of the message, the JCC framework queries the operation registry to find out which installed cassette is registered for a purchase operation and loads it along with the applicable protocol and instrument cassettes. If the proper operation cassette is not available or if the user lacks any cassette required for the operation, the JCC framework can locate and install the required cassette using information in the JCM.

Operation Cassette Classes

Without action, there can be no transaction. An operation cassette defines the action. An action is some activity like a purchase. Operation cassettes require one CassetteControl subclass, one operation commerce Bean--an implementation of the Operation interface class--and one subclass of the java.commerce.utl.Receipt class. If the transaction has a user interface, the cassette also requires an implementation of the ServiceUI interface class.

The implementation for the operation Bean's canUseProtocol method specifies the protocol cassettes that this operation uses. When the purchase operation is loaded, the JCC framework loads and presents the installed protocols to the canUseProtocol method.

Protocol Cassette Classes

Electronic actions are transferred between the JCC client and web server according to generally recognized standards. A protocol cassette implements one electronic transfer standard. One operation needs at least one protocol, but may be able to work with two or more as indicated in the JCM for the operation. A protocol cassette requires one CassetteControl subclass, and a protocol commerce Bean--an implementation of the Protocol interface class.

The implementation for the protocol Bean's canUseInstrument method specifies the required Instrument cassettes that the protocol uses. When the protocols are loaded, the JCC framework loads and presents the installed instruments to the canUseInstrument method.

Instrument Cassette Classes

Electronic actions are paid for with the financial instrument specified by the shopper. An instrument cassette represents a user-specific financial instrument such as a credit card. The JCM for the operation specifies valid instruments for a given web site.

Instrument cassettes require one CassetteControl subclass, one instrument commerce Bean--an implementation of the Instrument interface class--an implementation of the InstrumentAdministration interface class, a specialized CWPanel for creating new instances of the instrument, a specialized CWPanel for editing instances of the instrument, and a gif or jpeg image to represent the instrument.

Step 2: Implement the Operation Bean

Operation, protocol, and instrument Bean implementations are similar and somewhat involved. The good news is that their interface classes adhere to a general design pattern to simplify and enable commerce Bean operations. If your commerce Bean implementations keep to the pattern inherent in the interfaces and classes, the JCC framework seamlessly handles the low-level details and saves you a lot of coding, testing, and debugging time.

The JCC framework instantiates an operation Bean, and calls its execute method. The execute method performs the following initializations:

1. Fetches the set of (Instrument, Protocol[]) pairs that conform to the current JCM and are usable within the current operation.

 

2. Makes a decision regarding the instruments and protocols to use (often by presenting the information to the user for selection).

 

3. Passes the selected instrument or instruments, and JCM to the selected protocol(s) to perform the operation.

 

4. Records the results in the transaction log.

Conclusion

Different kinds of cassettes are made up of different elements. The key to writing a cassette is understanding what that cassette requires and implementing the classes according to the design patterns built into the interfaces and classes. In Part Three you see how easy the design patterns make it to add the gate and permit code for secure cassette interoperations.

Related Links

The JCC framework includes APIs for working with smart cards. JavaWorld is running a series that explains how to use them:

• Smart Cards: A Primer
• Smart Cards and the Open Card Framework
• Get A jumpstart on the Java Card

Java Card 2.0 is a framework and set of application programming interfaces (APIs) for designing and writing applets that implement smart card logic.

Monica Pawlan, a staff writer for the Java Developer Connection (JDC), is author of Essentials of the Java Programming Language: A Hands-On Guide (Addison-Wesley, 2000), and co-author of Advanced Programming for the Java 2 Platform (Addison-Wesley, 2000).

Lisa Stapleton, a former programmer, has been senior editor for InfoWorld, UnixWorld, and Open Computing. She has served as editorial director for NetscapeWorld, the JDC, and is currently consulting editor for Sunnyvale-based TechWeek.