ISO/IEC 19763-7:2015

INTERNATIONAL ISO/IEC
STANDARD 19763-7
First edition
2015-10-15
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
Reference number
©
ISO/IEC 2015
© ISO/IEC 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviated terms . 4
4 Conformance . 5
4.1 General . 5
4.2 Degree of conformance . 5
4.2.1 General . 5
4.2.2 Strictly conforming implementation . 5
4.2.3 Conforming implementation . 5
4.3 Implementation Conformance Statement (ICS) . 5
5 MFI Service model registration . 6
5.1 Overview of MFI Service model registration . 6
5.2 Associations between MFI Service model registration and other parts in MFI . 7
5.3 Structure of MFI Service model registration . 8
5.3.1 Atomic_Expression . 8
5.3.2 Composite_Expression . 9
5.3.3 Exit_Condition . 9
5.3.4 Expression . 10
5.3.5 Input_Message . 11
5.3.6 Message_Type . 11
5.3.7 Output_Message . 12
5.3.8 Postcondition . 13
5.3.9 Precondition . 13
5.3.10 QoS_Assertion . 14
5.3.11 QoS_Type . 14
5.3.12 Service . 15
5.3.13 Service_Description_Language . 16
5.3.14 Service_Model . 16
5.3.15 Service_Operation . 17
5.3.16 Service_Type . 18
5.3.17 User_Tag . 18
Annex A (informative) List of existing service description languages . 19
Annex B (informative) Examples . 20
Bibliography . 35

© ISO/IEC 2015 – All rights reserved iii

Figures
Figure 1 — Scope of MFI Service model registration . 1
Figure 2 —Metamodel of MFI service model registration . 6
Figure 3 —The associations between MFI Service model registration and MFI Process model registration and

MFI Role and Goal model registration . 7
Figure 4 —The associations between MFI Service model registration and MFI Core and mapping . 8
Figure B.1 –The service model of Hotel_Reservation in WSDL 2.0 notation (fragment) (Part 1 of 2) . 21
Figure B.1 –The service model of Hotel_Reservation in WSDL 2.0 notation (fragment) (Part 2 of 2) . 22
Figure B.2 –Registration of the Hotel_Reservation example . 23
Figure B.3 –The service model of Book_Ticket in WSML notation (fragment) . 24
Figure B.4 –Registration of the Book_Ticket example (Part 1 of 2) . 25
Figure B.4 –Registration of the Book_Ticket example (Part 2 of 2) . 26
Figure B.5 –The service model of Search_item in WADL notation (fragment) . 27
Figure B.6 –Registration of the Search_Item example . 28
Figure B.7 –The service model of Congo_BookBuying_Agent in OWL-S notation (fragment) (Part 1 of 4) . 29
Figure B.7 –The service model of Congo_BookBuying_Agent in OWL-S notation (fragment) (Part 2 of 4) . 30
Figure B.7 – The service model of Congo_BookBuying_Agent in OWL-S notation (fragment) (Part 3 of 4) . 31
Figure B.7 – The service model of Congo_BookBuying_Agent in OWL-S notation (fragment) (Part 4 of 4) . 32
Figure B.8 –Registration of the Congo_BookBuying_Agent example (Part 1 of 2) . 33
Figure B.8 –Registration of the Congo_BookBuying_Agent example (Part 2 of 2) . 34

Tables
Table A.1 - List of existing service description languages . 19

iv © ISO/IEC 2015 – All rights reserved

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. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
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).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on the ISO
list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT),
see the following URL: Foreword — Supplementary information.
ISO/IEC 19763-7 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information Technology,
Subcommittee SC 32, Data management and Interchange.
ISO/IEC 19763 consists of the following parts, under the general title Information technology — Metamodel
framework for interoperability (MFI):
 Part 1: Framework
 Part 3: Metamodel for ontology registration
 Part 5: Metamodel for process model registration
 Part 6: Registry summary
 Part 7: Metamodel for service model registration
 Part 8: Metamodel for role and goal model registration
 Part 9: On demand model selection [Technical Report]
 Part 10: Core model and basic mapping
 Part 12: Metamodel for information model registration
 Part 13: Metamodel for form design registration
