Moderator (MDR): MDR-gvoss

Guest Speaker (SPK): SPK-name

MDR-gvoss: Hello everyone, Welcome to this week's forum on Java Electronic Commerce. We'll be talking with Loren Hart (and possibly Dan Guinan) from the Java Electronic Commerce team. Specifically, we'll be discussing the Java Electronic Commerce Framework (JECF) which is both an execution framework and an API. The Java Electronic Commerce Framework is designed for use with credit-card applications, personal finance, and large scale banking. Developers of JECF applications are expected to write programs called "cassettes." You can think of cassettes as being similar to beans (if you are familiar with JavaBeans technology). In fact the JECF team is considering renaming cassettes "commerce beans." Though this may not be the actual name that winds up being applied to cassettes, the term "commerce beans" should give you a good idea of the kind of technology Loren Hart (logged in today as llh) is working on. He has worked at Sun for six years and has been at JavaSoft with the Commerce group since last September.

SPK-llh: Hello All.

MDR-gvoss: If you have any questions about Electronic Commerce, please go ahead and send them now. In the meantime I'll invite Loren to present an overview of the JECF. One of the first classifications that is useful (for this audience) is whether programmers would consider themselves cassette developers, or Java Wallet users. Loren, can you explain these two concepts of "cassette" and "Java Wallet?"

SPK-llh: Let me say that the first objective of the Java Wallet is to provide a consistant user interface for making purchases over the internet.

MDR-gvoss: As I understand it, Java Wallet is a GUI front end that is intended as a way to provide shopping and product browsing functionality to potential shoppers, right?

SPK-llh: Correct. And the relationship between the "Java Wallet" and the JECF is similar to the relationship between Hot Java and the JDK.

MDR-gvoss: Okay, so you're trying to make it easy for developers to extend the functionality of a base system that provides certain shopping (browsing) and payment (financial transaction) capabilities.

SPK-llh: The purpose of the Java Wallet is focused much more on the payment portion of the transaction. Although a cassette developer could write a shopping cart cassette.

MDR-gvoss: Both jrosario and selhorn have similar questions:

sellhorn: Is this going to be part of the "core" Java API, or an extension?

jrosario: Are these going to be included in the core API?

SPK-llh: We might get just enough of the JECF technology placed into the Java Core to enable the JECF. But there is great pressure to keep the Java Core small, so I doubt that the entire JECF will be put into the core API.

MDR-gvoss: So the Java Wallet is a specific type of cassette. Is there a useful distinction between the terms "wallet" and "cassette?"

SPK-llh: As I said before, the Java Wallet is a specific cassette. So you might have any number of cassettes, such as a home-banking cassette, or a shopping-cart cassette. The Java Wallet is basically a purchase cassette.

MDR-gvoss: I'm curious how cassettes or wallets interact. A programmer might write an application (for example a home-banking application) that needs to interact with Java code that is written by a bank or financial institution. How does this work in practice. There must be some agreed-upon protocol for these two pieces of code to communicate with each other. Is this protocol specified by JECF? Or is the protocol negotiated by those who develop the communicating pieces of the applications?

SPK-llh: All operations in the JECF are initiated with a Java Commerce Message. A Java Commerce Message (JCM) is basically a Properties file. For example, the JCM for a purchase looks a lot like an invoice.

MDR-gvoss: Can you go into a little more detail? Welcome to our second guest, Dan Guinan, also from the Java Electronic Commerce team.

SPK-llh: Sure. A purchase will start with a selection on a merchant site. This selection will cause a JCM to be sent to the client machine, where the JECF will be launched as a helper application. The JECF will recognize that the JCM is requesting a purchase and in turn will launch the Java wallet.

SPK-dguinan: Hello everyone!

MDR-gvoss: sellhorn has concerns about adding too much code to the core API:

sellhorn: If you add this to the core API, please keep it small!!! There are too many APIs and Java is getting too big. I guess you might just want to put enough code there so browsers can do "java commerce"

