Home

MultiXTpm Application Server

TpmConfig.xml Configuration File

To manage and control its runtime environment, MultiXTpm Application Server manages several types of entities:
  • Process Classes
  • Communication Links
  • Messages
  • Processes Groups
When MultiXTpm Process starts, it reads a configuration file and performs some initial steps to kick start the entire system.
  1. Start all required instances of all defined process classes.
  2. If there are definitions for communication links assigned to a class, MultiXTpm Process forwards these definitions to each process instance it starts.
  3. Once all the required instances are up and running, MultiXTpm Process monitors the processes state for routing and control purposes.
  4. MultiXTpm Process enters an endless loop, waiting for incoming messages
    • When MultiXTpm Process receives a message, it scans its messages table.
    • If a message with the same MessageCode does not exist in its table, it replies with an error to the sender.
    • When a valid message is received, it checks which Process Groups should receive the message.
    • For each group that it finds, it looks for the most available (smallest queue) process, puts the message in its queue and tries to forward the message immediately to the process.
    • When a response received from the process, MultiXTpm Process forwards it back to the original sender.

In order for this cycle to happen, we need to provide MultiXTpm Application Server with configuration information. This information is stored in an XML file that has a well known schema. You can find the schema definition in the file TpmConfig.xsd located in MultiXTpm Application Server directory.

The schema defines 4 main data types:

  • ProcessClass
  • Link
  • Group
  • Message
ProcessClass

A process class defines the attributes of a process that MultiXTpm Process controls and manages. The following table describes all attributes of a Process Class.

ID Each process class has an id which is a numeric value. When MultiXTpm Process starts a new instance of that class, it creates an instance ID for that instance. The ID of the instance is calculated as: ID of MultiXTpm Process * 100000 + Class ID * 100 + instance number (which is incremented by one for each instance). This instance ID has a meaning for the Inter Process Communication mechanism used by MultiX
Description A free text field to describe the class
PasswordToSend Tells MultiXTpm Process what to send to an instance of that class in order to identify itself to that process. It is used by that instance to very that it has a connection with the correct process. See CMultiXProcess::OnLoginReq in MultiX API.
ExpectedPassword Tells MultiXTpm Process what to expect when a connection is established with an instance of this class. See CMultiXProcess::OnAccepted.
ClassName Can be any string, it can be used by two peer applications to verify the class name of each other. When MultiXTpm Process sends its information to other processes, it always uses the class name “MultiXTpm”
DebugLevel Any number >= 0 to be used by an instance of the class. An instance can get the value configured for the class. See CMultiXApp::DebugLevel().
DefaultSendTimeout A value in milliseconds that specifies how long a send message operation should be pending before a timeout occurs. The timeout can be specified on the send operation itself, but if not specified, the default value is used.
MaxQueueSize Specifies how many messages should MultiXTpm Process queue for a specific instance of that class before it creates a new instance.
MaxSessions Specifies how many concurrent sessions an instance of that class can have before MultiXTpm Process creates a new instance of that class.
MaxRecoveryQueueSize Not used.
AutoStart Tells MultiXTpm Process whether to start instances from this class automatically or something else is responsible for starting/restarting processes from this class.
ExecCmd Specifies the command to use in order to start an instance of this class. It is usually the name of the executable but it can be any command or batch file name. The function used by MultiXTpm Process is “system()”, so any value that is valid for the system() call is valid here.
ExecParams Parameters used on the command line when starting a new instance of that class.
MinInstances Minimum number of instances that this class should have at any point in time. This value has meaning only if AutoStart is true. In that case, when MultiXTpm Process starts, it starts this number of instances, regardless of the load on the system.
MaxInstances The maximum number of instances that this class should have. It has meaning only if AutoStart is true. When the load on a process class gets high (All Queue in all instances reached their MaxQueueSize), MultiXTpm Process creates instances as needed, until the number of instances gets to this number. As load decreases, instances of this class will start to shutdown until the number of instances gets to MinInstances.
StartProcessDelay When MultiXTpm Process needs to restart a process that has crashed, it will wait this number of milliseconds before restarting it.
InactivityTimer The time MultiXTpm Process waits when an instance is idle before it shuts down the instance.
Params An array of ParamName/ParamValue pairs that is passed to each newly created instances. This is used to pass application dependent parameters to each instance. For example if the process class handles database activities, here is a good place to pass each instance the information about the database name and user name and password and so on.
LinkIDs An array of IDs of Links that this process class should use. When MultiXTpm Process starts a new instance, it provides the instance with information on all links that the process should use. See CMultiXApp:: OnTpmConfiguredLink().
Link