© ISO/IEC 2015 – All rights reserved v

Introduction
With the rapid development of SOC (Service Oriented Computing), 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 which
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 machines. It is,
therefore, necessary to semantically describe service information, including functional and non-functional
information, and provide corresponding registration and management mechanism.
This part of ISO/IEC 19763 provides a framework for registering generic functional and non-functional
information about web services.

vi © ISO/IEC 2015 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 19763-7:2015(E)

Information technology — Metamodel framework for
interoperability (MFI) — Part 7: Metamodel for service model
registration
1 Scope
The primary purpose of the multipart standard ISO/IEC 19763 is to specify a metamodel framework for
interoperability. This part of ISO/IEC 19763 specifies a metamodel for registering models of services,
facilitating interoperability through the reuse of services.
This part of ISO/IEC 19763 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 part of ISO/IEC 19763.
NOTE: Not every model needs to exist in a repository before registration
Figure 1 — Scope of MFI Service model registration
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its
application. For dated references, only the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments) applies.
© ISO/IEC 2015 – All rights reserved 1

NOTE  One or more terms and definitions of the referenced International Standards listed below are used in Clause 3 Terms and
Definitions.
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, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1.1
atomic expression
logical expression (3.1.5) that is not decomposed
3.1.2
composite expression
logical expression (3.1.5) that comprises multiple atomic expressions (3.1.1) and/or other composite
expressions (3.1.2) by using connectives such as conjunction, disjunction and negation
3.1.3
entity service
web service (3.1.22) that bases its functional boundary on one or more related organization entities, such as
customer, employee, invoice and claim
3.1.4
exit condition
constraint that, if true, will cause an operation to finish unsuccessfully
NOTE The operation can be a process or a service operation
3.1.5
expression
sentence which is expressed using a logical notation to specify either a condition that applies to a service
operation (3.1.18) or a quality of service (3.1.17) that applies to a service
3.1.6
goal
intended outcome of user interaction with a process (3.1.13) or service (3.1.17)
[ISO/IEC 19763-8, 3.1.1]
3.1.7
input message
information contained in the message that a service operation (3.1.18) consumes for its execution
3.1.8
involvement type
statement that indicates the type of involvement of a role(3.1.16) with a process (3.1.13) or service (3.1.17)
NOTE Examples are performer, beneficiary, customer
2 © ISO/IEC 2015 – All rights reserved

[ISO/IEC 19763-8, 3.1.4]
3.1.9
message type
classification of the message or a set of messages that is/are consumed or generated during execution of a
service operation (3.1.18)
3.1.10
output message
information contained in the message that the service operation (3.1.18) generates after its execution
3.1.11
postcondition
constraint that must be true at the completion of an operation
NOTE The operation can be a process or a service operation
[ISO/IEC 14813-5:2010 B.1.116]
3.1.12
precondition
constraint that must be true when an operation is invoked
NOTE The operation can be a process or a service operation
[ISO/IEC 14813-5:2010 B.1.117]
3.1.13
process
collection of related, structured activities or tasks that achieve a particular goal (3.1.6)
[ISO/IEC 19763-5, 3.1.12]
3.1.14
QoS assertion
specification of one or more QoS types (3.1.15) for the service (3.1.17)
3.1.15
QoS type
specified non-functional property for a service (3.1.17), such as availability, response time, etc
3.1.16
role
named specific behaviour of an entity participating in a particular context
[ISO/IEC 19763-8, 3.1.7]
3.1.17
service
application which encapsulates one or more computing modules and can be accessed through a specified
interface
3.1.18
service operation
execution action of a service (3.1.17)
3.1.19
task service
web service (3.1.22) with a functional boundary directly associated with a process model
© ISO/IEC 2015 – All rights reserved 3

