Novell is now a part of Micro Focus

Inter-Application Transaction Processing: The TUXEDO System Approach

Articles and Tips: article

JUAN M. ANDRADE
Software Engineer Consultant
Tuxedo System Architecture Group

01 Sep 1994


As the distribution requirements for a business grow, application developers need to structure and model applications into sets of functionality that require administrative autonomy because of their nature, geographical location, or confidentiality. These functionally distinct segments require information sharing and, therefore, must be able to interoperate. This DevNote discusses how the TUXEDO System /Domain feature provides the necessary infrastructure for this inter-application transaction processing.

Introduction

The TUXEDO System provides an extended client/server application programming framework that simplifies the development of distributed business applications by hiding the complexity associated with the distribution of application processing. TUXEDO provides a scalable, standards-based software architecture that supports a wide variety of hardware platforms, networks, and operating systems.

A company can use TUXEDO to develop and centrally administer their critical business applications on their heterogeneous distributed environments, while still preserving the performance, reliability, and scalability required for the business.

As an enterprise grows, different segments of the information management area usually have to be organized into sets of functionality that require administrative autonomy because of their nature, geographical location, or confidentiality. The enterprise may also want to expand its business by cooperating with other enterprises that provide, or require, other information management services needed for the growth of the business.

This inter-enterprise cooperation requires special mechanisms to simplify the integration of the distinct computer environments used by these enterprises, while still preserving their autonomy.

The TUXEDO System addresses the modeling and interoperation between these functionally or geographically distinct information management segments with the /Domain feature. This feature extends the usefulness of TUXEDO to provide transaction processing interoperability between applications running in very distinct environments, networks, geographic locations, and companies.

This DevNote discusses the characteristics of the TUXEDO System /Domain feature.

The TUXEDO System

The TUXEDO System provides a framework for the development of open distributed business applications (see reference 1 at the end of this DevNote.). Applications use an extended client/server model that hides the heterogeneity of the different computers, the heterogeneity of application programs, and the location of these application programs.

With this framework, TUXEDO also provides a centralized administration subsystem that allows application administrators to control all cooperating nodes as a single application.

Across the different nodes of a TUXEDO-based application, programs are written using a single programming interface, the ATMI interface. As a result, applications can be easily moved from one node to another without requiring changes. Figure 1 illustrates the environment provided by TUXEDO.

Figure 1: This shows the TUXEDO System.

Applications running on workstation nodes are requesters of services offered by application servers running on other computer nodes. TUXEDO supports PCs running MSDOS, Windows, NT, OS/2, Mac OS System 7, and workstations running the UNIX operating system.

The TUXEDO System allows applications to be isolated from the particular networking subsystem required for interconnecting the different computer nodes used for the distributed application. TUXEDO supports networks with different transport interfaces (e.g., TLI, XTI, Sockets, NETBIOS) and protocols (e.g., TCP/IP, SPX/IPX, X.25, OSI).

TUXEDO is the "glue" that ties together the distributed components of an application.

The TUXEDO System's client/server model offers a number of programming methodologies: pure RPC, request/response, connection-oriented processing, reliable queuing, unsolicited notification (i.e., callbacks), and event brokering (see reference 2 at the end of this DevNote). These programming paradigms are designed to meet the needs and requirements of application developers to structure their code for portability, location transparency, performance, modular growth, and reliability.

The /Domain Framework

As the distribution requirements for a business grow, application developers need to structure and model applications for the different business segments separately to provide administrative autonomy, but at the same time to allow sharing of services and data. Each computing segment defines an application that may span multiple computer nodes and that is independently administered from the other applications.

Each one of these applications is called a "domain". Domains can be distributed across different geographical locations, across departments of a company, or even between different companies.

The TUXEDO System /Domain feature provides a framework that allows the cooperation of TUXEDO-based applications in hundreds of geographically distributed domains. These domains can be other TUXEDO-based applications or applications running in other transaction processing environments.

/Domain extends the scope of the TUXEDO client/server model to provide coordinated transaction processing interoperability across the enterprise geographic or organizational boundaries. Client applications can request services that may be available on another domain.

