web analytics
Bea Tuxedo Application-to-Transaction Monitor Interface (ATMI) In C/C++ Options
codeling
Posted: Tuesday, April 5, 2016 11:15:59 PM

Rank:Advanced Member
Groups: Member
Joined: 12/11/2015
Posts: 777
Points: 3264

The Application-to-Transaction Monitor Interface (ATMI), the BEA Tuxedo API, is an interface for communications, transactions, and management of data buffers that works in all environments supported by the BEA Tuxedo system. It provides the connection between application programs and the BEA Tuxedo system. The ATMI is a simple interface for a comprehensive set of capabilities. It implements the X/Open DTP model of transaction processing.

The ATMI library offers you a variety of functions for defining and controlling global transactions in a BEA Tuxedo application. Global transactions enable you to manage exclusive units of work spanning multiple programs and resource managers in your distributed application. All work in a single transaction is treated as a logical unit, so that if any one program cannot complete its task successfully, no work is performed by programs in the transaction. Most ATMI functions support different communication styles. These functions knit together distributed programs by enabling them to send and receive data. All ATMI functions send or receive data in typed buffers. Following is a list of ATMI functions in C language, and the tasks they perform. The functions are grouped by task.

Client membership

  • tpchkauth(3c): Check whether authentication is required
  • tpinit(3c): Have a client join an application
  • tpterm(3c): Have a client leave an application

Buffer management

  • tpalloc(3c): Create a message buffer
  • tprealloc(3c): Resize a message buffer
  • tpfree(3c): Free a message buffer
  • tptypes(3c): Get a message type and subtype

Message priority

  • tpgprio(3c): Get the priority of the last request
  • tpsprio(3c): Set the priority of the next request

Request/response communications

  • tpcall(3c): Initiate a synchronous request/response to a service
  • tpacall(3c): Initiate an asynchronous request (fanout)
  • tpgetrply(3c): Receive an asynchronous response
  • tpcancel(3c): Cancel an asynchronous request

Conversational communications

  • tpconnect(3c): Begin a conversation with a service
  • tpdiscon(3c): Abnormally terminate a conversation
  • tpsend(3c): Send a message in a conversation
  • tprecv(3c): Receive a message in a conversation

Reliable queuing

  • tpenqueue(3c): Enqueue a message to a message queue
  • tpdequeue(3c): Dequeue a message from a message queue

Event-based communications

  • tpnotify(3c): Send an unsolicited message to a client
  • tpbroadcast(3c): Send messages to several clients
  • tpsetunsol(3c): Set unsolicited message call-back
  • tpchkunsol(3c): Check the arrival of unsolicited messages
  • tppost(3c): Post an event message
  • tpsubscribe(3c): Subscribe to event messages
  • tpunsubscribe(3c): Unsubscribe to event messages

Transaction management

  • tpbegin/tx_begin(3c): Begin a transaction
  • tpcommit/tx_commit(3c): Commit the current transaction
  • tpabort/tx_rollback(3c): Roll back the current transaction
  • tpgetlev(3c): Check whether in transaction mode
  • tpsuspend(3c): Suspend the current transaction
  • tpresume(3c): Resume a transaction
  • tx_info(3c): Returns global transaction information
  • tx_set_commit_return(3c): Sets commit_return characteristic
  • tx_set_transaction_control(3c): Sets transaction_control characteristic
  • tx_set_transaction_timeout(3c): Sets transaction_timeout characteristic

Service entry and return

  • tpsvrinit(3c): Initialize a server
  • tpsvrdone(3c): Terminate a server
  • tpservice(3c): Prototype for a service entry point
  • tpreturn(3c): End a service function
  • tpforward(3c): Forward request

Dynamic advertisement

  • tpadvertise(3c): Advertise a service name
  • tpunadvertise(3c): Unadvertise a service name

Resource management

  • tpopen/tx_open(3c): Open a resource manager
  • tpclose/tx_close(3c): Close a resource manager
Sponsor
Posted: Tuesday, April 5, 2016 11:15:59 PM
codeling
Posted: Wednesday, April 6, 2016 3:36:51 PM

Rank:Advanced Member
Groups: Member
Joined: 12/11/2015
Posts: 777
Points: 3264

Communication Paradigms

