System for allocating adaptor to server by determining from embedded foreign protocol commands in client request if the adapter service matches the foreign protocol5812768Abstract An object interface is disclosed that supports three modes of inter-object communication--message processing (store and forward), conversational communication, and remote procedure call. A service broker manages service requests from, and responsive services provided by, a plurality of clients and servers, respectively, which may reside on different hardware platforms and operating systems and may be connected to computer networks having different network architectures and associated communications protocols. The broker manages the service offerings from servers and service requests from clients, and clients and servers communicate and exchange information with one another via the broker. The service broker includes different application programming interfaces for allowing participants to access the functionality of the service broker. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
Field Input/
Name Out-
(abbrev.)
Description put Cat. Fmt
______________________________________
FUNC- The function to be brokered.
I 1 A16
TION
(F)
SERVER-
Logical name of the server
I 1 A32
NAME
(SN)
SERVER-
Used to differentiate between
I 1 A32
CLASS simultaneously active servers with the
(SC) same logical name
BROKER-
Unique identifier which is used to send
I 1 A32
ID a request to a Broker other than the
(BID) default/local Broker
SERVICE
Classifies the service to be performed
I 2 A32
(SV) by a server if this server offers multiple
services
USER-ID
ldentification of the user, required to
I 2 A32
(UID) perform security checks
PASS- Required for user authentication
I 1 A32
WORD
(PW)
WAIT For synchronous or asynchronous
I 1 A8
(W) request processing for the RECEIVE
and SEND function
ERROR- Errors detected by the Broker are
I 1 A8
CODE returned in this field
(EC)
CONV-ID
A unique conversation identifier,
I/O 2 A16
(CID) assigned by the Broker, used to
continue a dialog.
OPTION A field with various values depending
I/O 1 A32
(OP) on the requested function.
TOKEN Allows the user to re-establish
I 2 A32
(TK) connection with existing conversations.
SECU- Provides a means uf user authentication.
I 2 A32
RITY-
TOKEN
(STK)
SEND- Specifies the length in bytes of the data
I/O 2 A8
LENGTH to be forwarded by the broker.
(SL)
RE- Specifies the length of data that the
I 2 A8
CEIVE- caller wants to receive.
LENGTH
(RL)
EN- A read-only field that contains
O 1 A32
VIRON- information required for Broker
MENT translation services (for example,
(ENV) EBCDIC to ASCII)
______________________________________
The Function field identifies which function is to be performed by the broker. These functions are described in detail below. The Server Name field identifies the logical name of the participant that provides the requested service. One of the broker's functions is to translate the logical name into the "real" address of the server. The Server Class field identifies the name of the server type. Several like servers may be active simultaneously with different logical names. The Broker-ID field identifies the broker. It is used when a client requires access to a server registered with a remote broker without directory assistance. This also accommodates the simultaneous use of more than one broker on the same platform. The Service field defines the service to be performed by the server. The User-ID field identifies the user and is required, for example, if the broker is providing security services. The Password field is used to prevent unauthorized access to a service as part of the Security Services. With the Wait field, the caller can choose between synchronous and asynchronous processing by using this field. It also determines the length of time spent waiting for a response from the various functions--the "time-out" value. The broker obtains the Min, Default, and Max allowable wait values from the Attribute file (if available). The administrator can set these values on a global or individual basis. Defined values include:
______________________________________
Value
Meaning
______________________________________
YES The caller has requested synchronous processing. The broker will
not return control until the request has been processed or a
"time-out" has occurred.
NO The caller has requested asynchronous processing. The broker
will return control without waiting.
MAX The caller has requested synchronous processing. The broker sets
the "time-out" value to the maximum set by the administrator.
n The caller has requested synchronous processing. The broker will
check that "n" is within the Min and Max settings allowable and
then set the "time-out" value to "n."
______________________________________
Errors detected by the broker are returned in the Error.sub.-- Code field. For all conversations a unique conversation identification is assigned by the broker. Both client and server must use this Conv.sub.-- ID to continue a dialogue. Requests/responses are taken from the queue on a FIFO basis. To initiate a dialogue, Conv.sub.-- ID=NEW must be given by the client (SEND) and by the server (RECEIVE). To initiate a non-conversational or connectionless request, the client (SEND) must use Conv.sub.-- ID=NONE. Defined values for the Conv.sub.-- ID field include:
______________________________________
Valid with
Value Function Meaning
______________________________________
NEW SEND Initiates a new conversation -- the broker will give a
unique new ID in return.
RECEIVE Returns the request/response for a new conversation
OLD RECEIVE Broker will return the request/response only for an
existing conversation.
ANY RECEIVE Broker wili return the request/response on the queue
for any conversation (old or new) on a FIFO basis.
EOC Action will be applied to all conversations.
NONE SEND The broker will not initiate a new conversation. The
caller's request will be forwarded and a response
returned if one becomes available and the caller is
waiting. A maximum of 1 response is allowed using
this value.
n SEND, The broker will process the SEND or RECEIVE
RECEIVE for the particular conversation identified by "n."
DELETE, The action will only be appiied to this conversation.
UNDO,
EOC
______________________________________
The Option field has various values depending on the requested function. Defined values for the Option field include:
______________________________________
Valid with
Value Function Meaning
______________________________________
IMMED DEREGISTER,
The action is immediate and no further
EOC processing will be allowed. New requests
will be refused and all conversations will
be terminated.
QUIESCE
DEREGISTER The broker will not accept any more new
requests to start conversations. Existing
conversations are allowed to continue within
an administrator-defined time-out period.
When all the existing conversations have
been ended the broker takes the caller of the
active list and performs clean up and
termination activities.
EOC The broker will not accept any more SEND
processing. RECEIVE processing will be
allowed to continue until no more items
exist or a time-out occurs. The
conversation(s) are then ended.
NEXT RECEIVE The next unprocessed response/request on
the queue is returned to the caller.
LAST RECEIVE The request previously processed is re-read
and returned to the caller.
EOC SEND See function EOC for description of the use
of this option with SEND.
HOLD SEND, UNDO Accumulates or removes records in a
HOLD queue.
______________________________________
The user token in the Token field allows the user to re-establish connection with existing conversations. If the user has several applications running in parallel originating from the same physical location using the same UID and it is necessary to support a possible change of physical location (e.g. the client's terminal goes down) without losing existing conversations then this field should be provided by the user when the conversation is initiated. If a new request from the user comes from a different location but with the appropriate Token, then the broker will reconnect the user with the previous environment. This is subject to validation if security is in effect. This is not needed by applications that mask the location from the broker or in circumstances when the broker can uniquely identify the reconnection. The Security Token field is only valid for certain types of security systems and is only then required if security is in effect. It provides a convenient means of user authentication and is returned to the user following successful password verification. This is valid for the current session between the broker and a client/server only--when a client/server has timed-out or Deregistered, a new security token must be obtained. The Send.sub.-- Length field is necessary for SEND processing--it specifies the length (in bytes) of the data to be forwarded by the broker. The supplied data must be at least as long as the supplied length, as the broker does not pad the data. With SEND implying RECEIVE and no receive-length has been specified, the broker will use the supplied send buffer and this field to return the reply. The Receive Length field specifies the length of the data the caller wishes to RECEIVE. an explicit receive buffer of at least this length must be provided if the field is specified. The broker allows that both send and receive buffers may be located in the same place. If the returned data is longer than the value of this field, the data will be truncated to fit the supplied buffer and an appropriate Error Code returned. If the data is shorter than the value of the field, the supplied buffer will be filled up to this length. The Environment field is an informative (read only) field giving details of the environment under which another client/server is active. Its primary use is by the broker in applying translation services. D. Structure HAPI Although the parameter string format is more accessible to an application developer than the FSP control block format, in many programming languages generating a parameter string with appropriate separators is more difficult than other command structures. In many languages a more convenient mechanism is the Self-Defining Parameter Area ("SDPA"). The SDPA thus forms another HAPI, illustrated in FIG. 3A as the "struct" HAPI 46. If client/server 74 uses one of these SDPAs, a simple stub program 92 is used to convert the SDPA to the parameter-string format. The implementation of stub program 92 will be evident to the artisan. At least two types of SDPA are contemplated. The first SDPA is presented as a "C" structure in Table 1, below.
TABLE 1
__________________________________________________________________________
typedef struct.sub.-- SDPA
BEGIN
BYTE sdpatype; /*
Type of SDPA
*/
BYTE version; /*
for backwards compatibility
*/
BYTE length; /*
length of SDPA in bytes
*/
BYTE reserve; /*
Reserved */
BYTE func; /*
Function -- see Note 1
*/
BYTE option; /*
Option -- see Note 2
*/
BYTE env(.linevert split.S.sub.-- ENV.linevert split.);
/*
Environment */
char server (.linevert split.S.sub.-- SERVER.linevert split.)
/*
Server name */
char class (.linevert split.S.sub.-- CLASS.linevert split.)
/*
Server class
*/
char service (.linevert split.S.sub.-- SERVICE.linevert split.)
/*
Service name
*/
char etbid (.linevert split.S.sub.-- ETBID.linevert split.)
/*
Target Broker
*/
char uid (.linevert split.S.sub.-- UID.linevert split.)
/*
Logical UID */
char token (.linevert split.S.sub.-- TOKEN.linevert split.)
/*
Security Token
*/
char stoken (.linevert split.S.sub.-- TOKEN.linevert split.)
/*
User Token */
char password (.linevert split.S.sub.-- PASSWORD.linevert split.)
/*
Password */
char server (.linevert split.S.sub.-- WAIT.linevert split.)
/*
Wait */
char server (.linevert split.S.sub.-- ERROR.linevert split.)
/*
Broker Error Code
*/
char server (.linevert split.S.sub.-- CONVID.linevert split.)
/*
Conversation ID
*/
unsigned long l.sub.-- send.vertline.);
/*
Send buffer length
*/
unsigned long l.sub.-- rec;
/*
Receive buffer length
*/
BYTE send-buffer (.linevert split.l.sub.-- send.linevert split.);
/*
opt send buffer
*/
BYTE rec-buffer (.linevert split.l.sub.-- rec.linevert split.O;
/*
opt receive buffer
*/
>) SDPA;
__________________________________________________________________________
The defines and notes for the first SDPA are illustrated in Table 2, below.
TABLE 2
______________________________________
The following #DEFINES apply:
______________________________________
#define BYTE unsigned char
#define S.sub.-- UID 32
#define S.sub.-- OPTION
32
#define S.sub.-- TOKEN 32
#define S.sub.-- STOKEN
32
#define S.sub.-- CONVID
16
#define S.sub.-- ETBID 32
#define S.sub.-- SERVICE
32
#define S.sub.-- SERVER
32
#define S.sub.-- CLASS 32
#define S.sub.-- ENV 32
#define S.sub.-- PASSWORD
32
#define S.sub.-- WAIT 8
#define S.sub.-- ERROR 8
Note 1 -- Function Values
#define SEND 1
#define RECEIVE 2
#define DELETE 3
#define UNDO 4
#define EOC 5
#define REGISTER 6
#define DEREGISTER 7
Note 2 -- Option Values
#define MSG 1
#define HOLD 2
#define IMMED 3
#define QUIESCE 4
#define EOC 5
#define ALL 6
#define LAST 7
#define NEXT 8
______________________________________
The second type of SDPA, again presented as a "C" structure in Table 3, below, differs from the first type in the use of references to values rather than to the values themselves.
TABLE 3
__________________________________________________________________________
typedef struct.sub.-- SDPA
BEGIN
BYTE sdpatype; /*
Type of SDPA
*/
BYTE version; /*
for backwards compatibility
*/
BYTE length; /*
length of SDPA in bytes
*/
BYTE reserve; /*
Reserved */
BYTE func; /*
Function -- see Note 1
*/
BYTE option; /*
Option -- see Note 2
*/
BYTE env (.linevert split.S.sub.-- ENV.linevert split.);
/*
->Environment
*/
char *server (.linevert split.S.sub.-- SERVER.linevert split.)
/*
->Server name
*/
char *class (.linevert split.S.sub.-- CLASS.linevert split.)
/*
->Server class
*/
char *service (.linevert split.S.sub.-- SERVICE.linevert split.)
/*
->Service name
*/
char *etbid (.linevert split.S.sub.-- ETBID.linevert split.)
/*
->Target Broker
*/
char *uid (.linevert split.S.sub.-- UID.linevert split.)
/*
->Logical UID
*/
char *token (.linevert split.S.sub.-- TOKEN.linevert split.)
/*
->UserToken */
char *stoken (.linevert split.S.sub.-- STOKEN.linevert split.)
/*
->Security Token
*/
char *password (.linevert split.S.sub.-- PASSWORD.linevert split.)
/*
->Password */
char *server (.linevert split.S.sub.-- WAIT.linevert split.)
/*
->Wait */
char *server (.linevert split.S.sub.-- ERROR.linevert split.)
/*
->Broker Error Code
*/
char *server (.linevert split.S.sub.-- CONVID.linevert split.)
/*
->Conversation ID
*/
unsigned long l .sub.-- send;
/*
Send buffer length
*/
unsigned long l .sub.-- rec;
/*
Receive buffer length
*/
BYTE *send-buffer (.linevert split.l.sub.-- send.linevert split.);
/*
->opt send buffer
*/
BYTE *rec-buffer (.linevert split.l.sub.-- rec.linevert split.O;
/*
->opt receive buffer
*/
>) SDPA;
__________________________________________________________________________
E. Pre-Compilers and Integrated Functions Conceptually, another HAPI takes the form of a single programming language command, with the appropriate parameters in a parameter list. This type of HAPI can be achieved in two different ways. The first is to build the broker commands into the language. For example, a "SEND" statement can be built into the language so that a programmer simply writes a SEND statement and the programming language issues an appropriate parameter string to the parameter string HAPI 46. The integrated command represents a very high level API ("VHAPI") 50. The language can be viewed as providing a stub 90 to generate the appropriate parameter string. Alternatively, the broker command can be imbedded in an application and a pre-compiler used before the application is compiled to convert the command into a call to a specially-written subroutine, which converts the call command into the appropriate format for one of the HAPIs or the LAPI. The application program and the subroutine are then compiled, with the compiled subroutine forming a stub 96 for the application program 80, as illustrated schematically in FIG. 3A. F. Client/Server Implementations Each type of service request (RPC, conversational, and message queue) can be implemented via the LAPI or any of the HAPIs described above. Examples of implementations for client and server programs for each type of service request are given below. 1. RPC a. Client Programs An RPC can be implemented as a call to a subroutine. If an existing local subroutine implemented in a 3GL is to be processed as an RPC, the local subroutine must be replaced by a stub program with the same name. This stub program can be generated by a pre-compiler, as described above. However, as shown in FIG. 4, the stub procedure simply mimics the presence of the local procedure so that the client is unaware that the called procedure is not local. A symmetrical server stub is used with the server to provide the appropriate interface to the broker. After the broker receives the request via the client stub, the called procedure in the remote environment is invoked by service dispatcher 18. A pseudocode example for an RPC in a 3GL is given in Table 4, below.
TABLE 4
______________________________________
CALL "subroutine name" (parameters to be passed to the remote
subroutine)
______________________________________
b. Server Program An RPC server program can be written in a 3GL as a standard subroutine complying with the standards of the operational environment. This subroutine is dependent on the environment as long as it is implemented in a 3GL. Such servers must be described in the server directory if they are to be known by the broker. When a client request arrives, the broker activates the server in the appropriate environment via the dispatcher. As described above, the subroutine may have a server stub generated by a precompiler so that the server program can receive the remote parameters. A pseudocode example for an RPC server written as a COBOL subprogram is given in Table 5, below.
TABLE 5
______________________________________
PROGRAM "A"
.
DATA DIVISION
WORKING-STORAGE SECTION
.
LINKAGE SECTION
01 parm-n1
.
PROCEDURE DIVISION
.
RETURN
______________________________________
In a programming language that enables the VHAPI, the invocation of a subprogram is identical in both local and remote operations. The language handles ail of the logic necessary to establish an RPC transparently. A pseudocode example of a 4GL (NATURAL) call statement is given below in Table 6 for a client and in Table 7 for a server.
TABLE 6
______________________________________
DEFINE DATA LOCAL
1 #NAME (A20)
1 #ADDRESS (A40)
END-DEFINE
CALLNAT "REMPROG" #NAME #ADDRESS
END
______________________________________
2. Conversational and Messaging The implementation of conversation and messaging requests is handled symmetrically for clients and servers. A pseudocode example for a conversational server in a 3GL at the parameter string HAPI 46 or the structure HAPI 48 is given in Table 8, below.
TABLE 8
______________________________________
CALL "broker" parameter string or SDPA
(i.e., function, type of request end data to be passed)
______________________________________
Alternatively, the conversational or message queue request can simply be handled as a statement in a programming language that includes the desired function as a statement. G. Network Data Conversion Different network architectures and hardware platforms have different data representations and parameters. Communications network 22 may therefore perform data conversion from one network architecture/standard to another, such as by translating data between ASCII and EBCDIC formats and performing data compression/decompression and encryption/decryption. III. THE SERVICE BROKER'S STRUCTURE The core or kernel of the broker consists of an initialization routine, an internal dispatcher, a variable number of workers, and several managers. These parts of the kernel create and manage a set of data structures. The Initialization routine establishes the broker environment. It first gets broker or default server attributes from an attribute file (if one exists). The routine then calculates the sizes of the various tables for the normal operating environment. The routine next obtains the necessary storage, then initiates and chains the various control blocks, queues, and tables, and sets a series of counters. The Initialization routine then sets up a virtual address entry (VAE) structure for the virtual storage manager. Next, the routine validates the various structures, then restores any reliable conversations from a reliable storage source. Finally, if all of the preceding steps are successful, the routine initiates the service dispatcher. The Worker component(s) of the kernel are responsible for the processing of participant requests. A Worker consists of all the routines that deal with the various functions (described below), such as Register, Send, Receive, etc. Upon startup, the internal dispatcher activates the required number of identical Workers (determined from the attribute file, if one exists, or a default number. The Dispatcher then activates the various managers (discussed below). If the managers are successfully activated, the Dispatcher activates any "internal" servers to provide attendant services, etc. Once this has been accomplished, the broker is ready to process requests. Upon receiving a request, the Dispatcher selects a Worker that is waiting for work and passes the request to the Worker for processing. These requests are any of the available functions. The Dispatcher constantly monitors the status of all workers and the managers for changes in status and takes appropriate action when a status changes. The Dispatcher also takes the appropriate action if an Administrator/Operator command is actioned by a manager or an internal server. The internal dispatcher is also responsible for the orderly shutdown of the system components upon receipt of the request from the Administrator/Operator. The dispatcher uses a Dispatcher Control Table (DCT) to coordinate its activities. A Worker Queue structure is used to pass requests to the worker components. A. Overall Data Structure and Broker Environment All of the data structures created and maintained by the broker and that define the broker environment are accessible via a single Global Address Table (GAT). The status of each of the other broker kernel components are held in the GAT. As illustrated in FIG. 7A, the GAT also includes the Broker Attribute Table (BAT), the Global Count Table (GCT), and the Dispatcher Control Table (DCT). In addition, the GAT includes a series of Global Address Entries (GAEs), one for each of the other broker structures. The GAT is illustrated as a "C" structure in Table 9, below.
TABLE 9
__________________________________________________________________________
typedef struct.sub.-- GAT
BEGIN
struct.sub.-- HEADER
header; /*
standard header */
BYTE vers(|S.sub.-- VERS|);
/*
Broker version */
BYTE loadtime(S.sub.-- LOADTIME|);
/*
Broker load time */
LWORD bstatus; /*
Current broker status
*/
LWORD cumstat; /*
CUM status */
LWORD tomstat; /*
TOM status */
LWORD comstat; /*
COM status */
LWORD wkrstat; /*
WKR status */
BYTE *store; /*
Start of virtual store
*/
struct.sub.-- BFPTR
efile; /*
trace levels */
long nerrmsg; /*
elog file pointer
*/
struct.sub.-- ERRMSGS
*errmsgs; /*
number of error messages
*/
struct.sub.-- KEY
*apikeys; /*
pointer to allowed API keywords
*/
struct.sub.-- KEY
*satkeys; /*
pointer to allowed SAT keywords
*/
struct.sub.-- KEY
*batkeys; /*
pointer to allowed BAT keywords
*/
struct.sub.-- BAT
bat; /*
Broker attribute/defaults
*/
struct.sub.-- GCT
gct; /*
GCT - Global counts
*/
struct.sub.-- DCT
dct; /*
DCT - dispatcher control
*/
struct.sub.-- GAE
sat; /*
SAT entry */
struct.sub.-- GAE
pcb; /*
pcb entry */
struct.sub.-- GAE
pcbext; /*
pcbext entry */
struct.sub.-- GAE
scb; /*
scb entry */
struct.sub.-- GAE
scbext; /*
scbext entry */
struct.sub.-- GAE
ccb; /*
ccb entry */
struct.sub.-- GAE
toq; /*
toq entry */
struct.sub.-- GAE
uiq; /*
uiq entry */
struct.sub.-- GAE
cuq; /*
cuq entry */
struct.sub.-- GAE
wq; /*
wq entry */
struct.sub.-- GAE
omb; /*
omb entry */
struct.sub.-- GAE
vae; /*
vae entry */
LALIGN lalign; /*
Ensure GAT aligned
*/
END GAT;
__________________________________________________________________________
BROKER ATTRIBUTE TABLE The fields in this table reflect the attributes that determine the internal environment (e.g., table sizes) in which the broker is currently operating. The BAT is illustrated in Table 10, below.
TABLE 10
__________________________________________________________________________
typedef struct.sub.-- BAT
BEGIN
struct.sub.-- HEADER
header: /*
standard header */
char bid(|S.sub.-- ETBID|);
/*
This broker's ID
*/
BYTE spec(|S.sub.-- BATSPEC|);
/*
Specification flags
*/
long maxvs; /*
Maximum virtual storage allowance
*/
long nwkrs; /*
Number of workers
*/
long alloc; /*
Default allocation size
*/
long split; /*
Default split size
*/
long totalp; /*
Total participants
*/
long normp; /*
Normal number of participants
*/
long totalsv; /*
Total services */
long normsv: /*
Normal services */
long totalcv; /*
Total conversations
*/
long normcv; /*
Normal conversations
*/
long avenm; /*
Average number of conc msgs
*/
long avemsgi; /*
Average message length
*/
END BAT:
__________________________________________________________________________
GLOBAL COUNT TABLE The Global Count table (GCT) contains various counts used in broker operation. The GCT is illustrated in Table 11, below.
TABLE 11
__________________________________________________________________________
typedef struct.sub.-- GCT
BEGIN
struct.sub.-- HEADER
header;
/*
standard header
*/
long convid;
/*
current convid */
long nfbytes;
/*
remalning virtual store
*/
long nwkrs;
/*
number of workers
*/
long ombseqn;
/*
omb sequence number
*/
long nfomb;
/*
number of free ombs
*/
long ntoq;
/*
number active in TOQ
*/
long nuiq;
/*
number active in UIQ
*/
long ncuq;
/*
number active in CUQ
*/
long nftoq;
/*
number of free TOQs
*/
long nfpcb;
/*
number of free PCBs
*/
long nfsat;
/*
number of free SATs
*/
long nfvae;
/*
number of free VAEs
*/
long nfscb;
/*
number of free SCBs
*/
long nfccb;
/*
number of free CCBs
*/
long nfpcbex;
/*
number of free PCBEXTs
*/
long nfscbex;
/*
number of free CCBEXTs
*/
END GCT;
__________________________________________________________________________
DISPATCHER CONTROL TABLE The Dispatcher Control table (DCT) consists of various component status, communication, and flag words, together with a pointer to the WQ structure. This structure is used by the internal dispatcher to control the various components (TOM, CUM, COM, and workers) and to distribute the requests among the workers. The structure of the DCT, and its relationship to the WQ (discussed below) is illustrated in FIG. 7F. The DCT is also illustrated as a "C" structure in Table 12, below.
TABLE 12
__________________________________________________________________________
typdef struct.sub.-- DCT
BEGIN
struct.sub.-- HEADER
header;
/*
standard header */
struct.sub.-- WQ
*wqtop;
/*
pointer to top of broker WQ
*/
XWQH *xwqh;
/*
pointer tc XCOM WQ header
*/
BYTE free1;
/*
free byte for alignment
*/
BYTE free2;
/*
free byte for alignment
*/
BOOLEAN compost;
/*
com posted by wkrerr
*/
BOOLEAN posted;
/*
dp posted by worker
*/
ECB dpecb;
/*
dispatcher ecb (for wkrs)
*/
ECB cumecb;
/*
CUM ECB */
ECB tomecb;
/*
TOM ECR */
ECB comecb;
/*
COM ECB */
CUMERP cumep;
/*
CUM error parameter structure
*/
TOMERP tomep
/*
TOM error parameter structure
*/
COMERP comep;
/*
COM error parameter structure
*/
LWORD cumstat;
/*
CUM status */
LWORD tomstat:
/*
TOM status */
LWORD comstat;
/*
COM status */
LWORD wkrstat;
/*
WKR status */
END DCT;
__________________________________________________________________________
GLOBAL ADDRESS ENTRY The standard structure used to address and control the various linked lists is the Global Address Entry (GAE). The GAE is illustrated in Table 13, below.
TABLE 13
__________________________________________________________________________
typedef struct.sub.-- GAE
BEGIN
struc.sub.-- HEADER
*header;
/*
Standard header */
BYTE *top /*
Pointer to top of chain/table
*/
int max.sub.-- ent;
/*
Maximum number of entries
*/
int n.sub.-- ent;
/*
Number of entries
*/
int s.sub.-- ent;
/*
Size in bytes of entry
*/
int i.sub.-- ent;
/*
Initial number of entries
*/
int e.sub.-- ent;
/*
Existing (???) number of entries
*/
BOOLEAN chained;
/*
chain or flat table
*/
struct.sub.-- HEADER
*e.sub.-- chain;
/*
Pointer to END.sub.-- OF.sub.-- CHAIN
*/
END GAE;
__________________________________________________________________________
B. Participant and Communication Data Structures At any given time, each participant may be offering (as a server) and/or requesting (as a client) one or more services simultaneously, and each service may be offered or requested by more than one client or server at once. Thus, there may be multiple services used or offered by each participant simultaneously, and there may be multiple communications taking place for each service. The service broker keeps track of this complex interaction of multiple participants, services, and conversations by maintaining the relevant information and parameters in several linked list data structures, including control blocks, tables, and queues. As shown in FIG. 7C, a Participant Control Block (PCB) is created for each participant. For each service offered by the participant, a corresponding Service Control Block (SCB) is created, and for each conversation that involves that service, a corresponding conversation control block (CCB) is created. An additional SCB is also created for each participant operating as a client to control the services that the client will receive (as is the case in FIG. 7C, which shows a SCB for a client). Each CCB in turn includes pointers to a Message Queue (MQ), which includes pointers to data (such as a send or receive buffer). Each control block includes several parameters or variables, which may be set or initialized by the broker to identify the participant, service, or conversation. Each group of control blocks (participant, service, and conversation) is arranged as a linked list. When a participant "registers" with the service broker (via the "REGISTER" function) the broker adds the participant and each of its service offerings (if any) to the linked list by allocating PCB and SCB(s), if such blocks have not already been allocated for that participant and those services. Each PCB includes values for parameters including a flag for locking, an entry status, a user's logical ID and user token, a pseudo physical ID, the type of the participant, a pointer to the Timeout Queue (discussed below), a pointer to a waiting server, and a pointer to a corresponding PCB extension. For purposes of illustration, a PCB as defined by a "struct" statement in the "C" language is shown in Table 14, below, along with the PCBEXT.
TABLE 14
______________________________________
typedef struct.sub.-- PCB
BEGIN
struct.sub.-- PCB *lckowner;
/* PCB address of owner
*/
struct.sub.-- PCB *head;
/* Pointer to chain head
*/
struct.sub.-- PCB *prev;
/* Pointer to previous entry
*/
struct.sub.-- PCB *next;
/* Pointer to next entry
*/
WORD lock; /* Lockflag */
WORD status; /* Entry status */
char uid(|32|);
/* Logical UID */
char token(|32|);
/* User token */
BYTE puid(|32|);
/* Pseudo physical ID
*/
char convid(|16|);
/* Waiting conversation
*/
struc.sub.-- SCB *wos;
/* Pointer to waiting server
*/
struct.sub.-- TOQ *toq;
/* Pointer to timeout entry
*/
struct.sub.-- PCBEXT *ext;
/* Pointer to extension
*/
BYTE type; /* Participant type
*/
BYTE convstat; /* Wait status */
WORD free; /* Free */
END PCB;
typedef struct.sub.-- PCBEXT
BEGIN
struct.sub.-- PCB *lckowner;
/* PCB address of owner
/*
struct.sub.-- PCBEXT *head;
/* Pointer to chain head
/*
struct.sub.-- PCBEXT *prev;
/* Pointer to previous entry
/*
struct.sub.-- PCBEXT *next;
/* Pointer to next entry
/*
WORD lock; /* Lockflag /*
WORD status; /* Entry status /*
struct.sub.-- SCB *scb:
/* Pointer to SCB /*
END PCBEXT
______________________________________
Each PCB also includes pointers to the first PCB in the list, and pointers to the next and previous entries. Each PCBEXT includes a pointer to an SCB. The purpose of a PCBEXT is to link the participant with a service (if any) that the participant is currently offering. A standard header is used to provide a common chaining mechanism. This allows a common search mechanism and a common lock mechanism. It
TABLE 15
______________________________________
typedef struct.sub.-- HEADER
BEGIN
void *owner; /* PCB address of owner
*/
void *head; /* Pointer to chain head
*/
void *prev; /* Pointer to previous entry
*/
void *next; /* Pointer to next entry
*/
WORD lock; /* Lockflag */
WORD status; /* Entry status */
END HEADER;
______________________________________
also aids in diagnosis in the event of a broker failure. The standard header is shown as a "struct" statement in the "C" language in Table 15, below Each SCB similarly includes a number of fields for each service provided by the participant identified in the corresponding PCB. For purposes of illustration, an SCB as defined by a "struct" statement in the "C" language is shown in Table 16, below. These fields include lockflag, entry status, service name, server name, server class, pointer to the CCBs, pointer to attribute entry,
TABLE 16
__________________________________________________________________________
typedef struct.sub.-- SCB
BEGIN
struct.sub.-- PCB /*lckowner;
PCB address of owner
*/
sttuct.sub.-- SCB /*head;
Pointer to chain head
*/
struct.sub.-- SCB /*prev;
Pointer to prevous entry
*/
struct.sub.-- SCB /*next;
Pointer to next entry
*/
WORD lock; /*
Lockflag */
WORD status; /*
Entry status */
char service(|32|);
/*
Service name */
char server(|32|);
/*
Server name */
BYTE class(|32|);
/*
Server class */
struct.sub.-- CCB /*ccb;
Pointer to CCB */
struct.sub.-- SAE /*sae;
Pointer to attribute entry
*/
struct.sub.-- SCBEXT *ext;
/*
Pointer to extension
*/
int nccb; /*
Number of conversations
*/
int naccb; /*
Number of active conversations
*/
int ne; /*
Number of extensions
*/
int nae; /*
Number of active extensions
*/
BYTE conf; /*
Conferencing flag
*/
BYTE free; /*
Free */
WORD free2; /*
Free */
END SCB;
typedef struct.sub.-- SCBEXT
BEGIN
struct.sub.-- PCB /*lckowner;
PCB address of owner
/*
Struct.sub.-- SCBEXT *head;
/*
Pointer to chain head
/*
struct.sub.-- SCBEXT *prev;
/*
Pointer to previous entry
/*
struct.sub.-- SCBEXT *next;
/*
Pointer to next entry
/*
WORD lock; /*
Lockflag /*
WORD status; /*
Entry status /*
struct.sub.-- PCB /*pcb;
Pointer to PCB /*
int noccb; /*
Number of owned CCBs
*/
WORD free; /*
Free */
END SCBEXT
__________________________________________________________________________
pointer to SCB extension, number of conversations, number of active conversations, number of extensions, and a conferencing flag. The SCB extension includes the fields lockflag, entry status, pointer to PCB, and number of owned CCBs. The purpose of the SCBEXT is to provide the necessary backward links between services available and the servers who are providing them. The SCBEXT mechanism allows the broker to "dispatch" the incoming requests for a particular service to a suitable previously registered server. Each CCB includes fields for each conversation between a participant (acting as a server) and another participant (acting as a client) involving the corresponding service provided by the server (and identified by the SCB). For purposes of illustration, a CCB as defined by a "struct" statement in the "C" language is shown in Table 17, below. The fields may include a lockflag, entry
TABLE 17
__________________________________________________________________________
typedef struct.sub.-- CCB
BEGIN
struct.sub.-- PCB
*lckowner;
/* PCB address of owner
*/
struct.sub.-- CCB
*head;
/* Pointer to chain head
*/
struct.sub.-- CCB
*prev;
/* Pointer to previous entry
*/
struct.sub.-- CCB
*next;
/* Pointer to next entry
*/
WORD lock; /* Lockflag
*/
WORD status; /* Entry status
*/
char convid(|16|); /* Conversation ID
*/
struct.sub.-- SCB
*scb; /* Pointer to SCB
*/
struct.sub.-- CCB
*partner;
/* Pointer to partner conversation
*/
struct.sub.-- PCB
*owner;
/* Pointer to conversation owner
*/
struct.sub.-- TOQ
*toq; /* Pointer to timeout entry
*/
struct.sub.-- MQ
*mqtop;
/* Pointer to message queue head
*/
struct.sub.-- MQ
*mqbot;
/* Pointer to previous message
*/
int max.sub.-- m; /* Maximum of messages
*/
int nnhm; /* Number of none hold messages
*/
int nhm; /* Number to hold messages
*/
BYTE convstat; /* New conversation?
*/
BYTE eoc: /* End of conversation?
*/
END CCB;
__________________________________________________________________________
status, conversation ID, pointer to SCB, pointer to CCB partner, pointer to the associated PCB, pointer to timeout entry, pointer to message queue, maximum number of messages, number of none hold messages, number of hold messages, conversation status and EOC. The conversation ID identifies the conversation for this CCB, the SCB pointer points to the SCB for this conversation, the PCB pointer points to the PCB for this conversation. The pointer to the CCB partner identifies the CCB on the other side of the broker. This partner CCB is used to identify the conversation as seen by the other participant. A message queue (MQ) is created for each of the CCBs. The message queues are preferably arranged as a linked list, like the control blocks. Therefore, in each message queue, there are pointers to the first, next, and previous message queues of the linked list. The message queue also includes the fields lockflag, entry status, a pointer to data and the length of the data, and an option (hold/read/msg). For purposes of illustration, the Message queue as defined by a "struct" statement in the "C" language is shown in Table 18, below.
TABLE 18
______________________________________
typedef struct.sub.-- MQ
BEGIN
struct.sub.-- PCB
*lckowner;
/* PCB address of owner
*/
struct.sub.-- MQ
*head; /* Pointer to chain heed
*/
struct.sub.-- MQ
*prev; /* Pointer to previous entry
*/
struct.sub.-- MQ
*next; /* Pointer to next entry
*/
WORD lock; /* Lockflag */
WORD status; /* Entry status */
void data; /* Pointer to data
*/
long l.sub.-- data
/* Length of data
*/
BYTE option; /* HOLD/READ/MSG */
BYTE free; /* Free */
WORD free2; /* Free */
END MQ;
______________________________________
The Message queue is used by the broker to store requests and responses for services for each participant (or CCB). A participant can access the Message queue for one of its conversations with the service broker using the function "RECEIVE." The status of the Message queue (e.g., how many entries are still to be read) can be found by using the broker attendant services, described below. The interrelationship of the structures described above is further illustrated in FIGS. 7D and 7E. The participant in FIG. 7d is registered as a client (with a client SCB) and a server (with a service SCB). The service that this participant offers is also offered by another participant. Thus, the service SCB has two SCBEXTs, one with a pointer to the illustrated participant, and one with a pointer to the other participant offering the service. FIG. 7E illustrates the interrelationship between two participants that are communicating with each other. The client has a client SCB with a pointer to the CCB chain that includes a CCB for a conversation with the server. The server has an SCB for the service that the client has requested, and that SCB has a pointer to a CCB chain that includes a CCB for the same conversation. Each participant's CCB for the conversation has a pointer to the CCB of the other participant for that conversation. SERVER ATTRIBUTE TABLE Each entry in the Server Attribute Table (SAT) defines the attributes that apply to a particular service identified by the SID structure (name, class, and service) within the SAT entry. In addition to the various attributes that have been determined when the service was registered (from the Attribute file, if one exists, or from defaults), the SAT contains pointers to the SCB currently used to offer the service. The SAT is illustrated in Table 19, below.
TABLE 19
__________________________________________________________________________
typedef struct.sub.-- SAT
BEGIN
struct.sub.-- HEADER
header; /* standard header
*/
struct.sub.-- SCB
*scb; /* Pointer to SCB
*/
struct.sub.-- SID
sid; /* name, class, service
*/
BYTE spec(|S.sub.-- SATSPEC|);
/* Specification flags
*/
char desc(S.sub.-- DESC|);
/* Description */
BOOLEAN astart; /* Autostart flag
*/
char aparms (|S.sub.-- APARMS|);
/* Autostart parameters
*/
time.sub.-- t
startt; /* Server start time
*/
time.sub.-- t
endt; /* Server end time
*/
long defto; /* Default timeout
*/
long minto; /* Minimum timeout
*/
long maxto; /* Maximum timeout
*/
long eocto; /* Conversation timeout
*/
long maxmsgl; /* Max message length
*/
long maxnm; /* Max number of messages
*/
long maxnccb; /* max number of ccbs
*/
PFTRANS trans; /* pointer to translation routine
*/
PFMQACC mqacc; /* pointer to Q access routine
*/
PFTERM term; /* Pointer to terminate routine
*/
PFSECUR secur; /* Pointer to security routine
*/
PFLOG log; /* Pointer to logging routine
*/
PFTRACE trace; /* Pointer to trace routine
*/
PFACCNT accnt; /* Pointer to accosting routine
*/
END SAT;
__________________________________________________________________________
The SID referred to in the SAT is illustrated in Table 20, below.
TABLE 20
______________________________________
typedef struct.sub.-- SID
BEGIN
char server(|S.sub.-- SERVER|);
/* Server name
*/
char class(|S.sub.-- CLASS|);
/* Server class
*/
char service (|S.sub.-- SERVICE|);
/* Service name
*/
ENDSID;
______________________________________
C. Timeout Handling The broker kernel includes as an autonomous part a Time-out Manager (TOM), which is responsible for detecting and actioning the various time-outs that can occur (i.e., conversation time-outs and participant time-outs). This is done by the use of a Timeout Queue (TOQ), which is maintained in a time-ordered sequence. Time-outs that have been temporarily inhibited while a request is being processed and are subsequently uninhibited and placed on an Uninhibit Queue (UIQ) are reinstated in the correct time sequence by the TOM. Time-outs that have occurred are placed on a Cleanup Queue (CUQ) for further processing by the Cleanup Manager (CUM) after the appropriate flags have been set in the broker structure so that future requests are aware that a timeout has occurred. The CUM is another autonomous component of the broker kernel. The CUM takes entries for the CUQ (that have been placed in that queue following a timeout by the TOM) and recover for reuse the parts of the broker structure no longer being used. The CUM also replies to any waiting participants that a timeout has occurred. This occurs when the CUM is attempting to recover the structure and a waiting participant is found. CUM also ensures that the internal structures of the broker are dynamically adjusted, acquiring and releasing storage as appropriate. The TOQ, CUQ, and UIQ are arranged as linked lists, as illustrated in the following tables. The number of entries in any queue is determined by user requirements--the broker adjusts the queue size dynamically. TIMEOUT QUEUE The timeout and subsequent "clean-up" processing is platform independent and requires no special system services. The TOQ includes entries for participants and for conversations. For purposes of illustration, the TOQ as defined by a "struct" statement in the "C" language is shown in Table 21, below.
TABLE 21
__________________________________________________________________________
typedef struct.sub.-- TOQ
BEGIN
TABID tabid;
/* table identifier
*/
LWORD tabno;
/* table relative number
*/
struct.sub.-- PCB
*lckowner;
/* PCB address of owner
*/
struct.sub.-- TOQ
*head;
/* Pointer to chain head
*/
struct.sub.-- TOQ
*prev;
/* Pointer to previous entry
*/
struct.sub.-- TOQ
*next:
/* Pointer to next entry
*/
WORD lock; /* Lockflag */
WORD status;
/* Entry status */
void *owner:
/* CCB or PCB pointer
*/
time.sub.-- t
time; /* Absolute */
int counter;
/* User counter */
BYTE type; /* Entry type (Conversation or Participant)
*/
END TOQ;
__________________________________________________________________________
CLEANUP QUEUE The Cleanup queue (CUQ) passes information about conversations or participants that have "timed-out" from the Timeout manager (TOM) to the Cleanup manager (CUM). The Cleanup manager operates independently and uses this information to recover the entries in the various tables (linked lists) for reuse. For purposes of illustration, the Cleanup queue as defined by a "struct" statement in the "C" language is shown in Table 22, below.
TABLE 22
______________________________________
typedef struct.sub.-- CUQ
BEGIN
TABID tabid; /* table identifier
*/
LWORD tabno; /* table relative number
*/
struct.sub.-- PCB
*lckowner; /* PCB address of owner
*/
struct.sub.-- CUQ
*head; /* Pointer to chain head
*/
struct.sub.-- CUQ
*prev; /* Pointer to previous entry
*/
struct.sub.-- CUQ
*next; /* Pointer to next entry
*/
LWORD lock; /* Lockflag */
LWORD status; /* Entry status */
VOID *owner; /* Pointer to owner
*/
TOQ *toq; /* Pointer to TOQ entry
*/
END CUQ;
______________________________________
UNINHIBIT QUEUE The UIQ is used to maintain a list of entries on the TOQ that have been inhibited temporarily from time-out processing and need to be reinstated into the TOQ once they have been uninhibited. For purposes of illustration, the UIQ as defined by a "struct" statement in the "C" language is shown in Table 23, below.
TABLE 23
______________________________________
typedef struct.sub.-- UIQ
BEGIN
TABID tabid; /* table identifier
*/
LWORD tabno; /* table relative number
*/
struct.sub.-- PCB
*lckowner;
/* PCB address of owner
*/
struct.sub.-- UIQ
*head; /* Pointer to chain head
*/
struct.sub.-- UIQ
*prev; /* Pointer to previous entry
*/
struct.sub.-- UIQ
*next; /* Pointer to next entry
*/
LWORD lock; /* Lockflag */
LWORD status; /* Entry status */
struct.sub.-- TOQ
*toq; /* Pointer to TOQ entry
*/
long time; /* Relative time */
END UIQ;
______________________________________
D. Communication and Storage Handling The broker employs workers to process requests (SEND, RECEIVE, etc.). The number of workers determines the number of requests that the broker can concurrently process (in parallel). Each worker is identical and is capable of doing any of the broker functions. WORKER QUEUE The Worker queue (WQ) is used by the internal dispatcher to pass requests to one of the Workers for processing. For purposes of illustration, the WQ as defined by a "struct" statement in the "C" language is shown in Table 24, below.
TABLE 24
__________________________________________________________________________
typedef struct.sub.-- WQ
BEGIN
struct.sub.-- HEADER
header;
/* standard header */
struct.sub.-- GAT
*gat;
/* pointer to GAT */
XWQE *xwqe;
/* pointer to current worker XCOM-WQE
*/
ECB wecb;
/* ECB for broker-worker
*/
TCB *wtcb;
/* pointer to worker TCB
*/
struct.sub.-- DCT
*dct;
/* pointer to OCT */
WKRERP wkrep;
/* worker error parameter structure
*/
LWORD status;
/* Entry Status (w, a, d, p, f, u)
*/
END WQ;
__________________________________________________________________________
The relationship between the DCT and the WQ is illustrated in FIG. 7F. The DCT includes a pointer to the WQ chain. Each WQ entry includes a pointer back to the DCT. It also has a pointer to the XWQE, which is the current item of work. The work item is the structure that has the addresses for the parameter string HAPI fields send buffer, receive buffer, and reply address. The WQ entry also has a pointer to the broker structure accessed through the GAT. Each active worker has an active WQ entry. The WQ entries contain the information necessary for each worker to complete the requested function and return an appropriate reply. The WQ is thus the main mechanism used by the internal dispatcher (along with the DCT) to distribute work to appropriate workers. 1. Communication Manager The Communication manager (COM) handles all necessary communication with the Operator/Administrator when an "internal" server is not available to accomplish the task. It is an autonomous component of the kernel. 2. Virtual Store Manager The Virtual Store manager is an integral part of the kernel. All components of the kernel have access to this component, which manages the available storage, ensuring efficient use of the available storage in a changing environment. E. Client/Server Attributes The broker environment can be customized by the administrator and appropriate participant defaults can be chosen by setting various attributes in the attribute file. The broker can function without a file since important attributes are given default values. The attributes can be grouped into two categories--broker attributes and participant attributes. The latter category can be further subdivided into defaults and individual overrides. The broker attributes are specific to the broker and its control of the workload. The participant definitions within the attribute file define both global and individual participant defaults, enabling the administrator to customize and control the environment (e.g., size and rater of conversations, number of conversations, etc.). The broker obtains broker specific and global defaults from the attribute file (if one is available) on startup. Specific overrides are accessed upon Register. The administrator can thus alter specific environments without reloading the broker. Each occurrence of an attribute definition consists of an attribute name and an attribute value. For some attributes a null value is allowed. The broker uses multiple occurrences of certain attribute definitions to accumulate values for the attribute when this is meaningful. If multiple definitions of the same attribute are not meaningful, the broker treats them as errors. Conflicting settings of different attributes are treated as errors. The value of an attribute is determined by the following rules: First, values set dynamically by the administrator are taken. Second, the broker takes the values in the attribute file for the particular participant (if one exists). Third, the broker takes the values found in the attribute file for a global default if one is found. Finally, if no file is available, or no setting is found, the broker-supplied default applies. 1. Broker Specific Attributes The Broker specific attributes are identified in the following table and are described in more detail below.
__________________________________________________________________________
ATTRIBUTE
SHORT ALLOWED DEPENDENT
NAME FORM DEFAULT
VALUES ATTRIBUTES
__________________________________________________________________________
BROKER-ID
(BID) LOCALBRK
Name
OPERATOR (OPER)
ASK ASK, YES(Y), NO(N)
DUMP (DUMP)
NONE REL-QUEUES (RELQ)
ALL-QUEUES (ALLQ)
SYSTEM (SYS)
NONE
START (START)
WARM COLD(C), WARM(W)
MAX-STORE
(MAXST)
P.D n, nK, nM
NUM-WORKERS
(NWKRS)
P.D n
ALLOC-SIZE
(ASIZE)
P.D n, nK, nM
SPLIT-SIZE
(SSIZE)
P.D n, Nk, nM
TOTAL-PART
(TOTALP)
P.D n
NORM-PART
(NORMP)
P.D n
TOTAL-CONV
(TOTALCV)
P.D n
NORM-CONV
(NORMCV)
P.D n
AVE-NMSGS
(AVENM)
P.D n
AVE-MSGLEN
(AVEML)
P.D n, nK, nM
ALLOW-REG
(ALLOWR)
NO NO(N), YES(Y)
__________________________________________________________________________
In the preferred embodiment, the following syntax rules are applied. Spaces are not significant between Keywords and Values. Neither are leading or trailing spaces. However spaces are significant within Keywords and Values (eg. SN=PCOMPLETE, SC=TPMON, SV=UEDIT is acceptable whereas SN=PCOMPLETE, SC=TP MON, S V=UEDIT is not). Commas and equal signs are keyword and value separators and cannot be used with the exception of the `param string` (see below). Lowercase is allowed in keywords and set values but not mixed case. P.D. indicates a Platform Default selected by the BROKER. An `n` indicates an unsigned numeric integer. A `name` indicates an acceptable meaningful name. No conversion is performed on the name so care should be used when mixed case or special characters are used (eg. ABC, abc and AbC are all different). `Null` indicates a null value is acceptable (e.g. SV=, is a means of specifying a general service. `Time`--two time formats: a) HH:MM:SS (where HH,MM,SS are Hours, Minutes and Seconds, respectively) and b) n,nH,nM,nS (the number of Hours, Minutes or seconds past midnight). A `param string` indicates that the broker accepts a parameter string format as <delimiter> parameter string <delimiter>. A quote has no special meaning, any characters other than space, comma, equals and period can be used as <delimiters>. Parameter strings cannot extend over input records (eg. `ABC, Name=FRED, custno=1234` and/A=1234,EP=`$STRT`,XYZ/are both acceptable parameter strings). N/A indicates Not Applicable. BROKER-ID is a mandatory parameter and must be the first keyword in the first record of the Attribute file if one exists. If no Attribute file is available then the BROKER-ID will be as specified under DEFAULT below. OPERATOR informs the broker if the Operator is allowed to use certain Admin functions which apply to the broker specifically. If the attribute has the value ASK--this implies YES and where appropriate the Operator will be asked for a course of action. DUMP indicates whether to take a dump and what to dump in the event of a shutdown of the Broker. START indicates the type of Startup the Broker should attempt. If the OPERATOR attribute is set to ASK the Operator will be asked to confirm or to override this default. MAX-STORE is the MAXimum storage (in bytes) available to the broker below. NUM-WORKERS is the number of concurrent worker tasks (these can be subtasks, processes or separate address space depending on the platform) that the broker can use. This parameter determines the number of functions (eg. SEND, RECEIVE,REGISTER etc) that are processed concurrently. ALLOC-SIZE is the amount of storage the broker will try to obtain when he workload increases and more storage is required. The broker obtains `ALLOC-SIZE` amounts up until `MAX-STORE`. Extreme care should be used with this parameter as an incorrect setting could severely affect performance. SPLIT-SIZE is used by the broker to make efficient use of storage. It should usually be set if the workload contains a large number of messages that are shorter than the default. In these circumstances a value equal to the shorter message length will usually provide better performance. TOTAL-PART is the TOTAL number of concurrent participants. This is used by the broker to make decisions on the size of the workload in order to make the best use of the available resources. If specified the broker will limit the workload to `TOTAL-PART` concurrent active participants. NORM-PART is the NORMal number of concurrent participants. This is used by the broker to make decisions on the size of the workload in order to make the best use of the available resources. If the workload is significantly different from the broker default for the platform, use of this parameter is recommended. It does not have any restrictive effect on the broker's ability to support the workload. It would not be advantageous to set the value to some large arbitrary value as this would lead the broker to assume a large normal workload. TOTAL-SERV is the TOTAL number of concurrent Services. This is used by the broker to make decisions on the size of the workload in order to make the best use of the available resources. If specified the broker will limit the workload to `TOTAL-SERV` concurrent active Services. Note that this is the number of Services, not servers. NORM-SERV is the NORMal number of concurrent services. This is used by the broker to make decisions on the size of the workload in order to make the best use of the available resources. It would not be advantageous to set the value to some large arbitrary value as this would lead the broker to assume a large normal workload. TOTAL-CONV is the TOTAL number of concurrent Conversations. This is sued by the broker to make decisions on the size of the workload in order to make the best use of the available resources. If specified the broker will limit the workload to `TOTAL-CONV` concurrent active Conversations. NORM-CONV is the NORMal number of concurrent Conversations. This is used by the broker to make decisions on the size of the workload in order to make the best use of the available resources. It would not be advantageous to set the value to some large arbitrary value as this would lead to the broker to assume a large normal workload. AVE-NMSGS is the AVErage number of concurrent active messages. Together with the `AVE-MSGLEN` parameter the broker can make decisions on the size of the workload in order to make the best use of the available resources. It would not be advantageous to set the value to some large arbitrary value as this would lead to the broker to assume a large normal workload. AVE-MSGLEN is the AVErage length of messages. Together with the `AVE-NMSGS` the broker can make decisions on the size of the workload in order to make the best use of the available resources. It would not be advantageous to set the value to some large arbitrary value as this would lead the broker to assume a large normal workload. ALLOW-REGISTER is a simple switch to indicate whether the broker will allow the Servers that are not found in the Attribute file but attempt to REGISTER to do so. It has no meaning to an individual application. 2. Participant Specific Attributes The participant specific attributes are identified in the following table and are described in more detail below.
__________________________________________________________________________
Attrib. Name
ShortForm
Default
Allowed Values (Short)
Dep. Attrib.
__________________________________________________________________________
SERVER-NAME
(SN) N/A Name SERVER-CLASS
SERVER-CLASS
(SC) N/A Name SERVER-NAME
SERVICE (SV) N/A Name, Null SERVER-NAME
SERVER-CLASS
START-TIME
(STARTT)
N/A Time END-TIME
END-TIME
(ENDT)
N/A Time START-TIME
SCOPE (SCDPE)
LOCAL
LOCAL(L), GLOBAL(G)
CONV-SHARE
(CSHARE)
NO YES(Y), NO(N)
CONV-MODES
(CMODES)
ALL SYNCHRONOUS (SYNCH)
ASYNCHRONOUS (ASYNCH) ALL
CONV-TYPES
(CTYPES)
ALL NONCONV, CONVERSATIONAL
(CONV) ALL
OPERATOR
(OPER)
NO ASK, YES(Y), NO(N)
DUMP (DUMP)
NONE CONV-QUEUE(CONVQ), ALL-
QUEUES(ALLQ), NONE
NON- (NAVAIL)
DISCARD
DISCARD, KEEP
AVAILABLE
MQ-ACCESS
(MQACC)
NO NO(N), Routine Name
TRANSLATION
(TRANS)
NO NO(N), Routine Name
TERM-ACTION
(TERM)
NO NO(N), Routine Name
SECURITY
(SECUR)
STD OFF, STANDARD(STD), Routine Name
LOGGING (LOG) OFF OFF, STANDARD(STD), Routine Name
TRACING (TRACE)
OFF OFF, STANDARD(STD), Routine Name
ACCOUNTING
(ACCNT)
STD OFF, STANDARD(STD), Routine Name
AUTO-START
(ASTART)
NO YES(Y), NO(N) SERVER-NAME
SERVER-CLASS
AUTO-PARMS
(APARMS)
N/A `Param string` AUTO-START
DESCRIPTION
(DESC)
N/A `Param string` SERVER-NAME
SERVER-CLASS
DEF-TIMEOUT
(DEFTO)
P.D n, nS, nM, nH
MIN-TIMEOUT
(MINTO)
P.D n, nS, nM, nH
MAX-TIMEOUT
(MAXTO)
P.D n, nS, nM, nH
CONV- (CONVTO)
P.D n, nS, nM, nH
TIMEOUT
MAX-MSGLEN
(MAXML)
P.D n, nK, nM
MAX-NMSGS
(MAXNM)
P.D n
MAX-NCONVS
(MAXNC)
P.D n
__________________________________________________________________________
SERVER-NAME defines an Application participant name that will be allowed to REGISTER and be given the associated attributes from the Attribute file. The Administrator uses this field to associate specific attribute settings to an individual Application Server. A SERVER-CLASS must also be specified. Server names starting with any of the following are reserved for use by SAG. SERVER-CLASS defines the Class associated with the SERVER-NAME above. Together a complete ID for the SERVER is formed. Server classes starting with any of the following are reserved for use by SAG. SERVICE defines one of the Services that is available. Multiple occurrences of this field are used to offer several services from the same Server. At least one occurrence must exist for each SERVER-NAME, SERVER-CLASS combination. SERVICE-START, used in conjunction with SERVICE-END, specifies the Service interval. The time must be in one of the Broker acceptable time formats and is taken as the time from Midnight. If the time has already passed then the service is offered immediately upon REGISTER. No service is offered at all until REGISTER unless AUTO-START is used. SERVICE-END is used in conjunction with SERVICE-START to determine the Service interval. The time must be in one of the Broker acceptable time formats and is taken as the time from Midnight. If the time has already passed then the Service is not started until the next SERVICE-TIME occurs. The time must be later than the SERVICE-START time. At the end of the Service time the SERVER will be terminated with DEREGISTER OPTION=QUIESCE. SCOPE determines the SCOPE of the offered services. The current options are to restrict the services to local use within the BROKER environment or offer them globally outside the BROKER. If associated with an individual Application it applies to the specific Application only. CONV-SHARE--If a Key value is specified then the Application is taking part in CONFERENCING ie. it is sharing CONV-ID's with other participating applications. CONV-MODES indicates which modes of running are supported by the Server. If associated with an individual Application it applies to the specific Application only. CONV-TYPES indicates which type of conversation the Server is capable of dealing with. If associated with an individual Application it applies to the specific Application only. OPERATOR indicates to the broker whether the Operator is permitted to use the appropriate Administrator function for the SERVER-NAME,SERVER-CLASS. If set as a global default then the Operator has extensive control over the whole environment. If the value is set to ASK then this implies YES and under certain circumstances the Operator will be asked for a course of action eg. when the participant has been inactive longer than the allowed time-out period. DUMP indicates whether to take a dump and what to dump in the event of a time-out (or other Broker detected event) of the participant. NON-AVAILABLE indicates to the broker the action to take with the queue entries for conversations for a Server that is not active at present but for which an entry is available in the Attribute file. The queues are still subject to normal time-out processing. If associated with an individual Application it applies to the specific Application only. TRANSLATION--Translation services can automatically be invoked by the broker by the use of this attribute. One of the translation routines supplied with the broker can be used or the Administrator can choose a User supplied routine. Client/Servers can communicate in different data formats provided a suitable translation routine is available. If associated with an individual Application it applies to the specific Application only. TERM-ACTION--The broker uses this Attribute to invoke a termination routine (if one has been defined) as part of DEREGISTER. If associated with an individual Application it applies to the specific Application only. SECURITY--The broker uses this Attribute to invoke the required Security checks. The value STD invokes the standard routine that is supplied with the BROKER. If associated with an individual Application it applies to the specific Application only. LOGGING--This Attribute is used to control the amount of logging required. Again the value STD invokes the standard routine that is supplied with the broker. If associated with an individual Application it applies to the specific Application only. TRACING--This Attribute is used to control the amount of Tracing required. Again the value STD invokes the standard routine that is supplied with the BROKER. Multiple occurrences of this Attribute can be used to also set the tracing level. If associated with an individual Application it applies to the specific Application only. ACCOUNTING--This Attribute is for Accounting control. The value STD invokes the standard routine that is supplied with the BROKER. If associated with an individual Application it applies to the specific Application only. AUTO-START determines whether a particular Application Server is started by the BROKER automatically under certain conditions. The BROKER will not start a Server outside it's defined Service interval if one has been defined. It is only available on platforms where the possibility to start the relevant Server exist. AUTO-PARMS are parameters that are passed upon AUTO-START unchanged. Note that parameters cannot be continued over input record boundaries. DESCRIPTION is a short Administrator defined description that can be retrieved using the BROKER information services. DEF-TIMEOUT is the Default time-out period used in Synchronous processing. If associated with an individual Application it applies to the specific Application only. Should no entry be found in the File then the BROKER will choose a suitable Platform optimized default. The value that is given can be followed by one of H,M or S standing for Hours, Minutes and Seconds respectively. If none of these are specified then Seconds is assumed. MIN-TIMEOUT is the MINimum time-out period used in Synchronous processing. The time-out value associated with the field WAIT must fall within the values MIN-TIMEOUT and MAX-TIMEOUT. If associated with an individual Application it applies to the specific Application only. Should no entry be found in the File then the broker will choose a suitable Platform optimized default. The value that is given can be followed by one of H,M or S standing for Hours, Minutes and Seconds respectively. If none of these are specified then Seconds is assumed. MAX-TIMEOUT is the MAXimum time-out period used in Synchronous processing. The time-out value associated with the field WAIT must fall within the values MIN-TIMEOUT and MAX-TIMEOUT. If associated with an individual Application it applies to the specific Application only. Should no entry be found in the File then the broker will choose a suitable Platform optimized default. The value that is given can be followed by one of H,M or S standing for Hours, Minutes and Seconds respectively. If none of these are specified then Seconds is assumed. CONV-TIMEOUT is the End-Of-Conversation time-out value. It must be greater than MAX-TIMEOUT. If associated with an individual Application it applies to the specific Application only. Should no entry be found in the File then the BROKER will choose a suitable Platform optimized default. The value that is given can be followed by one of H,M or S standing for Hours, Minutes and Seconds respectively. If none of these are specified then Seconds is assumed. MAX-MSGLEN is the MAXimum length of a record on the incoming (RECEIVE) queue that is to be allowed. If associated with an individual Application it applies to the specific Application only. Should no entry be found in the File then the broker will choose a suitable Platform optimized default. The value that is given can be followed by one of K,M standing for Kbytes or MegaBytes respectively. If none of these are specified then n is taken in Bytes. is assumed. MAX-NMSGS is the MAXimum number of messages allowed to reside on the queue waiting to be RECEIVED. If associated with an individual Application it applies to the specific Application only. Should no entry be found in the File then the BROKER will choose a suitable Platform optimized default. The value that is given can be followed by one of K,M standing for Kbytes or MegaBytes respectively. If none of these are specified then n is taken in Bytes. is assumed. MAX-NCONVS is the MAXimum number of conversations that are to be supported simultaneously. If associated | ||||||