A good example is a bank in which several autonomous applications can be defined.

/Domain is the "link" between a TUXEDO based application and another application.

Figure 2: This shows the /Domain framework.

Let's look at the four components in the bank example "linked" together by the TUXEDO System /Domain feature.

  • Branch offices: Each branch controls a set of local accounts and offers local or global operations to its customers. Branches offer an automatic teller machine service, and customers usually can go to any other branch and perform banking transactions on their accounts. These banking transactions will have to be re-routed to the branch controlling the corresponding account.

  • Loan services: The bank may also have a loan service that operates independently from the activities at each branch. However, customers can apply for a loan or pay their loan installments at any branch.

  • Accounting and payroll: The bank also needs to keep track of its accounting, finances, investments, etc., independently from the activities at the branch or loan offices. However, input may be required from these offices to reconcile the bank's own accounts. The bank also needs a payroll application that may be running independently from the activities at branches and loan offices but that needs some interaction with the central accounting application.

  • Interbank activities: Banks need to expand their business and they cooperate to offer customers services across their enterprise boundaries, e.g. ATMs, electronic transfers, etc.

This example shows the applicability of the /Domain technology. Each one of the bank branches can have a distributed computer system (e.g., teller workstations, ATMs, printer servers, data servers, etc.) running a distributed application implemented with the TUXEDO System or another transaction processing system (see Figure 1).

This application is administered and runs independently from the computer systems running at the other branches, i.e., the distributed system within a branch defines a "domain." The applications running at the bank's headquarters or the loan offices may also run independently from the activities at each branch, and therefore each one of these applications also defines a domain. Finally, each Bank in itself defines a domain with respect to the banking transactions with another bank by advertising a subset of its services to the "outside" world.

/Domain Functionality

/Domain provides a framework that allows the interconnection and interoperability across these domain boundaries. The framework provides a gateway that manages the communication between domains. This is illustrated in Figure 3, which shows a TUXEDO-based application that requires services (e.g., credit card authorizations) from a remote domain.

Figure 3 shows a TUXEDO-based application that requires the services from another domain, a credit card authorization center. Remote services appear as local services in the TUXEDO application service naming space. Clients use remote services in the same way they use local services.

The application accepts service requests (e.g., balance inquiries) from remote domains. The gateway process provides bi-directional transaction control. Also, a set of administrative tools allow administrators to define the configuration required for interoperability of the local application with other domains. This configuration information includes the identification of a set of exported services, imported services, addressing, and access control.

Figure 3: This shows the /Domain gateway.

The /Domain framework is, however, totally transparent to application programmers. Application programmers can use the different programming paradigms provided by the TUXEDO client/server model to request services offered by other domains exactly as if they were services offered within the local TUXEDO application. Thus, the /Domain framework is geared towards the TUXEDO System application administrator.

Application administrators use the /Domain administrative functionality to make services that are in other domains available to the application programmers. The application administrator can use the /Domain administrative subsystem to allow access from remote domains to a set of local services. This set of local services is called a local domain. Local domains help the application administrator to provide secure views of a TUXEDO-based application, i.e., subsets of the local services that are accessible by a particular set of remote domains.

In addition, administrators can restrict further access by defining an access control list with each local services. This access control list defines which remote domains are allowed to issue requests to that particular local service.

The /Domain framework was designed to support the following functionality:

  • X/Open XATMI request/response model: application programs using the TUXEDO system can request services from applications running in another domain. Also, remote applications can request services from local servers.

  • X/Open XATMI conversational model: application programs can establish conversations with programs in another domain. Remote domains can establish conversations with conversational services offered by local servers.

  • lnter-domain message queuing: application programs can use the/Domain framework in combination with the TUXEDO System Reliable Queuing Facility (/Q) to structure their applications for reliability with a store and forward mechanism. Requests to remote domains may be queued and forwarded at a later time. This programming approach addresses the cases in which a remote domain may not be active, i.e., the application programmer stores a service request with the enqueuing facility and then forwarding mechanism sends the request (via the /Domain framework) to the remote domain at a later time.

  • Transaction management: application programs can interoperate with other domains within a transaction. /Domain coordinates the commitment or rollback of transactions executing across domains.

  • Administration: /Domain gateways can be booted or shutdown exactly like any other TUXEDO server. Run-time administration is provided and administrators can dynamically change the configuration to tune the performance of a /Domain gateway.

  • Multi-domain interaction: /Domain gateways can interoperate with multiple domains at the same time.

  • Multi-network support: gateways can communicate with remote domains using different types of networks.

