<
  Manycom DTS
 
Manycom Solutions

Home > Products > Manycom DTS > Technical Description

 
 

Product Description

Contents
Introduction | Benefits | Technical Description | Cases and References | System Requirements | Prices | Availability and Support | Manuals and Documentation | License and Maintenance Agreements

Technical Description

When to use real-time communications

In today's eBusiness environments there are natural and increasing needs to offer real-time (accurate and up-to-date) data services to the end-users. More and more often this need arises also in the multi-system and multi-vendor environments, where the applications and databases are distributed to several different systems.

It is important to realize, that batch type communications such as FTP file transfer or e-mail cannot be used as a transfer method for real-time communication purposes. These methods are too slow and loady when each transaction (change of data field or record) should be transferred and updated immediately in the other systems. Batch type communications can neither be used for real-time or on-line access to the remote databases.

In fact, real-time data services are possible only if real-time communication methods (protocols) are used for accessing, transferring, updating and processing the distributed data.

About the client-server communications

Along the traditional three-layer application architecture a typical application consists of three main functions: presentation, processing and database. Communications, if needed in the application, is actually the fourth main function.

Communications between the systems can take place basically in five different ways depending on which parts of the applications take care of the communications. All the five communications types are called 'client-server', because technically the side, which initiates the transaction (service request) over the line is always the 'client', and the other side, which responses to the service requests, is the 'server'.

The following figure shows the five basic client-server communication types.

Client/Server Communication Types

DTS base operations for the client-server communications

DTS is a communication middleware software, which enables easy implementations of one of the five basic client-server communications types - the distributed processing. With distributed processing the client and server applications can share the processing of the transactions exactly as is desired and programmed, and the communication takes place by exchanging 'data messages' between the applications through the DTS-to-DTS connection.

