Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Understanding CAN/CSA-ISO/IEC 15474-2:04 – Language-Independent Service Specifications: Basic Services
A comprehensive guide to the framework and technical requirements for language-independent basic services in distributed systems
Introduction
The standard CAN/CSA-ISO/IEC 15474-2:04 (identical to ISO/IEC 15474-2:2004) is part of the Language-Independent Service Specifications (LISS) family. It defines the structure and semantics of basic services that can be specified independently of any particular programming language, enabling interoperability across heterogeneous computing environments. This article provides a detailed technical overview of the standard’s scope, architecture, implementation guidelines, and conformity considerations.
Tip: CAN/CSA-ISO/IEC 15474-2:04 is the Canadian adoption of the international ISO/IEC 15474-2:2004. It is identical in content and technical requirements to the original ISO/IEC edition.
Scope and Application
ISO/IEC 15474-2:2004 specifies a set of abstract basic services that are fundamental for distributed applications in open systems. These services are described in a language-independent manner, meaning they can be bound to any concrete programming language (e.g., C++, Java, Ada) via the associated binding specifications (ISO/IEC 15475 series).
The standard covers the following categories of basic services:
- Naming Service – Mapping names to object references.
- Trading Service – Dynamic discovery of service providers.
- Event Service – Decoupled communication through events.
- Time Service – Synchronization of system clocks.
- Life Cycle Service – Creation, deletion, and management of objects.
- Relationship Service – Management of associations between objects.
- Transaction Service – Coordination of atomic operations.
These services are intended to be platform-neutral and are commonly used in middleware architectures such as CORBA, DCOM, and web services frameworks.
Technical Requirements and Architecture
The standard defines each basic service through a set of interfaces and operations expressed in an abstract Interface Definition Language (IDL). The IDL used in ISO/IEC 15474-2 is a language-independent notation that can be mapped to any concrete IDL (e.g., OMG IDL, WSDL).
Service Specification Structure
Each service specification includes:
- A service name and purpose.
- Interface definitions with operations and their signatures.
- Behavioral semantics described using pre- and post-conditions, invariants, and state diagrams.
- Inter-service dependencies (e.g., the Event Service may rely on the Naming Service).
Example: The Naming Service Interface
| Operation | Input | Output | Description |
|---|---|---|---|
bind | name: Name, obj: Object | void | Associates a name with an object reference. |
resolve | name: Name | Object | Returns the object bound to the given name. |
unbind | name: Name | void | Removes the binding for a name. |
list | pattern: String | NameList, BindingList | Enumerates bindings matching a pattern. |
Important: All interfaces are defined using abstract types (e.g.,
Name, Object) that must be further refined in a concrete mapping to a specific programming language or middleware. Implementation and Conformity
Implementing a service that claims conformance to ISO/IEC 15474-2 requires adherence to the specified interfaces, behavioral semantics, and any required inter-service protocols. The standard defines two levels of conformance:
- Basic Conformance: The implementation provides the mandatory operations of a service as defined in the standard.
- Full Conformance: The implementation additionally supports all optional operations, ensures correct behavior under all specified conditions, and passes a set of abstract test cases defined in Annex A of the standard.
Developers typically use a mapping to a concrete language (e.g., using the CORBA mapping defined in ISO/IEC 15476-1) to produce compilable interfaces. The standard does not mandate a particular implementation technology; it only specifies what a service must offer, not how it is built internally.
Best Practice: Use automated conformance test suites (e.g., those provided by OMG for CORBA services) to verify that your implementation meets the behavioral requirements of the standard.
Implementation Considerations
- Interoperability: The language-independent specification ensures that a service implemented in Java can interoperate with a service implemented in C++ if both follow the same interface definitions and protocols.
- Performance: The abstract nature of the specification allows implementors to optimize internal representations as long as external behavior is preserved.
- Security: Although ISO/IEC 15474-2 does not define security services, it recommends integration with security frameworks (e.g., ISO/IEC 10181) when deploying in open networks.
Compliance and Certification Notes
Compliance with CAN/CSA-ISO/IEC 15474-2:04 is typically assessed by:
- Declaration of Conformance – The implementor declares which services and conformance level are supported.
- Proof of Mapping – A documented mapping from the abstract interfaces to the target programming language is required.
- Behavioral Testing – The implementation must pass a set of abstract test cases that exercise the required operations under various scenarios.
In Canada, the Standards Council of Canada (SCC) recognizes this standard through the CSA Group. Certification bodies may offer voluntary verification programs, but the standard itself is not directly linked to governmental regulations. It is widely used in enterprise middleware and telecommunication systems where language-neutral service definitions are essential.
Note: Always verify that your implementation is based on the latest amendment. ISO/IEC 15474-2:2004 has not been superseded, but amendments to individual services (e.g., the Event Service) may be introduced in companion standards.
Frequently Asked Questions
Q: What is the relationship between ISO/IEC 15474-2 and CORBA services?
A: ISO/IEC 15474-2 defines abstract service specifications that are largely aligned with the Object Management Group’s (OMG) CORBA services. In fact, many of the services (Naming, Trading, Event, etc.) have direct counterparts in OMG specifications. The LISS framework allows these services to be bound to languages other than those supported by OMG IDL.
A: ISO/IEC 15474-2 defines abstract service specifications that are largely aligned with the Object Management Group’s (OMG) CORBA services. In fact, many of the services (Naming, Trading, Event, etc.) have direct counterparts in OMG specifications. The LISS framework allows these services to be bound to languages other than those supported by OMG IDL.
Q: Can ISO/IEC 15474-2 be used for web services?
A: Yes. Although originally designed for CORBA-like environments, the abstract interface definitions can be mapped to WSDL and SOAP, enabling language-independent service definitions for SOA. Several industry implementations exist.
A: Yes. Although originally designed for CORBA-like environments, the abstract interface definitions can be mapped to WSDL and SOAP, enabling language-independent service definitions for SOA. Several industry implementations exist.
Q: Does this standard specify any security or quality-of-service aspects?
A: Not directly. Security and QoS are considered orthogonal concerns. The standard provides hooks for integration with security services (e.g., authentication for bindings), but the specifics are left to other standards or profiles.
A: Not directly. Security and QoS are considered orthogonal concerns. The standard provides hooks for integration with security services (e.g., authentication for bindings), but the specifics are left to other standards or profiles.
Q: Where can I obtain a copy of CAN/CSA-ISO/IEC 15474-2:04?
A: The standard can be purchased from the CSA Group website or from ISO national member bodies. It is identical to ISO/IEC 15474-2:2004.
A: The standard can be purchased from the CSA Group website or from ISO national member bodies. It is identical to ISO/IEC 15474-2:2004.