Link defines the attributes of a connection intended to be used by one or more processes in a MultiXTpm Application Server environment. Instead for each application to hold a private configuration file with information on connections and other parameters, MultiXTpm Application Server holds a repository for the communication parameters for all process classes. The association between a Link definition and the process classes that use it, is done thru the “LinkIDs” element in the ProcessClass element.
The following table describes all attributes of a Link.

ID Is used as key to the Links table, has no specific purpose besides identifying a specific link when associating it with a process class.
Description Free text describing the Link
LinkType Can be only “MultiXLinkTypeTcp”, future releases may support more link types.
OpenMode Can be one of:
  • MultiXOpenModeServer – Implies a listener socket in TCP/IP
  • MultiXOpenModeClient – Implies a client socket.
Raw When set to True, MultiX API provides only the interface to the transport infrastructure, the application is responsible for all application layer protocol and data.
When set to False, MultiX API uses this link for it's inter process communication. The application is never exposed to the underline protocol and data flow. Each process in a MultiXTpm Application Server environment has at least one implicit link defined for it for communicating with MultiXTpm Process.
LocalAddress This address is used to bind to the local socket created by this Link. On a Client Link, it enables binding to a specific adapter, on a Server Link it implies the address the socket will listen on.
LocalPort On a Server Link it implies the port to listen on, on a Client Link, it is the port we use for the local socket.
RemoteAddress Used on Client Links only and represents the address of the remote host.
RemotePort Used on Client Links only and represents the remote port to call.
Params An array of ParamName/ParamValue pairs that is associated with each Link. It's purpose is to enable passing extra information to the application on behalf of the specific Link. It is interpreted by the application only. MultiXTpm Application Server implementation of Secured Socket Layer (SSL) is based on providing special parameters in this collection when SSL support is required for the specific Link. More information on these parameters can be found in the file SSL_Support.htm located in MultiXTpm Application Server directory.
Message

Message attributes are used by MultiXTpm Process to decide what to do with a message when it is received from other processes. Since MultiXTpm Process is a router, it needs some rules on how and whom the received message should be forwarded to. A message can be forwarded to one or more destinations and it can have a response or no response at all.
The following table describes all the attributes of a Message:

ID This field is very important in the MultiXTpm Application Server environment. When using the MultiX API, every Send(...) operation has a MessageCode parameter. When MultiXTpm Process receives a message for forwarding, the first thing it does is looking for a message definition for the MessageCode it received. The MessageCode specified in the API is the ID specified here. This ID must be unique for each message definition. It can be any numeric value. Since MultiXTpm Process uses some reserved numbers for it's use, it is advisable to always use POSITIVE numbers.
Description Free text describing the message.
Stateful When set to True and the message is received in the context of existing MultiX Session, MultiXTpm Process will always forward the message to the instance of a process class that received the first message in the current session.
When set to False, MultiXTpm Process will elect the most available instance and will forward the message to it. See CMultiXSession in MultiX API.
 Timeout The time in milliseconds that MultiXTpm Process will wait for a response for that message before it decides that the forward operation failed.
Priority This field is intended for the receiving process only and it is implementation dependent. MultiXTpm Process forwards it's messages using FIFO; it does not priorities it's messages.
 WSURL When MultiXTpm Process receives a message that is indicated as a Web Service Request, it first looks for a message that has the WSURL field set to the URL received in the request. If no such message is found, the message is rejected.
