protocol
AutoRouter handles messages that conform to the Ab Initio Protocol. Thus, any application that understands the Ab Initio Protocol can use the AutoRouter services. Applications like AutoMan and HS use this protocol to communicate with each other via AutoRouter.
An Ab Initio Protocol message is designed to execute procedures, or methods, in a remote target object. Each message is a string of up to 5120 ASCII characters, and contains fields to describe the destination and source address, the message type, and the method to execute. Optional fields (gray regions) for symbols and their values can be present. The message structure looks like this: target mode method sender token token value token value value
where the fields are defined as follows: target Target address: Instance, class, and node name
mode Message type: One of EVENT, QUERY, or REPLY
method Method to execute: e.g. CONNECT, DISCONNECT, ABORT, SETUP, DATA, MESSAGE.
sender Destination address: Instance, class, and node name
token Symbol name (optional)
value Symbol values (optional)
The first character in the message is the delimiter for the entire message. The commonly used delimiter is the pipe '|' character. The optional token fields are separated by two delimiter characters, '||' for example.
The target is the name of the object that receives the message. The target is further sub-divided into 3 components: _
target := [instance.]object[@node] _
The object name identifies the class of the object. The optional _instance _ name is used to identify a unique instance of the class object. The node name identifies the node address of the object, specified as an IP address. In general, a client target will have an instance and object name, whereas a server target will generally have only an object name. When the node name is unspecified, it implies the local node.
The mode is a keyword that indicates the client-server relationship. The mode keyword is one of QUERY, REPLY, or EVENT. QUERY messages are paired with REPLY messages for synchronous client/server communication, whereas EVENT messages are used alone for asynchronous communication.
The method is a case-sensitive name referring to a function or procedure that the target of a QUERY or EVENT message should perform. In a QUERY/REPLY message pair, the method name must be the same.
The sender is the name of the object that sends the message. Like the target, the sender is also sub-divided into 3 components: _
sender := [instance.]object[@node] _
The token is the name of a variable associated with the method. A token name has a maximum of 32 characters and is case-sensitive. A message can have zero or more tokens. Multiple tokens must be separated by a double delimiters, as in "||token1||token2||token3||"
The value is the value of a token variable. A value has a maximum of 64 characters. There can be zero or more values per token. Multiple values are separated by single delimiters as in "||token1|value1|value2|value3||"
An object that initiates a message conversation is a client by convention. The target of the initiating message is a server by convention.
A client object sends a QUERY message to the server and receives a REPLY message from the server. Providing that the STATUS of the reply message from the server indicates acknowledgement, the client-server relationship is sustained and the client may continue the message conversation with another QUERY message to the server.
When the STATUS of the reply message from the server indicates a non-acknowledgement, the client-server relationship is aborted and must be re-established with a new message conversation.
A QUERY-REPLY message pair must always use the same method. For example, if the QUERY message method is SETUP, then the REPLY message must also use the SETUP method. Within a message conversation of QUERY-REPLY message pairs, a client object is free to transition from one method to another with each new QUERY message.
When a client sends an asynchronous EVENT message to server, an arrangement can be made so that the client becomes a server and the server becomes the client. This is the case with AutoMan, the automation interface to the PROMIS system. As the initiating client, AutoMan sends an EVENT CONNECT message to a remote automation server target to begin the automation process. Thereafter, AutoMan becomes a server and waits for the remote automation object to QUERY it as a client.
The target of an EVENT message may choose not to respond, instead passing the message onto another object. This mechanism of passing EVENT message from one object to another is called responder chaining, and is extremely useful within an object oriented environment. By maintaining the original sender of the EVENT message in all EVENT messages that are passed along a responder chain, the object that finally services the request can communicate directly with the original sender.
Although not yet implemented, the concept of PUBLISH/SUBSCRIBE would be supported as follows:
Tokens are the mechanism by which information and data is passed between objects. Each method type has its own unique set of token keywords. A message may contain zero or more tokens and tokens themselves may be specified with zero or more values.
In a QUERY message, a token specified without a value is an indication to the target object that it must supply the value of that token in its REPLY message to the sender. A token with one or more values in a QUERY message is an indication to the target object that it should set its token to the supplied values.
In a REPLY message, all tokens must have values. A token without a value in a REPLY message is actually a token with a NULL value. A REPLY message must always include the STATUS token and its value as the last token in the message. The QUERY message does not explicitly specify the STATUS token, however, it is implicit as the last token in the message. In an EVENT message, there is no STATUS token, explicitly or implicitly, since an EVENT message never gets a REPLY message.
In a REPLY message, the STATUS token has only one value that describes the status of the QUERY-REPLY message. The first character of the STATUS value indicates the value of status as being "$" for Success, "!" for Warning, and "%" for Error. For example: "$Acknowledge", "!Warning", and "%Error".
In some cases, the Ab Initio Protocol is used like a stream protocol because the tokens and values in the QUERY or EVENT messages can be processed sequentially by the target object in a stream. For example, the same token can be specified multiple times in the EVENT or QUERY message, and the target of the message can process the tokens in that order. The DATA method serviced by the PROMIS automation interface, AutoMan, handles the tokens in a stream manner. In the REPLY message, the tokens and values that the sender requested are also received in a stream. The values of the tokens returned should reflect the way they were processed.
|FT650|CONNECT|QUERY|PROMIS||LOTID|F40101.F1X||EQPID|ACD4-F|
|PROMIS|CONNECT|REPLY|FT650||STATUS|$Acknowledge|
A PROMIS object, AutoMan, sends a QUERY message to the FT650 object requesting that FT650 perform its CONNECT method. The status of the CONNECT method is also requested. In the REPLY message, the FT650 object responds with an acknowledgement. ` |PROMIS|DATA|QUERY|FT650||&Resistivity|5.43||WAFERID||STATE| |FT650|DATA|REPLY|PROMIS||WAFERID|F40101.2||STATE|SOME||STATUS|$Entered|
The FT650 object sends a QUERY message to PROMIS (AutoMan) with a token value for
Resistivity and a request for the value of the next wafer and the state of the dcOp.
PROMIS inserts the value for Resistivity into its database and sends a REPLY
message with the value for
the next wafer id, the state, and the status. `
|FT650|SETUP|EVENT|PROMIS|
|PROMIS|SETUP|QUERY|FT650||$RECPE|
|FT650|SETUP|REPLY|PROMIS||$RECIPE|XYZ-01||STATUS|$Acknowledge|
PROMIS sends an EVENT/SETUP message to FT650. The FT650, assuming client control, requests the value for the $RECIPE parameter from PROMIS. PROMIS returns an acknowledgement and the value of the $RECIPE parameter (and the status).