SPIRIT Set Structure

This chapter and SPIRIT Sets are normative except for the paragraphs indicated as informative. This chapter describes the way in which SPIRIT specifications have been organised into useful groupings, how these groupings may be combined and expected to coexist, and the meaning of conformance to these groupings.

SPIRIT Sets

SPIRIT specifications have been organised into system sets and component sets.

SPIRIT System Sets

Typical platform configurations can be classified in three ways:

• the type of application supported

• the role of the application with respect to other applications

• the execution guarantees provided by the platform.

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. However, agents can be considered to be embedded in clients, servers, managers or other system elements, so SPIRIT has only defined a system set for the manager. The manager role is to provide the functions needed to manage all the hardware and software of a SPIRIT Platform and the applications running on it. It also provides the functionality needed to build and run services and network management applications for TMN.

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 at all. The results of a transactional service are stored in a resource. The resource used to store the result of a transactional service is called a transactional resource.

A non-transactional service has no guarantees about successful completion nor about the ease of undoing the effects after unsuccessful or incomplete execution. The results of a non-transactional operation are stored in a non-transactional resource.

Management applications generally use only non-transactional services.

From these three categories, SPIRIT defines the following five system sets:

• Manager

  A Manager is a SPIRIT manager supporting non-transactional services.

• Non-transactional Client

  A Non-transactional Client is a client supporting non-transactional services.

• Transactional Client

  A Transactional Client is a client supporting transactional services.

• Non-transactional Server

  A Non-transactional Server is a server supporting non-transactional services.

• Transactional Server

  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 (see SPIRIT Component Sets ). The following notation is used in SPIRIT Sets to specify inclusion in a system set:

M:

Mandatory

To conform, implementations must support this specification.

O:

Optional

Not required for conformance, but may be required by a particular Service Provider.

N:

Not applicable

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 specifications. System sets are defined in System Set Specifications (see System Sets ).

System Sets shows the different use of system sets for applications (AP1, AP2, and so on) in which sets are chosen according to each application's specific functional requirements.

SPIRIT Component Sets

For the management and communications services (see Platform Model ) where there are complex dependencies between specifications, it is helpful to define sub-assemblies of specifications which are technically-consistent. These are called component sets, and are defined in SPIRIT Component Set Specifications .

Coexistence and Combination

Specifications in a SPIRIT Platform are said to coexist only if the services can be used in the same compile unit, except where otherwise noted. Examples of conflicts which can hamper coexistence are listed in Coexistence of Specifications . For Manager, management services do not have to coexist in the same compile unit as the managed objects.

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:

• Non-transactional Client + Non-transactional Server

• Transactional Client + Transactional Server

• Manager + Non-transactional Server

• Manager + Transactional Server

• Manager + Non-transactional Client + Non-transactional Server

• Manager + Transactional Client + Transactional Server

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 to System Sets

Conformance is defined as meeting all requirements of a specification, a component set or a system set. A platform implementation is said to conform to a system set when it meets all of the following requirements:

• All SPIRIT specifications or component sets listed as mandatory within each system set must be implemented.

• All SPIRIT specifications or component sets listed as mandatory within each system set must be able to coexist. Additionally, the platform must support the required combination of system sets, if more than one system set is combined.

• Any additional requirements stated in each system set must be satisfied.

Conformance is distinguished from assurance, which is independent verification of conformance. Within SPIRIT system sets there are some specifications referenced for which independent verification is performed by an independent agency. Where vendors are able to obtain such verification, conformance is assured. If independent verification is not available, then vendor conformance is unassured.

Where SPIRIT references a specification and there exists independent verification of conformance to the specification, assurance is possible. A vendor declaration is a formal statement by a vendor to apply all reasonable efforts to conform to a specification or a component set and a commitment to correct any variances in product from the specification expeditiously. A vendor declaration is possible for all SPIRIT specifications. However, from a Service Provider's perspective, vendor conformance is still unassured.

Thus, there are three possible states of conformance for any vendor's product with respect to SPIRIT referenced specifications:

• non-conforming

• conforming with vendor declaration

• assured conformance.

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.

Using System Sets

This section is informative.

Specifications are included in Part 1, Overview and Core Specifications because:

• They meet user requirements.

• Vendors agreed they are implementable in the short term (that is, 6 to 12 months following publication).

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:

• portability of applications from one compliant vendor platform to any other compliant vendor platform

• interoperability of applications between any compliant vendor platforms

• competition among SPIRIT vendors.

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 Conformance to System Sets are met.

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.

See Example System Set Usage for an example of how system sets are used in procuring application systems.