There are two basic communication paradigms: request/response and conversational. Request/response services are invoked by service requests along with their associated data. Request/response services can receive exactly one request (upon entering the service routine) and send at most one reply (upon returning from the service routine). Conversational services, on the other hand, are invoked by connection requests along with a means of referring to the open connection (that is, a descriptor used in calling subsequent connection routines). Once the connection has been established and the service routine invoked, either the connecting program or the conversational service can send and receive data as defined by the application until the connection is torn down.

Note that a process can initiate both request/response and conversational communication, but cannot accept both request/response and conversational service requests.

codeling
Posted: Wednesday, April 6, 2016 3:38:19 PM

Rank:Advanced Member
Groups: Member
Joined: 12/11/2015
Posts: 777
Points: 3264

BEA Tuxedo ATMI System Request/Response Paradigm for Client/Server

With regard to request/response communication, a client is defined as a process that can send requests and receive replies. By definition, clients cannot receive requests nor send replies. A client can send any number of requests, and can wait for the replies synchronously or receive (some limited number of) the replies at its convenience. In certain cases, a client can send a request that has no reply. tpinit() and tpterm() allow a client to join and leave a BEA Tuxedo ATMI system application.

A request/response server is a process that can receive one (and only one) service request at a time and send at most one reply to that request. (If the server is multithreaded, however, it can receive multiple requests at one time and issue multiple replies at one time.) While a server is working on a particular request, it can act like a client by initiating request/response or conversational requests and receiving their replies. In such a capacity, a server is called a requester. Note that both client and server processes can be requesters (in fact, a client can be nothing but a requester).

A request/response server can forward a request to another request/response server. Here, the server passes along the request it received to another server and does not expect a reply. It is the responsibility of the last server in the chain to send the reply to the original requester. Use of the forwarding routine ensures that the original requester ultimately receives its reply.

Servers and service routines offer a structured approach to writing BEA Tuxedo ATMI system applications. In a server, the application writer can concentrate on the work performed by the service rather than communications details such as receiving requests and sending replies. Because many of the communication details are handled by BEA Tuxedo ATMI system's main, the application must adhere to certain conventions when writing a service routine. At the time a server finishes its service routine, it can send a reply using tpreturn() or forward the request using tpforward(). A service is not allowed to perform any other work nor is it allowed to communicate with any other process after this point. Thus, a service performed by a server is started when a request is received and ended when either a reply is sent or the request is forwarded.

Concerning request and reply messages, there is an inherent difference between the two: a request has no associated context before it is sent, but a reply does. For example, when sending a request, the caller must supply addressing information, whereas a reply is always returned to the process that originated the request, that is, addressing context is maintained for a reply and the sender of the reply can exert no control over its destination. The differences between the two message types manifest themselves in the parameters and descriptions of the routines described in tpcall().

When a request message is sent, it is sent at a particular priority. The priority affects how a request is dequeued: when a server dequeues requests, it dequeues the one with the highest priority. To prevent starvation, the oldest request is dequeued every so often regardless of priority. By default, a request's priority is associated with the service name to which the request is being sent. Service names can be given priorities at configuration time (see UBBCONFIG(5)). A default priority is used if none is defined. In addition, the priority can be set at run time using a routine, tpsprio(). By doing so, the caller can override the configuration or default priority when the message is sent.

codeling
Posted: Wednesday, April 6, 2016 3:38:55 PM

Rank:Advanced Member
Groups: Member
Joined: 12/11/2015
Posts: 777
Points: 3264

BEA Tuxedo ATMI System Conversational Paradigm for Client/Server

With regard to conversational communication, a client is defined as a process that can initiate a conversation but cannot accept a connection request.

A conversational server is a process that can receive connection requests. Once the connection has been established and the service routine invoked, either the connecting program or the conversational service can send and receive data as defined by the application until the connection is torn down. The conversation is half-duplex in nature such that one side of the connection has control and can send data until it gives up control to the other side. In a single-threaded server, while the connection is established, the server is "reserved" such that no other process can establish a connection with it. When a connection is established to a multithreaded server, however, that server is not reserved for exclusive use by one process. Instead, it can accept requests from multiple client threads.

As with a request/response server, the conversational server can act as a requester by initiating other requests or connections with other servers. Unlike a request/response server, a conversational server cannot forward a request to another server. Thus, a conversational service performed by a server is started when a request is received and ended when the final reply is sent via tpreturn().

Once the connection is established, the connection descriptor implies any context needed regarding addressing information for the participants. Messages can be sent and received as needed by the application. There is no inherent difference between the request and reply messages and no notion of priority of messages.

Users browsing this topic
Guest

Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.


© 2017 Digcode.com. All rights reserved.