Interoperability

/Domain has been designed for extensibility, performance and adaptability to the different interoperability protocols that may be used by remote domains. The /Domain framework defines a family of gateways that implement a mapping from the X/Open XATMI and TxRPC specifications to the corresponding protocols used by the remote domain environment (see references 3 and 4).

Several instantiations of the /Domain framework will be available:

  • The TDOMAIN instantiation that allows interoperability with other TUXEDO-based applications.

  • The OSITP instantiation, a standards-based solution, that allows interoperability with applications running on other TP environments. This solution implements the X/Open XATMI Application Service Element (XATMI ASE) specification and requires the OSITP protocol for interoperability (see [3]). This instantiation also implements the OSI Unstructured Data Transfer Application Service Element (UDT ASE).

  • The LU6.2 instantiation that provides interoperability with legacy applications (running for example on CICS or IMS systems). This instantiation integrates and extends the capabilities of the TUXEDO System /Host extension to provide coordinated transaction management with CICS or CPI-C applications.

  • The TxRPC instantiation that provides transaction management interoperability with DCE RPC applications using the X/Open TxRPCRTI ASE (see reference 4). This ASE also uses the OSI TP protocol.

All these instantiations share the same core architecture. Each new instantiation is designed as an asynchronous communications access module that plugs into the /Domain core. However, each instantiation defines a distinct gateway specialized for the communication with the remote applications that use the corresponding communications protocol.

The introduction of this family of gateways will come in several phases. Initially, TDOMAIN will be available followed shortly by the OSITP instantiation. Other instantiations will follow thereafter.

Interoperability with other TUXEDO-based applications

The architecture of /Domain also recognizes that enterprises need superior performance and interoperability on networks that use protocols such as TCP/IP or IPX/SPX. To satisfy these needs, the /Domain framework includes a particular instantiation, also called /TDOMAIN, that provides an optimized interoperability solution between autonomous TUXEDO-based applications.

/TDOMAIN provides connectivity over different types of networks to multiple remote domains. This feature allows a given domain to connect to remote domains that use different networks and transport protocols, e.g. TCP/IP, SPX/IPX, or X.25.

/TDOMAIN optimizes the communications and the number of connections required with a remote application. Connections to remote domains are established the first time a request is issued to a remote domain.

Usually, the connection stays up but it may be closed automatically if the connection is not used for a certain amount of time (an idle time defined by the application administrator). /TDOMAIN also reuses the connections to remote domains by multiplexing the requests and replies that flow from or to these remote domains.

Administrators can specify multiple network addresses per remote domain. /TDOMAIN uses the first network address to establish the connection to the selected remote domain. However, if this connection fails, /TDOMAIN tries to establish the connection with the next address in the list.

If after trying all the back-up addresses /TDOMAIN cannot establish a connection to the remote domain, then a failure will be returned to the requester.

/TDOMAIN allows secure connections by authenticating incoming connections from the remote domains. This security mechanism has been abstracted to allow application administrators to "plug" their preferred security mechanism, e.g. Kerberos.

/TDOMAIN optimizes transaction management by reducing the number of messages and the number of branches required in the transaction tree. This feature allows a reduction in the number of messages required for the completion of the transaction.

Application administrators can also use /TDOMAIN in combination with the TUXEDO System Reliable Queuing Facility (/Q) to define a domain with the basic role of storing and forwarding reliable requests. The administrator just needs to define in the /Domain configuration file an entry for the "queuing" domain and entries for the corresponding queuing and dequeueing services.

