Skip to content Skip to navigation
Oil and Gas Oil and Gas Facility Management Water and Wastewater Aerospace Mining Communication Pharmaceuticals Healthcare Pulp and Paper Military Power Generation

Technical Architecture

Application Architecture

The IOM-OG Register is split into two broad layers, a server layer that handles HTTP requests and renders HTML, and a client layer that provides rich application behavior for users via JavaScript. Both of these layers are broken down into further layers, as shown in the diagram below. The server uses a Model-View-Controller (MVC) architecture via the Ruby on Rails framework, while the client uses Backbone.js for JavaScript organization and jQuery for event handling and Document Object Model (DOM) manipulation.

Application Layers

Logical Data Integrity

The IOM-OG Register ensures logical integrity of its data via a multi-layer validation mechanism. Data validation rules are enforced at the schema level by the RDBMS (e.g. foreign key and null constraints) and at the model domain level by the Rails framework (e.g. generating UUIDs and default types). The JavaScript view layer also introduces data validations, but these are redundant as they are also implemented in the other two layers and are only present to provide improved usability (e.g. prompts on mandatory values and autocomplete textboxes for referential integrity). For imports via the ws-ISBM or files, additional payload validations ensure that the content meets the correct specification or standard (e.g. CCOM BOD specification and MIMOSA CCOM Guidelines).

Multi-layer data validation

Client Environment

The IOM-OG Register heavily uses JavaScript for a rich user experience and supports JavaScript-enabled browsers including IE8+, Chrome and Firefox.

Application Environment

Under the hood, the IOM-OG Register uses JRuby, an implementation of the Ruby programming language that can be run on a Java Virtual Machine (JVM). JRuby acts much like a bridge between the Java and Ruby world allowing the flexibility of Ruby on Rails development to be combined with the maturity of a JVM.

The IOM-OG Register is deployed as a Java Web Archive (WAR) file. This WAR file can be hosted by any Java application server including Glassfish, JBoss, Tomcat or WebSphere. The WAR file contains all necessary resources required to host the IOM-OG Register application.

Database Environment

The IOM-OG Register supports any of the database types that are supported by Rails’ ActiveRecord JDBC adapter. These include Oracle Database and Express Edition, Microsoft SQL Server and Express, and PostgreSQL.

Cloud Deployment Architecture

The following architecture is used for our cloud deployments to provide a highly available and scalable enterprise solution.

Cloud deployment architecture
  1. Static content used by the IOM-OG Register is stored and served by the web server. The reverse proxy provides SSL/TLS termination to ensure all traffic between end users and the IOM-OG Register is secure. If multiple application servers are in use, the load balancer directs a specific request to an available application server.
  2. The application server provides the functionality of the web application by receiving and responding to HTTP requests.
  3. A relational database is the primary data store for the appliation and is hosted redundantly to provide high availability.
  4. To speed up responses to requests, an application cache is used to store commonly accessed data in a in-memory key-value data store.
  5. Any files including uploaded documents or imports, or files received via a ws-ISBM Service Provider are stored on a file server. These are served to end users via the application server (rather than the web server) to ensure users have permission to access the files.
  6. Notifications to administrators and users are sent via the email server.
  7. Error logging and general application performance monitoring provide the health status of the IOM-OG Register. These services are hosted external to the IOM-OG Register so they are reusable across other web applications.
  8. Integration with other applications occurs via a ws-ISBM Service Provider, which provides a standardized interface to an application messaging service.