SPK-dguinan: If anything is added to the core JDK, it will probably be either an extension to the classloader (that will suck down the commerce cassettes the first time they are used), or a small API that performs that some function.

MDR-gvoss: Many people have concerns about security when money is involved in data being sent through public networks:

sellhorn: What kind of security/encryption mechanism does this API provide users? Do we have to program our own encryption algorithms or do you have some default protection for sensitive financial data?

SPK-dguinan: Touchy subject: As you all know, our mobility in the cryptography space is limited by the NSA. We have the base algorithms in place, but because the framework is a "framework", it should be possible for third-party providers (overseas) to add to the framework much as a third-party provider would add to an operating system. We will be releasing domestic and international (export) versions of crypto libraries containing the typical assortment of algorithms with the typical key sizes.

MDR-gvoss: Another security question from John

John: Okay, suppose I sell myself as being able to provide online transaction capabilities to merchants. What kind of guarantees can I give about transaction security? Suppose my programming is shoddy, do I assume full responsibility, or does the merchant's insurance cover that, i.e. what are some of the legal issues involved? Or is this out-of-scope?

SPK-dguinan: Liability in cyberspace is the same as in realspace. In other words the merchant is still responsible, unless they are using code (specifying protocol cassettes) that is provided by entities that offer some liability protection.

MDR-gvoss: JavaBeans and JavaCommerce seem like complementary technologies as pointed out in the following question.

randyk: I am interested in developing a way to build a micropayment-based system that will allow me to sell a package of JavaBeans, each of which may have been developed by a different developer. It would be great to track usage of each Bean (day/month/year/each time), etc., and then have a centralized-payment collection server keep track of usage so that each author could be paid a royalty. Is this possible with the architecture that you are developing, or is my use too fine-grained?

SPK-dguinan: You have a lot of work to do. Fortunately, much of the difficult payment related issues are handled for you in the JECF. Tracking usage in the Bean must be done by you. Paying for that usage can be done through the JECF (i.e. send a JCM to the JECF). If you are looking for tighter integration, you could write your own operation (to handle bean downloading, etc..) and your own microtransaction protocol.

SPK-llh: We are planning to add pre-authorized payments, which would make this scenario more friendly to users.

MDR-gvoss: We've gone a little beyond our alloted time, but we've got a couple more interesting questions in the queue. I'll post both of those and give Loren and Dan a chance to answer. If you've got to sign off, you can come back later and read the transcript. Thanks for participating.

jwpaulsen: I am curious about the different categories of developers interested in using JECF. Will companies like VISA develop objects that are available to developers of a electronic store application? What role will Javasoft play in this?

SPK-dguinan: Exactly. The idea is: Let the institutions and technology vendors provide enabling cassettes that everyone can combine and use to make money (or spend it, as the case may be).

SPK-llh: There are three different consumers of commerce software: The merchant, selling things on the Internet, the consumer that uses the wallet, and the financial institutions. Developers are likely to target one of these areas.

MDR-gvoss: One last question:

jwpaulsen: What is the comparison between JECF and EDI (electronic data interchange)?

SPK-dguinan: Apples and Oranges. However, cassettes could be written to handle EDI through the JECF.

MDR-gvoss: Loren and Dan, thanks for joining us and sharing your thoughts and experiences in the development of JECF.

SPK-dguinan: Thanks everyone -- you can forward additional comments and questions to commerce@java.sun.com. Our web page is at http://java.sun.com/commerce. And remember to download our alpha release of the JECF (newer alpha-bits will be up soon).

MDR-gvoss: Thanks everyone else for joining us and submitting some interesting questions on commerce applications, security, and financial transaction. I know a lot of programmers are thinking today about how to make money through Internet commerce. We hope that today's forum provides a starting point for those who want to become familiar with the Java Electronic Commerce Framework. So long, everyone. See you next week.