Java APIs: Playing Monopoly with Java via the JECF

Online commerce takes new steps with the Java Electronic Commerce Framework

In my recent trip to New York, I dropped by the Forbes Museum to see the collection of Faberge Eggs, toy soldiers, and original Monopoly board games belonging to the empire of the Forbes family (which is most well known, of course, for Forbes magazine). Almost anyone who has played a board game is familiar with Monopoly. The principle of the game is simple enough that even an 8-year-old can play. The amazing thing is that it has lasted well over 50 years with few changes and still remains a success.

The creation of a concept that lasts like Monopoly happens rarely. This decade we will see a similarly successful and long-lasting concept emerge, a new concept that takes financial matters into a different dimension: global online electronic commerce. The interesting thing is that it places quite a large emphasis on the network that is supposed to survive a nuclear attack but has at one time or another fallen prey to rampaging teenagers.

For a relatively insecure environment such as the Internet, there is quite a significant amount of development for future online commercial transactions. With the recent test release of the Secure Electronic Transaction (SET) system, we see the next generation of online commerce efforts backed by such giants of the financial industry as Visa and MasterCard as well as computer industry bigwigs like IBM, Netscape, Microsoft, and SAIC.

In addition, the established secure communications protocols and standards such as SSL and RSA continue to thrive in their own area of the transmission of high-risk information such as credit card numbers, financial information, and personal data.

With these ongoing efforts, you might have wondered: "What about providing interfaces to these systems through Java? Sun and JavaSoft would have had to be pretty blind if they were to ignore the future of financial transactions, right?"

Well, don't fret. The Java Electronic Commerce Framework (JECF) will provide the programmatic interface for your Java applets and applications. JECF is the set of APIs that will help you develop commerce applications.

JavaSoft will surely release commercial server applications incorporating these APIs. But as always, do not confuse the API with the implementation product.

How JECF works

The simplest way to describe JECF is to give an example scenario of how JavaSoft envisions online transactions will function. Typically, this involves a user with a browser (capable of running Java, of course) who visits a site with JECF-based services. This JECF-based service can appear in the form of an online-store Java applet in your browser, or it could be a specific Java application on your machine.

Once you have selected the item you wish to purchase, you click on the button on the applet to pay for the goods. Using a payment cassette module in the applet, a message is sent to the remote server indicating the purchase. When the cassette is received, the browser will then display three new applets:

  • A seller identity applet provides a secure authentication of the online store vendor.
  • A tally applet shows a description of the items you wish to purchase.
  • A payment instrument selection applet will show you the payment options you can choose, such as payment by credit cards, debit cards, checks, and other means.

Here's where the JavaWallet comes in. The Wallet holds a set of online credit or debit cards. Each card has your unique card number and identification information stored locally on your system. This encoded information is passed to the store server each time you purchase an item or a basket of items.

In the background, your card identification information is taken by the remote vendor's online store software and relayed to Visa, MasterCard or another online credit clearing house, along with details about the item to be purchased. This information exchange can take a few seconds or several minutes depending upon the complexity of the purchase and protocol used to convey this data. This is similar to waiting for your credit card to finish processing once you run it through a credit card terminal at a retail store.

When the transaction is sent to be processed, it is stored on a pending transactions list on the local computer. If you should get disconnected from the network or your machine should crash while it is still processing, the next time you start up, you will be able to retry the purchase or back out of the transaction if necessary. When completed, this transaction is stored in the permanent transaction register, which keeps a history of all purchases made through the system. The information in this same register could be used by other applications. For example, your personal banking software could grab this data and subsequently balance your books automatically each time you purchase a product.

JECF components

The JECF implementation architecture from Sun consists of the following components:

  • Infrastructure
  • Database
  • Payment Cassettes
  • Service Cassettes
  • Administrative Interfaces.

The Infrastructure component provides the interaction mechanism between the other components. The Database stores permanent records of personal information, transaction history, and a list of the types of payment instruments the user has available.

