Use Case: Migrating Legacy Software to Distributed Environment
For software that's been developed in separate components but some components are resource hungry and need to run on different servers, it's a major effort to re-implement it for a distributed environment. MAE transparently provides a distributed environment for applications; MAE's virtual file system provides all components with the same file system view.
You have an application that needs to be broken up into separate pieces to leverage a distributed environment, but you don't want to create the communications platform that is needed so the components can message each other. With the program broken up, you need to be able to quickly check the status of any/all running components. Also, once it is broken up, you want the components to have transparent access to the same file system resources, but you don't want to (or can't) use NFS or Samba to provide that common filesystem view.
Although MAE runs fine on a single server, it natively runs distributed as well, providing inter-process communication, common file system access, and component control. A MAE ecosystem incldues all servers participating in the application. From any MAE server, you can readily view the status of all its components. A MAE component may run multiple instances of itself, perhaps the instances are distributed across the servers, while being coordinated by the first/base instance. The individual components all communicate with each other without the knowledge of where they are running, unless they explicitly need to know.
In short, the MAE components work collectively the same whether they are running on a single host or distributed across many hosts.
Does this solution look like a fit for your organization? Reach out to HanoverSoft at +1 (919) 270-6712 or info@hanoversoft.net to discuss.
MAE manages its components from CommHub; it can start and stop a task/component by user control from the command line. If a process stops on its own, but MAE was told it should run all the time, then MAE will automatically restart the task unless a user recently told it to stop it via the comman line.
All integrated tasks communicate their current status to MAE, so issuing tstatus will provide a summary of all runable tasks and their current state (NotRunning, Initializing, OK, Completed/Failed). If you have a task that is running on multiple hosts (like IoGW does), then tstatus will only show you the status of the starting instance, e.g.
tstatus iogw
You can view the status of all the instances using
tstatus iogw.*
Each instance is assigned an instance number, whether by you with tstart (e.g. tstart mytask.13) or by the base task instance. A base task instance is instance number 0.
Start tasks using tstart; stop tasks using tstop. By default, a task starts on the last system it ran on, but you can override that and start it on a different system using something like
tstart spokename:mytask
To explicitly start a task instance, you can use something like
tstart mytask.13
Each MAE component has the option to open a message channel (or multiple message channels) using a keyword. The message channel is for SOA requests to other components or to simply update another component. MAE has simplified messaging mechanics by automatically generating an API for each message channel - by processing the channel's .mreg file using genmae. And it has simplified the processing of inbound requests; the .mreg file specifies what to do for each request; that is, what method in your program to call.
If a MAE component has a message for all other components, it can broadcast a message. Broadcast messages are configured in broadcast.mreg, which is used by genmae to create BroadcastAPI.h and BroadcastAPI.cpp. Note that if your app wants to receive certain broadcast messages, remember to configure that in your channel's .mreg file.
Message requests can be sent into MAE via the command line using tmesg. This is helpful when a non-MAE integrated program wants to send information to a MAE integrated program.
If you're curious, MAE's MsgBroker component manages all these messages.
If your component needs a response from another component before it continues processing, it will use MAE's RemoteService class for a remote procedure call. Each request has a unique keyword. MAE will forward the request to the component that registered to service it and then forward the response back to your component. Data is passed back and forth this way. When designing your software, be careful not to create deadlocks where A calls B, B calls C and C calls A; the final call from C to A is put on hold until A's call to B completes; hence, the deadlock.
Like messaging, the .mreg file is where you register services and specify what program method should be called when the request comes in.
Remote service requests can be sent into MAE via the command line using trpc. This is helpful when a non-MAE integrated program wants to get information from a MAE integrated program.
If you're curious, MAE's RpcBroker component manages all these requests and responses.
Use tioreg to declare resources available to MAE components. If the resource name looks like a filename with a path, such as /red/ball, then you are implicitly defining it in MAE's virtual file system. Every MAE application that accesses the registered resource name will access the same exact resource, regardless on which system the resource resides. When declaring the resource with tioreg, you specify the spoke hostname in a URL-like faction, such as:
tioreg /logs/tours file://tours/arana/log/test.log?poll=60
which can be used to register the file /arana/log/test.log on the spoke named tours using the MAE resource name /logs/tours. To declare a similar resource, but on the root server, use
tioreg /logs/root file:/arana/log/test.log?poll=60
which is used to register /arana/log/test.log on the root MAE server using the MAE resource name /logs/root. If you have an app that monitors log files, it can query the /logs directory of MAE's virtual filesystem using the IOPort class, which will report two files, tours and root.
If you're curious, MAE's IoGW component manages all MAE I/O resources and the virtual file system.