In-Depth

J2EE bridges the legacy gap

• By Frank Teti
• June 1, 2001

Typically, dot.com Internet forward engineering is characterized as being "green field," with virtually no in-place environments that tend to bias technology decisions. From an architectural perspective, it doesn't get any better than this. But on the other hand, Fortune 1000 firms' technology environments have ugly legacy systems, which can challenge even the most seasoned architects and hamper progress toward more modern architectures. Still, e-commerce solutions cannot ignore the considerable investments that corporations have made in these environments.

Today's e-commerce strategies are all about opening up various back-end office applications to external customers. Even large corporations are grappling with fundamental technology decisions, such as whether to choose J2EE or .NET for Internet development. For professional service firms that consult with Fortune 1000 corporations, there really is no alternative but to support both technologies, since the consensus among "more balanced" analysts is that there will be a near-term stalemate, with J2EE and .NET claiming equal shares of the market.

Even if members of an organization can decisively answer whether they want to be platform-independent or XML-enabled and language-independent—that is, choose J2EE or .NET, respectively—it is usually not possible to reach corporate-wide consensus on a clear, definitive standard. However, the J2EE architecture is a better fit for organizations interested in reengineering and integrating with legacy applications via the Internet. Still, attempting to standardize has been a relentless IT objective, ever since software became unbundled from hardware in 1969, which many IT pundits peg as "year one" of the software industry. Once an organization decides to standardize on J2EE, it is immediately faced with a stream of associated IT decisions:

• What Internet hosting platform should be used: Sun Ultra Enterprise with Solaris 8, IBM RS6000 SP2 with AIX 4.3.3, or IBM S/390 running OS/390 V2R6?
• Or should there be multiple hosting environments?
• What is the best HTTP server?
• Which J2EE vendors should be evaluated?
• Which is the best DBMS environment?

For corporations that are interested in providing true e-commerce functionality, the answer to these questions really lies in the selection of an application server and the available packaged solutions for that environment. However, resolving this issue and balancing it with existing technology investments is not a trivial decision on an enterprise-wide scale (see Fig. 1).

Figure 1

Selecting an application server and packaged solutions available for the environment, and balancing them with existing technology investments is not trivial on an enterprise-wide scale.

The re-emergence of methodology
Confronted with related but disparate decisions, some sort of methodology needs to be invoked. It is becoming abundantly clear that complex e-commerce projects have brought about the re-emergence of the methodology, whether it is for security risk and vulnerability analysis, full life cycle development, or the selection of Internet-related enabling technologies. Internet deployment has required most life cycle methodologies to be revamped. To determine core Internet technologies, a simple, but effective, approach is:

1. determine e-commerce initiatives,
2. identify existing applications impacted by these initiatives,
3. evaluate the best ways to reengineer or interface with existing applications,
4. select a J2EE application server standard and
5. define reference architecture(s).

Determine e-commerce initiatives
Whether in Internet terminology you call this options analysis or business requirements, it is important to understand what the digital strategy is before you start executing tactics. It is amazing how often developers are put on the ground to build a reference architecture when basic details about the business model are still unresolved.

Identify existing applications impacted by the initiatives
Based on high-level business requirements, existing applications that need to be exposed to the Internet can be identified. For example, enabling order processing or tracking via the Internet might impact three disparate systems: an OS/390 CICS COBOL application, an NT data warehouse and a Unix Customer Information System. There is a recursive relationship or feedback loop between business requirements and platform requirements (see Fig. 2); even during high-level analysis, certain integration techniques may not be viable from a business process or cost justification standpoint.

Figure 2

There is a recursive relationship or feedback loop between business requirements and platform requirements.

Evaluate state-of-the-art mechanisms for integrating with existing applications
Understanding the nature of the integration requirements gives you solid technical detail on the requirements for the application server. Additionally, highly scalable application servers integrate with external environments using gateway and adapter technologies. These features are a must-have for dependable and robust legacy integration.

Gateway connectivity is probably the most common method of communication for e-commerce applications. IBM Gateways are available for relational databases using JDBC and transactional processing systems using CICS, MQSeries and DCE Encina. The MQSeries Gateway provides a Java-based Queue Manager, which executes within the middle tier and manages asynchronous messaging to MQ-enabled applications on various back-end systems. Cutting-edge support, such as XA-style, distributed transactions are not a mandatory part of the current industry-supported J2EE version 1.2.1, but for J2EE 1.3 they are. So, if high-level technical analysis indicates the need for integration with a queuing service and a DBMS in one unit of work, then an application server that supports XA and includes a TP monitor is probably a stiff requirement. Examples of XA-compliant resources are: Oracle, MQSeries and Sybase.

