ISO/IEC 19763-7

• Abstract:

  The primary purpose of the multipart standard ISO/IEC 19763 is to specify a metamodel framework for interoperability. ISO/IEC 19763-7:2015 specifies a metamodel for registering models of services, facilitating interoperability through the reuse of services. ISO/IEC 19763-7:2015 is only applicable to web services whose capabilities are described by some web service description language (see Annex A for examples of such languages). Figure 1 shows the scope of ISO/IEC 19763‑7:2015.

• Status: Not Published
• ICS: 35.040.50 - Automatic identification and data capture techniques
• Technical Committee: ISO/IEC JTC 1/SC 32 - Data management and interchange
• Drafting Committee: ISO/IEC JTC 1/SC 32/WG 2 - MetaData
• Current Stage: 6000 - International Standard under publication
• Start Date: 16-Sep-2026
• Completion Date: 19-Sep-2026

• Revises: ISO/IEC 19763-7:2015 - Information technology — Metamodel framework for interoperability (MFI) — Part 7: Metamodel for service model registration
• Effective Date: 10-May-2025

Overview

ISO/IEC 19763-7:2026 - titled "Information technology - Metamodel framework for interoperability (MFI) - Part 7: Metamodel for service model registration" - is an international standard from ISO and IEC designed to facilitate interoperability in heterogeneous digital ecosystems through a structured metamodel for registering web service models. This document is a key part of the ISO/IEC 19763 multipart series, which provides a comprehensive metamodel framework for enabling consistent and efficient interoperability between diverse information systems.

Part 7 of the series focuses specifically on the registration of service models, allowing for the management of administrative and evolution-related metadata of web services. It supports the discovery, reuse, and dynamic evolution of web services described in various service description languages, such as WSDL, OpenAPI, gRPC, and more, as detailed in the informative Annex.

Key Topics

• Metamodel for Service Model Registration:
  • Offers a generic framework for registering both functional (i.e., operations, input/output messages) and non-functional (e.g., QoS, evolution history) features of web services.
  • Supports the registration of services described in multiple service description languages.
• Service Evolution and Change Management:
  • Tracks and documents changes across the service lifecycle, including major, minor, and patch updates, as well as protocol, message format, and endpoint changes.
• Communication Patterns and Protocols:
  • Accommodates various invocation methods, protocols (SOAP, REST, GraphQL, gRPC, WebSocket), and message data formats (JSON, XML, Protobuf).
• Associations and Roles:
  • Integrates closely with related parts of the MFI series, managing relationships among service models, roles, goals, and processes.
  • Provides support for goal achievement tracking and the involvement of organizational roles in services.
• Conformance Requirements:
  • Specifies criteria for strict and extended conformance, ensuring implementations maximize interoperability while permitting necessary extensions.

Applications

• Web Service Discovery and Integration:
  • Enables efficient discovery and composition of services, crucial for enterprise application integration, cloud ecosystems, and service-oriented architectures (SOA).
• Digital Transformation Initiatives:
  • Facilitates the creation of dynamic service registries that support evolving business processes and rapid technology change.
• Interoperability in Heterogeneous Environments:
  • Supports the coexistence and interaction of varied web services across different organizations, technologies, and protocols.
• Governance and Lifecycle Management:
  • Provides a structured way to record and manage administrative data, QoS assertions, and service evolution, underpinning compliance and governance efforts.
• Semantic Service Registries:
  • Moves beyond basic keyword discovery by enabling machine-processable, semantically rich service metadata for automated service selection and composition.

Related Standards

The ISO/IEC 19763-7:2026 standard is closely linked with other parts of the ISO/IEC 19763 series:

• ISO/IEC 19763-3: Metamodel for ontology registration
• ISO/IEC 19763-5: Metamodel for process model registration
• ISO/IEC 19763-8: Metamodel for role and goal model registration
• ISO/IEC 19763-10: Core model and basic mapping

Other relevant standards for web service description and interoperability include:

• WSDL (Web Services Description Language)
• OpenAPI (formerly Swagger)
• ebXML Registry and Repository
• GraphQL and gRPC protocols

Practical Value

ISO/IEC 19763-7 provides organizations a standard way to catalog, manage, and evolve their web service assets within complex, multi-protocol, and multi-language environments. By supporting advanced registration and discovery mechanisms, it underpins robust interoperability strategies, reduces integration complexity, enhances service reuse, and enables agile adaptation in fast-changing digital ecosystems. This makes it particularly suitable for organizations aiming to maximize business value from their service architectures while ensuring long-term compliance with internationally recognized interoperability standards.

