Home

MultiXTpm Application Server

Open Source/Free Software
MultiXTpm is an Application Server, Message Oriented Middleware (MOM) and Transaction Processing (TP) Monitor. It provides the runtime environment and rich API for developing large, scalable applications that are required to process online transactions originated from various types of computers and devices.
A MultiXTpm based system is built from various types of processes that run on one or more machines and communicate with each other using the provided API. Among other things, this API enables the developers to build systems that are based on multiple processes that communicate with each other, rather than build one monolithic program that does all processing of all types of activities.
As an Application Server and Message Oriented Middleware (MOM) in a Distributed Processing environment, MultiXTpm provides a system that is as open and flexible as it can be. MultiXTpm can provide services to all kinds of applications and hardware devices. It does not impose any restrictions or requirements on any part that is external to the main processes of the system. For example, if there is a requirement to connect a specific POS (Point of Sale) terminal to the system but it uses a specific protocol and data format, in that case MultiXTpm provides all the facilities and API to interact with that POS terminal, convert its data to an “understood” format and “inject” the data into the system as it was received from some other internal resource. This flexibility makes MultiXTpm the best solution for large scale systems that are required to support a wide range of devices and input methods. This is in opposite to all object oriented application servers that enforce the developers to use a single or maybe two input methods in order to interact with the main application server.
When it comes to connecting to legacy systems and proprietary applications or hardware controllers, MultiXTpm provides all the necessary services to:
  • Act as a server to these systems, handle requests and provide responses to these requests.
  • Act as a client to these systems by handling all the protocol and data conversions when sending requests and receiving responses.
  • Act as an Application Level Router/Gateway/Connector between different systems

MultiXTpm Architecture

MultiXTpm architecture is based on the idea that the entire runtime environment comprises of multiple processes of different types and purposes that communicate with each other using messages. In order to enable efficient use of resources and to enable each process handle as many requests as possible in a short time, MultiXTpm environment provides a special API that is implemented in a special DLL called MultiX. The MultiX API provides the framework for developing event driven processes where all inter process communications and communication related issues are handled by the MultiX DLL and are performed in a NO WAIT manner. This architecture enables a single process to handle many requests in a short time without the process needing to explicitly wait for the data to arrive and without wait for response to be actually sent. Since the application is event driven, MultiX is responsible for receiving the data buffers, assembling it into a logical message and notifying the application on the complete message. When a response needs to be sent, the application just issues a send request, regardless of the message size, and MultiX will send the message, one fragment after the other and at the end, it notifies the application on the success or failure of the send. During this whole time, the application may receive and process many other messages.

Compact and Modular Code

Since MultiXTpm environment is built from many processes that communicate with each other, the designer of a given implementation is encouraged to build a system that comprises of many processes where each process has a well defined function in the system. This approach enables building a very modular system and a very efficient and scalable system. The fact that the system modularity is achieved thru multi processing makes the system very highly distributable and scalable. This architecture also makes it very easy to maintain and debug the modules. Small, functional processes are a lot easier to debug than large processes that are built from thousands of lines of code and it is easier than debugging a DLL that is part of a larger process.

Threading

An application designed to run in MultiXTpm environment using the MultiX API, is usually built single threaded. While MultiX itself uses multithreading for processing its events, the application is usually written single threaded. The idea is that multi threading in the application layer is done to achieve concurrency and higher throughput, but in MultiXTpm environment these goals are achieved thru use of multi processing and not multi threading. In MultiXTpm environment it is MultiXTpm's responsibility to launch instances of the same program when needed and stop these instances when the load gets low. This capability of MultiXTpm frees the developer from the burden of developing multithreaded applications. It also frees the designer of the application from the burden of building tools to load balance the system within one process (multi threads), within one machine (how many instances of a given process and when) and within a domain or a cluster (how many processes on each machines and when to launch them).
Never the less, if a developer chooses to use multiple threads for processing multiple requests simultaneously within the same process; MultiX API provides excellent threading support that fits within the entire architecture. A good example for using multiple threads within the same process for achieving better throughput can be found MultiXTpm gSoap Enhancer where each service call is handled by different thread, allowing the main process doing other activities while the Web Service performs its own activities.