WSSoapAction If a Web Service Request is received and the SoapAction is specified, MultiXTpm Process will look for a message definition with the same WSURL and WSSoapAction that are the same as received in the request. If this field is not specified, MultiXTpm Process will elect the message that has the WSURL the same as in the request.
WSDllFile When MultiXTpm Process forwards the Web Service request to the process instance that should handle the request, it notifies it about the DLL to use in order to process the Web Service Request.
WSDllFunction When MultiXTpm Process forwards the Web Service request to the process instance that should handle the request, it notifies it about the DLL function to use in order to process the Web Service Request.
ForwardFlags An array of flags that tells MultiXTpm Process who should receive the message and how, these are the flags:
  • GroupID – The ID of the group to receive the message. MultiXTpm Process may forward the message to one or more groups. In each group, one or more instances will receive the message depending on “ForwardToAll” flag.
  • ResponseRequired – If set to True, MultiXTpm Process will wait for a response from that group before sending a response to the sender. If more than one group has this flag set to true, MultiXTpm Process will wait until all groups have responded, only then it will respond to the sender. Based on the value of the flag IgnoreResponse, MultiXTpm Process decides which specific response should be sent back to the sender.
  • IgnoreResponse – If set to True, MultiXTpm Process waits for a response from that group but when it is received, it is ignored. In case that more than one group has the “IgnoreResponse” set to False, MultiXTpm Process will forward the first response it received, the later ones will be ignored. The assumption is that the client application is not aware that more than one server application receives it's messages, so it is not able to interpret more than one response.
  • ForwardToAll – When set to True, MultiXTpm Process will forward the message to all running instances of that group. We use such a flag when we want to notify all processes in a group about some special event, for example, we want all processes to close all files because we want to do End of Day processing.
Group

Group is a logical entity that exists only for the purpose of routing messages. When MultiXTpm Process needs to forward a message, it will forward it to one or more groups. MultiXTpm Process forwards it's messages to a group and not to a process class.
This is done in order to enable forwarding a Message (identified be a specific MessageCode) to Process Classes that can equally process the message but still have different Process Class attributes. An example for two process classes that are identical in functionality but still not defined in one Process Class is when we want to distribute the processes on more than one machine. In such a case we define two process classes, one form processes on machine A and one for machine B. The only difference between these two Process Classes is that the "ExeCmd" field is different. In one class we specify a command to start a process locally and in the other class we specify a command to start the process remotely. For all other purposes, the two Process Classes are identical.

For the purpose of Load Balancing we want MultiXTpm Process to treat all Process Classes in a Group as if they where defined in one Process Class. This way when MultiXTpm Process forwards a request to a group, it will always balance the load between all processes in a group, regardless of their physical location. This what makes MultiXTpm Application Server environment very dynamic and scalable.

The idea of forwarding a message to more than one group is to enable extra processing for a request that does not force the application itself to know about. For example, if a request arrives that requires us to update some information in the database and also we need to notify someone else on the fact that this request has arrived. We could implement the notification mechanism in the Database application, but this would require the database application to know details about if and how to communicate with the other party. By using the “Multicast” feature of MultiXTpm Application Server, the forwarding of the message to another entity is done without the database application knowing about it, so a full independence between various parts of the system is achieved.

The following table describes the Group attributes:

ID Identifies the group and is used in the forwarding flags in the message definition.
Description Free text describing the group.
ProcessClassIDs An array of process class IDs that belong to this group.

Download information

MultiXTpm Application Server is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

MultiXTpm Application Server is distributed in source code format and it supports: Windows OS, Linux, Solaris and HP Nonstop Server OSS.

The source code is packed in ZIP file and can be downloaded from SourceForge.net.

To Access the Download Page at SourceForge.net you may click Here
or
Navigate to http://sourceforge.net/projects/multixtpm

Contact information

For more information, Bug Reports, Feature Requests, and Support Requests, please use:
SourceForge.net tracker
or
SourceForge.net Project Forums
or
MultiXTpm group at Yahoo Groups.
or
you may send an email to: Moshe Shitrit
Home