J2EE Connector Architecture and the Enterprise

Connecting disparate EIS systems throughout the enterprise is a lofty goal indeed. It's fraught with the kind of complex problems that can always be found in the integration of incompatible interfaces. The J2EE Connector Architecture attempts to untangle this web through mechanisms of standardization.

What Is an EIS?

Just exactly what is an EIS system? When we speak of EIS systems, we're usually talking about the core applications that a business runs on. They often have a long-standing history with a company and represent a significant part of the IT budget. Over time, a great deal of effort is spent in their customization and fine-tuning in order to tailor them to a particular organization's needs. A significant investment has been made in their implementation and deployment and in the personnel required to maintain them with the hope that they will provide a competitive advantage in the marketplace. More often than not, they've become so entrenched that the thought of replacing them just isn't a viable option. Known projects of rewriting EIS systems have cost millions, shipped late, or never ship at all because the deployment phase was too complex. Another argument against rewriting an EIS is, "Why fix it if it's not broken?" Claims that EIS system doesn't integrate well or uses an older technology are not heavy enough in the scale to warrant rewriting large amounts of well-functioning code.

Some types of systems that could be classified as EIS systems are Oracle ERP (Enterprise Resource Planning) Financials, IBM CICS and IBM IMS applications, SAP R/3, PeopleSoft, J.D. Edwards, CRM (Customer Relationship Management), and Supply Chain Management to name a few.

Although each of these applications is full-featured and offers extensive services and advantages in its own right, they tend to be isolated. The application exists as an island in and of itself. Integration options with other platforms are not readily available; when they are available, they invariably come in a proprietary fashion. External applications wanting to connect to these EIS systems must endure a complex, labor-intensive effort in the manual creation of customized adapters.

Implications for Enterprise Application Integrators

Seizing on yet another opportunity to add value, some system integrators have specialized in an area known as EAI (enterprise application integration). These vendors provide tools to simplify the process of application integration, albeit still in a vendor-specific fashion. Each offers its own proprietary adapters built to work with its own products, which allow for synchronous and asynchronous communication between EISs. With each of these products, data must be translated between the native formats found across systems. This data mapping represents the most time-consuming aspect of system integration because complex business objects must be painstakingly mapped between applications. EAI vendors provide visual tools to aid developers in this process. Their products typically supply message brokers, which enable point-to-point and publish/subscribe messaging. Messaging is often the core mechanism used to provide connectivity between heterogeneous systems.

The J2EE Connector Architecture in no way conflicts with the work being done by EAI vendors. From the onset of the formation of the standard, the intent has always been to aid EAI initiatives, not to supplant them. In the "Working with Java Connector Architecture Components" section of this chapter, we learn about the Common Client Interface (CCI), which defines a standard low-level client API for accessing EIS resource adapters. The goal of this API has always been to provide a least common denominator, base-level API that is available to all EAI vendors in the hope of finally achieving some base level of standard interoperability between them. EAI vendors are expected to build out the API, but a great deal of work is still left to be done. They're looked upon to deliver on a more full-featured interface for application developers who desire quick and easy access to EIS resources. EAI vendors will continue to add value to the proposition in areas such as data mapping, message brokering, workflow, and user interface integration.

Business-to-Business e-Marketplaces

Companies are increasingly looking for better ways to integrate their information systems to more effectively collaborate with suppliers and partners over the Web. Early out-of-the box B2B (business-to-business) initiatives were quick to market but lacked the real-time access to legacy systems that true complex e-business solutions demand. Opening up access to the information repositories of a company allows for real-time availability of goods and services. This makes Internet-based B2B propositions very compelling for companies because they open up new opportunities that simply have not existed before.

For example, a widget supplier (see Figure 31.2) can dial up over the Internet through a common browser (which one could argue is already as ubiquitous as the telephone) and, with proper authentication, in seconds tie directly into a company's mainframe data. The client can communicate via universally recognized protocols of XML over HTTP to access a WebLogic application server–hosted JSP. In turn, the JSP calls an Enterprise JavaBean through a middle-tier servlet, caching information garnered from an EIS system exposed though a standard resource adapter. This loosely coupled configuration achieves the connectivity sought after, while respecting the lines of demarcation that typically exists between systems. Adopting such an e-market approach breathes new life into aging legacy systems. The significant investment already made in this area can be leveraged substantially.

Deployment costs in establishing relationships with new suppliers are next to nothing. Orders are fulfilled in real-time. This has huge implications for just-in-time manufacturing, inventory control, and the overall cost of doing business.

The ramifications of seizing on this technology are tempting because after a company's information systems become accessible across any geographic boundary, the company's reach in effect becomes global.

Challenges Facing the J2EE Connector Architecture

So far, this all sounds too good to be true. However, it's important to keep in mind that the J2EE Connector Architecture is by no means a mature standard at this point. And although it does have considerable momentum behind it and promises to be a unifying force, the one drawback that does exist can be found in the fact that the J2EE Connector Architecture is still a standard provided by a single vendor. As with all emerging standards, only time will tell how complete its ultimate acceptance will become.

Full-featured enterprise information systems offer an enormous amount of functionality and services to companies. The degree of feature availability they contain is directly proportional to the complexity of their overall system design. Internally, these systems can be quite complex. Behind the scenes, performance and high availability are achieved through custom optimization and proprietary designs. The programming models used vary widely across different EISs and elements of transaction and security management are particularly unique.

All this makes integration efforts all the more difficult. It's critical that proven application development tools be continually upgraded and enhanced beyond the base standard that the J2EE Connector Architecture offers to ease the tasks associated with enterprise system integration.

It is a given that for any API to effectively mask lower-level EIS connection mechanisms from view, a certain amount of overhead must be incurred. However, Web applications demand speed and must be able to scale to a large number of concurrent users, all vying for the same resources managed by the EIS system. Any undue latency at the application level will not sit well with customers.