MultiXTpm Processes

When building an application for MultiXTpm environment we may define 4 types of processes that can take part in a given system:
  • MultiXTpm itself.
  • Front End processes.
  • Back End / Application / DB Server processes.
  • Gateway / Converter / Adapter processes.

MultiXTpm

This process is the heart of the system and it is responsible for the following activities:
  • Processes Control - Control all other processes by means of starting, stopping or restarting them either automatically as required or manually as requested by operators.
  • Process Configuration - Provide configuration information to the other processes when they start or when they get connected to MultiXTpm.
  • Messages Routing - Route messages between all processes as dictated by the configuration information stored in its XML configuration file.
  • Messages Queues Management -  Since it acts as router and load balancer, MultiXTpm maintains a message queue for each group of processes and for each process in particular.
  • Sessions Management - MultiX Sessions enable the sharing of a single context between multiple processes. This enables management of stateful objects at the application level. MultiXTpm has the knowledge on all existing sessions at any given time and it is responsible to notify all relevant processes when a member joins a session, when it leaves the session and when a session is terminated.
  • Load Balance - MultiXTpm is responsible for load balancing of all activities between all processes so no one process can be overloaded while other processes are doing nothing. This load balancing crosses machine boundaries which makes the system scalable and can be balanced using unlimited number of machines.
  • High Availability - MultiXTpm's ability to distribute the processing between multiple processes and multiple machines makes the system highly available where no one application or machine can stop system operation.

Front End Processes

Since MultiXTpm based applications communicate with each other using the MultiX API, there comes a time that there is a need to communicate with an application or a device that do not use the MultiX API. In such situation, a Front End Process is created. It has two logical end points, one to communicate with the non-MultiX device or application thru using some kind of protocol and data format and the other end point is to communicate with MultiXTpm and the other MultiX based processes.
A typical implementation of a Front End Process is as follows:
  1. The process is started, getting configuration from MultiXTpm.
  2. Listen on one or more ports for incoming connection (using the MultiX API).
  3. When a new connection is established, some hand shaking takes place.
  4. Receive some data from the remote end (thru the Event mechanism that is built into the MultiX API).
  5. Analyze the data and if the received data is not a complete message (application dependent) step 4 is performed again.
  6. When a complete message is received, it may convert the data to some internal format and forward it to MultiXTpm using the MultiX API for application level processing.
  7. At some point, a notification is received from MultiXTpm that there is a response for the request.
  8. The response may be converted to some other format and forwarded back to the remote end using the specific protocol and data format that is suitable for the remote end.
  9. The Front End Process may choose to disconnect the connection to the remote end or wait for another message, it is all implementation dependent.
Some typical scenarios for implementing Front End Processes are:
  • Communicating with devices like POS terminals that use some complicated protocol and data format, for example, a terminal that uses X28 for its protocol and ISO 8583 for its data format.
  • Communicating with legacy systems that interact with others by sending and receiving proprietary text or binary messages, for example, an IBM mainframe that runs CICS and can handle transactions sent and received in EBCDIC format.
  • Interacting with hardware controllers that use proprietary protocol over a multidrop link (RS448) and represents multiple sub devices of different types.
  • Acting as an XML Web Services server where it receives all the HTTP and SOAP data and forwards it to the actual application server to process the web service request.
Secured Socket Layer (SSL) Support
Since Front End Processes interact with external applications and devices, there might be a requirement for these interfaces to be secured. To fulfill this requirement, MultiXTpm Application Server provides SSL support using the OpenSSL software package. Front End Processes make use of this capability provided by MultiXTpm Application Server. Read more about SSL Support.