3.1.20
user tag
tag annotated by an individual or organization in order to describe the service (3.1.17) according to the
understanding of the creator of the tag
3.1.21
utility service
web service (3.1.22) that is dedicated to provide reusable, cross-cutting utility functionality, such as event
logging, notification, and except handling
3.1.22
web service
service (3.1.17) that is designed to support interoperable machine-to-machine interaction over a network
3.2 Abbreviated terms
ebXML RegRep
ebXML Registry and Repository
[OASIS ebXML RegRep Version 4.0: 2012]
IRI
Internationalized Resource Identifier
[W3C RFC 3987: 2005]
MFI Core and mapping
ISO/IEC 19763-10, Information technology – Metamodel framework for interoperability (MFI) – Part 10: Core
model and basic mapping
MFI Process model registration
ISO/IEC 19763-5, Information technology – Metamodel framework for interoperability (MFI) – Part 5:
Metamodel for process model registration
MFI Role and Goal model registration
ISO/IEC 19763-8, Information technology – Metamodel framework for interoperability (MFI) – Part 8:
Metamodel for role and goal model registration
MFI Service model registration
ISO/IEC 19763-7, Information technology – Metamodel framework for interoperability (MFI) – Part 7:
Metamodel for service model registration
OWL-S
Web Ontology Language for Services
QoS
Quality of Service
SWRL
Semantic Web Rule Language
SWSL
Semantic Web Service Language
WADL
Web Application Description Language
4 © ISO/IEC 2015 – All rights reserved

WSDL
Web Service Description Language
WSML
Web Service Modelling Language
4 Conformance
4.1 General
An implementation claiming conformance with this part of ISO/IEC 19763 shall support the metamodel
specified in clause 5, depending on a degree of conformance as described below.
4.2 Degree of conformance
4.2.1 General
The distinction between ‘strictly conforming’ and ‘conforming’ implementations is necessary to address the
simultaneous needs for interoperability and extensions. This part of ISO/IEC 19763 describes specifications
that promote interoperability. Extensions are motivated by needs of users, vendors, institutions and
industries, but are not specified by this part of ISO/IEC 19763.
A strictly conforming implementation may be limited in usefulness but is maximally interoperable with respect
to this part of ISO/IEC 19763. A conforming implementation may be more useful, but may be less
interoperable with respect to this part of ISO/IEC 19763.
4.2.2 Strictly conforming implementation
A strictly conforming implementation
a) shall support the metamodel specified in clause 5;
b) shall not use, test, access, or probe for any extension features nor extensions to the metamodel
specified in clause 5.
4.2.3 Conforming implementation
A conforming implementation
a) shall support the metamodel specified in clause 5;
b) as permitted by the implementation, may use, test, access, or probe for any extension features or
extensions to the metamodel specified in clause 5.
NOTE 1 All strictly conforming implementations are also conforming implementations.
NOTE 2 The use of extensions to the metamodel might cause undefined behaviour.
4.3 Implementation Conformance Statement (ICS)
An implementation claiming conformance with this part of ISO/IEC 19763 shall include an Implementation
Conformance Statement stating
a) whether it is a strictly conforming implementation in clause 4.2.2 or a conforming implementation in
clause 4.2.3;
© ISO/IEC 2015 – All rights reserved 5