Each DTS has two components, the DTS client (also called 'front-end') and the DTS server (also called 'back-end' or 'handler', and each DTS node can operate simultaneously in both roles, if needed.

With DTS, the client application sends the server application an input message, which is a data buffer up to 32 kB of data, and gets back the response message (up to 32 kB) during the same connection (communications session) as soon as the server applications has processed the input data and returned the output data.

The 39 first bytes of the input data contains the DTS header or control fields, which include among other things the name of the remote DTS node, the name of the server application and the DTS function code (or operation type: real-time, semi-real-time or spooled/queued).

In each transaction, the client application calls the DTS client API program giving the input data and input data length in the input parameters to the DTS client. After performing the configured EBCDIC/ASCII data conversion (if requested), the DTS client performs the 'init connection' operation in the communications interface (e.g. TCP/IP socket or APPC) in order to establish a physical link and logical communication session with the DTS server.

DTS server must be activated and waiting for the incoming calls, for instance in the configured IP port and address (or in the configured SNA LU if the SNA is used). After a successful connection the DTS client sends the input data to the DTS server. The DTS server, after performing the requested ASCII/EBCDIC conversion, immediately calls the server application named in the DTS header, and gives the input data and input data length in the input parameters to the server application.

The server application now processes the input data and returns the output data and output data length in the output parameters to the calling DTS server program, which in turn writes it to the still open communications session. The local DTS client, which is waiting for the return message, reads the output data from the communications interface, closes the logical connection, and performs the configured ASCII/EBCDIC character code conversion (if requested), and returns the output data and output data length to the calling client application.

The client and server applications can be built with any programming language available in that system, which supports the 'program call' function such as CL, COBOL, FORTRAN, C or RPG.

DTS takes care of all the operations on the lower-level communications programming interface (TCP socket, APPC, DECnet, etc.), and interprets and maps the communication interface return code to the related DTS return code passing it to the calling application in the first two bytes of the first output parameter. The client application can then see if the operation was successful or not, and decide what to do next.

Notice, that DTS handles the entire transaction during the same call and active session. The separate 'synchronization' of the input and output message is not needed in the applications, because the response is always returned to the client application when the program call returns!

Although the way in which way DTS operates may look a bit complicated, it is actually a very simple, robust and effective way to communicate. Distributed processing and real-time data messaging provide often the best way to solve the transaction processing and communication needs, especially in multi-vendor environments with different operating systems, applications and databases.

Throughput and performance of DTS are excellent, since distributed processing allows optimal use of the line capacity and processing power. How the processing of transactions is divided between the client and server applications, and which data and in which format is exchanged between the applications, is up to the system designers and programmers.

About the DTS API

In the client application, you first set the names of the DTS server 'node' and DTS server application also called a 'DTS handler' you want to communicate with during the next call. The node name and the related location (e.g. IP address) must be configured in the local DTS. The handler name must be configured and is checked for security reasons in the server site.

You also set the DTS function code, which defines the transaction type: real-time (no spooling), semi real-time (spooling allowed) or spooled (always spooled). The function code also controls the use of the ASCII/EBCDIC character conversion table and DTS compression, which are pre-configured separately for each configured DTS node.

Notice, that these settings need to be changed before each transaction (call) only if some of the values change, for instance if you change the name of the DTS server node or server application in order to call and communicate with another system or application.

You need to move these values to the specific positions in the beginning of the input data buffer.
DTS reserves 39 first bytes of the input data buffer for this control information, which is delivered to the DTS server program. This is how the DTS server knows which server application to start.

The actual user input data is moved to the rest of the input buffer starting in the position 40. The maximum sizes of the data buffers (input and output) are 32 kB.

You have to move then this input buffer to the input parameter1 (p1) and the length of the input data to the input parameter2 (p2) before calling the DTS client API program.

The local client application can now call the local DTS client API program with the two input and two output parameters. The 39 bytes of DTS control data and the input data are in the parameter p1. The calling client application keeps waiting for the return from the called DTS client program.

The DTS server program calls the server application with four parameters: the 'input data' and 'input data length' are the first two parameters, and the 'output data' and 'output data length' are for getting the response from the server application.

The DTS server program gets the two bytes long return code followed by the possible output data in the first output parameter, and the output data length in the second parameter when the call returns from the server application. Notice, that this DTS server interface with the four parameters is identical with the DTS client interface.

The DTS server program then writes the output data to the still open communications session.

The DTS client program, which is waiting for the DTS return code and response data from the line, reads the data, closes the connection, and moves the output data and output data length in the two output parameters p3 and p4, and returns the control to the calling client application.

The 2 first bytes of the output data contain the DTS return code, which tells to the client application if the transaction was successful or not. The actual user data starts in the position 3.

The same operations are always repeated for each new DTS call.

Additional features

DTS also provides additional functions such as ASCII/EBCDIC character code conversion and DTS data compression. Some DTS implementations also use data encryption and exchange of the keys on transaction level.

One of the most useful features is the spooling or queuing capability of DTS. When problems occur with the connection, DTS automatically stores and then later resends the transactions in the same order to the remote application.

All DTS implementations also include a ready-to-run file copy application for sending and receiving files (actually records of the files).

The installation menu and procedures enable you to configure DTS nodes, applications, protocols and communications resources of the network quickly and easily. Statistics, traffic monitoring and logging functions help in maintenance and problem management.

Some remarks

After performing the data conversion, compression and possible encryption for the input data, the DTS client program establishes the physical link, if not yet active, and then establishes the logical communications session with the DTS server program. Then it sends the data to the DTS server.

If the DTS transaction type is set to 'real-time' (function code 01), but the connection cannot be established, the DTS client returns an error code to the calling application in the two first bytes of the first output parameter.

If the client application allows DTS spooling the transaction (function codes 02 and 03), DTS saves the transaction in a file, returns the call immediately with an 'ok' return code, and tries to send the data to the server DTS as soon as possible. DTS spooler always sends the spooled transactions in the proper order to the server. DTS spooler makes as many retries as is needed to get the next transactions sent to the server. The retry interval is pre-configured for the spooler. Transactions cannot pass each other.

Only 39 bytes of DTS control information are included in the beginning of each input data buffer, and 2 control bytes in the beginning of the output data buffer. The maximum data length for input and output data buffers is 32 kB. The data contents of each transaction can be anything you have agreed between the partner applications. The data can be in a bit stream or any character coded format. DTS supports binary transfer without any code conversion.

The DTS server checks the requested server application name from its DTS configuration table. If not found, an error return code is sent back to the DTS client.

If the requested transaction is not successful because of a local or remote program error, physical or logical communication session error, or because of logical errors in the server application (e.g. the requested file or program is not found), DTS interprets the situation and returns the relevant DTS return code to the client application.

 
Top of the page