Product Description
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.
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.
|