The /TDOMAIN product demonstrates the TUXEDO System commitment towards enterprise solutions that require high performance, modularity, and adaptability to different heterogeneous networking environments.

Interoperability with another Application via the OSI TP protocol

The International Standards Organization (ISO) has produced the OSI specification for Distributed Transaction Processing (known as OSI TP, ISO IS 10026). OSI TP is currently the only standard protocol available for open distributed transaction management and it has been selected by X/Open as the protocol for Transaction Processing interoperability.

The /Domain OSI TP instantiation (also called /OSITP) extends the TUXEDO System client/server model to provide coordinated transaction level interoperability with the OSI TP protocol. Application programmers and end-users do not need to be aware of all the mechanisms necessary for the communication with a remote OSI TP compliant system.

/OSITP performs this communication in a way that is transparent to both the application programmer and the end-user. /OSITP effectively maintains the TUXEDO System client/server model by handling all the translations and formatting required for accessing the services available on the remote TP System (or accepting service requests from a remote TP system).

/OSITP simplifies the development of TUXEDO-based applications by allowing programmers to use the X/Open XATMI interface to access services provided by (or requested from) another TP system.

Together, both the request/response and the connection-oriented paradigms supported in XATMI help distributed application developers structure their code for portability, location transparency, performance, modular growth, reliability, and now with support for OSI TP, for interoperability with other TP systems.

/OSITP fully implements the X/Open XATMI specification. This specification defines a client/server programming model designed to structure transaction applications as client and servers. The specification also defines the XATMI Application Service Element (XATMI ASE) that describes how the XATMI primitives are mapped to the OSI TP protocol.

/OSITP can also be used with the ISO Unstructured Data Transfer Application Service Element (UDT ASE). Support for the UDT-ASE has been provided to allow quick integration with existing TP applications. The use of the UDT ASE requires that applications agree on the format used for the data exchanged.

In the TUXEDO System, applications use typed buffers to pass data from clients to servers. This typed buffer mechanism manages the translation of data to the format required by the remote machines or the remote application.

/OSITP generalizes this mechanism to allow an automated translation from the TUXEDO System or application defined buffer types to the structure required by the remote TP application. This feature enhances the portability of client and server applications written with TUXEDO and protects the investment made by an enterprise.

The /OSITP architecture was also built to standard interfaces that facilitate the integration with OSI TP protocol stacks provided by different vendors. Novell, ICL, Groupe Bull and Unisys have been working with standards committees to standardize these interfaces, giving customers choice in their selection of the OSI TP protocol implementation.

A major result of this cooperation has been the adoption by X/Open of the XAP-TP interface, an event-driven low-level standard interface to an OSI TP protocol stack. /OSITP uses the XAP-TP interface to interact with an OSI TP protocol stack. XAP-TP can also be used with OSI stacks that use TCP/IP as the transport protocol and the Internet RFC 1006 is used to insure interoperability.

The /OSITP product demonstrates the commitment that TUXEDO has towards an open and standards-based architecture.

Interoperability with Legacy Applications

The TUXEDO System architecture recognizes that interoperability with legacy applications is important to facilitate the transition from a centralized system to a distributed system. The TUXEDO System /Host product provides an initial step in this transition with an interoperability solution between TUXEDO-based applications and CICS applications.

The /Host CICS gateway already provides basic interoperability from a TUXEDO-application to a CICS application that behaves as a TUXEDO service. This CICS application uses TUXEDO System software to facilitate the management of the data required for processing and the data returned to the service requester.

The /Domain LU6.2 instantiation, also called /LU6.2, enhances the /Host interoperability solution by providing bidirectional coordinated transaction management with CICS or other applications using IBM's LU6.2 protocol. Also, because /LU6.2 does not require TUXEDO software on the CICS system, direct interoperability with applications written with CPI-C or APPC can be easily obtained.

