MAE Overview
MAE (Multi-Application Ecosystem) uses a SOA to provide a platform for enterprise software development. Build your app by leveraging the wealth of application support already built in; build your app faster. Your app is separated from rapidly changing technology, so when technology is upgrade, your app requires little or no maintenance.
The platform itself supports REST API, web access, messaging, database access, remote procedure calls, user notifications, and virtual file system access. Your application connects to MAE via socket or TCP connection; interfaces in C++ handle those details. Python and Java interfaces are planned for future releases.
REST API - MAE handles HTTP protocol, authentication and data conversions; your application handles the meat of the API call. MAE converts to/from JSON and XML for your application. Authenticated and unauthenticated calls supported.
Web Access - MAE handles the serving of web pages and notifies your application with user-triggered events such as button press, hotspot click, menu selection, positional mouse click in image, a user keystroke, a pull-down selection, file upload, or text response. HTML content is organized separately from your program. Web pages are updated asynchronously, allowing you to create Single Page Applications.
Messaging - MAE handles inter-application asynchronous messaging over application channels or via broadcast. Messages allow one application to easily update other applications. A message interface builder tool ( genmae ) enables developers to easily create compliant message interfaces (avoiding mismatched or missing parameters). Applications are event-driven; events are typically a request in a message.
Database - MAE abstracts database access for easy datastore software development. As of 2023, MAE specifically supports MySQL and CSV; future releases will support other SQL servers (e.g. Postgres, Oracle, Microsoft SQL) or Non-SQL servers (e.g. Mongo, Cassandra, SnowFlake).
Remote Procedure Calls - (Synchronous messaging or SOA request and response) MAE handles inter-application method calls to send data to another application and receive a synchronous response.
User Notifications - MAE abstracts urgent and less urgent user notification with interfaces to send SMS, in-application notices, or e-mail messages.
Virtual File System - MAE allows the developer to map out a virtual file system so applications use a developer-architected file system that may include files from diverse systems or directories into a singular virtual file system, including access to special files such as pipes, sockets, TCP connections, UDP connections, and pttys. The files actually reside somewhere in the host file system, but may be distributed transparently across multiple MAE servers.
Multi-Server Transparency - MAE is comprised of one core server and zero or more spoke servers. Application components can run on any of the servers in a MAE deployment, transparently working with components on other MAE servers. Multiple servers may be useful for distributing processing load or distributing access to remote resources; edge devices such as Raspberry Pi SBCs serve well as MAE spoke servers providing access to IoT and other devices.
MAE is a language agnostic development platform that enables REST, interactive websites, and separation of ever-changing technology from application code.
For websites, MAE uses the MVC model. Displayable HTML content resides in resource files separate from applications: the starting page, sub-page components, and forms. Content is displayed to tagged regions (via HTML id values), so applications are HTML unaware. Styles of HTML display are identified by keywords (and defined by UI developers via CSS).
The MVC philosophy applies similarly to other aspects of MAE: database, messaging, remote procedure calls, user notification, and file access. MAE abstracts all these technologies to greatly minimize app maintenance. Technologies can change, evolve or replace; when they do, the appropriate part of MAE is altered without the need for MAE application alteration. MAE application components can be built from C++, Python, or Java; they will seemlessly interact with other components, regardless of any specific component's programming language.
MAE is not an all-or-nothing platform; MAE does not require the application developer to use all of MAE or none of MAE. Use as much of MAE features as you like; ignore other features you don't wish to use.
Today, software developers have a plethera of tools to draw upon. So, when should I used MAE? Here are various use cases.
For legacy data that still runs on legacy hardware or uses old formats that is still needed in real-time, MAE provides the platform to fetch the data, transfer the data, and make the data available via modern means such as JSON, XML, or REST API. See Use Case: Migrating Legacy Data in Real-Time.
For legacy software that's been maintained for years, it's daunting to pick new technologies to migrate to - especially new technologies that may require another software development in five years. MAE provides an environment to minimize the code changes required to modernize your software. See Use Case: Migrating Legacy Software to Web.
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. See Use Case: Migrating Legacy Software to Distributed Environment.
MAE has built-in virtual terminals so legacy software that cannot be updated can display into a virtual terminal and then displayed to a web browser. See Use Case: Web-Enabling Legacy Text-Based Software.
MAE has created all the mechanics of receiving, decoding, encoding, and responding to REST API calls as well as a prototype daemon as a code starting point. Your developers focus on the core functionality of your REST API services. This makes for rapid REST API development. See Use Case: Rapid REST API Development
MAE has created all the mechanics of receiving, decoding, encoding, and responding to REST API calls as well as a prototype daemon as a code starting point. Further, MAE provides ready access to database tables. See Use Case: Develop REST API for Database Table(s).
(Future release use case.) Since the MAE environment is language agnostic with interfaces for C++, Python, and Java, your developers can create various components of your application in any of the supported languages; they will seemlessly exchange data and interoperate without the need for a shim or other technically challenging cross-language interface. See Use Case: Interoperability Between C++, Python, Java
Setup a MAE spoke on a Raspberry Pi or other SBC. Once setup, MAE's virtual file system can be configured to access files, sockets, pipes, etc on that spoke - or write a MAE component for that spoke. Once connected to MAE, all other MAE applications can access that data or simply store it in a connected database table. See Use Case: IoT Data Collection.
Log data may come from files or devices connected via serial ports. Either way, MAE's virtual file system allows ready access to log data, which an application may consume or it may be saved to a database table (or to syslog or a new file). See Use Case: Log Data Collection.
New and revised technology requires software revisions to match them, but MAE isolates various technologies into different components and abstracts them for your applications. By using MAE, your software maintenance is limited to functional bug fixes, not technology mismatches. See Use Case: Low Software Maintenance.