Let me first intoduce PurchasePro.com, Inc. - a provider of Internet B2B electronic commerce services. The company's e-commerce solution consists of public and private "e-marketplaces" where businesses can buy and sell a wide range of products and services in an efficient, competitive and cost-effective manner. It was built using Microsoft technologies such as COM and SQL Server.
Until recently, our procurement solution was in the form of a Windows "fat application" that used a custom communications medium called the Datapipe to connect to our Microsoft SQL Server database. There were advantages as well as some inherent disadvantages to this approach. One of the advantages was that businesses rely on Microsoft to provide complete solutions for their technological needs and some businesses won't let non-Microsoft technology be a part of their solution. Another was that the learning curve for these technologies is fairly low, thus there are more qualified candidates to do the job.
The foremost disadvantage, however, was difficulty of maintenance: in an environment in which new bug fixes and hot fixes for major security holes are constantly being applied and released, keeping everyone up to date became a nightmarish task. Admittedly, the problem wasn't necessarily attributable to Microsoft technologies alone, but the frequency with which we needed to apply service packs and hot fixes was astronomical.
A second drawback was that, in releasing our solution as a Windows-executable only, we limited our market. Anyone not meeting the minimum requirements for our client application either had to buy a new computer or not use our solution. And third having the business logic in our fat application hindered us from rapidly implementing the new and improved features that keep us competitive.
Disadvantages like these prompted us to move from a client/server solution to a Web-based application and n-tier architecture. Moving to a Web-based solution not only opened new markets to us but allowed us to move toward implementing a true middle tier and to switch our back end from Microsoft SQL Server to Oracle. Currently our middle tier is built using Microsoft COM technology, which leverages object-oriented features such as reusability and encapsulation. Using COM allowed us to use the existing hardware and software to build a better, more robust solution. Our system integrates and interfaces with external systems using technologies including XML, EDI, OBI (Open Buying on the Internet) and various text file formats (see Figure 1). The current middle-tier architecture, though robust and solid, limits us to the Windows platform and, of course, to PC servers. With our exponential growth, outgrowing PC servers was just a matter of time.
Moving Beyond Microsoft COM
When examining possible technologies to move our middle tier into, Java - especially J2EE - presented itself as the clear winner.
The current J2EE specification provides many features ideal for solving problems. In particular, the EJB and XML technologies are perfectly suited to our needs. We needed a solution that would run on our existing hardware as well as on any hardware that we introduce into the middle tier in the future. One of Java's key selling points is the concept of "write once, run anywhere." Although the slogan doesn't hold completely true, making little or no modifications to the code to make it run on a completely new platform is definitely better than completely rewriting the code.
We also didn't want to be dependent on one vendor for key elements of our solution because at present we're at the mercy of Microsoft for bug fixes, enhancements and support. With Java we're able to switch JVMs, application server vendors and so on at will, if necessary. Scalability of our solution was another critical factor in our decision-making process. COM allows us to grow horizontally, but the lack of support for the Alpha platform in Windows 2000 means that there's no vertical growth. Java's ability to run on various platforms once again played to its advantage. In order to achieve vertical growth, all we have to do is buy a more powerful machine, even if it means that we have to switch the hardware platform and operating systems.
Our new middle tier will be database-independent and will consist of EJBs and servlets (see Figure 2). PurchasePro.com's own blend of XML will be used extensively in this new design. EJBs allow us to separate the database layer from the business logic. Most, if not all, of the business logic will reside at the EJB level in the new architecture, which will allow us to change databases or add additional layers of abstraction as necessary. By implementing EJBs, we'll be able to leverage such features as application-server-based caching, transactions, resource pooling and security. Servlets, combined with XML and XSL, separate the presentation layer from the core business logic. Servlets will match the XML with the XSL and process it through the XSLT engine to generate the required file whether it's HTML, WML or whatever.
One of our biggest problems is that our presentation layer programmers not only need to know the ins and outs of designing a user interface but are also required to be intimately familiar with PurchasePro.com's complex business logic. Currently, a tremendous amount of time, about a month on average, is spent bringing the presentation layer programmer up to speed on our business logic. By completely separating the business logic from the presentation layer, the presentation layer programmers can concentrate on designing more functional and efficient user interfaces instead of worrying about implementing the business logic.
One of the most requested and popular features in our current system is the use of a custom "skin." A skin allows for a change in the look and feel of the Web application. Using skins, we can change the logo, color schema and so on. Even with skins, the basic look and feel of the Web application remains unchanged. By leveraging XML and XSL, we can achieve a look that is truly customized. For example, a customer can display the purchase order in the same layout as their paper-based purchase order and even include their logo. We can format the same purchase order to be viewable on a PDA. As far as the form of presentation goes, the possibilities are endless - and it'll be as easy as creating an XSL sheet.
Redesigning Our Enterprise Resource Planning
With the redesign of the middle tier, our ERP interface and integration architecture needed to be redesigned as well. Currently all new projects involving ERP interfacing need to be written from scratch, and integration projects need major reworking in order to deploy them. Needless to say, this process is very time-consuming and tedious. Even though we have standardized methods of interfacing to - or integrating with - our system, there aren't any abstract classes that expedite such common chores as logging and error notification. We also create a separate executable for each interface that we create.
To alleviate the problem, the new architecture will have classes that execute tasks such as logging, error notification and setup. All interfaces will be dynamically loaded plug-ins to the main servlets. Since common tasks needn't be reprogrammed for each interface, turnaround time will be greatly reduced. The new architecture will not only have existing features such as extensive logging, pager and e-mail notification of errors, it will also implement new features such as message queuing and tighter integration with ERP systems through the use of OnDisplay's
(www.ondisplay.com) CenterStage suite of tools.
Instead of building a custom interface to each customer's ERP system, we'll be using OnDisplay's certified interfaces to systems such as SAP, Peoplesoft and Oracle. We'll use OnDisplay's document transformation tool to handle most of our document transformation to formats such as EDI, delimited text file and fixed-width file.
FTP has been one of the most popular methods of transportation in exchanging documents for our clients, mainly because it's readily available. But the problem with FTP is that it doesn't guarantee the delivery of data, and queuing needed to be done by a separate application - an added cost to our clients. Nor can FTP be used in a real-time environment, which is fine for most clients but for those who require real-time transactions we needed to create custom programming to satisfy their needs.
With the recent release of XMLConnect, a free product available at www.xmlconnect.net (provided by OnDisplay), guaranteeing the delivery of data has become a reality for those of our customers who couldn't afford a solution. Despite the name, XMLConnect can transport many types of files and can be automated using its available (though rather limited) APIs. XMLConnect's ability to communicate with the CenterStage suite allows us to let clients who might not be able to afford OnDisplay's CenterStage suite exchange documents with us. It can be used in a real-time and a batch-mode system.
XML integration is becoming popular in the enterprise. Technologies such as the cXML (www.cxml.org) punch-out model allow us to integrate with customers that already have an electronic catalog available on the Web. Seamless login using XML is another popular method of integrating with our system. A DTD has been created specifically for use on seamless login and we'll continue to support cXML punch-out with clients who currently use it. We're developing DTDs for all of our documents and functionality so that the clients who wish to create their own application can do so and still communicate with us as if they are using our Web application. The problem with XML, as far as using it for B2B document exchange is concerned, is that there's no standard such as EDI's X12. Since we can't force our flavor of XML on all our clients, we need a method of transforming the various XML documents to a format usable by our middle tier. We'll create an XML gateway to receive all sorts of XML documents and transform them into our proprietary format. The transformation engine will free our middle tier from worrying about translating different types of documents and concentrate instead on processing them. The transformation engine will not only receive different XML documents but will send them to the appropriate client as well.
One of the toughest challenges we've faced and continue to face during this migration concerns the speed of our solution. Or lack of it. Although our Java architects and programmers have yet to fully optimize the new architecture, preliminary results are less than promising. In certain tasks the new solution runs almost twice as slow as the current system. We were able to track down the main cause of our problems: one of our biggest bottlenecks is the Oracle JDBC driver. Under a simulated load of 50 concurrent users, almost half the time is spent in the JDBC driver. We've yet to find a suitable replacement for the driver.
Coming from a Microsoft background, I've found the IDEs for Java to be less than adequate. We have tried a variety of IDEs and reluctantly settled on Sun's Forté for Java. I know that the IDE doesn't matter in the end product, but it sure is nice to work with an IDE that increases productivity rather than decreases it.
The lack of a frozen code base has always been a challenge for us. Even though we'd like to freeze the code, the speed of growth of our company and our customer base makes it impossible to freeze the code long enough to carry out a major task such as converting to a Java-based middle tier.
Chris Kang is a lead ERP interfacing programmer at PurchasePro.com (
www.purchasepro.com). A Microsoft certified professional, Chris is also involved in the Java migration of the whole middle tier.