/LU6.2 gateways extend the X/Open XATMI specification by defining a mapping from the XATMI ASE to the IBM LU6.2 protocol. This extension allows transaction processing interoperability with both the request/response and the connection-oriented programming paradigms defined by the XATMI interface.

The /LU6.2 architecture is similar to the architecture of a /OSITP gateway that uses the ISO Unstructured Data Transfer Application Service Element (UDT-ASE). That is, interoperating applications should have an agreement on the format used for the data exchanged between the applications.

These agreements can be easily automated in the TUXEDO-based application with the TUXEDO typed buffer mechanism that allows system administrators to predefine how data should be conveyed to the remote application. Application programmers do not need to be aware of this translation and they can continue using the buffer types defined for the local application. This approach allows adaptability to the interoperating needs of a TUXEDO-based application with a legacy application.

The /LU6.2 product demonstrates Novell's commitment towards enterprise solutions that require transaction interoperability with legacy applications.

Interoperability with other RPC-based Systems

The X/Open TxRPC Specification (see [4]) describes how TxRPC transactional applications built with different TxRPC providers can interoperate. The specification defines how the OSF DCE RPC protocol should be used with the OSI TP protocol.

This mapping to the OSI TP protocol, also known as the Remote Task Invocation model, has several layers: the Remote Task Invocation (RTI) protocol, the Dialogue Control (DC) protocol, and the OSF RPC protocol. Each one of these layers defines an OSI Application Service Element (ASE).

The RTI-ASE defines the top-level abstraction and the mapping of the TxRPC primitives to the RTI-ASE services. The RTI-ASE maps these services to OSI TP services, DC-ASE services, or RPC-ASE services. The OSI TP protocol defines how transaction management is performed between two applications. The DC-ASE defines the structure of the information required for OSF client/server authentication. The RPC-ASE provides services that model the OSF RPC data transfer protocol.

TxRPC interoperability is provided in the TUXEDO System via the /Domain TxRPC instantiation, also called /TxRPC. /TxRPC gateways allow bidirectional inter-application transaction processing between TUXEDO-based applications and TxRPC applications running on another computing environment. /TxRPC gateways perform all the necessary mappings and translations to/from the TxRPC RTI Model.

The /TxRPC product enhances the portability of applications written with the TUXEDO System and demonstrates Novell's commitment towards enterprise solutions that require standards-based OSF DCE interoperability.

/Domain Characteristics

The following is a summary of the characteristics provided by the /Domain feature to a TUXEDO based application.

Scalability and Modular Growth

/Domain allows applications to grow while maintaining application portability. Application administrators can easily distribute and connect applications across one or more domains. Applications programmers can structure their application for modularity, isolation of failures, and independent growth.

Interoperation with other applications can be easily achieved by just adding to the /Domain configuration the description of the interfaces (i.e., services) that a remote application uses in their cooperation. A single TUXEDO domain can contain between 1 to 100 machines. A TUXEDO domain can be connected to more than 100 domains.

Complete Administrative Subsystem

/Domain provides a complete administrative subsystem that allows application administrators to create or change a particular configuration, audit the activities performed by a /Domain instantiation, or monitor and tune the /Domain parameters for performance. The administrator can perform all these activities while the application is active.

The /Domain architecture is also integrated with the TUXEDO System administrative subsystem. The facilities maintained for remote domains are accessible via the TUXEDO system administrative application programming interface.

Transparency and Independence

TUXEDO based applications are totally unaware of service distribution. A service may be available on the same machine where the application is running, or on another machine with in the local domain, or with /Domain, on a remote domain. Client application programmers do not have to know the location of the service or how the service is implemented.

The application administrator has complete freedom and independence to change the location of services without having to inform the application users or programmers. Applications will continue to run unchanged. With the TUXEDO System and the /Domain framework, an application administrator can easily plan the growth of a distributed application.

The application administrator can easily partition an application into modules and place those modules under a separate administrative subsystem, e.g. for security. Changes in the application configuration can be done dynamically and without having to alter running programs.

Interoperability with Heterogeneous Environments