International
Standard
Second edition
Information technology —
Metamodel framework for
interoperability (MFI) —
Part 7:
Metamodel for service model
registration
Technologies de l'information — Cadre du métamodèle pour
l'interopérabilité (MFI) —
Partie 7: Métamodèle pour l'enregistrement du modèle de service
PROOF/ÉPREUVE
Reference number
© ISO/IEC 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 3
5 Conformance . 4
5.1 General .4
5.2 Degree of conformance .4
5.2.1 General .4
5.2.2 Strictly conforming implementation .4
5.2.3 Conforming implementation . .4
5.3 Implementation Conformance Statement (ICS) .4
6 MFI Service model registration . 5
6.1 Overview of MFI Service model registration .5
6.2 Associations between MFI Service model registration and other parts in MFI .6
6.3 Structure of MFI Service model registration .8
6.3.1 Service_Description_Language .8
6.3.2 Service_Model .9
6.3.3 Service .9
6.3.4 Service_Operation .11
6.3.5 Service_Type. 12
6.3.6 Service_Evolution . 12
6.3.7 Service_Change . 13
6.3.8 Change_Impact . 13
6.3.9 Change_Type.14
6.3.10 Invocation_Way .14
6.3.11 Protocol . 15
6.3.12 Message_Exchange_Pattern . 15
6.3.13 Message_Data_Format . . 15
6.3.14 Message_Type .16
6.3.15 Input_Message .16
6.3.16 Output_Message .17
6.3.17 Expression .18
6.3.18 Atomic_Expression .18
6.3.19 Composite_Expression .19
6.3.20 Composition_Type .19
6.3.21 Precondition .19
6.3.22 Postcondition . 20
6.3.23 Exit_Condition .21
6.3.24 QoS_Type .21
6.3.25 QoS_Assertion . .21
6.3.26 User_Tag . 22
Annex A (informative) List of existing service description languages .23
Annex B (informative) Examples .24
Bibliography .52
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC have not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 32, Data management and interchange.
This second edition cancels and replaces the first edition (ISO/IEC 19763-7:2015), which has been technically
revised.
The main changes are as follows:
— Additional metaclasses have been introduced in the metamodel of MFI service model registration to
support registration of heterogeneous services using multiple protocols, including Invocation_Way,
Message_Exchange_Pattern, Protocol, and Message_Data_Format.
— Additional metaclasses have been introduced in the metamodel of MFI service model registration to
support registration of service evolution, including Service_Evolution, Service_Change, Change_Type,
and Change_Impact.
— Annex B has been updated, providing registration examples, including an OpenAPI service registration
example and a PROTO3 service registration example.
A list of all parts in the ISO/IEC 19763 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
iv
Introduction
With the rapid development of Service Oriented Computing (SOC), more and more computing resources are
presented in the form of web services. Meanwhile, business integration based on web services is becoming a
popular application development method. A web service is a kind of Web based application that encapsulates
one or more computing modules and is designed to support interoperable machine-to-machine interaction
over a network.
In Web Service registration and management, ebXML RegRep is a standard defining the Service interface,
protocols and information model for an integrated registry and repository, which provides basic support for
publishing and discovering Web Services within and across enterprises. Nevertheless, keyword matching
is the basic service discovery method in ebXML RegRep, thus the discovery results will be inevitably
inaccurate, and the discovery process will be time-consuming. When business information interchange and
integration becomes increasingly frequent, major work in web service discovery should be processed by
machine. This shift necessitates the semantic description of administrative and evolution-related metadata
of services, along with the provision of corresponding registration and management mechanisms. Moreover,
with the rapid growth of service networks and service ecosystems, where large numbers of heterogeneous
services coexist and dynamically evolve, the demand for interoperability becomes increasingly critical.
Services characterized by more diverse communication protocols, description languages, message exchange
patterns, and data formats must be capable of sharing and interaction. To support this, service registration
frameworks must be enhanced to ensure that services can be discovered, composed, and evolved within
highly dynamic and diverse digital ecosystems.
This document intends to provide a generic framework for registering administrative and evolution
information about web services in an explicit way. The relationship between MFI service model registration,
the service registry, and service models expressed in different service description languages is illustrated in
Figure 1.
Key
service model
metadata about service
NOTE Not every model needs to exist in a repository before registration
Figure 1 — Scope of MFI Service model registration
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
v
International Standard ISO/IEC 19763-7:2026(en)
Information technology — Metamodel framework for
interoperability (MFI) —
Part 7:
Metamodel for service model registration
1 Scope
The primary purpose of the ISO/IEC 19763 series is to specify a metamodel framework for interoperability.
This document specifies a metamodel for registering administrative and evolution information of models of
services, facilitating interoperability through the reuse of services.
This document is only applicable to web services whose capabilities are described by some web service
description language (see Annex A for examples of such languages). Figure 1 shows the scope of this
document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 19763-3, Information technology — Metamodel framework for interoperability (MFI) — Part 3:
Metamodel for ontology registration
ISO/IEC 19763-5, Information technology — Metamodel framework for interoperability (MFI) — Part 5:
Metamodel for process model registration
ISO/IEC 19763-8, Information technology — Metamodel framework for interoperability (MFI) — Part 8:
Metamodel for role and goal model registration
ISO/IEC 19763-10, Information technology — Metamodel framework for interoperability (MFI) — Part 10: Core
model and basic mapping
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19763-3, ISO/IEC 19763-5,
ISO/IEC 19763-8, ISO/IEC 19763-10 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
service
kind of application which encapsulates one or more computing modules and can be accessed through a
specified interface
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
3.2
service operation
execution action of a service (3.1)
3.3
expression
sentence which is expressed using a logical notation to specify either a condition that applies to a service
operation (3.2) or a QoS assertion (3.13) that applies to a service (3.1)
3.4
atomic expression
logical expression (3.3) that has the unit granularity
3.5
composite expression
logical expression (3.3) that comprises multiple atomic expressions (3.4) and (or) other composite expressions
(3.5) by using connectives such as conjunction, disjunction and negation
Note 1 to entry: Models can be used to express a set of information requirements, processes, services, roles, goals or
some other aspect of a domain of interest.
3.6
precondition
constraint that must be true when an operation is invoked
Note 1 to entry: The operation can be a process or service operation (3.2).
3.7
postcondition
constraint that must be true at the completion of an operation
Note 1 to entry: The operation can be a process or service operation (3.2).
3.8
exit condition
constraint that, if true, causes an operation to finish unsuccessfully
Note 1 to entry: The operation can be a process or service operation (3.2).
3.9
message type
type of the message or a set of messages that is (are) consumed or generated during the execution of a service
operation (3.2)
3.10
input message
information contained in the message that the service operation (3.2) consumes for its execution
3.11
output message
information contained in the message that the service operation (3.2) generates after its execution
3.12
QoS type
specified non-functional property for a service (3.1), such as availability, response time, etc
3.13
QoS assertion
specification of one or more QoS types (3.12) for the service (3.1)
3.14
web service
kind of service (3.1) that is designed to support interoperable machine-to-machine interaction over a network
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
3.15
entity service
webservice (3.14) that bases its functional boundary on one or more related organization entities, such as
customer, employee, invoice and claim
3.16
task service
web service (3.14) with a functional boundary directly associated with a process model
3.17
utility service
web service (3.14) that is dedicated to providing reusable, cross-cutting utility functionality, such as event
logging, notification, and exception handling
3.18
service evolution
changes in the functional or non-functional properties of a service (3.1) that occur throughout the lifecycle of
the service (3.1)
Note 1 to entry: Such changes include, but are not limited to, modifications to its computing modules, interfaces,
communication protocols, message exchange patterns, or data formats.
3.19
user tag
tag annotated by an individual or organization in order to describe the service (3.1) according to the
understanding of the creator of the tag
4 Abbreviated terms
ebXML RegRep ebXML Registry and Repository
GraphQL Graph Query Language
gRPC Google Remote Procedure Call
IRI Internationalized Resource Identifier
MFI Core and Core model and basic mapping (see ISO/IEC 19763-10)
mapping
MFI Process Metamodel for process model registration (see ISO/IEC 19763-5)
model registration
MFI Role and Metamodel for role and goal model registration (see ISO/IEC 19763-8)
Goal model registration
MFI Service Metamodel for service model registration (see ISO/IEC 19763-7)
model registration
OWL-S Web Ontology Language for Services
QoS Quality of Service
REST Representational State Transfer
SOAP Simple Object Access Protocol
SWRL Semantic Web Rule Language
SWSL Semantic Web Service Language
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
WADL Web Application Description Language
WSDL Web Service Description Language
WSML Web Service Modelling Language
5 Conformance
5.1 General
An implementation claiming conformance with this document shall support the metamodel specified in
Clause 6, depending on a degree of conformance as described in 5.2.
5.2 Degree of conformance
5.2.1 General
The distinction between ‘strictly conforming’ and ‘conforming’ implementations is necessary to address
the simultaneous needs for interoperability and extensions. This document describes specifications that
promote interoperability. Extensions are motivated by needs of users, vendors, institutions and industries,
but are not specified by this document.
A strictly conforming implementation may be limited in usefulness but is maximally interoperable with
respect to this document. A conforming implementation may be more useful, but may be less interoperable
with respect to this document.
5.2.2 Strictly conforming implementation
A strictly conforming implementation:
a) shall support the metamodel specified in Clause 6;
b) shall not use, test, access, or probe for any extension features nor extensions to the metamodel specified
in Clause 6.
5.2.3 Conforming implementation
A conforming implementation:
a) shall support the metamodel specified in Clause 6;
b) as permitted by the implementation, may use, test, access, or probe for any extension features or
extensions to the metamodel specified in Clause 6.
NOTE 1 All strictly conforming implementations are also conforming implementations.
NOTE 2 The use of extensions to the metamodel can cause undefined behaviour.
5.3 Implementation Conformance Statement (ICS)
An implementation claiming conformance with this document shall include an Implementation Conformance
Statement stating:
a) whether it is a strictly conforming implementation in 5.2.2 or a conforming implementation in 5.2.3;
b) what extensions, if any, are supported or used if it is a conforming implementation.
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
6 MFI Service model registration
6.1 Overview of MFI Service model registration
This part of MFI specifies the metamodel that can be used to register functional and non-functional
information about web services (hereafter referred to simply as “services”). Examples of some service
description languages that can be registered using this metamodel are listed in Annex A.
Figure 2 shows the metamodel for the registration of services. This metamodel allows the registration of the
common functional and non-functional features of services described using a number of service description
languages. Each service model, expressed using a specific service description language, may describe one
or more services. Each service is comprised of one or more service operations. Each service is described
by zero or one QoS assertion. This QoS assertion is used to represent the quantitative or qualitative non-
functional features of the service, such as response time, cost, reliability, etc. Each QoS assertion is defined
using one and only one expression, which may be a composite expression or an atomic expression. Each
QoS assertion is of one or more QoS types. Each service undergoes multiple service evolutions throughout
its lifecycle. Each service evolution comprises one or more service changes, with each change describing a
specific modification and its corresponding impact on service consumers.
A service is an independent and modular component and it can be accessed only by interfaces. For this reason,
the functional capability of a service is expressed using service operations, where each service operation
denotes an execution action of the service. Each service is comprised of zero, one or more service operations.
Each service operation is described with zero or one precondition, with zero or one post condition and with
zero or one exit condition. A precondition specifies a constraint that must be true when a service operation
is invoked. A postcondition specifies a constraint that must be true at the completion of a service operation,
and an exit condition specifies a constraint that, if true, causes an operation to finish unsuccessfully. Each
precondition, each postcondition and each exit condition is defined using one and only one expression,
which may be a composite expression or an atomic expression. Each service operation is also described with
zero, one or more input messages and with zero, one or more output messages. Each input message specifies
information that the operation needs for its execution. Each output message specifies information that the
operation generates after its successful execution. Each message type provides a description of a message or
a set of messages, where each of these messages is consumed or generated during the execution of a service
operation. Each input message is constrained by zero, one or more preconditions and each output message
is constrained by zero, one or more post conditions. Each service operation has a distinct invocation way,
which involves the communication protocol, message exchange pattern, and message data format. Each
service can be annotated by zero, one or more user tags, each of which may be created by any person using
the service.
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
NOTE Metaclasses whose names are italicized are abstract metaclasses.
Figure 2 — Metamodel of MFI service model registration
6.2 Associations between MFI Service model registration and other parts in MFI
Figure 3 shows the associations between MFI Service model registration (this document) and MFI Role and
Goal model registration and MFI Process model registration.
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
Key
metaclasses from other parts of MFI
Figure 3 — Associations between MFI Service model registration and MFI Process model
registration and MFI Role and Goal model registration
Each service achieves zero, one or more goals. Each goal is achieved by zero, one or more services. Each service
operation achieves zero, one or more goals. Each goal is achieved by zero, one or more service operations.
Each service operation can fully realize zero, one or more processes. Each process is fully realized by zero,
one or more service operations. Each service involves zero, one or more service involvements, where each
service involvement is the involvement of a role with a service, such as actor or beneficiary. Each service
involvement indicates that a role is involved in the execution of one and only one service.
The association between the metaclasses in MFI Service model registration and the metaclasses in MFI Core
and mapping is shown in Figure 4.
Service_Description_Language in MFI Service model registration is a subclass of Modelling_Language in
MFI Core and mapping. Service_Model in MFI Service model registration is a subclass of Model in MFI Core
and mapping. All the remaining metaclasses are subclasses of Model_Element in MFI Core and mapping.
All subclasses have the associations which are inherited from their superclass. Some inherited associations
are specifications of associations specialized in MFI Core and mapping. The details of specialization are
defined in 6.3.
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
NOTE Metaclasses whose names are italicized are abstract metaclasses
Figure 4 — The associations between MFI Service model registration and MFI Core and mapping
6.3 Structure of MFI Service model registration
6.3.1 Service_Description_Language
Service_Description_Language is a metaclass each instance of which represents a language or a notation
that is used to model a service.
Superclass
Modelling_Language (from MFI Core and mapping)
Attribute DataType Multiplicity Description
name string 1.1 The name of this service description language
Reference Class Multiplicity Description Inverse Precedence
expressed_model Service_Model 0.* The set of service describing_ No
models that are language
described by this
service description
language. This
reference special-
izes the ‘describes’
reference which is
inherited from the
superclass
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
Constraints
[None]
6.3.2 Service_Model
Service_Model is a metaclass each instance of which represents a model that is used to model services that
can be modelled.
Superclass
Model (from MFI Core and mapping)
Attribute DataType Multiplicity Description
name string 1.1 The name of this service model
described_IRI string 0.1 The IRI that identifies the corresponding service
model
Reference Class Multiplicity Description Inverse Precedence
describing_language Service_ 1.1 The language or expressed_ Yes
Description_ notation that is model
Language used to model this
service. This ref-
erence specializes
the ‘described_by’
reference which is
inherited from the
superclass
contained_service Service 1.* The set of services, containing_ Yes
each of which is model
modelled by this
service model. This
reference special-
izes the ‘contains’
reference which is
inherited from the
superclass
Constraints
The value of attribute ‘described_IRI’ has to be unique in this metaclass.
6.3.3 Service
Service is a metaclass each instance of which represents a kind of web based application which encapsulates
one or more computing modules and can be accessed through a specified interface.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType Multiplicity Description
name string 1.1 The name of this service
requested_IRI string 1.1 The IRI for invoking this service
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
domain string 1.1 The domain that this service belongs to
service_type Service_Type 1.1 The type of this service
Reference Class Multiplicity Description Inverse Precedence
owned_qos_ QoS_Assertion 0.1 The QoS assertion asserted_service Yes
assertion that applies to this
service
contained_service_ Service_Operation 0.* The set of service containing_ Yes
operation operations, each of service
which denotes an
execution action of
this service
service_tag User_Tag 0.* The set of tags, tagged_service Yes
each of which is
annotated by an
individual or an or-
ganization in order
to describe this
service
composing_ service Service 0.* The set of services, composed_ Yes
each of which is a service
component of this
service
composed_ service Service 0.1 The composite ser- composing_ No
vice which contains service
this service
containing_model Service_Model 1.* The set of service contained_ No
models, each of service
which is used to
model this service.
This reference spe-
cializes the ‘con-
tained_by’ reference
which is inherited
from the superclass
evolved_evolution Service_Evolution 0.* The set of service evolving_ Yes
evolutions, each of service
which is used to de-
scribe an evolution
achieved_goal Goal 0.* The set of goals, achieving_ Yes
(from MFI Role each of which is service
and Goal model achieved by this
registration) service
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
involving_ service_ Service_ 0.* The set of service involved_ Yes
involvement Involvement involvement, each of service_
(from MFI Role which represents a involvement
and Goal model statement that spec-
registration) ifies how a particu-
lar role is involved in
this service
Constraints
The value of attribute “requested_IRI” has to be unique in this metaclass.
6.3.4 Service_Operation
Service_Operation is a metaclass each instance of which denotes the execution actions of a service.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType Multiplicity Description
name string 1.1 The name of this service operation
Reference Class Multiplicity Description Inverse Precedence
consumed_ Input_Message 0.* The set of messag- containing_ Yes
message es, each of which is service_
consumed by this operation
service operation for
its execution
generated_ Output_Message 0.* The set of messages, containing_ Yes
message each of which is gen- service_
erated by this service operation
operation after its
execution
contained_ Precondition 0.1 The constraint that containing_ Yes
precondition must be true when service_
this operation is operation
invoked
contained_ Postcondition 0.1 The constraint that containing_ Yes
postcondition must be true at the service_
completion of this operation
operation
contained_ Exit_Condition 0.1 The constraint that containing_ Yes
exit_condition must be true when service_
a service operation operation
exits abnormally
containing_ Service 1.1 The service that contained_ No
service contains this service service_
operation operation
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
used_invocation_ Invocation_Way 0.1 The invocation way containing_ Yes
way used by the service service_
operation operation
achieved_ goal Goal(from MFI 0.* The set of goals, achieving_ Yes
Role and Goal each of which is service_
model registra- achieved by this ser- operation
tion) vice operation
fully_realized_ Process(from 0.* The set of processes, fully_realizing_ser-Yes
process MFI Process each of which is fully vice_operation
model registra- realized by this ser-
tion) vice operation
Constraints
[None]
6.3.5 Service_Type
Service_Type is an enumerated datatype with the following values.
Value Description
entity_service Indicates that this service bases its functional boundary on one or more related organiza-
tion entities, such as customer, employee, invoice, and claim.
task_service Indicates that this service has a functional boundary directly associated with a process
model.
utility_service Indicates that this service provides reusable and cross-cutting utility functionality, such
as event logging, notification, and exception handling.
6.3.6 Service_Evolution
Service_Evolution is a metaclass that has information on the evolution of a service.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType Multiplicity Description
version_number string 1.1 The new version number of this evolution
description string 1.1 The description of this evolution
Reference Class Multiplicity Description Inverse Precedence
evolving_service Service 1.1 The service that evolved_evolution No
occurs this evolu-
tion
contained_ Service_Change 1.* The service containing_ Yes
service_change changes belonging service_
to this evolution evolution
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
previous_evolution Service_Evolution 0.1 The immediately next_evolution Yes
preceding version
of this evolution
next_evolution Service_Evolution 0.1 The next previous_evolution No
evolution that suc-
ceeds this version
Constraints
[None]
6.3.7 Service_Change
Service_Change is a metaclass that specifies the details of modifications occurring during a service evolution.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType Multiplicity Description
name string 1.1 The name of this service change
change_type Change_Type 1.1 The change type of this evolution
change_impact Change_Impact 1.1 The change impact of this evolution
change_detail string 0.1 The description of what specifically changed
Reference Class Multiplicity Description Inverse Precedence
containing_ Service_Evolution 1.1 The service evolution evolved_evolution No
service_ to which this change
evolution belongs
Constraints
[None]
6.3.8 Change_Impact
Change_Impact is an enumerated datatype with the following values.
Value Description
initial Indicates the initial introduction of a service or operation. It is not a modification of an
existing element but serves as the baseline version from which future changes will be
tracked.
major Indicates breaking changes that are not backward-compatible. Such changes often re-
quire substantial adjustments by service consumers, such as introducing a new version of
an API with different endpoints or data structures
minor Indicates additive changes that are backward-compatible. Such changes may add new
functionality or enhancements without breaking existing compatibility, such as adding a
new optional parameter to an existing API endpoint
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
patch Indicates bug fixes or small improvements that are backward-compatible. The change ad-
dresses minor fixes, such as fixing a bug in the service that caused crashes or optimizing
performance for a specific service operation
6.3.9 Change_Type
Change_Type is an enumerated datatype with the following values.
Value Description
initialization Indicates the initial registration of a service, capturing its baseline definition
when it is first registered into the registry.
service_name_change Indicates that the change involves modifying the name of a service, which may
affect how the service is identified and referenced by its consumers
input_output_change Indicates that the change involves adding, removing, or altering the input and
(or) output message of a service operation, which may affect the compatibility of
consumers relying on the existing input and (or) output format
operation_change Indicates that the change involves adding, removing, or altering operations
within a service, which may affect the service's functional boundary and its
interaction with consumers
protocol_change Indicates a change in the communication protocol (e.g., from REST to gRPC),
which may require significant client adaptation
endpoint_change Indicates that the service’s network address (e.g., URL or port) has changed,
affecting service accessibility and requiring updates to service registries or
clients
message_exchange_ Indicates that the change involves modifying the message exchange pattern
pattern_change used by the service, which may affect communication flows and interaction
semantics with consumers
message_data_format_ Indicates changes in the serialization format (e.g., from XML to JSON), impacting
change how clients parse or generate messages
QoS_change Indicates changes in QoS properties, which may affect service selection or con-
tractual guarantees
6.3.10 Invocation_Way
Invocation_Way is a metaclass that denotes the invocation way of a service.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType MultiplicityDescription
protocol string 1.1 The protocol used in this invocation
message_exchange_ string 1.1 The message exchange pattern used in this invocation
pattern
message_data_ string 1.1 The message data format used in this invocation
format
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
Reference Class MultiplicityDescription Inverse Precedence
containing_service_ Service_ 0.* The service operation u se d _ No
operation Operation that uses this invocation_way
invocation way
Constraints
[None]
6.3.11 Protocol
Protocol is an enumerated datatype with the following values.
Value Description
SOAP Indicates that the communication uses the Simple Object Access Protocol, a standardized
protocol for exchanging structured information in web services
REST Indicates that the communication follows the Representational State Transfer architec-
tural style
GRAPHQL Indicates that the communication uses GraphQL, a query language and runtime for APIs
that enables clients to request only the data they need
gRPC Indicates that the communication uses gRPC, a high-performance RPC (Remote Proce-
dure Call) framework based on HTTP/2
WebSocket Indicates that the communication uses WebSocket, a full-duplex communication protocol
over a single, long-lived TCP connection
6.3.12 Message_Exchange_Pattern
Message_Exchange_Pattern is an enumerated datatype with the following values.
Value Description
request-response Indicates a two-way interaction where the sender (service consumer) sends a re-
quest message to the service, and the service responds with a corresponding reply
message. This pattern is synchronous and typically used for operations requiring
immediate feedback or results
one-way Indicates a one-way interaction where the sender sends a message to the service
without expecting a response. This pattern is asynchronous and is often used for op-
erations where the sender does not require confirmation or further communication
publish-subscribe Indicates a pattern where the service (publisher) broadcasts messages to multiple
subscribers, which receive updates based on their subscriptions
6.3.13 Message_Data_Format
Message_Data_Format is an enumerated datatype with the following values.
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
Value Description
JSON Indicates that the message data is formatted using JavaScript Object Notation (JSON), a
lightweight, human-readable, and widely used data interchange format
XML Indicates that this service has a functional boundary directly associated with a process
model.
Protobuf Indicates that the message data is formatted using Protocol Buffers (Protobuf), a compact
binary serialization format
6.3.14 Message_Type
Message_Type is a metaclass each instance of which represents a data type of the me
...

