domain: | github.com/FirebirdSQL/Butler |
---|---|
shortname: | 3/FBSD |
name: | Firebird Butler Service Definition |
status: | raw |
editor: | Pavel Císař <pcisar@users.sourceforge.net> |
This document describes a specific category of software components capable of providing their services to clients working in the same or different contexts where the context may be a thread or a process. It defines common functionality and operational parameters to ensure interoperability and integration under defined working conditions.
Copyright (c) 2018 The Firebird Butler Project.
This Specification is distributed under Creative Commons Attribution-ShareAlike 4.0 International license.
You should have received a copy of the CC BY-SA 4.0 along with this document; if not, see https://creativecommons.org/licenses/by-sa/4.0/
This Specification is a free and open standard and is governed by the Consensus-Oriented Specification System (COSS) (see “2/COSS - Consensus-Oriented Specification System”).
Note
All ideas and change proposals SHOULD be presented and discussed first in the Firebird Butler forum.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC2119.
The purpose of this specification is to define software components capable of efficient asynchronous communication with other components through both tight and loose bindings in a diverse operating environments.
The main objectives are:
Firebird Butler Service is any software unit that performs an activity required by the Client, and where communication between the Service and the Client is solely through the exchange of messages via ZeroMQ sockets.
The Service MUST meet the following criteria:
The Client is any software unit that meets the following criteria:
The method of implementation of the Service is not specifically defined or limited, but the following recommendations should be taken into account:
Important
Any violation of these recommendations SHOULD be clearly specified in Service documentation.
The method of implementation of the Service Client is not specifically defined or limited, but the following recommendations should be taken into account:
Important
Any violation of these recommendations SHOULD be clearly specified in Client documentation.
Both the Service and the Client can run in the same or different context, the context being the process thread or the separate process, or a separate process on another network node.
When using different ZeroMQ protocols, the following combinations can be achieved:
Scenario | Service Context | Client Context | ZeroMQ protocol |
---|---|---|---|
1. | Thread T of Process P on node N | Thread T of Process P on node N | inproc [1] |
2. | Thread T1 of Process P on node N | Thread T2 of Process P on node N | inproc [2] |
3. | Thread T of Process P1 on node N | Thread T of Process P2 on node N | ipc, tcp [3] |
4. | Thread T of Process P on node N1 | Thread T of Process P on node N2 | tcp |
[1] | This scenario requires an ioloop supported and shared by both, the Client and the Service. It is NOT RECOMMENDED to mix this context scenario with others. |
[2] | inproc is the most efficient, but other protocols could be used as well, especially when the same Service Socket should be used in multiple contexts scenarios. |
[3] | ipc is the most effective option but may not be available on all platforms. In such a case, use of tcp through local loopback is the RECOMMENDED option. |
Service could work with Clients using multiple scenarios at once. However, the following recommendations should be taken into account:
Taking into account the previous recommendations, it is advised to use one of the following recipes for combined scenarios:
Supported scenarios | Service Sockets |
---|---|
3. and 4. | Efficiency and Simplicity: One socket using tcp transport |
2. and 3. | |
2., 3. and 4. | |
2. and 4. |
Tip
When implementing Services, it is RECOMMENDED to use a procedure that allows the same service code to be used in different contexts through adapters or containers. Most typically, the Service could be implemented as a Class, that accepts Service Socket specification (protocol and address, or already bound 0MQ socket instance) as a constructor parameter.
Alternatively, it is possible to encapsulate the service into another service that would act as a router or bridge to Clients or Services in another contexts.
One of the main goals of this specification is to enable the creation of services that do not work in isolation according to the client / server schema, but function as integral components of a larger integrated entity. To achieve this goal, it is essential for services to use other available services themselves.
When implementing Services that are also Clients of other services, the following recommendations should be taken into account:
Important
For the successful creation of interconnected systems, due attention needs to be paid to the initialization and termination of Services, especially due to possible dependencies between Services.
For systems built from components made up of separate processes or network nodes, due consideration should also be given to the mechanism of continuous monitoring and maintenance of the link between Services.
It is RECOMMENDED to use standardized methods and protocols for these purposes.
FBSD does not specify any authentication, encryption or access control mechanisms, and fully relies on security measures provided by ZeroMQ, or other means.
None at this time. In future, the Saturnin and Saturnin-SDK will act as the prime reference implementation for FBSD.