/Domain manages the data translations required for the interoperation with heterogeneous environments. Application programmers are relieved from these tasks. /Domain provides a complete framework for interoperability with remote applications running on heterogeneous environment (including a different Transaction Processing environment).

Performance

The /Domain framework implements a high performance gateway. The /Domain architecture has also been designed to exploit the power of a multiprocessor computer system. Multiple occurrences of a /Domain gateway can be running in parallel, i.e., each occurrence may be running on a separate processor and all occurrences sharing the same request queue. This architecture uses the operating system to load balance the load across multiple processors, and to allow parallel processing of incoming or outgoing requests to remote domains.

The architecture of the multithreaded gateway performs service request routing asynchronously, multiplexes connections (eliminating the cost of connection setup). It also permits multiple requests to be processed at the same time, and optimizes the number of messages required for the transaction management protocol.

Aliasing Capability

This capability allows administrators to define a mapping between the service names used by a remote application and the service names used by the local application. By using this feature administrators can easily integrate applications that use different naming schemes.

Transaction Management and Reliability

The /Domain architecture integrates with the TUXEDO System transaction management capabilities. Applications can request remote services within the scope of a transaction. /Domain performs the mapping between the TUXEDO System transaction management protocol and the transaction protocol used by the remote domains (e.g., OSI TP).

/Domain also coordinates the recovery operations required for the completion of transactions involving remote domains. /Domain can also be used with the TUXEDO System Reliable Queuing facility to provide reliable store and forward capabilities across domains.

Adaptability and Availability

Administrators can use the configuration capability to define data dependent routing criteria for remote domains. This feature allows /Domain to select a remote domain according to a field value defined in the request (e.g., an account number).

In addition, /Domain allows application administrators to define multiple network addresses for a particular remote domain. This capability can be used by the administrator to specify a back up "domain" for the services provided by a particular remote domain.

/Domain enhances the availability and performance of the communications with remote domains by allowing multiple gateway occurrences to be running concurrently. An administrator can use the TUXEDO administrative subsystem to split across two or more gateways the communications required by several remote domains.

Administrators can also use the TUXEDO System routing and load balancing capabilities to direct the work to the corresponding remote domains. This capability may be used to enhance the availability and reliability of the communications to critical remote domains.

Security

The /Domain architecture includes several security features. It allows "pluggability" with the application's preferred authentication mechanism (e.g., Kerberos), it provides an access control list facility to restrict access to local services from a particular set of remote domains, and finally it provides a structuring capability for defining different "views" of the "exported" services available to remote domains.

Coexistence with Other /Domain Instantiations

/Domain instantiations can run concurrently. The application administrator can use this feature to control the type of services offered or accessed by remote domains.

Using the /Domain Framework

The /Domain framework allows application administrators or application designers to add components to an application in a modular manner. The following examples provide an idea of how the /Domain framework may be used.

Example 1: The Decentralized Bank

A bank is downsizing its computer operation from a mainframe to a network of computers. The designers would like to give more control of localized operations to each branch and they have decided to place two server computers at each branch.

Each one of these computer systems will maintain a localized set of the accounts managed by the branch. Each teller will have their own workstation and the branch's ATMs will be connected to the computer system. However, the bank wants to retain a centralized system for account reconciliation and auditing. The banking transactions performed by each branch must be sent to the centralized system as soon as they are processed by the local branch.

Finally, because customers may want to access their accounts from any branch, the application designers would like to have interconnectivity between the branch offices.

Figure 4: This shows an example of a decentralized bank.

The TUXEDO System is used at each branch, and the application is structured as an autonomous domain. A client/server application is written to provide access to client accounts. The teller (the client application) will use a set of screens to request services like open account, close account, transfer money between accounts, credit an account, debit an account, etc. These services are provided by a set of TUXEDO-based servers that access a database containing the customers accounts.

The designers have also abstracted the central system activities as a set of services that can be requested from the branches. These services could be similar to the services offered at each branch. In order to ensure that the transactions with the central system happen even is the central system is offline, the server application at each branch uses the TUXEDO System Reliable Queuing facility to enqueue the service requests to the central system.