ISO/IEC DISPRF 19763-7:2026(en)
ISO/IEC JTC 1/SC 32/WG 2
Secretariat: ANSI
Date: 2026-05-1908-18
Information technology — Metamodel framework for
interoperability (MFI) —
Part 7:
Metamodel for service model registration
Technologies de l'information — Cadre du métamodèle pour l'interopérabilité (MFI) —
Partie 7: Métamodèle pour l'enregistrement du modèle de service
FDIS stage
ISO/IEC PRF 19763-7:2026(en)
© ISO/IEC 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
EmailE-mail: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
ISO/IEC PRF 19763-7:2026(en)
Contents
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 3
5 Conformance . 4
5.1 General. 4
5.2 Degree of conformance . 4
5.3 Implementation Conformance Statement (ICS) . 5
6 MFI Service model registration. 5
6.1 Overview of MFI Service model registration. 5
6.2 Associations between MFI Service model registration and other parts in MFI . 6
6.3 Structure of MFI Service model registration . 8
Annex A (informative) List of existing service description languages . 23
Annex B (informative) Examples . 24
Bibliography . 75

© ISO/IEC 2026 – All rights reserved
iii
ISO/IEC PRF 19763-7:2026(en)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members
of ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC
Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC have not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent database
available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 32, Data management and interchange.
This second edition cancels and replaces the first edition (ISO/IEC 19763-7:2015), which has been technically
revised.
The main changes are as follows:
— — Additional metaclasses have been introduced in the metamodel of MFI service model registration to
support registration of heterogeneous services using multiple protocols, including Invocation_Way,
Message_Exchange_Pattern, Protocol, and Message_Data_Format.
— — Additional metaclasses have been introduced in the metamodel of MFI service model registration to
support registration of service evolution, including Service_Evolution, Service_Change, Change_Type, and
Change_Impact.
— Annex B— Annex B has been updated, providing registration examples, including an OpenAPI service
registration example and a PROTO3 service registration example.
A list of all parts in the ISO/IEC 19763 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© ISO/IEC 2026 – All rights reserved
iv
ISO/IEC PRF 19763-7:2026(en)
Introduction
With the rapid development of Service Oriented Computing (SOC), more and more computing resources are
presented in the form of web services. Meanwhile, business integration based on web services is becoming a
popular application development method. A web service is a kind of Web based application that encapsulates
one or more computing modules and is designed to support interoperable machine-to-machine interaction
over a network.
In Web Service registration and management, ebXML RegRep is a standard defining the Service interface,
protocols and information model for an integrated registry and repository, which provides basic support for
publishing and discovering Web Services within and across enterprises. Nevertheless, keyword matching is
the basic service discovery method in ebXML RegRep, thus the discovery results will be inevitably inaccurate,
and the discovery process will be time-consuming. When business information interchange and integration
becomes increasingly frequent, major work in web service discovery should be processed by machine. This
shift necessitates the semantic description of administrative and evolution-related metadata of services, along
with the provision of corresponding registration and management mechanisms. Moreover, with the rapid
growth of service networks and service ecosystems, where large numbers of heterogeneous services coexist
and dynamically evolve, the demand for interoperability becomes increasingly critical. Services characterized
by more diverse communication protocols, description languages, message exchange patterns, and data
formats must be capable of sharing and interaction. To support this, service registration frameworks must be
enhanced to ensure that services can be discovered, composed, and evolved within highly dynamic and diverse
digital ecosystems.
This document intends to provide a generic framework for registering administrative and evolution
information about web services in an explicit way. The relationship between MFI service model registration,
the service registry, and service models expressed in different service description languages is illustrated in
Figure 1Figure 1.
Key
Key reference Description
service model
metadata about service
© ISO/IEC 2026 – All rights reserved
v
ISO/IEC PRF 19763-7:2026(en)
Key
service model
metadata about service
NOTE : Not every model needs to exist in a repository before registration
Figure 1 — Scope of MFI Service model registration
© ISO/IEC 2026 – All rights reserved
vi
ISO/IEC PRF 19763-7:2026(en)
Information technology — Metamodel framework for interoperability
(MFI) —
Part 7:
Metamodel for service model registration
1 Scope
The primary purpose of the ISO/IEC 19763 series is to specify a metamodel framework for interoperability.
This document specifies a metamodel for registering administrative and evolution information of models of
services, facilitating interoperability through the reuse of services.
This document is only applicable to web services whose capabilities are described by some web service
Figure 1 shows the scope
description language (see Annex AAnnex A for examples of such languages). Figure 1
of this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 19763--3, Information technology — Metamodel framework for interoperability (MFI) — Part 3:
Metamodel for ontology registration
ISO/IEC 19763--5, Information technology — Metamodel framework for interoperability (MFI) — Part 5:
Metamodel for process model registration
ISO/IEC 19763--8, Information technology — Metamodel framework for interoperability (MFI) — Part 8:
Metamodel for role and goal model registration
ISO/IEC 19763--10, Information technology — Metamodel framework for interoperability (MFI) — Part 10:
Core model and basic mapping
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19763-3, ISO/IEC 19763-5,
ISO/IEC 19763-8, ISO/IEC 19763-10 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— — ISO Online browsing platform: available at https://www.iso.org/obp
— — IEC Electropedia: available at https://www.electropedia.org/
3.1 3.1
service
kind of application which encapsulates one or more computing modules and can be accessed through a
specified interface
3.2 3.2
service operation
execution action of a service (3.1(3.1))
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
3.3 3.3
expression
sentence which is expressed using a logical notation to specify either a condition that applies to a service
operation (3.2(3.2)) or a QoS assertion (3.13(3.13)) that applies to a service (3.1(3.1))
3.4 3.4
atomic expression
logical expression (3.3(3.3)) that has the unit granularity
3.5 3.5
composite expression
logical expression (3.3(3.3)) that comprises multiple atomic expressions (3.4(3.4)) and (or) other composite
expressions (3.5(3.5)) by using connectives such as conjunction, disjunction and negation
Note 1 to entry: Models can be used to express a set of information requirements, processes, services, roles, goals or some
other aspect of a domain of interest.
3.6 3.6
precondition
constraint that must be true when an operation is invoked
Note 1 to entry: The operation can be a process or service operation (3.2(3.2).).
3.7 3.7
postcondition
constraint that must be true at the completion of an operation
Note 1 to entry: The operation can be a process or service operation (3.2(3.2).).
3.8 3.8
exit condition
constraint that, if true, causes an operation to finish unsuccessfully
Note 1 to entry: The operation can be a process or service operation (3.2(3.2).).
3.9 3.9
message type
type of the message or a set of messages that is (are) consumed or generated during the execution of a service
operation (3.2(3.2))
3.10 3.10
input message
information contained in the message that the service operation (3.2(3.2)) consumes for its execution
3.11 3.11
output message
information contained in the message that the service operation (3.2(3.2)) generates after its execution
3.12 3.12
QoS type
specified non-functional property for a service (3.1(3.1),), such as availability, response time, etc
3.13 3.13
QoS assertion
specification of one or more QoS types (3.12(3.12)) for the service (3.1(3.1))
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
3.14 3.14
web service
kind of service (3.1(3.1)) that is designed to support interoperable machine-to-machine interaction over a
network
3.15 3.15
entity service
webservice (3.14web service (3.14)) that bases its functional boundary on one or more related organization
entities, such as customer, employee, invoice and claim
3.16 3.16
task service
web service (3.14(3.14)) with a functional boundary directly associated with a process model
3.17 3. 17
utility service
web service (3.14(3.14)) that is dedicated to providing reusable, cross-cutting utility functionality, such as
event logging, notification, and exception handling
3.18 3.18
service evolution
changes in the functional or non-functional properties of a service (3.1(3.1)) that occur throughout the lifecycle
of the service (3.1(3.1))
Note 1 to entry: Such changes include, but are not limited to, modifications to its computing modules, interfaces,
communication protocols, message exchange patterns, or data formats.
3.19 3.19
user tag
tag annotated by an individual or organization in order to describe the service (3.1(3.1)) according to the
understanding of the creator of the tag
4 Abbreviated terms
ebXML RegRep ebXML Registry and Repository
GraphQL Graph Query Language
gRPC Google Remote Procedure Call
IRI Internationalized Resource Identifier

