This chapter and
SPIRIT specifications have been organised into system sets and component sets.
Typical platform configurations can be classified in three ways:
The type of application supported by a SPIRIT Platform may be a business application or a management application. Business applications are typically data-intensive, high volume and multi-user. Management applications are typically event-driven, high throughput and near-real-time.
The role of one business application with respect to another can be
as client or server.
Clients initiate interactions which servers carry out.
Clients and servers together constitute a distributed system.
Similarly, management of a system involves the interaction of both
managers and agents.
A particularly important execution guarantee that a SPIRIT Platform can
provide is embodied as a transaction.
A transactional service is one which executes completely or not
A non-transactional service has no guarantees about successful
Management applications generally use only non-transactional services.
From these three categories, SPIRIT defines the following five system sets:
A Manager is a SPIRIT manager supporting non-transactional services.
A Non-transactional Client is a client supporting non-transactional services.
A Transactional Client is a client supporting transactional services.
A Non-transactional Server is a server supporting non-transactional services.
A Transactional Server is a server supporting transactional services.
Distributed transaction processing requires the use of both the Transactional Client and Transactional Server system sets.
Note that the support for transactional communication, which propagates a global transaction between SPIRIT Platforms, is a superset of non-transactional communication. That is, an application developed on the Transactional Client or Transactional Server system sets, can use both non-transactional and transactional communication. Non-transactional Client, Non-transactional Server and Manager system sets allow only for non-transactional communication. On a Transactional Server system set, users can develop a Non-transactional Server application, that can interoperate with a Non-transactional Client application developed on a Non-transactional Client system set.
SPIRIT system sets are defined by either referring directly to
SPIRIT specifications, or indirectly by selecting SPIRIT component sets
To conform, implementations must support this specification.
Not required for conformance, but may be required by a particular Service Provider.
Not applicable to the system set, and not required for conformance. For example, the transaction demarcation API is not applicable to the Non-transactional Server.
Where necessary, additional restrictions have been defined for
a particular system set.
Informative (non-normative) notes are also included where helpful;
for example, to point out dependencies between specifications.
Notes are summaries of what has already been specified in other
System sets are defined in
For the management and communications services (see
Specifications in a SPIRIT Platform are said to coexist only if the
services can be used in the same compile unit, except where otherwise
Examples of conflicts which can hamper coexistence are listed in
Note that the SPIRIT system sets define the APIs made available to application programmers, and do not apply to whatever internal interfaces there may be between components within a particular platform implementation. For example, an implementor may use C-ISAM internally to implement the SQL specification.
To better meet business needs, combinations of system sets may coexist on a single platform implementation. The following combinations are allowed:
For combinations of Client and Server system sets, all services can be used within the same compile unit. For other combinations (that is, Manager and Client/Server combinations), this is not required - the services are provided to different compile units. The product implementing a specification common to the combined system sets must be shared to avoid unnecessary infrastructure software duplication; for example, a DBMS that implements a data management service, a file manager accessed through a language service, and an OSI Transport and Lower Layer communications service shared between FTAM, CMIP and TP.
Conformance is defined as meeting all requirements of a
specification, a component set or a system set.
Conformance is distinguished from assurance, which is independent
Where SPIRIT references a specification and there exists independent
verification of conformance to the specification, assurance is
A vendor declaration is a formal statement by a vendor to apply all
Thus, there are three possible states of conformance for any vendor's product with respect to SPIRIT referenced specifications:
For SPIRIT Issue 3.0, only vendor declaration is possible for SPIRIT system sets. However, assured conformance is possible for specific specifications and component sets referenced in those system sets.
If a supplier makes a claim that a product conforms to an individual SPIRIT software specification, a SPIRIT component set or a SPIRIT system set, the supplier must indicate that such a claim is made by the supplier only, and that no determination has been made by SPIRIT or the NMF as to whether or not the product in fact conforms.
This section is informative.
Specifications are included in Part 1, Overview and Core Specifications because:
Some individual discussion and negotiation may be necessary with SPIRIT vendors to obtain precise statements of conformance. In general, however, Service Providers can include SPIRIT specifications in short-term procurement requests to ensure:
The system sets described in this document represent the easiest way to include references to SPIRIT specifications in Service Providers' procurement request documentation. Service Providers can choose among the system sets based on the infrastructure or platform functionality requirements of the application. Note that conformance to SPIRIT is based on independent specifications for functional services, and does not include vendor differentiators such as price/performance, service, quality of product, value-added tools, and so on. SPIRIT specifies a basic infrastructure platform to create sufficient commonality among vendor implementations to meet fundamental goals of portability and interoperability.
When looking at applications, Service Providers should choose a
system set according to the type of platform configuration in which
applications are built.
Then, Service Providers may choose to add or remove some specific
specifications, although Service Providers must check the
specifications for technical consistency, check with vendors for
implementability, and consider the cost of application portability
for addition and deletion.
Among the SPIRIT Platforms conforming to the same system set, applications
are to be portable and interoperable.
Vendors that provide compliant software must ensure that the
conformance requirements in
These choices provide a simple way to specify often complicated component relationships to ensure vendors provide compliant software to meet the goals of open systems applications.