The Payment cassettes are implementations of the various payment instruments and their associated protocols. For example, a Visa credit card and a Bank debit card would be involve two different payment cassettes. The service cassettes provide JECF services to other applications based upon your purchases. Our personal banking software keeping track of purchases would be one example.

And, finally, the Administrative Interfaces constitute the dialog windows and configuration units that control and customize the behavior of your JECF system as a whole.


Due to the financial nature of JECF code, it is certainly prudent to review the nature of the security elements behind this API. In addition to the secure functions of Java such as Signed Applets, which provide unique identification and security for applets sent over the network, access regulations, etc., JECF introduces other elements and modifications to the Java environment. Some of these security elements like the Signed Applets have yet to be released along with the formal Java Security API specification.

The core functions of user identification, authentication, and authorization are performed locally on your machine. Password protection and unique user information is performed and stored on your system, and none of this data is sent over the network.

When the applet is loaded, the Class Loader object is set to execute in a limited environment and calling programs are checked for their digital signature for uniqueness. When a JECF object is invoked, the invoking program or application is checked for its role. These roles dictate the available resources and security levels and control that program's interface to the JECF code. A local database contains these access control lists and role information. Each Payment and Service cassette with its specific roles must be signed by a trusted authority before use to guarantee the identity of the originator.

Each cassette's identity is established at the time of signing. This Identity class itself is not directly transferred between objects; instead, a Ticket is generated as a representative for the identity. If the identity were to be directly transferred, the calling cassette could attempt to impersonate the originator and thus break security. A Ticket object is for one-time use only, and once any of its methods are invoked, the object is thrown away. This prevents illegal reuse of a Ticket.

Eliminating bank errors

Error management in the financial computer industry is at least as important as security. There are all kinds of errors, ranging from the human-interface error to communication interruptions. JECF deals with the latter. JECF's error management strives to facilitate a consistent method of error recovery, a consistent error-reporting system, and internationalization of error messages.

Errors for JECF are implemented as Java exceptions. So far, a list of error classes have been identified:

  • Configuration errors for cassettes.
  • Data Corruption errors of information in transit or the corruption of the password and initialization files of the database or cassette.
  • Communications failure errors of a variety of forms.
  • Transaction failure errors due to insufficient funds, incorrect currency, bad credit, etc.

The error classes and exceptions are still being refined, and new ones may be added to the list before JECF is released.

Broader uses of JECF

Although we have used the example of an applet interface to an online store, there are many other uses that we have not yet indicated. For example, JECF can also be used for services that are not necessarily payment-related. This includes electronically signed documents such as proposals, bids, and contracts; and tallies such as invoices and statements.

Applications that might use JECF include purchasing and inventory databases, online stores, personal banking software, automated teller machines (ATMs), online reservations systems, document and contract management, legal document management, and billing services.

Currently JECF is still under development by JavaSoft. The good news is that JECF is not based upon a specific electronic commerce protocol. The development of a functional e-commerce protocol like SET takes a lot of work and industry cooperation. JECF leaves the actual protocol standards and mechanisms to others and concentrates on how to make the actual usage of these protocols on an implementation basis work; it still give a lot of programming independence to application builders.

Most of the new developments for electronic commerce are sound ideas, but only practice makes perfect. In a controlled environment like Monopoly, where the risk is loosing play money when you land at Boardwalk (or Mayfair if you played the British version like I did), there are few unknowns and misdirections, and even these are worrisome only for the brief period you are playing.

With the future world of finance at stake, any mess or miscalculation can cause the loss of millions of real dollars -- even if it lasts for a brief second. It is good to know, however, that the Java industry is taking steps to ensure a standard that will bring this technology carefully to life.

Rawn Shah is vice president of RTD Systems & Networking, Inc. He has watched the Java industry from its early emergence in 1995 and writes and gives presentations regularly on the subject. He is currently working on his fifth book, which focuses on Java-based authoring tools. Rawn's favorite Monopoly token is the little Irish Terrier.

Learn more about this topic