Introduction and Overview

The objective of this chapter is to introduce the concept of /Domain, to define terms and to give a brief overview of the capability of the feature.

What is a Domain?

As a business grows, application developers may need to organize the different segments of the business by sets of functionality that require administrative autonomy but allow sharing of services and data. Each functionality set defines an application that may span one or more computer nodes, and that is administered independently from other applications. Such a functionally distinct application is referred to as a domain; in practice, the organization often uses the domain's functionality as part of its name so you find applications with names like the "accounting" domain or the "order entry" domain.

The BEA TUXEDO System /Domain Feature

BEA TUXEDO System/Domain provides a framework for interoperability between the domains of a business that continues the System/T enhanced client/server model. Interoperability, it should be noted, means more than merely the ability to communicate from one domain to another; by transparently making access to services of a remote domain available to users of the local domain (or accepting local service requests from users of a remote domain), /Domain, in effect, breaks down the walls between the business applications of an organization. /Domain does this by defining a set of processes, called gateways, that manage the communication between domains.

Instantiations of the BEA TUXEDO System /Domain

BEA TUXEDO System/Domain is offered in an instantiation called /TDOMAIN, which can be used to provide interoperability between two or more BEA TUXEDO System/T applications.

/Domain Terms

Here are terms that are used in our discussion of /Domain.

BEA TUXEDO System/T Application: A BEA TUXEDO System/T Application is bounded by the environment described in a single TUXCONFIG file. A BEA TUXEDO System/T Application can communicate with another BEA TUXEDO System/T Application via a domain gateway group.
Domain:: Another word for a BEA TUXEDO System/T application.
Domain Gateway Group: A Domain Gateway Group is a collection of gateway processes that provide communication services with other domains.
Domain Gateway: A Domain Gateway is a BEA TUXEDO System/T process that relays requests and replies to other domains.
Local Domain: A Local Domain is a part of an application (set or subset of services) that is made available to other domains. A Local Domain is always represented by a Domain Gateway Group, and the terms are used interchangeably.
Remote Domain: A Remote Domain is a part of an application that is accessed through a Domain Gateway Group.
Remote Service: A Remote Service is a service of a remote domain that is made available to the local application through a Domain Gateway Group.
Local Service: A Local Service is a service of a local domain that is made available to remote domains through a Domain Gateway Group.

How /Domain Works

BEA TUXEDO System/T provides an application programming framework that simplifies the development of open OLTP distributed applications by hiding the complexity associated with the distribution of application processing. The framework consists of 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. The framework also provides a centralized administration subsystem that allows application administrators to control all cooperating nodes as a single application.

However, it is not always possible to structure applications as a single distributed application because of their nature, geographical location, confidentiality, and potential growth. Also, an enterprise may want to expand their business by cooperating with other organizations that provide OLTP services that may be under the control of different transaction processing monitors (for example, NCR's TopEnd, Transarc's Encina, IBM's CICS, Bull's TDS, Bull's TP8, ICL's TPMS, and so forth).

BEA TUXEDO System/T provides the basic framework for domain interoperability. This framework defines a set of processes, called gateways, that manage the communication between domains. These gateways run within a System/T server group. This is illustrated in Figure 1 which shows a System/T application that requires services (in this case, credit card authorizations) from a remote domain. The application also accepts service requests (for example, balance inquiries) from remote domains. The gateway process provides bi-directional transaction control, and administrative tools that allow the configuration of the information 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. BEA TUXEDO System/T configuration of /Domain is the subject of Chapter 3.

Fig. 1: A generalized view of two communicating domains

Figure 2 shows a more detailed view of the environment associated with domains. The example shows a credit card authorization center running under the control of System/T. There are two gateway groups: one (bankgw1) that provides access to remote System/T domains and another (bankgw2) that provides access to remote domains via OSI-TP protocol. Another System/T domain (bank ABC) generates service requests to the credit card authorization system. These requests are received by a gateway running within group bankgw1. This gateway will issue a service request on behalf of the remote domain to the credit card authorization service which is provided by a local server. The server processes the request and sends the reply to the gateway, and the gateway returns it to Bank ABC.

Fig. 2: A look at /Domain environments

The credit card authorization system may also issue service requests to bank ABC, for balance inquiries, for example. /Domain makes this possible by behaving as a local server that advertises the services available on the other domains as if they were local services.

/Domain provides the notion of a local domain to control incoming requests, and to provide a generic addressing framework for the application. Local domains help to provide partial views of an application, that is, a subset of the local services available to a set of remote domains. Each local domain is always represented by at least one gateway server group.

Cooperation With Other Applications

The main goal of the /Domain feature is to allow the cooperation of System/T applications with dozens of applications running in other administrative domains. By meeting this goal,

