Within the past year, Java and electronic commerce have become two of the most talked-about technologies in the industry. While the use of both is growing at a phenomenal rate and both could have a revolutionary impact, neither has yet lived up to its potential. But could their strengths and weaknesses be complementary? E-commerce is still searching for common ground among all its potential payment methods, transaction protocols, and systems on both the client and server. Java is still searching for killer applications that not only take advantage of, but demand, its promise of "write once, run anywhere." Together, Java and e-commerce may be an unbeatable combination.
In this article Iıll explore where Java is a good fit for e-commerce and where it still falls short. Iıll also take a look at Sun Microsystems Inc.ıs Java Electronic Commerce Framework (JECF) and several related APIs to see how they address some of these shortcomings. And finally, Iıll assess how soon weıll be able to use the JECF in our own products and systems.
Now that the Web browser and Web server markets have consolidated around a few large suppliers, software companies have turned their attention to e-commerce. We see press releases for new e-commerce servers, protocols, gateways, and standards almost every day. But in spite of all the activity, profitable e-commerce over the Internet remains an elusive target.
For merchants and their potential customers, all the choices get in the way of doing business. Every time they make a transaction they have to consider security, how to identify themselves, and how to pay ı with few, if any, common denominators. Buying and selling soon become frustrating. People spend more time figuring out how to buy and sell than they do actually making the transactions.
The same variety of products also frustrates developers and system designers. Their biggest concerns have become:
Java has also come a long way since its humble beginnings in a research lab. Sunıs quick, intelligent positioning put Java right on the crest of the Webıs wave of popularity. Its built-in awareness of networking, databases, and security issues makes it a compelling choice for online service applications.
Ignoring the current Sun/Microsoft legal imbroglio, the main challenges Java faces in the eyes of developers are:
Although Java has gotten a lot of press and has found its way into more and more Web sites, it is not indispensable. Hardware designers see no compelling reason to go to the effort of supporting Java in their devices when there are few signs of applications that would use it. In order to keep up Javaıs momentum, Sun has begun to develop and promote new libraries and APIs for various classes of applications. E-commerce, with its high profile and broad applicability, is just the type of domain Java needs to show off its strengths.
Sun began working on Javaıs e-commerce features late in 1996, along with database access (JDBC) and enhanced security features (supporting signed applications and roles) for the Java Development Kit (JDK) 1.1. The first external release (alpha 0.1) of the JECF came in February 1997, followed by a full public release (alpha 0.5) in April. The most recent version as of this writing (alpha 0.8) was released in October.
But why do we even need a framework for e-commerce? Donıt we already have products to handle encryption, digital signatures, EDI, credit card transactions, electronic catalogs, and online banking? And where does it fit in, if order-entry, financial, or banking systems are already in place?
It is true that there are dozens of pieces of the e-commerce puzzle already available, but if you try to build a complete system, you soon realize that some systemwide context is missing. For instance, if you decide to support credit cards, CyberCash, and First Virtual as payment methods, both you and your customers will have to deal with all the different interfaces that each method requires. What if you support SSL and you want to add SET and public-key authentication? How can you be confident that data is processed and stored securely at both the client and server levels? How will smart cards fit into your infrastructure? How do you open up your proprietary protocol to allow customers to interact with you directly ı without forcing them to learn a new interface?
For solutions, you can either wait to buy turnkey systems from third parties, which will limit you to their supported interfaces and protocols and still require your customers to learn how to transact differently with you vs. other sites. Or you can develop your own framework. This may give your company some significant competitive advantages over others, but it will be costly and time consuming ı and it really isnıt your companyıs main business. Or you could adopt a framework that was developed, promoted, and supported by multiple vendors, such as Sunıs JECF.
The JECF extends Java into the application domain of e-commerce. It provides a common, consolidated framework for e-commerce transactions (including purchase and delivery). Unlike database access APIs (ODBC, JDBC) or distributed object frameworks (CORBA, DCOM), the JECF is not for general-purpose programming. For example, it does not offer any help to those building systems to persuade customers to make a transaction or those trying to enhance customer loyalty after the transaction. Those areas remain well within the purview of application developers.
Because of the specialization of so many financial transactions, the JECF walks a fine line between being too general to be useful and being too specific to apply broadly. While the JECF is intended to be a framework for all aspects of e-commerce, Sun has chosen to demonstrate its value initially by focusing on purchasing transactions. In its current form, the JECF offers a common user interface for purchasing, secure databases for local storage, and consolidation of commerce instruments (credit cards, for example). Bidding, contracts, taxes, and all the other elements of commerce familiar to EDI developers (and business managers) may be incorporated into future releases.
Iıll begin by describing the Java Wallet, the frameworkıs most visible part. The Wallet is an interface to all the JECFıs functionality from a customerıs point of view. Just as a real wallet can contain cash, credit cards, and membership cards for frequent-flyer programs, video stores, and the like, a Java Wallet can contain a variety of instruments. Each instrument can support different payment protocols, authentication methods, and so on, but it works within the context of the Wallet. Some specific instrument implementations already defined in the JECF are the CreditCardInstrument, DiscountInstrument, MicroPaymentInstrument, StoredValueInstrument, and DynamicSmartCardInstrument. The Wallet interface also supports branding, so your bank- or organization-sponsored credit cards can remain in your virtual wallet as well.
Unlike a real wallet, however, a Java Wallet can keep track of your transactions. It allows you to save preferences about yourself. It can interface directly to your bank accounts, brokerage accounts, or personal finance and tax software. It can even (under your control) allow you to share data between items in your Wallet. For example, you may want your frequent-flyer program to know about a recent car rental or your tax software to know about your brokerage accountıs capital gains.
All of this functionality is added to the Java Wallet in the form of cassettes. The Java Wallet, with the JECF overall, provides facilities for secure data storage and for passing data securely between cassettes, but the cassettes themselves implement new instruments, protocols, and software intelligence in the Wallet.
A cassette is the basic unit of distribution within the JECF. Each cassette is a Java package (JAR file) that includes code to help it download, install, and update itself automatically. This allows customers to load cassettes easily as they need them, and it lets developers offer new functionality without worrying about version incompatibilities. Unlike applets, they remain on a customerıs system between transactions. For the most part, developers will add to the JECF by creating new cassettes. To get an idea of how cassettes fit into the overall JECF, see Figure 1. Sun already includes some cassettes with the JECF, including ones for SET, credit cards, and CyberCash.
After looking at Figure 1, you may think that you still have to handle all aspects of e-commerce within your own cassettes, with nothing but the lower layers to support you. Luckily, this is not the case, thanks to one of the most powerful features of the JECF ı the ability for cassettes to interoperate securely. But this is only possible because of the security features already built in to the Java language and virtual machines.
The Java language itself enforces both strong type-checking and access modes on its objects. It avoids even the possibility of out-of-bounds memory accesses or typecasting, making it safe for multiple applications to coexist in the same address space. The Java Virtual Machine (which executes Java programs) also implements a "sandbox"security model. In this model, all access to system resources (such as the file system or networking resources) is strictly controlled by a security manager class. If an application is trusted through a verified digital signature, the security manager may give it more access to system resources ı to read from and write to local storage, for example. This is enough for many types of applications, but e-commerce demands more.
In commerce transactions, there is almost always a notion of limited trust. You give your doctor access to your medical records and your tax preparer access to your tax data but not vice versa. Or you might give your tax preparer much more detailed information on your finances than you would to the IRS. The JECF introduces a "gateway" security model to implement and enforce the assignment of roles, rights, and responsibilities for limited-trust transactions.
Gateways perform something similar to the function of the security manager in the sandbox model but at a much more fine-grained level. When one application or cassette requests a service from another, it passes a one-time "ticket"containing its identification information (or "role"), along with the service it is requesting, to the JECF gateway. The gateway, using the Java Sandbox digital signature mechanism for authentication, then determines whether or not to grant a "permit" to the requester to perform the service. If the permit is not granted, the gateway throws an exception. If it is, the requester uses the permit to access the service.
Now that you have a cassette and it knows how to interact securely with other cassettes, how do you get it to start doing something useful? In JECF, every "operation" is triggered by a Java Commerce Message (JCM). ("Operation" in this context means something like a database transaction: It is a set of actions, plus some business logic, that is carried out as a single unit.) A JCM may be viewed as a list of name=value pairs, as a tree, or as a Java object. Its format is very similar to that currently used in Java preferences. Sun plans to issue an RFC proposing a new MIME type for JCMs.
Even at this early stage of JECF development, a few design decisions have been made that might hinder its widespread adoption. First, Sun/JavaSoft has chosen to implement its own encrypted database for the framework. This may be acceptable for current (small) Java client applications, but the broad range of potential applications for e-commerce and the variety of their requirements for data storage imply the need for far more flexibility in database storage options. Second, the introduction of yet another message format in JCMs is unfortunate. Although they are simple enough to create and parse, it is an inconvenience to learn one more set of syntax rules. Perhaps JCMs will eventually be able to present themselves in whatever form is most convenient ı a mapping to an XML format might be particularly useful.
In both cases these were reasonable decisions given the uncertainty of the alternatives, the difficulties in reaching broad consensus, and the need to enter the market quickly. Over time, however, Sun/JavaSoft will likely open up the JECF database interface to allow the incorporation of external, compliant databases.
Another area that the JECF (rightly) does not address is the creation of an entire service. Even using the JECF, you will still need to consider the needs of your operations team, your customer service department, and your companyıs finance and accounting group. The JECF might help you get customer transactions securely into your systems, but the rest is up to you.
More broadly, there are some issues with e-commerce in general that apply to any framework that might be proposed, including the JECF. Most current electronic encryption and authentication methods rely heavily on the use of public/private-key encryption. This in turn requires the creation and widespread adoption of a solid key management infrastructure. Merchants, consumers, application developers ı everyone involved in e-commerce ı should easily be able to get, use, validate, and revoke the keys they need to fulfill their roles in commercial transactions. All the participants should also understand the ramifications of compromising any of the keys under their control, at least as well as people now understand the consequences of giving out the PIN number of an ATM card. As long as key management remains an arcane science reserved for cryptologists, e-commerce will suffer. The JECF will take advantage of a key management infrastructure, if one is in place, but it does not create one itself.
Related to key management, secure cooperation between applications requires the developers of both applications to communicate to each other which roles they support and negotiate cooperation between their applications before it will be allowed. The JECF provides a context for such negotiations, but it does not resolve business-to-business negotiations. As a result, creating an application with broad (but secure) interoperability could be time consuming.
Another factor inhibiting the wide-spread adoption of e-commerce, at least in the mass consumer market, is the lack of portability of client applications (for example, the JECFıs Wallet). Consumers must install and configure clients on every computer they use, and if they conduct a transaction through one computer, their other computers may never know about it. If you install a key on one computer, you wonıt be able to use it from another. And most people do not have their own computer with them everywhere they might want to conduct a transaction.
Fortunately, for issues of both key management and portability, smart cards could greatly aid the development of solutions. Their ability to store data and fit into a real wallet means they could both hold key management data and travel with customers wherever they go. And Java, with its much-touted portability, can also run on smart cards. The JavaCard specification was developed with just this in mind.
So where is Java-based e-commerce now, and what should you do about it? As of this writing, the latest release of JECF is still an alpha version. New features may be added and existing ones may still be modified substantially. Even after it is released in final form, it will be some time before the JECF is stable. If you are a fan of either Java or e-commerce, you should be closely monitoring these developments as they happen and begin experimenting with them yourself. If you have already built large, working systems based on other standards (such as EDI) and you want to use the JECF, you are probably better off waiting for third-party vendors to write the cassettes you need.
There is also still the chicken-and-egg question of market adoption. If the JECF is to be successful, it must be supported by many, if not all, of the biggest players in software, systems development, and finance. But before it will be supported, it must prove that it will be successful. Although the JECF and e-commerce in general still have some weaknesses, market potential is driving both Sun and the industry as a whole to find solutions fast. Sun continues to walk a fine line between controlling Java and all its standards and opening it up for broad industry support. Given Sunıs past successes in making NFS and NIS industry standards, I wouldnıt bet against the company now.
Sun/JavaSoft is committed to making Java a success, and the company has seen a huge opportunity for it in e-commerce. Javaıs multilayer security mechanisms and its portability make it an obvious candidate for e-commerce applications. The JECFıs secure storage and fine-grained access controls make it even easier. If Sun can succeed in making JECF part of its other Java initiatives (for example, smart cards, embedded controllers, and Java chips), it will truly be able to claim Java as the lingua franca for e-commerce.
Figure 1.
A simple schema of the JECF (adapted from The Gateway Security Model in the Java Electronic Commerce Framework, Theodore Goldstein, Chief Java Commerce Officer, Sun Microsystems Laboratories / JavaSoft, 11/29/96).
What did you think of this article? Send a letter to the editor.