Skip directly to searchSkip directly to the site navigationSkip directly to the page's main content

System Documentation - Architecture

The IBIS-PH system consists of three applications 1) a semi-private Indicator Profile data maintenance and publishing system, 2) a public Indicator Profile and adhoc query view request system, and 3) a private, backend SAS data interface system. These applications communicate with each other via standard HTTP web requests with XML data responses or text responses (this type of distributed system interaction is commonly referred to as ReST which is defined as Representational State Transfer). The applications can be hosted on as few as one computer (server) or can be distributed and load balanced across multiple clustered servers.

Listed below is a description of the applications followed by a diagram showing a high level view of the three applications hosted on four servers, followed by an example of a typical distributed environment using five servers.

The IBIS-PH System Applications - The Three Musketeers

  • IBIS-PH Data Administration and Maintenance System - Web/intranet based application that allows different health program offices to maintain/edit health indicator profile data and publish these data to the public View System for consumption by the public. This application is a standard Java web MVC application - Java servlets and controllers (control), JSPs (view), and any SQL backend database with Java beans (model).
  • IBIS-PH View System - Public web/internet based application that allows the viewing of health data which indicator profile reports, custom queries, and pages that describe the system, and various Health Department meta data type pages. This application is also based on the MVC design pattern with Java servlets and controllers (control), XSLTs (view), and XML documents/data files (model).
  • IBIS-Q Query System - Web/internet based CGI application that the IBIS-PH View System can interact with to build and execute SAS procedures that query and perform calculations on SAS datasets. This application also has the capability to deliver query results without using the IBIS-PH View System. It is written in 'c' and runs on HP-UX, Linux, or MS-Windows using the Apache web server software.

Figure 1

IBIS-PH View and IBIS-Q Notes:
  • The IBIS-Q CGI Application *MUST* reside on the same server as the SAS application.
  • IBIS-Q provides an HTML interface for those who do NOT want to use the IBIS-PH View front end.
  • The IBIS-PH View System can interface with any backend server process that can accept queries in the form of an HTTP URL request and that can stream back the results in either a CSV format or XML. In 2005 a demonstration was done showing the IBIS-PH View system interacting with the SAS Intrnet product. Note that for this functionality some extra Java XML/CSV interface code is needed but is easily plugged in.

Application to Application Communication/Interaction

The high level diagram shown above depicts the typical system parts and basic interaction. The applications interface/communicate with each other using standard HTTP "get"s and "put"s. Each request is programmed to give a certain response with each response message being specifically programmed for as well. This type of interaction now has a fancy name and is commonly referred to as "REST", or Representational State Transfer. REST is described as an architectural style for building applications that leverages basic current web technology for passing data between computer systems. In a sense, REST takes the same technological concepts behind a browser requesting data from an application running on a server, and applies them to application-to-application communications. For the IBIS-PH System, most requests involve either a simple text message response or an XML text stream. The system does not currently have any support for SOAP, web services, or other more complex web application communication solutions although it could very easily be added to the View and Admin applications.

Distributed Environment Example Using Five Servers

This configuration is depicted in the above Figure 1 with the exception that the front end Web Server Proxy is not shown.
  • Web Server Front End Proxy. Some installations will choose to have a web server proxy front end for the IBIS-PH web applications. This allows for content caching, tracking/reporting user requests (web trends), and to potentially increase the security of the backend Java application server by not allowing public access to the application servers.
  • Java Application Server - IBIS-PH Data Administration and Maintenance System. Since this application is an intranet application and needs to interact with a relational database, this application can be put on a server that does not have public access to it to help keep the system more secure with limited database server exposure. This application also needs to communicate with the View System using standard HTTP request URLs.
  • Database Server - IBIS-PH Data Administration and Maintenance System data. The IBIS-PH Data Admin System can work with any SQL-based database server that has a JDBC driver and a way to connect to it. It has successfully been run on MS-SQL Server, MySQL, and Oracle.
  • Java Application Server - IBIS-PH View System. This server needs to be able to communicate via HTTP to the Admin System (if Indicator Profiles) and the IBIS-Q System (if Adhoc queries).
  • CGI Web Server and SAS Server - IBIS-Q Query System. This server needs to be able to communicate via HTTP with the View System. Due to the nature of the IBIS-Q application, it also requires that the SAS application be installed on the same server.

JAVA APP SERVER CLUSTERING NOTE: When deploying to a clustered environment, all XML data files MUST be shared on a common file server.
The information provided was retrieved on: Sat, 20 April 2019 17:24:28.

Content updated: Wed, 4 Nov 2015 09:26:28 MST