b) what extensions, if any, are supported or used if it is a conforming implementation.
5 MFI Service model registration
5.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.
Expression
notation[1.*]
postcondition_
1.1 exit_condition_ composing_expression 1.* qos_logical_
precondition_ 1.1 1.1 1.1
logical_expression
logical_expression logical_expression expression
Atomic_Expression
Service_Description_Language
expression_text[1.1]
name[1.1]
expressed_exit_
0.*
condition
describing_
1.1
Exit_Condition language
Composite_Expression
name[0.1]
composition_type[1.1]
0.1
expressed_
contained_exit_
0.1 composed_expression
0.*
model
condition
Service_Model
QoS_Type
name[1.1]
expressed_ name[1.1]
expressed_postcondition 0.*
described_IRI[0.1]
0.*
precondition
1.*
used_qos_type
1.*
containing_model Postcondition
Precondition
name[0.1]
described_qos_assertion 0.*
1.*
name[0.1] contained_service
asserted_ owned_qos_ contained_ constraining_
constraining_
contained_ Service QoS_Assertion
0.* 0.1
service assertion
postcondition postcondition
precondition 0.*
precondition
name[1.1] 1.1 0.*
0.1 0.1
requested_IRI[1.1]
1.*
tagged_service expressed_qos_assertion
domain[1.1]
composing_
service_type[1.1]
service
0.*
User_Tag
containing_ 0.*
1.1 0.1
service
tag_creator[1.1]
service_tag
composed_service
tag_text[1.*]
containing_ containing_
service_ service_ 1.1
contained_service_
1.1 1.1
operation operation 0.* operation containing_service_operation
Service_Operation
name[1.1]
containing_service_operation 1.1
0.*
1.1 containing_service_operation
constrained_
<> <>
constrained_
0.*
input
0.* consumed_message
Service_Type
Composition_Type 0.*
generated_message output
Input_Message
conjunction entity_service
Output_Message
task_service
disjunction
name[1.1]
name[1.1]
negation utility_service
involving_input_message
0.* involving_output_message
0.*
0.1 involved_input_message_type involved_output_message_type 0.1
Message_Type
name[1.1]
message_type_description[0.1]
NOTE Metaclasses whose names are italicized are abstract metaclasses

Figure 2 —Metamodel of MFI service model registration
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 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.
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
6 © ISO/IEC 2015 – All rights reserved

service operation. An exit condition specifies a constraint that, if true, will cause 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 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
can be annotated by zero, one or more user tags, each of which may be created by any person using the
service.
5.2 Associations between MFI Service model registration and other parts in MFI
Figure 3 shows the associations between MFI Service model registration (this part) and MFI Role and Goal
model registration and MFI Process model registration.

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 4.

© ISO/IEC 2015 – All rights reserved 7

Core_Model Package from MFI Core and mapping
0.* 0.*
Modelling_Language Model Model_Element
1.* 0.*
(from MFI Core and mapping) (from MFI Core and mapping) (from MFI Core and mapping)
described_by describes contained_by contains
Service_Description_Language Service_Model Service
MFI Service registration
User_Tag Expression Output_Message Precondition QoS_Type Message_Type
Input_Message Exit_Condition Postcondition QoS_Assertion
Service_Operation
NOTE      Metaclasses whose names
Atomic_Expression
Composite_Expression
are italicized are abstract metaclasses

Figure 4 —The associations between MFI Service model registration and MFI Core and mapping
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 inherit the associations from their superclass in MFI Core and mapping. Some of these
inherited associations are further specialized in this part. The details of these specializations are defined in
Clause 5.3.
5.3 Structure of MFI Service model registration
5.3.1 Atomic_Expression
Atomic_Expression is a metaclass each instance of which represents a logical expression that has unit granularity.
Superclass
Expression
Attribute Datatype MultiplicityDescription
expression_text string 1.1 The text, using a logical notation, of this atomic expression.
Reference Class MultiplicityDescription Inverse Precedence
[None]
Constraints
[None]
8 © ISO/IEC 2015 – All rights reserved

5.3.2 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 MultiplicityDescription
composition_ Composition_Type 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 that composed_ Yes
expression comprise this composite expression
expression.
Constraints
[None]
5.3.3 Composition_Type
Composition_Type is an enumerated datatype with the following values:
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 composite expression is false only in the case when all of the
expressions that comprise this composite expression are false.
negation An indication that whether the composite expression is true or false is the opposite of that of
the single expression that comprises this composite expression.

5.3.4 Exit_Condition
Exit_Condition is a metaclass each instance of which specifies the constraint that, if true, will cause the operation to finish
unsuccessfully.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType MultiplicityDescription
name string 0.1 The name of this exit condition.
Reference Class Multiplicity Description Inverse Precedence
exit_condition_ Expression 1.1 The sentence which is expressed_ Yes
logical_ described by a kind of logic exit_
© ISO/IEC 2015 – All rights reserved 9

