JPay Draft APIs Could Be Ready By Xmas
A draft JPay JSR could be ready as early as Christmas, which would create new Java APIs to ease the design and deployment of end-to-end e-payments. JPay is backed by leaders in transaction-driven Java, including Oracle, IBM, Sun, HP and Siemens. Integration Developer News interviews a JPay exec to learn more about its impact on architects and developers.
As early as Christmas, Java execs expect to complete the first draft proposal for JPay, an new set of open APIs to ease the cost, time and complexity for supporting electronic payments.
Under the proposed JPay JSR (182) now before the Java Community Process, the JPay API will support payments in an open, Web-like environment, and specifically allow Java applications (typically Web applications or Java enabled content servers) to utilize a third-party payment service.
The proposal is being back by some of the leading names in transaction-driven Java, including Oracle, IBM, Sun, HP and Siemens, This week, Integration Developer News interviews Karsten LÃ¼ttge, a key Siemens exec driving the JPay JSR. Luttge gives IDN a sense of just what is behind JPay, how it will work, and what opportunities it presents for enterprise Java architects and developers.
An Integration Developer News interview
with Karsten LÃ¼ttge, Core Network Standardization Group
IDN: What trends in the e-commerce and/or B2B IT markets do you see occurring that requires the creation of JPay APIs? Are current J2EE and/or JMS integration techniques proving unsatisfactory?
LÃ¼ttge: Well, in terms of trends ... a lot of buzz has been around about e-commerce and mobile commerce. People are buying all kinds of goods in the internet, be it physical items such as books or DVD's, or information such as non-delayed stock exchange rates or the joke of the day.
Some more heavyweight online traders such as Amazon.com simply accept credit cards as any "real" bookstore. But when it comes to purchasing low-value items, e.g. a song for 99 cents, the overhead of a credit card transaction is too big. Collecting many transactions with multiple merchants over a billing period solves this problem and provides a new business opportunity for so-called payment service providers.
IDN: And why does this require the creation of a Java API? Why are off-the-shelf integration techniques unsatisfactory?
LÃ¼ttge: As we see it, J2EE is a typical platform on which an online merchant would develop and run his application, so it is worth to be addressed specifically. Clearly, the integration techniques provided by this platform - we are in favor of Resource Adapters, are very advanced.
However, both J2EE's Resource Adapters (through the generic Client Connection Interface, CCI) and JMS only help you to send or receive a message. In order to be able to talk to a remote system, you still need a contract telling you which operations you can invoke and which information you should send or expect to receive. JPay does exactly this.
Instead of the Common Client Interface (CCI), which comes along with the JCA specifications, we have created a specific client interface for payments. Any Resource Adapter connecting to a payment system should provide exactly this unique interface.
IDN: Can you give an example of where Jpay could open up some ecommerce opportunities for architects or devs?
LÃ¼ttge: We have seen companies offering to process small transactions and maintain customer accounts that can be used in multiple online shops, such as PayPal in the U.S., or Paybox in Europe. We do also expect mobile operators, or even utility providers, to offer such small transactions processing as a service to small businesses. These companies do have an account management and a billing system in place; allowing online merchants to use it just adds another feature and allows generating additional revenue through transaction or subscription fees.
IDN: What types of enterprise Use Cases do you envision from JPay?
LÃ¼ttge: It depends on how you define enterprise. We see a couple of stakeholders using Jpay.
(1) First, providers of payment services would be using JPay as the technical description of how to interface with their system. They would basically say, well, if you want to use our processing services, your J2EE application needs to sit atop the JPay API. We will provide you with the appropriate Resource Adapter; also,
(2) Vendors who implement a payment server product and sell it to payment services providers would also implement a Resource Adapter as a client-side stub. By doing so, they can chose whatever protocol between their server product and merchant system. The Resource Adapter would hide from the ecommerce application all the specifics of that protocol; and last but not least,
(3) Vendors of online stores or other ecommerce applications would build their products on top of JPay. They can test their products against the JPay reference implementation, which Siemens is currently working at, so they can do their development independent of the payment service provider they plan to use later on. The same ecommerce application could use different payment services providers in different deployments.
In an ideal world, your mobile operator (or utility provider) could offer a subscription package. If you plan to run your own ecommerce application in your garage, you get this package, consisting of credentials for authentication, the IP address of the server, and a CD with the JPay resource adapter and the JPay documentation.
You are able to run your ecommerce application without the hassle of creating, sending and tracking bills. Your mobile operator, or whatever payment service provider you have chosen, just sends you your earnings at the end of the month. You do not even need to explain what you plan to do.
IDN: How would JPay eliminate complexity of supporting electronic payments in a web or SOA environment? Will JPay work equally well for EJB 2.0 and EJB 3.0 J2EE?
LÃ¼ttge: JPay allows eliminating complexity by hiding a lot of functionality in the resource adapter implementation. For example, authentication of the ecommerce application towards the payment server is an issue; there are many ways of doing it and the ecommerce application developer may not be an expert in security issues.
Also, the type of credentials being used for authentication may vary in different deployments, although the logic of the ecommerce application is still the same. So we expect that the authentication is handled by the resource adapter. The deployment specific credentials for authentication are configured into the resource adapter upon deployment.
As I have described earlier, we expect that you will get the resource adapter implementation and the authentication credentials from the same source, e.g. from your mobile operator. All you need to do is deploy the resource adapter into your J2EE container and configure your authentication credentials.
IDN: Interesting, and with SOA?
LÃ¼ttge: About SOA - as I see it, SOA is about loosely coupled services that you discover and use as needed. It is more an ad-hoc style thing. This won't work for payment. In order to let somebody else handle payments for you, you need a long-term business relation with them. They will maintain an account for you which hold your earnings over a period of, say, a month. They need your bank account in order to transfer your earnings at the end of the month. Setting up such a business relation is not part of the JPay specifications.
We expect it to be in place when you start using JPay. As I said earlier - you may go to your mobile operator and buy a package. At that time, you will certainly leave your bank details and your address information. So you have established a formal, long-term business relation with that operator. This is different from what SOA stands for.
IDN: What suggestions would you have for IT professionals (architects, developers) for preparing to use JPay? What types of skills would you expect Java/J2EE developers need (might they include XML, metadata, workflow, security, persistence, etc?)
LÃ¼ttge: We tried to keep the API as simple as it can be. So, if you are creating and application on top of JPay, XML knowledge is not needed, persistence is needed only to the extend that you need it for your own application. Security - we do expect that the J2EE container handles it for you. Whatever needs to be stored regarding payments should be handled transparently by the resource adapter implementation.
IDN: What is your timeframe for draft review? Do you have any other co-signators or supporters (vendor or end user) for the JPay JSR?
LÃ¼ttge: The early draft review ends formally on December 25, 2004. We are at this time receiving comments from experts from all industries. We'll need some time to review them; we do expect slight changes to the specs, which should be completed early next year. So stay tuned to our homepage for the final release.
By the way, our JPay homepage is http://www.jcp.org/en/jsr/detail?id=182.
On our homepage you can also find the participating companies for JPay: Cingular Wireless, Hewlett-Packard, IBM, ,Oracle, Siemens AG, Sun Microsystems and a few private individuals including a representative from JPOS, an Open Source, Java based financial transaction framework.