In this era of enterprise system development, companies are facing a similar set of business imperatives:
To take business applications and processes to the Web
To comply with open standards-based architecture requirements
To share data among applications
To expand market reach
To decrease time to market
To mitigate costs
Faced with these demands, companies are choosing to integrate their legacy systems into their web-based business model, rather than re-engineer them.
The IBM WebSphere software platform provides an e-business infrastructure that is flexible, extensible and robust, helping organizations take their essential business services to the Web for e-commerce, B2B integration and enterprise application deployment.
XMLink, Prolifics' Java and XML connector, allows easy access and integration of legacy systems to IBM WebSphere without changes to the current environment, enabling organizations to integrate across the enterprise and business, and open new revenue streams with Web services.
This paper provides technical information about XMLink and its implementation.
The advantages of using XMLink to connect to legacy systems include its:
Standards-based integration and open API
Simple programming model that can be used from an EJB, servlet, JSP, or any other Java code
High level of transparency and independence from the legacy system
Complete transparency for all Java programs (applets, servlets, JSP, EJB ...)
Application positioning for dynamic e-business with Web services
XMLink adheres to the J2EE (Java 2 Platform, Enterprise Edition) Connector Architecture Specification. J2EE is designed to be used with multitiered, enterprise applications which separate the business logic and presentation aspects of the application from the system services provided by the J2EE platform. The addition of J2EE Connector (JCX) to the J2EE platform allows integration of existing Enterprise Information Systems (EISs) to newer Java-based applications.
In the language of the J2EE Connector specification, XMLink supplies a resource adapter and supports the two deployment scenarios needed for J2EE compliance. J2EE resource adapters can either be run under the auspices of an application server (such as IBM WebSphere) in which case they rely on services provided by the application server's framework, or they can be run in non-managed environment, in which case they are local to a Java client and do not need an application server.
Integrating with BEA Tuxedo.
In BEA Tuxedo, communication occurs by passing service requests between clients and servers using Inter-Process Communication (IPC) message queues and/or a client access layer (/WS). These messages are packaged in typed buffers. Having buffer types allows the type of message data to be specified in addition to the message data itself. XMLink, using the existing IPC or /WS configuration, comes packaged with the methods necessary to interact with the different buffer types.
Like any other BEA Tuxedo client, XMLink uses the ATMI (Application to Transaction Monitor Interface) layer to connect to BEA Tuxedo. The ATMI interface controls communication, transactions, and management of data buffers and implements the X/Open DTP model of transaction processing.
XMLink takes advantage of several BEA Tuxedo features:
Level1 to Level4 of BEA Tuxedo security paradigms
Fully multi-threaded (BEA Tuxedo v 6.4 and up)
Full support to BEA Tuxedo native buffer types : FML, FML32, STRING and CARRAY
Full support to BEA Tuxedo' XA calling interface (2 phase commit protocol)
Support for two calling paradigms:
Synchronous calls (tpcall)
Asynchronous calls with no replies (tpacall)
Naturally open and extensible to support BEA Tuxedo's extended calling paradigms (such as post/subscribe, queueing)
Seamlessly take advantage of BEA Tuxedo's scalability, load balancing, data routing, availability and fail over
Implementing XMLink using Java.
Get a BEA Tuxedo connection
Manage the Tuxedo transactions
Call services in the Tuxedo application
Methods are provided for working with the different types of data buffers used in a BEA Tuxedo application.
// get an initial JNDI naming context
Context initctx = new InitialContext();
// do JNDI lookup to get Connection Factory
// note that lookup does not return a
// ConnectionFactory, so a cast is needed
ConnectionFactory cfx = (ConnectionFactory)
// get a connection
Connection cx = cfx.getConnection();
// cx represents a previously acquired
// Connection instance
// first get a LocalTransaction instance
LocalTransaction ltx = cx.getLocalTransaction();
// mark the beginning of a BEA Tuxedo transaction
// get an Interaction instance
Interaction iact = cx.createInteraction();
// create a new InteractionSpec object
TuxInteractionSpec tux1 = new TuxInteractionSpec;
// set the properties of the InteractionSpec instance
// note InteractionVerb defaults to SYNC_SEND_RECEIVE
// so the second line below is not required
// get a RecordFactory instance
RecordFactory rcf = iact.getRecordFactory()
// create a Record Instance to hold input data
FMLRecord rc = (FMLRecord) rcf.createMappedRecord("FML");
// Populate Record instance with data
rc.addIn ("FirstField", "value1");
rc.addIn ("FirstField", "value2");
rc.addIn ("SecondField", "anothervalue");
// and so forth
// call the TUXEDO service
MappedRecord ret = iact.execute(tux1, rc);
// call other services in the transaction by creating
// new InteractionSpec instances and input records
// and calling execute as needed
// mark the end of the TUXEDO transaction
//close the InteractionInstance