In general, the idea of a Front End Process is that it handles interface issues related remote end applications or devices that do not use the MultiX API. It forwards the “normalized” message to some back-end/application process for the actual processing of the data. This is in contrast to implementing the interface/protocol/data conversion/data processing in a single process. This way, if more than one interface exists for a given service, only a Front End Process needs to be added/modified and the application that handle the data processing/business logic is not modified or touched at all.

Back End / Application / DB Server processes

Back End processes are responsible for the actual processing of the requests and only that. When a new requests is received by a Back End Process, it assumes that the request is complete and contains all the data and partial message that needs to be gathered from fragments. A Back End Process has no knowledge on the mechanism used to deliver the request,what protocol was used or what transport used. The same is tru when a Back End Process send its responses to the sender. In MultiXTpm environment, it is possible for more than one Back End Process to receive a request that was forwarded from a Front End Process, each Back End Process can act differently on the same request. Usually, Back End Processes are not aware of the fact that other processes receiving the same message.
A typical implementation of a back end process is as follows:
  1. The process is started, getting configuration from MultiXTpm.
  2. Process may do some initialization like opening a database or some other activity and enter a wait state for incoming requests.
  3. At some point a new request is received, either from MultiXTpm or from some other MultiX based process, Front End Process for example.
  4. It processes the request and it may respond to the originator immediately or it may forward it to another process for additional processing.
  5. If the request was forwarded for additional processing, a response for that forwarding may arrive at some point and the entire response will be returned to the originator.
  6. The process returns to a wait for a new request.
In a Back End process, there is no connection establishment and termination with the outside world, it has an open connection with MultiXTpm and maybe with other processes controlled by MultiXTpm.
The idea of implementing a Back End Process is to help the developer separate the development of the business logic from all other issues.
Back End Processes take care only for pure application issues and not for anything else. Some typical scenarios for implementing Back End Processes are:
  • Credit Card Authorization process, this process receives some data regarding the credit card, it does not care how the data got there, it checks the credit card for validity and the database for eligibility and it responds with the appropriate answer. It might need to forward the request to some other service for authorization, in that case it forwards it (thru MultiXTpm) to another process that might interact with that other service and only when the entire response is received, it is forwarded to the originator.
  • SOAP Web Service invocation server, this process receives some SOAP/XML formatted data, regardless of the source of the data, using some internal logic it invokes the appropriate function/DLL to parse, analyze and process the request, at the end, the SOAP/XML formatted response is forwarded to the originator.

Gateway / Converter / Adapter processes

Gateway Processes play almost the same role of Front End Processes except that they are logically located at the back end of the system. They are mainly used in cases where a request is originated at the front end side of the system, then forwarded to some Back End Process which in turn needs to forward the request to some external system for additional processing. In such scenario, the Gateway processes acts like a Back End Process by the fact that it receives its request from the internal processes, but on its other side it behaves like a Front End Process by the fact that it interacts with some external system using some specific protocol and data format.
The main difference between Front End Process and a Gateway Process is the origin of the request. In a Front End Process the request is originated from the remote non-MultiX end, then it is forwarded to an internal Back End Process and when a response is received from the Back End Process, it is sent back to the remote end. In a Gateway Process, the request is originated from some internal Back End or Front End Process, then when received by the Gateway Process, it is forwarded (and maybe converted) to some external non-MultiX remote end. When a response is received from the remote end, it is forwarded back to the internal Back End Process that originated the request.
Some typical scenarios for implementing Gateway processes are:
  • In a credit card authorization, a local authorizing application might need to forward the authorization request to the credit card issuer for final authorization.
  • In a security system, a service provider might receive some alert for a security event, after processing the event, there might be a need to escalate it and forward the event to another service provider for additional processing.

Summary

MultiXTpm Application Server a high availability, high throughput, scalable server for implementing messages based and service oriented systems. It is built to support large number of processes that can run on one or more machine and platform. It load balances the system thru using multiple processes and multiple machines. It can easily interact with third party systems and with various hardware devices that use a variety of protocols and data formats. Finally, it is open ended and can be customized to support any future requirements for interaction with external systems and improving internal mechanisms for load balancing and message forwarding.

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