|
The ObjetX Application Framework provides a comprehensive set of tools and a platform for implementing a wide range of applications with the maximum amount of consistency while giving developers a great deal of flexibility in how they implement their applications.
The Framework was designed first as an architecture for building scalable, enterprise class applications – it is also an architecture designed to support high transaction volume requests and interfaces to other local or disparate remote systems.
The design objectives for the Object Manager Application Platform (OM) drove the design of this architecture.
These objectives were in place long before the specifics of how they would be realized were fully understood.
These architectural tenets helped shape the Object Manager as it was designed and implemented.
The basic design of the OM called for a distinct separation between the UI and the UI support code (code behind/beside) and the business logic code (otherwise known as the model-view-controller pattern).
The OM provides a security and verification layer that ensures that the business objects receive valid data in a consistent manner.
The OM also provides a basic presentation capability, ensuring that data being returned to the front end is in a consistent format with all necessary adjustments made to suit the front end requirements.
This includes translation of data, messages and labels as required.
The OM was designed to be a comprehensive Application Platform with enough functionality that application developers could focus on application development rather than system level functionality.
The OM is intended to host any type of application.
This means that it has the capability to support a well rounded, interactive enterprise application as well as the throughput and responsiveness required to support a real-time or near real-time transaction processing application.
The OM was designed to be application agnostic such that there would be no application specific logic in the OM itself and it was also designed to support multiple applications running at the same time, running as an integrated set or completely independent of each other as application demands dictate.
It was designed to provide an environment where developers could focus on providing business logic development while having access to all of the necessary data manipulation, display and application control logic required to turn their business objects into a complete, usable application such that no client will hang waiting for a response.
The OM is designed to handle all client requests as separate transactions that are managed through to completion.
This means that all client input can be managed in discrete units, all control information and data can be found in one place and all requests can be managed in a consistent fashion.
All requests to the OM are packaged in such a way that any object based command can be represented by the Object Manager Object (OMO) and all information used to control and route the transaction is also contained within the OMO.
Also, because all requests are treated as transactions, the requests can be monitored and the OM can guarantee that any request will be responded to in an acceptable manner.
One of the top priorities in developing the Object Manager was the need to provide a high degree of linear scalability.
The capability to grow the OM infrastructure to support and to meet the needs of increasing application load in a manageable fashion is at the root of the OM architecture.
The OM is designed to support internal tuning and service availability growth as well as clustering of Object Managers such that application load grow internally and then can be distributed over 2 or more systems in a relatively seamless manner.
Routing within the OM is managed so that a client of a service has no need to know if the service provided is on the same OM, the same system or on an OM on a remote system.
A great deal of the code required to support any application is simply there to move data from one place to another or to manipulate that data for display or persistence.
The OM is designed to deal with this application data support by utilizing a model defined in the Object Builder.
The model provides a great deal of information about the data schema using in the application, thereby supporting a very rich User Interface, while at the same time offering greatly enhanced flexibility to modify data related aspects of the application without any need for manual code changes.
The model in the Object Builder is transformed in to a set of metadata that is stored in the OM Support database.
When the OM starts up, it loads up the model metadata which is used to manage and drive the application and to provide valuable information to various components as to how data should be presented, manipulated or stored.
Security in an Internet application is a basic necessity.
The OM guarantees that all access is properly authorized.
All logins to the OM go through a rigorous verification process and all requests to the OM must be accompanied by current session information.
There is an extensive permissioning system, which works in conjunction with the application model provided from the Object Builder which allows the OM to control access to any object in the system. Various monitoring and control systems within the OM verify input and guard against malicious behaviour like SQL injection attempts or password break attempts.
The OM monitors user behaviour to determine if suspicious activity has been noted and will even force a user off the system if there are too many positive signs of malefic activities.
The OM maintains all passwords in their encrypted form, never decrypting passwords even in memory. Database information is encrypted where necessary and in many cases hashed with the hash key stored in the record to guard against direct database manipulation of data.
The ability to continue to respond under almost any condition and/or load is also a basic necessity in an Internet application.
The OM monitors all transactions under its control to ensure that a response is sent to a client within a maximum period of time.
If a client has initiated a request that results in a long running business object execution, the OM will monitor that execution and shut it down after a maximum length of time and provide a response to client indicating a failure in the processing.
The OM will also monitor services running to ensure against excessive memory usage or CPU utilization.
Any thread that exceeds maximum allowable values will be shut down and restarted and the OM Object associated with the thread will be returned to the client with a failure notification.
Separating the platform and any application from the underlying database was considered particularly important for a number of reasons.
The most obvious being that writing data access code is time consuming, error prone and usually difficult to optimize.
By building data access capability into the OM, we could utilize the data description capability in the object model provided by the Object Builder, and we could also use the Object Builder to generate various aspects of the data access code and many aspects of the database itself.
We could also optimize the use of the database through various mechanisms that would ensure consistency and control over the way that a database would be used.
Clearly, we would also be able to divorce the application from the database such that we could use different database systems without the need to change the application, and we could monitor the use of the database such that we could further optimize its usage and guard against errors or malicious code.
On top of all of this, we could manage the databases in such a way as to support multi-tenancy and proper backup and replication of databases.
| 