MFI Core and Core model and basic mapping (see ISO/IEC 19763-10)
mapping
MFI Process Metamodel for process model registration (see ISO/IEC 19763-
model registration 5)
MFI Role and Metamodel for role and goal model registration (see
Goal model registration ISO/IEC 19763-8)
MFI Service Metamodel for service model registration (see ISO/IEC 19763-7)
model registration
OWL-S Web Ontology Language for Services
QoS Quality of Service
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
REST Representational State Transfer
SOAP Simple Object Access Protocol
SWRL Semantic Web Rule Language
SWSL Semantic Web Service Language
WADL Web Application Description Language
WSDL Web Service Description Language
WSML Web Service Modelling Language
5 Conformance
5.1 General
An implementation claiming conformance with this document shall support the metamodel specified in
Clause 6Clause 6,, depending on a degree of conformance as described in 5.25.2.
5.2 Degree of conformance
5.2.1 General
The distinction between ‘strictly conforming’ and ‘conforming’ implementations is necessary to address the
simultaneous needs for interoperability and extensions. This document describes specifications that promote
interoperability. Extensions are motivated by needs of users, vendors, institutions and industries, but are not
specified by this document.
A strictly conforming implementation may be limited in usefulness but is maximally interoperable with
respect to this document. A conforming implementation may be more useful, but may be less interoperable
with respect to this document.
5.2.2 Strictly conforming implementation
A strictly conforming implementation:
a) a) shall support the metamodel specified in Clause 6Clause 6;;
b) b) shall not use, test, access, or probe for any extension features nor extensions to the metamodel
specified in Clause 6Clause 6.
5.2.3 Conforming implementation
A conforming implementation:
a) a) shall support the metamodel specified in Clause 6Clause 6;;
b) b) as permitted by the implementation, may use, test, access, or probe for any extension features
or extensions to the metamodel specified in Clause 6Clause 6.
NOTE 1 All strictly conforming implementations are also conforming implementations.
NOTE 2 The use of extensions to the metamodel can cause undefined behaviour.
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
5.3 Implementation Conformance Statement (ICS)
An implementation claiming conformance with this document shall include an Implementation Conformance
Statement stating:
a) a) whether it is a strictly conforming implementation in 5.2.25.2.2 or a conforming
implementation in 5.2.35.2.3;;
b) b) what extensions, if any, are supported or used if it is a conforming implementation.
6 MFI Service model registration
6.1 Overview of MFI Service model registration
This part of MFI specifies the metamodel that can be used to register functional and non-functional
information about web services (hereafter referred to simply as “services”). Examples of some service
description languages that can be registered using this metamodel are listed in Annex AAnnex A.
Figure 2Figure 2 shows the metamodel for the registration of services. This metamodel allows the registration
of the common functional and non-functional features of services described using a number of service
description languages. Each service model, expressed using a specific service description language, may
describe one or more services. Each service is comprised of one or more service operations. Each service is
described by zero or one QoS assertion. This QoS assertion is used to represent the quantitative or qualitative
non-functional features of the service, such as response time, cost, reliability, etc. Each QoS assertion is defined
using one and only one expression, which may be a composite expression or an atomic expression. Each QoS
assertion is of one or more QoS types. Each service undergoes multiple service evolutions throughout its
lifecycle. Each service evolution comprises one or more service changes, with each change describing a specific
modification and its corresponding impact on service consumers.
A service is an independent and modular component and it can be accessed only by interfaces. For this reason,
the functional capability of a service is expressed using service operations, where each service operation
denotes an execution action of the service. Each service is comprised of zero, one or more service operations.
Each service operation is described with zero or one precondition, with zero or one post condition and with
zero or one exit condition. A precondition specifies a constraint that must be true when a service operation is
invoked. A postcondition specifies a constraint that must be true at the completion of a service operation, and
an exit condition specifies a constraint that, if true, causes an operation to finish unsuccessfully. Each
precondition, each postcondition and each exit condition is defined using one and only one expression, which
may be a composite expression or an atomic expression. Each service operation is also described with zero,
one or more input messages and with zero, one or more output messages. Each input message specifies
information that the operation needs for its execution. Each output message specifies information that the
operation generates after its successful execution. Each message type provides a description of a message or
a set of messages, where each of these messages is consumed or generated during the execution of a service
operation. Each input message is constrained by zero, one or more preconditions and each output message is
constrained by zero, one or more post conditions. Each service operation has a distinct invocation way, which
involves the communication protocol, message exchange pattern, and message data format. Each service can
be annotated by zero, one or more user tags, each of which may be created by any person using the service.
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
NOTE Metaclasses whose names are italicized are abstract metaclasses.
Figure 2 — Metamodel of MFI service model registration
6.2 Associations between MFI Service model registration and other parts in MFI
Figure 3Figure 3 shows the associations between MFI Service model registration (this document) and MFI
Role and Goal model registration and MFI Process model registration.
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
Key
Key reference Description
Metaclasses from other parts of MFI

