Examples of Topologies - Firebird

The Firebird server comes in several “models” that provide a variety of scaling options, ranging from the single-user, stand-alone desktop to the server farm.

Two-Tier Client/Server

Figure depicts a flexible system, where multiple Firebird servers are running on different operating and filesystem platforms. There is a mix of workstations, each running remote clients appropriate to its local platform. There are gateways to other networks. The Windows server here happens to be serving the day-to-day data processing of the business and is commanding a lot of disk capacity. It is possible for the Windows clients to be conversing with the Windows server using the Named Pipes protocol—commonly called NetBEUI—although it should be avoided in favor of TCP/IP, if possible.

The Linux server may be serving firewalls, gateways, ancillary databases, and other client/server systems, including company e-mail, Internet, and file services, such as NFS and Samba.

Two-tier Firebird client/server topology

Two-tier Firebird client/server topology

Heterogeneous database-serving networks are a common environment for Firebird. In small, single-server networks where an on -site administrator may not be part of the permanent staff, the trend is moving away from running the database server on a single, high-specification, multi-purpose Windows host, toward low-cost, dedicated Linux machines, well-supplied with RAM and fast storage. Maintenance is low, making it realistic to outsource most of the administrative functions. Systems like this have capacity for growth without major upheaval.

The Single-User Model

All Firebird servers can accept local clients. The connection protocols and options vary according to the server model you choose. Single-user installations fall into two categories:

  • Stand-alone server: In this model, the server is installed and running on the machine. Local attachments are made via network-style protocols, using the normal client libraries.
  • Embedded server: No server is installed. The client and server programs are rolled into a single dynamic library or shared object that is invoked by the application and starts a single, exclusive server process on attachment. When the application program terminates, the server process is unloaded.

Client/Server

In the stand-alone client/server model, the localized client attaches to the running server using a local protocol. The server can listen for connections from remote clients while a local client is attached. Figure illustrates the options.

Stand-alone servers

Stand-alone servers

The first example shows the local connect model. Up to and including Firebird 1.5, the IPSERVER subsystem simulates a network connection within the same block of interprocess communication space. Beyond v.1.5, IPSERVER is deprecated in favor of a local protocol using the faster, more robust, native XNET subsystem. A functionally equivalent local connect is supported for Classic server on POSIX.

In the other two examples, on Windows, Linux, or any other supported platform, the TCP/IP local loopback protocol is used with the Superserver. It is a regular TCP/IP attachment to the special IP address 127.0.0.1, which most TCP/IP subsystems install by default as the named host localhost. On Linux, the v.1.5 Classic server can be used in this mode, provided the client library libfbclient.so is used.

Embedded Server

Embedded servers are supported on both Windows and Linux/UNIX platforms, although the implementation models are different. The embedded server library on Windows, which runs an exclusive Superserver process, is called fbembed.dll. On Linux/UNIX, it is the standard mode for a local connection to the Classic server. The library libfbembed.so starts a single Classic server process (fb _inet _server or ib_inet_server) and attaches directly to a database. It is not exclusive—remote clients can connect concurrently, using fbclient.so, another libfbembed.so, or fbclient.dll.

Embedded servers are discussed in more detail in the next chapter.

Firebird Servers in DTP Environments

A detailed discussion of distributed transaction processing (DTP) environments is beyond the scope of this guide. However, suffice it to say that Firebird Superserver or Classic server sits well in a variety of DTP scenarios.

The Open Group defined the X/Open standard for DTP, envisioning three software components in a DTP system. The XA specification defines the interface between two of them: the transaction manager and the resource manager (RM). The system has one RM module for each server, and each RM is required to register with the transaction manager.

Figure illustrates how a Firebird server could be slotted into an XA-compliant DTP environment. The database application server module provides a bridge between high-level user applications and the RM, encapsulating the XA connection. The RM performs a client like role to negotiate with the database server for access to data storage.

The encapsulation of the XA connection enables the application developer to build and execute SQL statements against the RM. Transaction demarcation—which requires two-phase commit capability on the part of all servers—is moderated by the global transaction processing monitor (TPM). Cross-database transactions under the management of a transaction manager are made through a two-phase commit process. In the first phase, transactions are prepared to commit; in the second, the transaction is either fully committed or rolled back.The TPM will alert the calling module when a transaction does not complete for some reason.

Firebird in distributed transaction processing environments

Firebird in distributed transaction processing environments

The TPM coordinates distributed transactions in multiple database systems so that, for example, one transaction can involve one or more processes and update one or more databases. It keeps account of which RMs are available and involved in transactions.

The framework supports multiple databases per server and multiple servers, which need not all be Firebird. Up to and including v.1.5, Firebird does not support spanning a single database across multiple servers or serving a database that is not controlled by its host machine.

Transaction Server Frameworks

Microsoft Transaction Server (MTS) with COM+ is one such scenario. MTS/COM+ provides a process-pooling environment that encompasses the deployment and management of business logic components, including auditing control, security, and performance monitoring. One of its most significant features is declarative transaction management. Transactions initiated by MTS/COM+ are controlled by the Microsoft Distributed Transactions Coordinator (DTC), an XA resource manager. The native Firebird interface requires an ODBC or OLE DB provider that supports both Firebird’s two- phase commit capability and the MTS/COM+ call context.

Terminal Servers

Firebird is successfully deployed in MTS and IBM Citrix frameworks. The protocol is TCP/IP with attachments connecting to network IP addresses in all cases.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Firebird Topics