PIMAGOLD

Architecture

Software from PimaGold, based on LAMP and organized in accordance with the MVC, is presented as a service and is lightweight with a simple and clear structure, and has a low total cost of ownership. These features are used to achieve a number of objectives.

So, one of them is the ability to be useful both in the execution of business processes of various scales, as well as personal purposes.

Next goal is to provide simple and flexible means for rapid implementation and integration. Being good enough, the software requires little support and low-skilled personnel, and can operate for years without stopping.

Another, and perhaps the main goal is to make IT solutions affordable for small businesses.

Conceptual design allows, so the software has a concise and readable deployment model that can theoretically be improved by the owner, such as sole trader, by his own efforts alone. In any case, PimaGold offers a relatively easy way to create a GUI and enables secure authorized access to the host computing, as well as the collection of statistics about user activity. Besides, PimaGold always keeps in mind the approach to development which assumes that all parts of the project are elaborated simultaneously and iteratively. Such key features as openness and ultimate simplicity of the PimaGold Basic Application Architecture allows to achieve the stated objectives. To build on this architecture, there is no need to use proprietary components or sophisticated development tools, but only the knowledge is required.

Further, in the immediate fixation solutions in the codes, PimaGold style is to guide efforts of developers rather than to oblige them to comply with regulations in the mandatory manner.

Basic Application

Figure 1

As pictured in Fig.1, the Architecture does not involve the use of a dedicated application server, which is perhaps the most contributory factor in TCO at a basic level. Instead, the appliction server area of responsibility is divided between such units as Stored Programs in RDBMS and the Frontal FrameWork (FFW) and the Client-Side JavaScript Framefork (CS JS-FW) or the Mobile Framework coupled with JS-FW.

Why? The answer lies in the fact that there are many types of business processes that are not as valuable to embed them in a full-featured application server. But at the same time, these processes are common and essential, are subject to changes and have a relatively short life span. Most businesses, especially small scale, never grows beyond the area where such processes dominate. Absence of application server not only cuts TCO but gives an impetus to the fine decomposition of functionality. In the case of the PimaGold Architecture, as a result of this decomposition, a typical piece of code to deal with rarely exceed a few dozen lines. This code fragment is usually sufficient and is wrapped in a separate file. Thus, the need for CPD system that contributes to TCO is also eliminated. One more important TCO-factor is the volume of the network traffic. Passing through the SOAP-transport entails unnecessary overheads due to heavy meta-data. Instead, the PimaGold Architecture is based on a multi-purpose FFW-Protocol (FFWP, Fig.1) which makes it possible to build structures of arbitrary complexity of any number of components. The main advantages of using the protocol are both efficiency and friendliness in relation to cloud computing. FFW has its own encryption, so does not depend on the use of SSL or something like that, but it is not prohibited to use FFWP over SSL.

As shown in Fig.2, the FFWP-request includes the Request ID and the Session ID, as well as the unique identificators of both the web-service (FFW-ID) and the instance of the JS-FW (MFW-ID), that makes it possible to build on the level of the session over FFWP-transport. The session level of FFWP is widely used in the registration system (RAS, Fig.2), which authorizes, collects statistics and acts as a broker for requests to web services. For the sake of completeness, mention should be made about the other parts that make up the basic architecture. Thus, there is a debug emulator that uses the file system and enables continuous production in the direction of the controller area and view area, without waiting for the version of the model. Using the emulator eliminates the need to create isolation between the development environment and its productive system. The next part is the XML-templates, which are intended to facilitate the web-service code by moving the functionality responsible for assembling the AJAX-pages.

The resulting page is assembled from fragments of HTML and JavaScript components according to the rules written in the XML-script and in accordance with the internal state of a web-service. The next way to manipulate the content of the page is to apply the theme engine. This concerns both the language support and anything in general.

Advanced Application

Figure 2

In fact, in terms of the architecture, cloudlet as functional unit represents one or more AJAX-pages.

The long-term state of this unity is mapped on the RDBMS, and its current state is held in the context of the active session. The JS-FW is dedicated to maintain the client-side portion of this context. In addition, this unit performs works such as support for queuing of requests to the shared resources and the definition of interior design in the form of a set of API and library calls, along with the wrapping, if any, invocations of the Mobile Framework (MFW), including error processing, etc. By the way, all FFW-units demonstrate uniformity in the propagation of error messages through all the levels and bring them to the user and stores them in the system log. Generally speaking, it is good practice for the cloudlet to customize its own instance of the JS-FW for the sake of efficiency.

In the case of mobile devices, MFW is a platform abstraction layer for the JS-FW calls, combining all the common functionality, and provides an integrated environment that supports the workplace of end-user to be up-to-date with the help of local HTML pages and client-side inclusions, which are arranged together with the message log and preferences in a local RDBMS.

Furthermore, MFW has been designed to be enhanced through the support of various sensors such as GPS and others. The role played by the MFW in the PimaGold Advanced Application Architecture is not only to be a mediator between the cloudlet and the RAS, as shown in Fig.2, but this is seen as a way for front-office applications to migrate from desktops towards mobile platform. In this regard, any application within the PimaGold Architecture represents a set of web services that are used in the specific context of RAS-session, and are associated with the authorized agent. Such applications performing calculations for the most part on a mobile device, can utilize the resources allocated to it within the host and reflect their state there in the RDBMS as well as in the file system, affecting only those data that are at their disposal.

To put the last brick in the building of the PimaGold architecture, it is worth mentioning about the system of backup and restore.

As shown in Fig.2, the system consists of two parts, the web service at the host and a remote client thereto. As a result, it is possible to take a snapshot of the system data at any moment and send it to a remote storage. Conversely, it is possible to restore the data at the host using a remote copy.

Contact

Any questions? Contact us pimagold@gmail.com