The forwarding service sends the service requests to the remote central system via the /Domain framework. This central system can be a mainframe machine running a proprietary operating system or a TUXEDO domain (1 to 100 machines).

Using the TUXEDO System, application designers and application administrators can easily manage the integration between the branch and the central computer systems. The application administrator just adds /Domain gateway to the application configuration.

Then, the application administrator uses the /Domain configuration utility to define the characteristics of the central application, e.g. name of this remote domain, network addressing information, and the names of the services provided by the central application. Finally, the administrator starts the /Domain gateway and the gateway starts forwarding requests to the remote central application.

Connectivity between the branch offices can be achieved in a similar way. However, the bank may have hundreds of branches (some of them distributed across the country) and may not want to maintain hundreds of connections between these branches. With /Domain, the designers could implement a "hub" concept: branches are connected to a hub that manages the communications across branches.

Application designers can use the data dependent routing capabilities and the /Domain configuration file to convert a /Domain server group into a "router". Operating in this mode, /Domain gateways can forward requests to the appropriate branch using the data dependent routing facility (e.g., routing on the account number).

Finally, as the bank grows, the bank may merge with other banks that have different computer systems. Application designers can integrate these systems by "encapsulating" the services provided by these systems and then using the /Domain forwarding capabilities.

The aliasing capability in the /Domain framework can also be used to resolve the naming mapping problems and to normalize the service name space used by the services provided by the bank.

Example 2: Inventory Control

A retail store company has many stores distributed across the country. Each store has a small computer system that control the business transactions performed by the cashiers, and also maintains an inventory and prices of the different articles sold at the store.

The company has decided to automate the inventory control system. They decide to use TUXEDO to optimize access to set of databases containing the description, prices, suppliers, etc. for the different articles sold by the company. The company does not want to change the existing systems already deployed at the stores, but minimal new software can be added.

Application developers can use the /Domain framework to provide the connectivity required for this application. A local TUXEDO-based application can be deployed at the computer systems at the stores. This application analyzes the local inventory at the store, reports possible shortage of item, and accepts local commands from the store manager to order new items from the central inventory system.

This new inventory system at each store uses the existing hardware, and new orders are routed to the central inventory system through the /Domain framework via dial-up connections. The inventory system also allows incoming service requests from the central inventory management to verify which items are low, or find information about the quantity of certain items sold during the day, etc.

Figure 5: This shows an example of inventory control.

Example 3: Reservations System

A travel agency company needs to have access to a variety of reservations systems, e.g. airline, hotels, rental cars, etc. The company has the problem that all these systems use different conventions, interfaces, etc.. Also, the company would like to have a common and simple user interface that would minimize the training for travel agent representatives.

The company decides to use the TUXEDO System. With TUXEDO, the application designers can easily integrate all these distinct reservation systems as a single system with a common user interface. The system also provides additional value by keeping a database with the definition of the different travel packages sold by the agency. Access to this database is abstracted by a set of TUXEDO servers.

The connectivity to the remote reservations system is provided from another computer system (another domain). Access to the different reservation systems is abstracted at each travel agency as a set of services.

Figure 6: This shows an example of a reservations system.

The /Domain framework is used for the connectivity between the Travel agency system and the reservations systems. Services offered by the reservation systems are defined as remote services in the /Domain configuration. As the system grows, the application at the travel agency can easily adapt and evolve to accept new services provided from other reservation centers.

References

  1. Novell, Transaction Monitor Reference Manual. TUXEDO ETP System Release 4.2 Issue 4.

  2. Novell, Programming a Distributed Application. The TUXEDO System Approach.

  3. X/Open, Distributed Transaction Processing: The XATMI Specification, X/Open Preliminary Specification, July 1993.

  4. X/Open, Distributed Transaction Processing: The TxRPC Specification, X/Open Preliminary Specification, July 1993.

  5. X/Open, ACSE/Presentation: Transaction Processing API (XAP-TP), X/Open Preliminary Specification, January 1994.

* Originally published in Novell AppNotes


Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates