The discussion on Java connectors is located in Appendix A. This information is in the appendix because the main emphasis of this book is on web services and distributed application interoperability. Enterprise Information Systems (EISs), Enterprise Application Integration (EAI), and legacy applications are not the focus in this text.
Connectors provide a set of contracts describing how EISs can interact with enterprise applications and servers. The contracts reside between J2EE applications and the EIS. The Java connectors also supply a client interface API for purposes of allowing J2EE application reusable components to access EISs in a heterogeneous environment.
A Java connector defines two contracts:
A system-level specification between an application server and a resource adapter (a system library provides connectivity to a specified EIS)
An application contract between an application server and a resource adapter
The system-level contract defines a standard methodology for use by developers to support connectivity to multiple EISs. This contract comprises three subcontracts:
Connection management contract This allows an application server such as WebSphere to pool connections to an EIS. Pooling connections is significant when large numbers of clients request access to the underlying EIS.
Transaction management contract This specifies the conditions under which the transaction manager supports transactions across Internet spaces.
Security contract This enables tight security access to multiple EISs.
The application contract defines a client API that an application component utilizes for access to a specified EIS. For example, a client API for a relational database (JDBC) is an example of a resource adapter. Another example would be the Common Client Interface (CCI) API. The dataset could be IBM’s DB2, or MySQL.
Enterprise Application Integration (EAI) facilitates integration between legacy systems and applications. EAI enables enterprises to interoperate with new, emerging technologies and provides innovative solutions whereby enterprises can accommodate new methodologies and retain their existing systems. This eliminates the necessity for application and system redesign in addition to being cost effective.
As web services and business-to-business (B2B) applications continue to evolve and coalesce, XML, web services, and Java connectors are now commonplace in our digital, interconnected world. More frequently, new web-based applications are designed to plug into preexisting legacy systems and data-driven applications. In order to achieve interoperability, both off-the-shelf applications and in-house developed software systems must be compatible with J2EE specifications. Developers know how J2EE, in partnership with Java connectors, consists of a set of specifications and contracts between application servers and other enterprise servers and systems. When businesses start to merge their systems and applications, incompatibilities begin to emerge. However, a synergy between Java and XML exists. Therein lies the power of J2EE and Java’s J2EE connector architecture.
It is important for enterprises to share both data and business processes without modifying their existing applications. One of the main challenges facing developers is how to deal with a lack of industry-wide standards. Before application integration can exist, business partners must agree on both a communications protocol and a set of specifications and contracts. Java connectors fulfill this role by presenting a methodology and standard set of specifications (contracts) that business partners can utilize to communicate with each other.
Many real-world examples of EAI exist, for example, Amazon.com, Fidelity Investments, and Dell—all successful business models. As their software architecture evolves, they are the supply chains. Their success demonstrates how they have recognized the need to integrate their applications in order to stay competitive. Java connectors answer this need.
As businesses succeed, new challenges arise. For example, web-driven integration places additional security requirements on the enterprise. An application server must be both transactional and secure in order to maintain data integrity. Additionally, as systems grow and interact, the applications must be scalable. Considering the large number of Internet users requesting web services both hourly and daily, both systems and applications must be able to respond to consumer demands in a flexible and timely fashion. Adhering to this fast evolving concept of EAI is imperative. Traditionally, legacy systems managed the front end and back end separately, whereas now, web-enabled applications integrate both front end and back end as a single entity. Integrating applications and systems is only one piece of the puzzle. Enterprise Information System integration also requires attention.
An Enterprise Information System (EIS) places emphasis on business processes and its data in order to run and grow its business. This comprises both the business process and information technology (IT) infrastructure. The enterprise processes include applications for inventory management, delivery fulfillment, financial accounting, and other such system management tasks. The process may also include security, transaction services, and load balancing.
EISs must also integrate their infrastructures with existing web services. This entails both the data and business process. In many cases, these are legacy applications and systems, databases, and so forth.
EIS approaches to enterprise architectural design are many and varied, as the following list demonstrates:
Two-tiered client-server architecture
Application server–based approach
Synchronous adapter approach
Asynchronous adapter approach
Message broker approach
Typically, a two-tiered client-server approach does not base its design on web services. The EIS provides an adapter that defines API for data access and basic component functionality. The adapter’s task is mapping a reusable set of APIs to a vendor-specific EIS. Communications between adapter and EIS utilize a protocol applicable to the EIS. This may include support for transactions and security. A C library can function as an adapter, thereby enabling use of the Java Naming Interface (JNI) to access the library.
There are numerous advantages to programming within the Java VM environment. However, because a huge investment exists in legacy code, the JNI interfaces permit invocation of binary code.
Employing the application-based server approach is particularly appropriate because it provides a platform for development, deployment, and maintainability for web-based enterprise applications. This is especially true for building multi-tiered applications. The application architecture contains three levels: a client tier, a middle tier, and an EIS tier. The middle tier consists of business logic components, whereas the EIS tier contains the low-level systems that run enterprise applications and access databases. The client tier offers different kinds of functionality. It can, for example, be a web browser–based HTML-type client.
The application server functions as a component-based business model. It can host either business components, web components, or both. Business components contain the Enterprise JavaBeans for processing business logic, whereas the web components represent reusable components relevant to providing presentation web services such as servlets and Java Server Pages. The application server provides support for the following services:
Load balancing and failover
Components deployed on application servers can also utilize synchronous resource adapters to connect and access EISs. (A resource adapter is a system library designed to provide connectivity and access to a specific EIS.) One drawback to synchronous calls is that once the client makes its call, it waits for a server to process and fulfill its request, thereby blocking all other activity until it receives the server’s response.
It is imperative that the resource adapter runs within the application server’s namespace. Additionally, application components can offer a Java Message Service (JMS) provider to a message broker for purposes of integrating with EISs based on asynchronous messaging.
Asynchronous message-based communication allows enterprise applications and EISs to interact. In this scenario, two formats exist: publish-subscribe and queue-based messaging. The case study is a valid candidate for receiving stock quotes and publishing updated stock prices to subscriber applications. Message publishers broadcast messages, while message subscribers register their interest in specified messages. A separate message facility functions as a facilitator for receiving and distributing messages to subscribers.
In queue-based communications, an application sends messages to a message queue. Subsequently, a receiver application receives messages from the same queue and distributes them to interested subscribers.