/Domain maintains the BEA TUXEDO System/T client/server model by making access to services on the remote TP System (or accepting service requests from a remote TP System) transparent to both the application programmer and the end-user (See Figure 3). Application programmers use the ATMI interface to access the services provided by remote domains, or to define services that can be executed by a remote domain. Section BEA TUXEDO System/Domain Capability below, discusses the implications of these inter-domain communications on the different ATMI primitives.

Fig. 3: Two-way communication through a gateway

/Domain provides an asynchronous multi-threaded gateway able to process both requests going out to remote domains and requests coming in from remote domains. Any request can be processed within a transaction.

BEA TUXEDO System/Domain Capability

BEA TUXEDO System/T provides an application programming framework that simplifies the development of open OLTP applications and hides the complexity associated with the distribution of the application. The framework is an extended client/server model that offers four programming paradigms: request/response, connection-oriented processing, enqueue/dequeue, and unsolicited notification. These paradigms are provided through the Application Transaction Management Interface (ATMI), and are designed to meet the requirements of open OLTP systems. ATMI helps open OLTP application developers structure their code for portability, location transparency, performance, modular growth, and reliability.

/Domain extends the BEA TUXEDO System/T client/server model to provide transaction interoperability across TP domains. This extension preserves the model and the ATMI interface by making access to services on the remote domain (or accepting service requests from a remote domain) transparent to both the application programmer and the end-user. /Domain makes this possible via a highly asynchronous multi-tasking gateway that processes outgoing and incoming service requests to or from remote domains.

A /Domain gateway is a System/T-supplied server that enables access to and from remote domains. /Domain gateways (DGW in Figure 4) run as a Multiple Server Single Queue set (MSSQ) where each gateway uses a common request queue and has its own reply queue. In addition, /Domain provides a gateway administrative server (GWADM in Figure 4) that enables run-time administration of the /Domain gateway group and a /Domain administrative server (DMADM in Figure 4) that enables run-time administration of the /Domain configuration information. The application administrator enables remote domain access by specifying a gateway group and a domain administration group in the *GROUPS section of the TUXCONFIG file, and by adding entries for the gateway and the two administrative servers in the *SERVERS section. Configuration is covered in Chapter 3.

Fig. 4: Domain Gateway Group

/Domain gateways support the following functionality:

ATMI's request/response model. Application programs using BEA TUXEDO System/T can request services from applications running in another domain. Also, remote applications can request services from local servers. No changes are required to the application programs.
ATMI's conversational model. Application programs can establish conversations with programs running in another domain. Remote domains can establish conversations with conversational services offered by local servers.
Transaction management. Application programs can interoperate with other domains within a transaction. The gateway coordinates the commitment or rollback of transactions running across domains.
Administration. Gateways can be booted or shutdown exactly as any other System/T server. Run-time administration is provided through an administrative server, DMADM. Using DMADM, application administrators can make changes to the domain configuration file, and tune the performance of a gateway group.
Typed buffer support. Gateways can perform encoding and decoding operations for all typed buffers defined by the application.
Multi-domain interaction. Gateways can communicate with multiple domains of the same type.
Multi-network support. Gateways can communicate with other domains via a variety network protocols such as TCP/IP, IPX/SPX and others. However, a gateway is limited by the capabilities of the specific networking library linked with the gateway. In other words, a gateway typically supports a single type of network protocol.

The functionality of the BEA TUXEDO System/T client/server model listed above is realized through the following capabilities of /Domain gateways.

Request/Response communication
Conversational communication
Typed Buffers support
Timeout and error handling
Enqueue/Dequeue

Request/Response Communication

/Domain gateways provide support for the request/response model defined by the ATMI interface. A System/T application can request remote services exactly as if they were offered within the application. Also, remote domains can request services offered within the local application exactly as if they were offered within the remote application.

Not All System/T ATMI Primitives Supported

A small number of the System/T ATMI primitives are logically limited to use within a single application and so are not supported across domains:

tpinit()/tpterm(): BEA TUXEDO System/T applications do not attach to the environment of a remote domain, they use /Domain gateways to access the remote domain. There is therefore no need for the primitives through which a client attaches to an application or terminates a session.
Initially /Domain gateways will not support dynamic service advertisements across domains. This functionality may be implemented in the future via the /Domain administration facilities but in the meantime tpadvertise(3c) and tpunadvertise(3c) may not be used across domains.
tpnotify(3c) and tpbroadcast(3c): the initial version of /Domain will not be able to support the unsolicited communication paradigm provided by these primitives.
Event posting ( tppost(3c)) and notification of events ( tpsubscribe(3c)) are not available across domains.

Support for tpforward(3c) is provided to preserve the portability of applications using this primitive. Forwarded requests are interpreted by /Domain gateways as simple service requests. This is illustrated in Figure 5 for the simple case of a service using tpforward to a remote service.

Fig. 5: Service uses tpforward to a remote service

Conversational Communication