expression notation to express this exit condition
condition.
containing_ Service_Operation 1.1 The service operation that contained_ No
service_ may be finished exit_
operation unsuccessfully if this exit condition
condition is true.
Constraints
[None]
5.3.5 Expression
Expression is an abstract metaclass each instance of 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 MultiplicityDescription
notation string 1.* The set of logic languages or notations, each of which is used to
declare a quality assertion, a precondition, a postcondition or an
exit condition of a service.
Reference Class MultiplicityDescription Inverse Precedence
expressed_ Precondition 0.* The constraint that must precondition_ No
precondition be true when an logical_ expression
operation is invoked.
expressed_ Postcondition 0.* The constraint that must postcondition_ No
postcondition be true at the completion logical_ expression
of an operation.
expressed_ Exit_Condition 0.* The constraint that must exit_condition_ No
exit_condition be true to cause an logical_ expression
operation to complete
unsuccessfully.
expressed_ QoS_Assertion 0.* The specification of one qos_logical_ No
qos_assertion or more QoS types for expression
the service.
composed_ Composite_ 0.1 The composite composing_ Yes
expression Expression expression of which this expression
expression forms one of
the elements of that
composite expression.
Constraints
[None]
10 © ISO/IEC 2015 – All rights reserved

5.3.6 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 MultiplicityDescription
name string 1.1 The name of the message that is consumed for the execution
of a service operation.
Reference Class MultiplicityDescription Inverse Precedence
containing_ Service_Operation 1.1 The service operation consumed_ No
service_ that consumes this message
operation input message.
constraining_ Precondition 0.* The set of constrained_input Yes
precondition preconditions, each of
which constrains this
input message when
the service operation is
invoked.
involved_ Message_Type 0.1 The type of this input involving_ input_ Yes
input_message_ message. message
type
Constraints
[None]
5.3.7 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 MultiplicityDescription
name string 1.1 The name of this message type.
message_type_ string 0.1 The description of this message type.
description
Reference Class MultiplicityDescription Inverse Precedence
involving_input_ Input_Message 0.* The set of input involved_input_ No
message messages, each of which message_type
is described by this
message type.
© ISO/IEC 2015 – All rights reserved 11

involving_output_ Output_Message 0.* The set of output involved_output_ No
message messages, each of which message_type
is described by this
message type.
Constraints
[None]
5.3.8 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
Model_Element (from MFI Core and mapping)
Attribute DataType MultiplicityDescription
name string 1.1 The name of the message that is generated after the
execution of a service operation.
Reference Class MultiplicityDescription Inverse Precedence
containing_ Service_Operation 1.1 The service operation generated_ No
service_operation that generates this output message
message.
constraining_ Postcondition 0.* The set of postconditions, constrained_ Yes
postcondition each of which constrains output
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]
12 © ISO/IEC 2015 – All rights reserved

5.3.9 Postcondition
Postcondition is a metaclass each instance of which specifies the constraint that must be true at the completion of an
operation.
Superclass
Model_Element (from MFI Core and mapping)
Attribute Datatype Multiplicity Description
name string 0.1 The name for this postcondition.
Reference Class Multiplicity Description Inverse Precedence
postcondition_ Expression 1.1 The expression that expresses expressed_ Yes
logcal_ this postcondition as a logical postcondition
expression sentence.
constrained_ Output_Message 0.* The set of output messages, constraining_ No
output each of which is constrained postcondition
by this postcondition.
containing_ Service_Operation 1.1 The execution action of the contained_ No
service_ service which contains this postcondition
operation postcondition.
Constraints
[None]
5.3.10 Precondition
Precondition is a metaclass each instance of which specifies the constraint that must be true when an operation is invoked.
Superclass
Model_Element (from MFI Core and mapping)
Attribute Datatype Multiplicity Description
name string 0.1 The name for this precondition.
Reference Class Multiplicity Description Inverse Precedence
precondition_ Expression 1.1 The expression that expresses expressed_ Yes
logical_ this precondition as a logical precondition
expression sentence.
constrained_ Input_ Message 0.* The set of input messages, each constraining_ No
input of which is constrained by this precondition
precondition.
containing_ Service_ Operation 1.1 The execution action of a contained_ No
service_ service which contains this precondition
operation precondition.
© ISO/IEC 2015 – All rights reserved 13

