Extending J2C
for Conversation Support[1]
e-Commerce
Department
IBM T.J.Watson
Research Center, Yorktown Heights, NY
1. Introduction & Suggested Pre-reading
This document provides an overview of the J2C conversation architecture. An in-depth knowledge of the J2EE and J2C technologies are required to follow the technical nuances of this document. The following are suggested as pre-reading material.
Ø
Conversation Support for e-business White Paper by Jim
Hanson, David Levine and Prabir Nandi [2].
Ø
J2EE Connector Architecture Specification Ver
1.0 [4].
2. Conversation Basics
The word Conversation essentially describes the act of two or more parties interacting with each other to achieve a meaningful end viz. exchange sports news, fixing a lunch meeting etc. Conversation support for (e)-business extends the notion of human conversations to the realm of e-business. It is an architecture by which two or more computers belonging to different enterprises can ‘talk’ with each other to conduct business using the Internet.
The architecture introduces 2 main concepts,
· The conversation verbiage. The conversation verbiage includes the act of initiating/terminating a conversation and the act of sending/receiving a message in conversation.
· The sequence or rules governing the conversation. This is specified using a conversation policy (CP) [3] that provides a transcript describing the interaction. Conversing parties follow this common script to ‘speak as and when required’.
The intention of this paper is not to talk about the conversation concepts, but to elaborate its implementation applicability to the J2C architecture. An in-depth discussion of the technology can be found in the Conversation support for e-business white paper [2]. A dialect for describing conversation policies can be found in [3].
3. Extending J2C – The Conversational Adapter
Take for example, a conversation between a buyer and seller enterprise governed by a CP that deals with haggling on the price for the purchased commodity. The buyer may receive offers and counter-offers from the seller. As a result the buyer would need to decide whether he agrees or disagrees to the price. If he agrees he sends a confirmation to the seller and if not, he requests the seller to send a counter-offer. Thus the conversation support mechanism on the buyer side would need to pass “pls decide” messages to the business logic and in turn accept “decisions” from the business logic. The following diagram illustrates this interaction,
The following observations can be made from the diagram,
· A framework to manage conversation policies is required that,
1. will load and instantiate the conversation policies
2. be able to communicate with the trading partner.
· There is a requirement to communicate to the internal business logic regards business decisions to be taken as per the conversation policy. This business decision can be a simple method call to an application or can be complex enough that require a process flow. In either case, the business data (offer information etc.) needs to be adapted to the specific invocation.
· Decisions made by the internal systems needs to be communicated back to the conversation policy.
· The conversation policies should be able to communicate with each other across enterprise boundaries. The Buyer and the Seller can each offer access to their Conversation framework via different protocols over the Internet eg. SOAP over HTTP etc.
Enter J2C!
The Java 2 Connector (J2C) architecture defines a standard architecture for connecting the J2EE platform to heterogeneous Enterprise Information Systems (EISs). It addresses the key issues and requirements of EIS integration by defining a set of scalable, secure and transactional mechanisms that enable the integration of of EISs with application servers and enterprise applications. The EIS vendors or ISVs specializing in EAI uses the Connector architecture to develop standard resource adapters for different EIS types. Conforming to the architecture provides the guarantee of Resource Adapters (RA) to be able to run on any Application Server and avail of the system services (transactions, security and connection pooling) provided by the Application Server.
A set of contracts specified at the system and application level abstracts the details of both the interfaces and communication between the underlying resource adapter library and the EIS system. The application level developer focuses on the development of business and presentation logic for its application components and does not need to get involved in the system-level issues related to EIS integration. The following figure shows the component diagram for a typical RA.
Now we introduce the notion of a Conversational Adapters (CA) that extends the concept of adapting for a particular EIS to adapt to a particular B2B process defined by one or more conversation policies. A CA is a broker between conventional RAs in the process of executing a B2B interaction. The following diagram illustrates this idea. Essentially a CA is a specialized RA that adapts to another CA and the interaction between the two CA’s is controlled by one or more conversation policies.
The architecture of a CA thus allows you to build a B2B application that uses backend traditional RAs to provide EIS connectivity. The policy governing the conversation (CP) is kept separate from the binding with backend RAs. The architecture only specifies that the backend binding is done via the J2C application contract (CCI). As such the Buy-Sell CA can be used by any organization that wants to conduct B2B interactions using CP#300.
4. Component Architecture
The two key infratructure requirement to enable applications with convesation support are connection management and a suitable data representation. The JCA architecture already provides support for the same. Extending the JCA contracts to support conversations seemed mutually beneficial. On the one hand conversation support can now be made available on a standard architecture and platform (J2EE). Similary the JCA architecture can now support ‘conversational’ resources and play a key role in intra and inter entrerprise application integration.
The following diagram illustrates the extensions that have been made to the JCA architecture.
Connection, transaction and security contracts between a CA and the Application Server is the same as required by a traditional RA. The yellow markers in the diagram below shows the proposed architectural extensions to the current JCA specs (ver 1.0). In addition the application server is expected to provide support for conversation sessions for individual CAs. Additionally, it is expected to provide implementation and access ports for different possible conversation interactions viz. initate/terminate, send/receive etc.
The Conversational Resource in the figure, represents a component that provides a conversation framework and has similar access ports to support conversational interactions. In most cases these will be other CAs, but the architecture does not preclude using another implementation that supports the conversation contracts. In that sense, CAs are expected to support only peer-to-peer interactions, unlike a traditional resource adapter.
Our B2B interaction diagram changes as thus,
The adapters on each side can expose Web Services ports for receiving a Conversation Request, receiving a message in conversation or accepting a terminate conversation call. Current web services technology (WSDL, SOAP) can be used to encapsulate the Internet protocol to access these ports. Based on the control logic expressed by the conversation policies, the incoming message maybe routed to the backend business logic.
5. CA’s and Business Process Integration
Business Process Integration has emerged as an important aspect of the enterprise computing landscape. Intra-enterprise application integration (EAI) as well as the inter enterprise integration (B2B) are increasingly being performed in the context of business processes.
With the advent of CA’s, intra-enterprise process choregraphy engines (BPM) can now seamlessly and in a standard manner, bridge the gap between trading partner systems and its own backend applications.
Conversation support may also be applicable to integrate ‘conversational’ EIS’s. Such EIS’s usually maintain state between calls and support extended interactions. A CA can easily model such a long lived integration pattern. Thus the applicability of the CA is not restricted only to cross-enterprise integration; they are equally applicable for integrating intra-enterprise systems as well. As shown in the figure, the BPM module is integrated to a conventional EIS via a conventional Resource Adapter (RA) as well as to a ‘conversational’ EIS via a CA, in the context of a business process.
6. Conversation Adapter Tooling
CA’s provide a J2EE based runtime framework to execute conversation policies. It is envisaged that there will be specialized vendors that will write conversation policies (state machine based protocols and the corresponding message schemas). J2EE application server vendors could provide tools that can generate a conversation adapter from one or more such conversation policies.
The figure below illustrates the various players and their respective roles.
7. Recap
CA’s maintain the “create once use anywhere” of a traditional RA, while extending its scope to B2B integration.
CA’s encapsulate connectivity related nuances and presents a common front. Partners need know only the CA deployment descriptors (JNDI name and host running the naming service) to connect and ‘talk’. The deployment descriptors can be made available via a publicly available UDDI registry.
It maybe envisaged that vendors build CA’s for specific business patterns for the different industry segments that could be available out of the box and ready to run.
8. References
1. J2EE Connector Architecture and Enterprise Application Integration, a book by Rahul Sharma, Beth Stearns, Tony Ng. The Java Series Enterprise Edition.
4. J2EE Connector Architecture 1.0 Specifications from http://java.sun.com/j2ee/connector/