• eBD
• Company
• Training
• Partners
• eBD Community
• News

The architecture consists of three components:  a Web Server, an eBD Server and an eBD Transaction Server.  This modularity  separates the phases of the application increasing efficiency and availability.

Web Server

The Web Server directly interacts with the user's browser, receiving requests and communicating them to the eBD server.  It  is responsible for http functionalities (e.g. compression and encryption), acts as a cache for the public eBD server information, and helps balance the load between various eBD services.

These services do not contain any private information, nor do they have direct interaction with backend databases or user files. Thus the Web Server can be placed in an external location, eg a demilitarized area, since it only  contains public data.

eBD Server

The eBD Server processes incoming requests from the Web Server, coordinates tasks like email and Web services, and converts any results into http format to be displayed to the user.  It is eBD's central service, and more than one instance of it may be running concurrently (eBD cluster service).  It interacts with the transaction service to obtain relational data from user databases and dictionaries. It also has access to application and user files on the filesystem on the node on which it is installed.  In the case of eBD cluster service, you must ensure that the data each service sees is synchronized and up-to-date.  

eBD Transaction Server

The eBD Transaction Server's main objective is to keep connections with the databases alive for use by the eBD service.  It also handles any java transactions and maintains user sessions.  Specialized transaction services can be created to achieve improved service separation in applications that require this.