Constraints
[None]
5.3.11 QoS_Assertion
QoS_Assertion is a metaclass each instance of which represents a specification of one or more QoS types of a service.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType MultiplicityDescription
[None]
Reference Class MultiplicityDescription Inverse Precedence
used_qos_type QoS_Type 1.* The set of QoS types, each of described_ Yes
which is involved in this QoS qos_assertion
assertion.
qos_logical_ Expression 1.1 The expression that expresses expressed_ Yes
expression this QoS assertion as a logical qos_assertion
sentence.
asserted_ Service 1.1 The service whose quality is owned_qos_ No
service asserted by this QoS assertion. assertion
Constraints
[None]
5.3.12 QoS_Type
QoS_Type is a metaclass each instance of which is used to represent a specified non-functional property for a service,
such as availability, response time, etc.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType MultiplicityDescription
name string 1.1 The name of this type of non-functional property.
Reference Class MultiplicityDescription Inverse Precedence
described_ QoS_ Assertion 0.* The set of QoS assertions, used_qos_ No
qos_assertion each of which is described by type
this QoS assertion type.
Constraints
[None]
14 © ISO/IEC 2015 – All rights reserved

5.3.13 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 MultiplicityDescription
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 (see bibliography [1]).
service_type Service_Type 1.1 The type of this service.
Reference Class MultiplicityDescription Inverse Precedence
owned_qos_ QoS_ Assertion 0.1 The QoS assertion that applies asserted_ Yes
assertion to this service. service
contained_ Service_ 0.* The set of service operations, containing_ Yes
service_operation Operation each of which denotes an service
execution action of this service.
service_tag User_Tag 0.* The set of tags, each of which is tagged_ Yes
annotated by an individual or an service
organization in order to describe
this service.
composing_ Service 0.* The set of services, each of composed_ Yes
service which is a component of this service
service.
composed_ Service 0.1 The composite service which composing_ No
service contains this service. service
containing_model Service_Model 1.* The set of service models, each contained_ No
of which is used to model this service
service. This reference
specializes the ‘contained_by’
reference which is inherited from
the superclass.
achieved_goal Goal 0.* The set of goals, each of which is achieving_ Yes
(from MFI Role achieved by this service. service
and Goal model
registration)
involved_ service_ Service_ 0.* The set of service involvements, involving_ Yes
involvement Involvement each of which represents a service
(from MFI Role statement that specifies how a
and Goal model particular role is involved in this
registration) service.
Constraints
The value of attribute “requested_IRI” has to be unique in this metaclass.

© ISO/IEC 2015 – All rights reserved 15

5.3.14 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 MultiplicityDescription
name string 1.1 The name of this service description language.
Reference Class MultiplicityDescription Inverse Precedence
expressed_ Service_Model 0.* The set of service models that describing_ No
model are described by this service language
description language. This
reference specializes the
‘describes’ reference which is
inherited from the superclass.
Constraints
[None]
5.3.15 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 MultiplicityDescription
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 MultiplicityDescription Inverse Precedence
describing_ Service_ 1.1 The language or notation that is expressed_ Yes
language Description_ used to model this service. This model
Language reference specializes the
‘described_by’ reference which
is inherited from the superclass.
contained_ Service 1.* The set of services, each of containing_ No
service which is modelled by this model
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.
16 © ISO/IEC 2015 – All rights reserved

5.3.16 Service_Operation
Service_Operation is a metaclass each instance of which denotes one of the execution actions of an associated service.
Superclass
Model_Element (from MFI Core and mapping)
Attribute DataType MultiplicityDescription
name string 1.1 The name of this service operation.
Refere
...