For the most part, adapter connectivity encompasses the enterprise JavaBean APIs. Essentially, EJB still relies heavily on CORBA services for external system integration. In this model, entity beans are mapped directly into back-tier application servers. For example, BEA's eGen is a command line utility that generates Java source using a COBOL copybook and a small declarative script file as input. The result is a working Java skeleton application that can be used as a basis for new applications or as an addition to an existing application. It can generate a combination of a servlet for presentation and EJB for business logic. All generated skeletons include code that implements connectivity and data translation to CICS or IMS.

Programmers who maintain legacy applications typically violate the Model-View-Controller technique, which requires the separation of the business logic from the presentation. The corporate rationale for this usually starts from an assumption that the applications will be retired soon, and concludes that embedding pricing logic within application code to quickly satisfy a marketing campaign's needs is good enough for the interim. In this case, integrating with the data of the application is not enough; integration directly with the application is needed for consistent business transactions. Therefore, creative solutions, such as re-engineering an existing EDI interface or providing basic terminal emulation to a host S/390 through standard Web browsers, can provide integration with little to no programming of the legacy applications. Depending on the constituency—extranet or intranet—crude but effective solutions can take care of business. On the bright side, hands-down, character-based order entry systems can still be highly productive.

MQSeries or TIBCO can provide a reliable mechanism for integrating with an EDI interface. Simpler solutions, such as FTP, are not recommended, because they require persistent storage, commit/rollback functionality and fault tolerance to be custom developed. Both BEA and IBM have emulation services delivered through standard Web browsers. IBM's WebSphere Host On-Demand provides basic terminal emulation through a standard Web browser that will render an austere interface to the Internet customer. It also provides security functionality, permitting the encryption of both Web-to-host and Web-to-client sessions. BEA WebLogic Java Adapter for Mainframe utilizing SofTouch from CrossPlex addresses the need for reuse of any existing 3270 mainframe application, without the need for mainframe coding changes. (Any discussion of J2EE back-end integration would be incomplete without mentioning the Java Messaging Service (JMS), a form of Message-Oriented Middleware (MOM). MOM provides a common, reliable way for programs to create, send, receive and read messages in any distributed enterprise system. MOM ensures fast asynchronous electronic communication, guaranteed message delivery, receipt notification and transaction control. JMS provides a standard Java-based interface to the message services of a MOM of some other provider. Essentially, JMS has two different models—Publish/Subscribe and Point-to-Point Messaging.)

Table 1: Application server packages and OS considerations
	BEA WLS	IBM WAS
Sun Solaris 8	Main platform for highly scalable BEA implementations. BEA offers WebLogic Commerce Server, an e-commerce business package; however, it has a better reputation as a J2EE framework, rather than as a vertical business package ISP. An evaluation of Blue Martini's vertical eCommerce solutions should also be considered. However, BEA is definitely expanding into verticals with personalization recently added to Commerce Server.	At the end of Q1, IBM released Commerce Suite 5.1 for Oracle on Solaris. Interestingly, IBM has scheduled NT and Solaris before AIX for Commerce Suite 5.1 releases. IBM offers financial industry-specific solutions for: S.W.I.F.T. and Telex networks, risk management and straight through processing, and other banking-specific applications. Clearly, IBM wants to be a Wall Street player even if it isn't on their own hardware.
Microsoft NT	Blue Martini's Customer Interaction System is available for Intel NT 4.0 SP6. Blue Martini's infrastructure relies heavily on BEA's application server platform. This is a testimony to the strength of the BEA platform. Blue Martini also uses Blaze, an IBM company, for personalization.	Last November, IBM delivered WAS Commerce Suite 5.1 for UDB on NT. This was the first implementation of Commerce Suite 5.1. IBM is really pushing UDB (DB2) and packages it as a runtime DB in this environment, but its position is that WAS is a cross-database platform.
IBM AIX 4.3.3	BEA is certified for this environment; however, Blue Martini's B2B Customer Interaction System does not support AIX.	Although AIX is on the IBM WAS Commerce Suite release schedule, AIX does not appear to be a tier 1 platform. Support for WAS Commerce Suite 5.1 for Oracle AIX was available at the end of Q1.
IBM OS/390 V2R6	I do not believe BEA is the best choice for mainframe-hosted computing, although BEA does have Java Adapters for Mainframe Connectivity with CICS and IMS. With CICS, the Java application request/response operations interact using InterSystem Communications/Distributed Program Link (ISC/DPL). Mainframe CICS Servers are invoked as if the request originated from a DPL, executed in a partner CICS application.	IBM Commerce Suite is not scheduled to be released on the OS/390. For business logic, production EJB should not be deployed on WAS/390 until EE v4.0; use Java BO instead of EJB. Another consideration is to temporarily abandon the EJB scenario and build a JSP/Servlet and JavaBeans-based application on WAS/390 SE, and migrate the application to the EJB programming model (some rewrite required) in the "v4.0" timeframe.
Source: Frank Teti