metaclasses from other parts of MFI

Figure 3 — The Associations between MFI Service model registration and MFI Process model
registration and MFI Role and Goal model registration
Each service achieves zero, one or more goals. Each goal is achieved by zero, one or more services. Each service
operation achieves zero, one or more goals. Each goal is achieved by zero, one or more service operations.
Each service operation can fully realize zero, one or more processes. Each process is fully realized by zero, one
or more service operations. Each service involves zero, one or more service involvements, where each service
involvement is the involvement of a role with a service, such as actor or beneficiary. Each service involvement
indicates that a role is involved in the execution of one and only one service.
The association between the metaclasses in MFI Service model registration and the metaclasses in MFI Core
and mapping is shown in Figure 4Figure 4.
Service_Description_Language in MFI Service model registration is a subclass of Modelling_Language in MFI
Core and mapping. Service_Model in MFI Service model registration is a subclass of Model in MFI Core and
mapping. All the remaining metaclasses are subclasses of Model_Element in MFI Core and mapping.
All subclasses have the associations which are inherited from their superclass. Some inherited associations
are specifications of associations specialized in MFI Core and mapping. The details of specialization are defined
in 6.36.3.
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
NOTE Metaclasses whose names are italicized are abstract metaclasses
Figure 4 — The associations between MFI Service model registration and MFI Core and mapping
6.3 Structure of MFI Service model registration
6.3.1 Service_Description_Language
Service_Description_Language is a metaclass each instance of which represents a language or a notation that
is used to model a service.
Superclass
Modelling_Language (from MFI Core and mapping)
Attribute DataType Multiplicity Description
name string 1.1 The name of this service description language
Reference Class Multiplicity Description Inverse Precedence
expressed_model Service_Model 0.* The set of service describing_ No
models that are language
described by this
service description
language. This
reference
specializes the
‘describes’
reference which is
inherited from the
superclass
Constraints
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
[None]
6.3.2 Service_Model
Service_Model is a metaclass each instance of which represents a model that is used to model services that can
be modelled.
Superclass
Model (from MFI Core and mapping)
Attribute DataType Multiplicity Description
name string 1.1 The name of this service model
described_IRI string 0.1 The IRI that identifies the corresponding service
model
Reference Class Multiplicity Description Inverse Precedence
describing_language Service_ 1.1 The language or expressed_ Yes
Description_ notation that is used model
Language to model this
service. This
reference specializes
the ‘described_by’
reference which is
inherited from the
superclass
contained_service Service 1.* The set of services, containing_ Yes
each of which is model
modelled by this
service model. This
reference specializes
the ‘contains’
reference which is
inherited from the
superclass
Constraints
The value of attribute ‘described_IRI’ has to be unique in this metaclass.
6.3.3 Service
Service is a metaclass each instance of which represents a kind of web based application which encapsulates
one or more computing modules and can be accessed through a specified interface.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType Multiplicity Description
name string 1.1 The name of this service
requested_IRI string 1.1 The IRI for invoking this service
domain string 1.1 The domain that this service belongs to
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
service_type Service_Type 1.1 The type of this service
Reference Class Multiplicity Description Inverse Precedence
owned_qos_ QoS_Assertion 0.1 The QoS assertion asserted_service Yes
assertion that applies to this
service
contained_service_ Service_Operation 0.* The set of service containing_ Yes
operation operations, each of service
which denotes an
execution action of
this service
service_tag User_Tag 0.* The set of tags, tagged_service Yes
each of which is
annotated by an
individual or an
organization in
order to describe
this service
composing_ service Service 0.* The set of services, composed_ Yes
each of which is a service
component of this
service
composed_ service Service 0.1 The composite composing_ No
service which service
contains this service
containing_model Service_Model 1.* The set of service contained_ No
models, each of service
which is used to
model this service.
This reference
specializes the
‘contained_by’
reference which is
inherited from the
superclass
evolved_evolution Service_Evolution 0.* The set of service evolving_ Yes
evolutions, each of service
which is used to
describe an
evolution
achieved_goal Goal 0.* The set of goals, each achieving_ Yes
(from MFI Role of which is achieved service
and Goal model by this service
registration)
involving_ service_ Service_ 0.* The set of service involved_ Yes
involvement Involvement involvement, each of service_
(from MFI Role which represents a involvement
and Goal model statement that
registration) specifies how a
particular role is
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
involved in this
service
Constraints
The value of attribute “requested_IRI” has to be unique in this metaclass.
6.3.4 Service_Operation
Service_Operation is a metaclass each instance of which denotes the execution actions of a service.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType Multiplicity Description
name string 1.1 The name of this service operation
Reference Class Multiplicity Description Inverse Precedence
consumed_ Input_Message 0.* The set of messages, containing_ Yes
message each of which is service_
consumed by this operation
service operation for
its execution
generated_ Output_Messag 0.* The set of messages, containing_ Yes
message e each of which is service_
generated by this operation
service operation
after its execution
contained_ Precondition 0.1 The constraint that containing_ Yes
precondition must be true when service_
this operation is operation
invoked
contained_ Postcondition 0.1 The constraint that containing_ Yes
postcondition must be true at the service_
completion of this operation
operation
contained_ Exit_Condition 0.1 The constraint that containing_ Yes
exit_condition must be true when a service_
service operation operation
exits abnormally
containing_ Service 1.1 The service that contained_ No
service contains this service service_
operation operation
used_invocation_ Invocation_Way 0.1 The invocation way containing_ Yes
way used by the service service_
operation operation
achieved_ goal Goal(from MFI 0.* The set of goals, achieving_ Yes
Role and Goal each of which is service_
model achieved by this operation
registration) service operation
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
fully_realized_ Process(from 0.* The set of processes, fully_realizing_serv Yes
process MFI Process each of which is fully ice_operation
model realized by this
registration) service operation
Constraints
[None]
6.3.5 Service_Type
Service_Type is an enumerated datatype with the following values.
Value Description
entity_service Indicates that this service bases its functional boundary on one or more related
organization entities, such as customer, employee, invoice, and claim.
task_service Indicates that this service has a functional boundary directly associated with a process
model.
utility_service Indicates that this service provides reusable and cross-cutting utility functionality, such as
event logging, notification, and exception handling.
6.3.6 Service_Evolution
Service_Evolution is a metaclass that has information on the evolution of a service.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType Multiplicity Description
version_number string 1.1 The new version number of this evolution
description string 1.1 The description of this evolution
Reference Class Multiplicity Description Inverse Precedence
evolving_service Service 1.1 The service that evolved_evolution No
occurs this
evolution
contained_ Service_Change 1.* The service containing_ Yes
service_change changes belonging service_
to this evolution evolution
previous_evolution Service_Evolution 0.1 The immediately next_evolution Yes
preceding version
of this evolution
next_evolution Service_Evolution 0.1 The next previous_evolution No
evolution that
succeeds this
version
Constraints
[None]
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
6.3.7 Service_Change
Service_Change is a metaclass that specifies the details of modifications occurring during a service evolution.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType Multiplicity Description
name string 1.1 The name of this service change
change_type Change_Type 1.1 The change type of this evolution
change_impact Change_Impact 1.1 The change impact of this evolution
change_detail string 0.1 The description of what specifically changed
Reference Class Multiplicity Description Inverse Precedence
containing_ Service_Evolution 1.1 The service evolution evolved_evolution No
service_ to which this change
evolution belongs
Constraints
[None]
6.3.8 Change_Impact
Change_Impact is an enumerated datatype with the following values.
Value Description
initial Indicates the initial introduction of a service or operation. It is not a modification of an
existing element but serves as the baseline version from which future changes will be
tracked.
major Indicates breaking changes that are not backward-compatible. Such changes often require
substantial adjustments by service consumers, such as introducing a new version of an API
with different endpoints or data structures
minor Indicates additive changes that are backward-compatible. Such changes may add new
functionality or enhancements without breaking existing compatibility, such as adding a
new optional parameter to an existing API endpoint
patch Indicates bug fixes or small improvements that are backward-compatible. The change
addresses minor fixes, such as fixing a bug in the service that caused crashes or optimizing
performance for a specific service operation
6.3.9 Change_Type
Change_Type is an enumerated datatype with the following values.
Value Description
initialization Indicates the initial registration of a service, capturing its baseline definition
when it is first registered into the registry.
service_name_change Indicates that the change involves modifying the name of a service, which may
affect how the service is identified and referenced by its consumers
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
input_output_change Indicates that the change involves adding, removing, or altering the input and
(or) output message of a service operation, which may affect the compatibility of
consumers relying on the existing input and (or) output format
operation_change Indicates that the change involves adding, removing, or altering operations
within a service, which may affect the service's functional boundary and its
interaction with consumers
protocol_change Indicates a change in the communication protocol (e.g., from REST to gRPC),
which may require significant client adaptation
endpoint_change Indicates that the service’s network address (e.g., URL or port) has changed,
affecting service accessibility and requiring updates to service registries or
clients
message_exchange_ Indicates that the change involves modifying the message exchange pattern used
pattern_change by the service, which may affect communication flows and interaction semantics
with consumers
message_data_format_chan Indicates changes in the serialization format (e.g., from XML to JSON), impacting
ge how clients parse or generate messages
QoS_change Indicates changes in QoS properties, which may affect service selection or
contractual guarantees
6.3.10 Invocation_Way
Invocation_Way is a metaclass that denotes the invocation way of a service.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType Multiplicity Description
protocol string 1.1 The protocol used in this invocation
message_exchange_ string 1.1 The message exchange pattern used in this invocation
pattern
message_data_ string 1.1 The message data format used in this invocation
format
Reference Class Multiplicity Description Inverse Precedence
containing_service_ Service_ 0.* The service operation used_ No
operation Operation that uses this invocation_way
invocation way
Constraints
[None]
6.3.11 Protocol
Protocol is an enumerated datatype with the following values.
Value Description
SOAP Indicates that the communication uses the Simple Object Access Protocol, a standardized
protocol for exchanging structured information in web services
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
REST Indicates that the communication follows the Representational State Transfer
architectural style
GRAPHQL Indicates that the communication uses GraphQL, a query language and runtime for APIs
that enables clients to request only the data they need
gRPC Indicates that the communication uses gRPC, a high-performance RPC (Remote Procedure
Call) framework based on HTTP/2
WebSocket Indicates that the communication uses WebSocket, a full-duplex communication protocol
over a single, long-lived TCP connection
6.3.12 Message_Exchange_Pattern
Message_Exchange_Pattern is an enumerated datatype with the following values.
Value Description
request-response Indicates a two-way interaction where the sender (service consumer) sends a request
message to the service, and the service responds with a corresponding reply message.
This pattern is synchronous and typically used for operations requiring immediate
feedback or results
one-way Indicates a one-way interaction where the sender sends a message to the service
without expecting a response. This pattern is asynchronous and is often used for
operations where the sender does not require confirmation or further
communication
publish-subscribe Indicates a pattern where the service (publisher) broadcasts messages to multiple
subscribers, which receive updates based on their subscriptions
6.3.13 Message_Data_Format
Message_Data_Format is an enumerated datatype with the following values.
Value Description
JSON Indicates that the message data is formatted using JavaScript Object Notation (JSON), a
lightweight, human-readable, and widely used data interchange format
XML Indicates that this service has a functional boundary directly associated with a process
model.
Protobuf Indicates that the message data is formatted using Protocol Buffers (Protobuf), a compact
binary serialization format
6.3.14 Message_Type
Message_Type is a metaclass each instance of which represents a data type of the message that is consumed
or generated for the execution of a service operation.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType Multiplicity Description
name string 1.1 The name of this message type
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
message_type_ string 0.1 The description of this message type
description
Reference Class Multiplicity Description Inverse Precedence
involving_input_ Input_Message 0.* The set of input involved_ No
message messages, each of input_
which is described message_
by this message type
type
involving_output_ Output_Message 0.* The set of output involved_ No
message messages, each of output_
which is described message_type
by this message
type
Constraints
[None]
6.3.15 Input_Message
Input_Message is a metaclass each instance of which specifies information contained in the message that the
service operation consumes for its execution.
Superclass
Model_Element (from MFI Core and mapping)
Attribute Datatype Multiplicity Description
name string 1.1 The name of the message that is consumed for the
execution of a service operation
Reference Class Multiplicity Description Inverse Precedence
containing_ Service_Operation 1.1 The service operation consumed_ No
service_ that consumes this message
operation input message
constraining_precPrecondition 0.* The set of constrained_input Yes
ondition preconditions, each of
which constrains this
input message when
the service operation
is invoked
involved_input_mMessage_Type 0.1 The type of this input involving_ Yes
essage_type message input_message
Constraints
[None]
6.3.16 Output_Message
Output_Message is a metaclass each instance of which specifies information contained in the message that the
service operation generates after its execution.
Superclass
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
Model_Element (from MFI Core and mapping)
Attribute DataType Multiplicity Description
name string 1.1 The name of the message that is generated after the
execution of a service operation
Reference Class Multiplicity Description Inverse Precedence
containing_ Service_Operation 1.1 The service operation generated_mesNo
service_ that generates this sage
operation output message
constraining_ Postcondition 0.* The set of constrained_o Yes
postcondition postconditions, each of utput
which constrains this
output message when
the service operation is
invoked
involved_output_ Message_Type 0.1 The type of this output involving_ Yes
message_type message output_
message
Constraints
[None]
6.3.17 Expression
Expression is an abstract metaclass which represents a sentence that is expressed using a logical notation to
specify either a condition that applies to a service operation or a QoS that applies to a service.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType Multiplicity Description
notation string 1.* The logic language or notation that is used to declare a
quality assertion, a precondition, a postcondition or an
exit condition of a service
Reference Class Multiplicity Description Inverse Precedence
expressed_ Precondition 0.* The constraint that precondition_ No
precondition must be true when an logical_
operation is invoked expression
expressed_ Postcondition 0.* The constraint that postcondition_ No
postcondition must be true at the logical_
completion of an expression
operation
expressed_ Exit_Condition 0.* The constraint that exit_condition_ No
exit_condition must be true when a logical_
service operation exits expression
abnormally
expressed_ QoS_Assertion 0.* The specification of one qos_logical_ No
qos_assertion or more QoS types for expression
the service
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
composed_ Composite_Ex 0.1 The composite composing_ Yes
expression pression expression of which expression
this expression forms
one of the elements of
that composite
expression
Constraints
[None]
6.3.18 Atomic_Expression
Atomic_Expression is a metaclass each instance of which represents a logical expression that has the unit
granularity.
Superclass
Expression
Attribute Datatype Multiplicity Description
expression_text string 1.1 The text of logical expression which is described by a
kind of notation of expression
Reference Class Multiplicity Description Inverse Precedence
[None]
Constraints
[None]
6.3.19 Composite_Expression
Composite_Expression is a metaclass each instance of which represents a logical expression that comprises
multiple atomic expressions and/or other composite expressions by using composition types such as
conjunction, disjunction and negation.
Superclass
Expression
Attribute Datatype Multiplicity Description
composition_ string 1.1 The symbol which is used to connect two or more logical
type expressions
Reference Class Multiplicity Description Inverse Precedence
composing_ Expression 1.* The set of expressions composed_ Yes
expression that comprise this expression
composite expression
Constraints
The value of composition_type must be one of ‘conjunction’, ‘disjunction’ or ‘negation’.
6.3.20 Composition_Type
Composition_Type is an enumerated datatype with the following values.
© ISO/IEC 2026 – All rights reserved
ISO/IEC PRF 19763-7:2026(en)
Value Description
conjunction An indication that the composite expression is true only in the case when all of the
expressions that comprise this composite expression are true.
disjunction An indication that the com
...