The ATMI interface allows the definition of conversational services and provides a connection-oriented interface that allows clients to establish and to maintain a conversation with services configured and coded as conversational services.

System/T applications can use tpconnect(3c) to open a conversation with a remote service, tpsend(3c) and tprecv(3c) to communicate with this service, and tpdiscon(3c) to end the conversation. /Domain gateways maintain the conversation with the remote service, and provide the same semantics for returns (that is, tpreturn with TPSUCCESS or TPFAIL) and disconnects as defined for System/T conversational services.

Note that the ATMI connection-oriented primitives provide half-duplex conversations and that tpforward(3c) is not allowed within a conversational service.

Application administrators indicate whether a remote service is a conversational service by specifying CONV=Y in the *DM_REMOTE_SERVICES section of the DMCONFIG file.

Typed Buffers

In BEA TUXEDO System/T, applications use typed buffers to pass data from clients to servers. The typed buffer mechanism allows application programmers to pass data between clients and servers without having to be concerned about the data representation of the machines where these processes run.

A /Domain gateway can receive and process service requests sent from workstations, System/T nodes, or remote domains with different machine representations. Hence, gateways must be linked with the typed buffer switch defined by the application administrator so it knows how, for example, to decode the data sent with the service request.

/Domain gateways always try to decode any service request that is received encoded for two reasons:

The gateway may have to apply data dependent routing to select the remote domain that must execute the service request (data dependent routing criteria for remote domains is defined in the /Domain configuration file).
Each /Domain instantiation may use different data formats as required by the network protocol it implements or uses.

Point 2) is important to discuss further. Following the OSI terminology, a distinction must be made between the abstract syntax (that is, the structure of the data) and the transfer syntax (that is, the particular encoding used to transfer the data). Each typed buffer implicitly defines a particular data structure (that is, its abstract syntax) and the encoding rules (that is, its typed buffer operations) required to map the data structure to a particular transfer syntax (for example, XDR).

BEA TUXEDO System/T provides a set of pre-defined buffer types: STRING, CARRAY, FML, VIEW, X_C_TYPE, X_OCTET, and X_COMMON, and the necessary encoding rules required to map these types to the XDR transfer syntax.

Application programmers wishing to supply their own buffer types can do so by adding an instance to the tm_typesw array in $TUXDIR/lib/tmtypesw.c (see tuxtypes(5) and typesw(5)) and by supplying the routines for the new type (see buffer(3I)).

Timeout and Error Handling

BEA TUXEDO System/T provides two timeout mechanisms: a transaction timeout mechanism and a blocking timeout mechanism. The transaction timeout is used to define the duration of a transaction, which may involve several service requests. The timeout value is defined when the transaction is started (with tpbegin(3c)). The blocking timeout is used to define the duration of service requests, that is, how long the application is willing to wait for a reply to a service request. The timeout value is a global value defined in the BLOCKTIME field of the *RESOURCES section of the TUXCONFIG file. The transaction timeout always overrides a blocking timeout value.

The BEA TUXEDO System/T transaction timeout mechanism is used unchanged in the /Domain framework. This is possible because /Domain gateways implement the TMS functionality and therefore are required to handle the TMS_TIMEOUT messages generated by the BBL.

/Domain gateways, however, cannot use the BEA TUXEDO System/T blocking timeout mechanism. The main reason is that the blocking timeout mechanism uses information stored in the registry slot assigned to each client or server. Information in the registry slot is used by the local BBL to detect requesters that have been blocked for a time greater than BLOCKTIME.

However, /Domain gateways are multi-tasking servers that may process several service requests at a time. This means that the /Domain gateway cannot successfully use the registry slot mechanism.

When a /Domain blocking timeout condition arises, the /Domain gateway sends an error/failure reply message to the requester, and then it "cleans" any context associated with the service request.

Enqueue/Dequeue

The ATMI enqueue/dequeue communication paradigm allows applications to communicate via messages stored on stable-storage queues. This feature provides a reliable communication mechanism (messages are not lost if a machine crashes) and a mechanism by which applications can schedule the delivery of requests to an application server or replies to a requester.

The default mechanism provided with the Queued Message facility is as follows. A requester uses tpenqueue(3c) to place a service request on a queue that resides in a particular queue space. A queue space refers to a service provided by an enqueueing server ( TMQUEUE(5)) and a queue is associated with a particular application service (for example, credit); tpenqueue(3c) sends a message to the TMQUEUE server, and the message is stored in stable storage. When a message reaches the top of the queue, a dequeueing server ( TMQFORWARD(5)) dequeues the message and forwards the request (via tpcall(3c)) to the application service; when the service returns the reply, TMQFORWARD enqueues the reply on the reply queue in stable storage. At some later time, the requester uses tpdequeue(3c) to get the reply message; tpdequeue sends a request to the TMQUEUE server to retrieve the reply message from the reply queue.