Select a J2EE application server
With a solid understanding of the technical integration requirements based on e-commerce business functionality, a fairly informed decision on an application server can be made. An application server is the heart of any e-commerce solution.

IBM's WebSphere Application Server (WAS) and BEA's WebLogic Server (WLS) are clearly the market leaders in this space. Advanced application servers such as WAS and WLS have vertical market, e-commerce packages written for the application server. Identifying whether your e-commerce requirements are characterized as having standard e-commerce functionality or being more custom in nature can aid in selecting the appropriate application server. Standard e-commerce implementations can take advantage of "out-of-the-box" functionality such as cyber-payment and product catalogs.

WLS and WAS can be configured to run in the same process as the Web server or in a separate process. Running WebSphere "out-of-process" is preferred for high availability and large-scale configurations.

Table 2: Web server considerations
	BEA WLS	IBM WAS
Unix	BEA includes an HTTP server; however, static page serving is not a strong feature. Apache with WLS would be a preferable architecture. WLS 6.0, however, does add a number of new Web server features, such as virtual hosting, HTTP 1.1, fast static page serving, direct integration with hardware/software Web routing like Resonate and Cisco Local Director, and integrated user management.	WebSphere Application Server includes a copy of IBM HTTP Server, which is an enhanced version of the Apache Web Server. The IBM HTTP Server can be installed automatically as part of the WebSphere installation process for customers that do not have a Web Server.
IBM OS/390 V2R6	BEA is certified on the OS/390, but is not necessarily recommended for this platform.	To develop a two-tiered solution by hosting the HTTP server on OS/390, IBM's HTTP Server for OS/390 (once known as Domino Go WebServer) will have to be used; it is already a part of OS/390. WAS/390 executes as a plug-in within the IBM Web Server. In a future version, an OS/390 version of the IBM HTTP Server Powered by Apache may be provided as an additional option.
Source: Frank Teti

Defining your reference architecture
After the selection of your application server, rudimentary reference architectures can be drafted. A reference architecture should depict major processes, services, servers, persistent storage mechanisms, daemons and their associated protocols required for integration.

At this point, a Web server, an application server, host operating systems, a DBMS and optional package environment—Commerce Suite, Commerce Server and so forth—should all be referenceable.

And the decision is ...
At last count, there were about 13 J2EE application server vendors—and the shakeout has only just begun.

• Bluestone has recently been acquired by HP.
• Unify has cobbled together what has been called a "poor man's" J2EE suite, recently acquiring companies such as New Atlanta's ServletExec servlet engine.
• Apache will remain a player, at least at the Web server level, although it has several J2EE initiatives and some interesting SOAP reference implementations.
• At the enterprise level, the major competitors are clearly BEA and IBM.

For companies with a large IBM investment that are comfortable with not keeping up with J2EE compliance, IBM is a good choice. Additionally, IBM seems to be out in front of BEA with respect to e-commerce package solutions.

However, IBM's WAS and Visual Age for Java (VAJ) are behind the current EJB level, and they themselves are non-compatible. Specifically, WAS 3.5 patch 2 supports Servlet 2.2 and JSP 1.1, while VAJ does not, so you have to go outside of VAJ if you need Servlet 2.2 or JSP 1.1 functionality.

IBM's WAS recently started supporting EJB 1.1 and Java 1.2. By contrast, BEA's WLS 6.0 supports EJB 2.0, and WLS 5.1 supported JDK 1.3.

For vertical J2EE ISPs that use other vendors' infrastructure (such as Blue Martini) or that need cutting-edge J2EE support for custom implementations, especially for Sun and HP environments, including a TP monitor, BEA is clearly the right choice.