JECF Security Model
The Java Sandbox security model supports trusted applets and untrusted applets, but not partially trusted applets. Commercial entities (e.g., businesses, trading houses, banks) operate on relationships, that have defined limited trust among themselves. To get around the restrictions of the sandbox model, JECF provides the Gateway security model which supplies the means to implement contractual trust relationships. This model uses the safety features of the Java language as well as the infrastructure of the Java Sandbox security model. It also provides the ability for developers to create arbitrary trust relationships.

The two main concepts in the Gateway model are Principals and Roles, and Capabilities. A Principal can be a person, a bank, an application program. A Role represents a right (admin, user...) and is used in the Gateway model to authenticate Tickets in a Gate. "Role" is basically a container for a public key. The Role interface, defined in the package javax.commerce.cassette, could be implemented in different ways depending on the source of the public key. The Ticket is a use-once authentication token used by a Gate. The class Ticket defines a method stampTicket (Role role) that checks that the ticket for the role is verified by the public key. The Capabilities model has four components: the client code, the gate, a credential checker and the capability object. The client code passes a token (this is of class Ticket) to the gate, which authenticates the client using the role and returns a capability object, also referred to as a Permit. (See Listing 1 to view the Permit User side code. Listing 2 shows the Gate side code.)

The gate is implemented using a pattern called a Gate, which is a specialized form of factory pattern method [GHJV 95]. The permit is based on a delegate pattern (see Design Patterns [GHJV 95]). It forwards calls to the actual implementation object. Both the permits and implementation are in the same package. The implementation, however, has only package private constructors. The permit objects need to be obtained by the client code to be useful.

The interface javax.commerce.base.WalletGate specifies methods for obtaining access to Wallet and Cassette Permits. The method getWalletUserPermit(Ticket tix) returns a WalletUserPermit if the ticket was created for a Role W_USER. The method getWalletAdminPermit(Ticket tix) returns a WalletAdminPermit if the ticket was created for a Role W_OWNER.

The interface javax.commerce.database.WalletUserPermit specifies methods for opening selected databases in OWNER or USER Roles. The method openDatabaseUserPermit(Ticket tix, String location, String dbName, String password, boolean makeBackup) returns a DatabaseUserPermit if tix was created for a role DATABASE_USER.

This should give you a good overview of the Gateway model. The purpose here is not to delve deeply into the internal mechanisms, but to give an idea of the main concepts involved and needed for this model.

I've mentioned Commerce beans previously in this article; let's take a quick look at what they are.

Commerce Beans
A commerce bean is a reusable commerce component that meets specific interface requirements. A commerce bean can be:

Commerce beans are contained within cassettes. When a cassette is installed, the JECF can make use of the commerce bean(s) it contains in order to perform commerce operations. For example, the JECF could use a purchase operation bean in conjunction with an instrument and protocol bean to perform an online purchase. Currently, commerce beans do not meet the JavaBean interface requirements; JavaSoft plans to bring them in conformance in a future release.At this stage we've covered most of the concepts in JECF, but how do the various layers communicate with each other, i.e., what is the format for communication between servers, commerce beans and WalletUI?

The format is JCM, and I'll cover that in detail, as it is ubiquitous in JECF.

Java Commerce Messages (JCM)
JCM is a format for communication between Web servers and JECF and within the JECF. Communication in the JECF takes place between servers and JECF, between JECF and commerce beans, between commerce beans themselves and between commerce beans and the Java Wallet UI. JCMs supply the JECF with the information necessary to execute JECF operations. The JECF needs to know what operation the server is requesting. The operation bean might need to know what kind of instruments could be used for a particular operation, or which protocols it can use in conjunction with an instrument. On top of this, a user can select between different instruments accepted on a site. All of this information is communicated via JCM.

Structure of JCM
The JCM format is the language of operations within the JECF; a JCM is a list of name value pairs that describes some kind of transaction. Listing 3 shows part of a purchase JCM code.

The field operation=purchase in Figure 2 causes the JECF to look for a commerce bean that contains the purchase operation.

The field offer indicates that both of these items are presented as part of a single offer that expires 02/27/98 and bears id number ....

The lineItem fields describe individual items that are part of the offer.

A JCM is parsed by the JECF in the form of a labeled tree. Each branch has a name or number. Each leaf has a value named by the path from trunk to leaf. For each value a branch is created. Figure 3 shows a parsed JCM.

A JCM is organized into this structure by the JCM parser in the JECF. For example, if a transaction in the JECF is a purchase operation, then the JCM is sent to the purchase bean. The purchase bean (operation bean) contains a JCM parser, which reads the JCM as a tree.

Operation, Protocol, Instrument
The key field in any JCM is the operation = field. This field dictates what other fields are required in a JCM. In many cases an operation requires that the JECF use instruments and protocols to carry out the operation. These instruments and protocols also dictate, farther down the tree, what fields are required in a JCM. When instruments and protocols are required, the valid field must be present followed by a subfield of either instruments or protocols:

valid.instruments = VISA

Dependencies for a given operation are identified through the requires field.

requires.cassette = buy
requires.protocol = Mondex
requires.instrument = VISA

This field is the complement of the valid field, which establishes the instruments that will be accepted on a site. The requires field establishes the cassettes the user must have installed to complete the transaction.

JCM Delivery
Servers that intend to send JCMs and browsers that intend to receive JCMs must, respectively, send and receive the appropriate MIME type header in order to open the necessary JCM handler. With respect to JECF, the handler is the Java WalletUI. The MIME type for a JCM is application/x-java-commerce. The file extension for JCM is .jcm.

Any Web site, Web server or application that is intended for use with the JECF must be capable of generating JCMs. JCMs can be generated in a number of ways, either statically (html hyperlink references a .jcm file embedded in a Web page) or dynamically (cgi scripts, applets and servelets).

Walk Through a JECF Application
Let's walk through what happens when a shopper makes a purchase from an online store. We assume both the server and the client browser are configured to handle JCMs.

We'll examine the interaction between a merchant server, The Online Computer Store, and a shopper, "Billy," who has a Web browser and a system configured with JECF, and is looking for a new computer. Billy visits the Online Store's Web site, which presents him with the various models offered. Each model has an image and a hyperlink that, when selected, loads a .jcm file. Listing 4 shows the .jcm file.

When Billy selects a link, the server sends a MIME header Billy's browser receives the MIME type .jcm, finds the handler (the Java Wallet), and invokes the handler by passing in the JCM. The JECF starts an operation thread and passes the JCM to this thread. This happens through a call to the method JECF.startOperation (JCM, AppletContext, TransactionListener). This call creates an instance of class OperationThread and invokes its run method. The operation thread performs a series of look-ups. It looks into the JCM for the operation = field. It then looks in the JECF database for the operation cassette. If the database doesn't contain the cassette, then the thread checks the requires and locator fields in the JCM to see what cassette is required and where on the Web it can be found.

Let's say, in our case, the thread finds the operation cassette in the JECF database. Next, an instance of WalletCContext is created which holds context for that wallet. The thread then creates an instance of UICContext, passing it the WalletCContext, and then instantiates OperationCContext, passing it the UICContext. OperationCContext carries context relevant to that operation. It then instantiates the operation, passing it the OperationCContext object, and sets the JCM for this operation.

Next, the operation gets the UIFactory value from its context. If it's set to some preferred value, a check is made on all installed UI cassettes to see if any of them provide those services. If not found, JECF sets the UIFactory to DefaultUI and looks for a user interface associated with this operation. In this case the purchase operation has a ServiceUI consisting of a panel with an image inside it. The purchase operation implements Operation interface and ServiceUI interface. When the purchase operation was installed on Billy's computer, the method boolean canUseOperation(Operation op) was invoked on the installed WalletUI. This method checks the interfaces of the Operation and returns true if it can accommodate the Operation's UI requirements. In this case it returned a true value. The method addOperation(Operation op) was, subsequently, called, which in turn called addSelector(ServiceUI service). A resulting Selector Button was added to WalletUI, which, when clicked, shows the image panel.

The operation first makes a secure call into the Wallet to ascertain what instruments and protocols are accepted by the merchant site. The JECF takes the valid instruments and protocols listed in the JCM and compares them with the instruments and protocols registered in Billy's JECF database. The valid.instruments field in the JCM lists Mondex Card and Visa Cash. Billy's database contains Mondex card and Visa card. The same process takes place for protocols. The valid protocols on site are Mondex and Visa Cash. Billy's database contains Visa Cash, Post and Mondex.

Billy's wallet now appears on his screen. It shows a Pay button on the right side, and the instruments appear on the middle top of the screen. The protocols appear below the instruments, and the ServiceUI panel appears on the left side of the screen.

Billy selects the icon for Visa Card (instrument), chooses Mondex for protocol and then selects Pay in the WalletUI. The JECF gives the instrument to the protocol along with the portion of the JCM relevant to the protocol. In this example the Mondex protocol sends Billy's Visa information to the value acquirer. The amount of the purchase is deducted from Billy's card and placed in the Online Store's account. If everything works, the electronic receipt in Billy's Wallet UI is stamped PAID and he can dismiss the Wallet or continue shopping. If an applet sent the JCM, the applet is notified that the transaction is complete. Control is not returned to the caller until the user closes the Wallet or dismisses the purchase operation before completion.

Electronic commerce has its unique challenges, one of them the need to interoperate with a plethora of technologies, protocols and applications. JECF solves some of these problems through its concepts of cassettes. Since it's Java-based, a JECF-based application is portable (a significant benefit). With the diverse services that JECF provides, coupled with Java's strength as a portable, object-oriented, multithreaded and well-suited for Internet-based applications, this platform from JavaSoft will form the basis for the next wave of electronic commerce products, applications and frameworks.

Acknowledgements
JavaSoft Web site was the source of information on the JCM, Security Model and Architecture Layers.

References
The JavaSoft Web site, www.javasoft.com/products/commerce has the latest information on JECF, the class api documentation, papers on jcm, security model, WalletUIs and links to related sites.