Multitier architecture

DB-Adapter Tier

The code which defines mapping and optimises the distant databases to the needs of Middleware can be found in the so-called DB-Adapter. It is a tier which provides a unified and precisely specified interface from one side and understands the structure of a particular distant database from the other side. It follows that for each distant database there is exactly one DB-Adapter identified by a unique URL [Ref. 1]. The access to the interface of the DB-Adapter (as shown in the Fig 1) is effected via HTTP protocol [Ref. 2], the result of each request is a FLAT file, where each row represents a resource with attributes delimited by space. The interface is described at the Wiki page of the project OASIS[Ref. 3].

Middleware Tier

In this framework, Middleware serves as a tier between the web interface and individual DB-Adapters. It enables construction of enquiries, asynchronous communication and classification of results from DB-Adapters.

[Fig. 1]: CIANT: Front-end-Middleware-DBA Interfaces

The interface is defined from both sides of the Middleware (Fig 1). From the front-end side it is the HTTP+XML in RPC [Ref. 4] form. However this is not an existing standard (apart from the HTTP and XML as standards). For the purposes of OASIS, we have developed a communications protocol based on XML which contains the exact needs of OASIS.
From the other side the Middleware has to implement the already mentioned communications protocol which enables the contact with DB-Adapters. The list of individual DP-Adapters may be found in the configuration settings of the middleware. Other DB-Adapters may be dynamically added or removed with the help of several service scripts which will be elaborated upon later.

Frontend Tier

The presentation tier constitutes of a web interface created in the PHP language. The communication with middleware runs with the help of a protocol based on HTTP+XML. The system can be easily extended with other front-ends, which might use other technologies than PHP. Each front-end may be placed on separate hardware for reason of load balancing or several different instances might exist at one place e.g. for supporting several graphical designs. Implemented designs in OASIS Frontend

[Fig. 3]: CIANT: First Proposal for OASIS Search nteface [Fig. 4]: CIANT: Redesign of the OASIS Search Interface

The current version of web interface does not require the support of cookies within the browser, but the user has to have javascript enabled. The user may choose from two different designs at the moment. (Fig 3).

Load Balancing

Each of the represented components may (but does not have to) be located on separate hardware. This decision depends on the anticipated worki load of the system as the architecture allows load balancing. If needed, OASIS Middleware, OASIS Frontend instances perhaps even DB — Adapters may be applied concurrently as shown in picture Fig 5. In case of utilising the load balancing each instance of front-end has to communicate with exactly one instance of middleware. Opposed to this, middleware may communicate with different front-ends and different DB-adapters.

Fig. 5: Load Balancing

Fig: This option is not originally intended for the purposes of load balancing. However it is suitable in case we need to post several differently designed instances of front-end which communicate with common middleware. Fig: This option is the most suitable for the purposes of load balancing, namely because it increases the capacity of the centralized component of Middleware which carries the highest burden of the system. The one requirement of this solution is a fast network connection from Middleware to DB-Adapters. It can be noticed that all instances of Middleware communicate with identical DB-Adapters. Fig: The most complicated solution which requires duplicated instances of DB-Adapters. This option is based on precedent versions.

old references: observe this as formatvorlage

• Fig. 1: This option is not originally intended for the purposes of load balancing. However it is suitable in case we need to post several differently designed instnaces of frontend which communicate with common middleware.
  

The current version of web interface does not require the support of cookies in the browser, but the user has to have the javascript enabled. The user might choose from two different designs at the moment. (Fig. 3).

• Fig. 2: Load Balancing

Each of represented components might (but does not have to) be placed in separate hardware. This decision depends on the anticipated working load of the system as the architecture allows load balancing.
If needed, OasisMiddleware, OasisFrontend instances perhaps even DB—Adapters might be applied concurrently as showed in picture Fig 6.5. In case of use of load balancing each instance of frontend has to communicate with exactly one instance of middleware. On the contrary, middleware might communicate with different frontends and different DB-adapters.

• Fig 3: This option is not originally intended for the purposes of load balancing. However it is suitable in case we need to post several differently designed instnaces of frontend which communicate with common middleware.

• Fig 4: This option is the most suitable for the purposes of load balancing, namely because it increases the capacity of the centralized component of Middleware which is the most burdened element of the system. The one condition of this solution is fast network connection from Middleware to DB-Adapters. One can notice that all instances of Middleware communicate with identical DB-Adapters.

• Fig. 5: The most complicated solution which requires duplicated instances of DB-Adapters. This option is based on precedent versions.

• Fig.6 : This option is the most suitable for the purposes of load balancing, namely because it increases the capacity of the centralized component of Middleware which is the most burdened element of the system. The one condition of this solution is fast network connection from Middleware to DB-Adapters. One can notice that all instances of Middleware communicate with identical DB-Adapters.

• Fig 7: The most complicated solution which requires duplicated instances of DB-Adapters. This option is based on precedent versions.

Learn more about the platform's communication and follow the description of → Database Adapter and the → DBA-Cache (cache-per-day).

[TL]

Figures

References

• [Ref. 1]: T. Berners-Lee, L. Masinter and M. McCahill.

→ Uniform Resource Locators. 1994, December, RFC 1738.

• [Ref. 2]: R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee.

→ Hypertext Transfer Protocol -- HTTP/1.1. 1999, June, RFC 2616.

• [Ref. 3]: V. Simko, M. Leszczuk and P. Romaniak, [[En:Interface:Communication|→ DBA-Interface], 2006.

• [Ref. 4]: Wikipedia, → Remote procedure call, 2007.