IEC TR 62325-501:2005

TECHNICAL IEC
REPORT TR 62325-501
First edition
2005-02
Framework for energy market communications –
Part 501:
General guidelines for use of ebXML
Reference number
IEC/TR 62325-501:2005(E)
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the
60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.
Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,
edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the
base publication incorporating amendment 1 and the base publication incorporating
amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (www.iec.ch/searchpub) enables you to
search by a variety of criteria including text searches, technical committees
and date of publication. On-line information is also available on recently issued
publications, withdrawn and replaced publications, as well as corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/online_news/ justpub)
is also available by email. Please contact the Customer Service Centre (see
below) for further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:

Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
TECHNICAL IEC
REPORT TR 62325-501
First edition
2005-02
Framework for energy market communications –
Part 501:
General guidelines for use of ebXML

 IEC 2005  Copyright - all rights reserved
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
PRICE CODE
Commission Electrotechnique Internationale
X
International Electrotechnical Commission
Международная Электротехническая Комиссия
For price, see current catalogue

– 2 – TR 62325-501  IEC:2005(E)
CONTENTS
FOREWORD.4
INTRODUCTION.6

1 Scope .7
2 Normative references .7
3 Terms, definitions and abbreviations .8
3.1 Terms and definitions .8
3.2 Abbreviations .8
4 Generic technical architecture.9
4.1 General .9
4.2 Architecture.9
5 Comparison with other solutions .21
6 ebXML configuration.22
6.1 General .22
6.2 Business Process Specification.22
6.3 Collaboration Protocol Profile and Agreement (CPA/CPP) .23
6.4 Mapping to the UN/CEFACT Modelling Mythology UMM .24
6.5 Use of registries .24
6.6 Use of intermediates.24
7 Profile of the architecture.25
8 Migration scenarios .25
8.1 General .25
8.2 Recommended scenarios.26
8.3 ebXML and EDIFACT (X12) in parallel .26
8.4 ebXML with EDIFACT (X12) payload.27
8.5 EDIFACT (X12)/XML conversion .27

Annex A (informative) Scheduling example.28

Figure 1 – Process specification.11
Figure 2 – Business transaction .12
Figure 3 – Binary collaboration.13
Figure 4 – Multiparty collaboration .13
Figure 5 – Business document .14
Figure 6 – Collaboration protocol profile .15
Figure 7 – Collaboration rule.15
Figure 8 – Delivery channel.16
Figure 9 – Transport .16
Figure 10 – Document exchange .16
Figure 11 – ebXML binding of reliability and security .17
Figure 12 – SOAP envelope header and body .17
Figure 13 – Message header.18
Figure 14 – ebXML configuration interfaces.21

TR 62325-501  IEC:2005(E) – 3 –
Figure 15 – Migration from EDIFACT to ebXML and use of data networks .26
Figure 16 – Migration from EDIFACT to ebXML .26
Figure A.1 – Schedule planning transmission process.29
Figure A.2 – Sequence diagram for the document flow without business signals.30
Figure A.3 – ebXML registry scenario for scheduling .31
Figure A.4 – ebXML client where the messages are sent and received.32
Figure A.5 – Visualization of a message.32
Figure A.6 – Interface used to compose messages .33
Figure A.7 – ebXML BPSS DTD .38
Figure A.8 – ebXML BPSS of scheduling phase 1 – 3 in XML.39
Figure A.9 – CPP of the Transmission System Operator for scheduling .41
Figure A.10 – CPP of the Balance Responsible Party for scheduling .42
Figure A.11 – CPA for scheduling.44
Figure A.12 – XML message document example for schedules .45

Table 1 – Relation of UMM with ebXML .19
Table 2 – Mapping between UML classes and XML elements.23

– 4 – TR 62325-501  IEC:2005(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
FRAMEWORK FOR ENERGY MARKET COMMUNICATIONS –

Part 501: General guidelines for use of ebXML

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. However, a
technical committee may propose the publication of a technical report when it has collected
data of a different kind from that which is normally published as an International Standard, for
example "state of the art".
IEC 62325-501, which is a technical report, has been prepared by IEC technical committee
57: Power systems management and associated information exchange.
The IEC 62325 series cancels and replaces IEC 62195 (2000) and its amendment (2002).
It constitutes a technical revision.
IEC 62195 (2000) dealt with deregulated energy market communications at an early stage. Its
amendment 1 (2002) points out important technological advancements which make it possible
to use modern internet technologies based on XML for e-business in energy markets as an
alternative to traditional EDI with EDIFACT and X12. The new IEC 62325 framework series for
energy market communications currently consisting of IEC 62325-101, IEC 62325-102,
IEC 62325-501, and IEC 62325-502 follows this direction and replaces IEC 62195 together
with its amendment.
TR 62325-501  IEC:2005(E) – 5 –
The text of this technical report is based on the following documents:
Enquiry draft Report on voting
57/706/DTR 57/723/RVC
Full information on the voting for the approval of this technical report can be found in the
report on voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
IEC 62325 consists of the following parts, under the general title Framework for energy
market communications:
Part 101: General guidelines
Part 102: Energy market model example
Part 201: Glossary
Part 3XX: (Titles are still to be determined)
Part 401: Abstract service model
Part 501: General guidelines for use of ebXML
Part 502: Profile of ebXML
Part 503: Abstract service mapping to ebXML
Part 601: General guidelines for use of web services
Part 602: Profile of Web Services
Part 603: Abstract service mapping to web services
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual edition of this document may be issued at a later date.

___________
Under consideration. Because the technologies have an inherent own glossary within their standard definitions,
2)
this glossary is a placeholder for a glossary for future parts indicated with including energy market specific
terms and definitions.
Under consideration. These parts for business content are mentioned for completeness only with a number
space as placeholder. They extend the original scope and require an agreed new work item proposal for further
work based on an overall strategy how to proceed.
Under consideration. These technical parts are mentioned for completeness with provisional title. They extend
the original scope and require an agreed new work item proposal for further work.

– 6 – TR 62325-501  IEC:2005(E)
INTRODUCTION
With the transition of monopoly energy supply structures to deregulated energy markets, the
function of the markets depends heavily on seamless e-business communication between
market participants. Compared with global e-business, e-business in the energy market is
only a small niche. Today EDIFACT or X12 messages, or proprietary HTML and XML
solutions based on Internet technologies are being used.
The ‘electronic business Extensible Markup Language’ (ebXML) specification and architecture
stems from UN/CEFACT and OASIS (see www.ebXML.org). The technical parts regarding the
technical e-business infrastructure have now become the multipart ISO 15000 series
“Electronic business eXtensible Markup Language (ebXML)” being complemented in future to
cover all technical aspects of ebXML. ebXML is a complete set of specifications and
standards to enable secure electronic business using proven, open standards such as
TCP/IP, HTTP, SOAP, XML, and SOAP signature and encryption. ebXML is also evolutionary
in nature, built on 25 years of EDI experience, designed to work with existing EDI solutions, or
be used to develop an emerging class of internet-based electronic business applications
based on XML. This means that existing EDI messages (EDIFACT, and X12) as well as XML
messages can be exchanged.
TR 62325-501  IEC:2005(E) – 7 –
FRAMEWORK FOR ENERGY MARKET COMMUNICATIONS –

Part 501: General guidelines for use of ebXML

1 Scope
This part of IEC 62325 provides general guidelines how to use the ebXML technology and
architecture in energy markets based on the ISO 15000 ISO series “Electronic business
eXtensible Markup Language (ebXML)” together with migration scenarios and an
implementation example. For recommended profiles, see IEC 62325-502.
2 Normative references
The following referenced documents are indispensable for the application 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 14662, Information Technology – Open-edi reference model
ISO 7372, Trade data interchange – Trade data elements directory
ISO 9735 (all parts), Electronic data interchange for administration, commerce and transport
(EDIFACT)
ISO/TS 15000-1:2004, Electronic business eXtensible Markup Language (ebXML) – Part 1:
Collaboration-protocol profile and agreement specification (ebCPP)
ISO/TS 15000-2:2004, Electronic business eXtensible Markup Language (ebXML) – Part 2:
Message service specification (ebMS)
ISO/TS 15000-3:2004, Electronic business eXtensible Markup Language (ebXML) – Part 3:
Registry information model specification (ebRIM)
ISO/TS 15000-4:2004, Electronic business eXtensible Markup Language (ebXML) – Part 4:
Registry services specification (ebRS)
ANSI ASC X12, Release 4040, December 2000
UN/EDIFACT, D.01A Directory, January 2001
UN/CEFACT Modelling Methodology (UMM), NO90 R12 or higher
UN/CEFACT ebXML Technical Architecture Specification, v1.04 or higher
UN/CEFACT ebXML Business Process Specification Schema, v1.10 or higher
In this part of IEC 62325, RFCs (Request for comments) from the Internet Engineering Task
Force (IETF) and recommendations from other Organisations such as the Word Wide Web
Consortium (W3C) and the Organization for the Advancement of Structured Information
Standards (OASIS) are mentioned which are not included here because these documents are
referenced in the references above.

– 8 – TR 62325-501  IEC:2005(E)
3 Terms, definitions and abbreviations
3.1 Terms and definitions
None.
3.2 Abbreviations
A2A Application-to-Application
AES Advanced Encryption Standard
B2B Business-to-Business
BDS Business Document Specification (instance)
BDSS Business Document Specification Schema
BIE Business Information Entity
BOV Business Operational View
BPMS Business Process Management System
BPSS Business Process Specification Schema (or instance)
BSI Business Service Interface
CC  Core Component (based on BIE)
CIM Common Information Model
CPA Collaboration Protocol Agreement
CPP Collaboration Protocol Profile
DSO Distribution System Operator (of power system
DUNS Data Universal Numbering System (North America)
EAN European Article Number (Europe)
ebMS ebXML Messaging Service
ebXML electronic business XML
EDI Electronic Data Exchange
EIA Enterprise Application Integration
EMS Energy Management Systems
ERP Enterprise Resource Planning
FOV Functional Service View
FTP File Transfer Protocol
HTTP Hypertext Transport Protocol
ICT Information and Communication Technology
ISO Independent System Operator
IT  Information Technology
MIME Secure/Multipurpose Internet Mail Extensions
MIS Market Identification Schema
MOM Message-oriented middleware
MSH Message Service Handler
PKI Public Key Infrastructure
QoS Quality of Service
RPC Remote Procedure Call
RR  Registry/Repository
TR 62325-501  IEC:2005(E) – 9 –
SAML Security Assertion Mark-up Language
SCADA Supervision, Control, and Data Acquisition
SMTP Simple Mail Transfer Protocol
SO  System Operator (of power system)
SOAP Simple Object Access Protocol
TLS Transport Layer Security
TSO Transmission System Operator (of power system)
UML Unified Modelling Language
UMM UN/CEFACT Modelling Methodology
VPN Virtual Private Network
WS  Web Services
WSDL Web Services Definition Language
XML eXtensible Markup Language
XKMS XML Key Management Specification
4 Generic technical architecture
4.1 General
The following text is mainly based on the public description of the ebXML initiative
(http://www.ebxml.org/) and is intended to provide a basic understanding of the technology.
For details, refer to the ebXML implementation framework specification and the ebXML
architecture document of the initiative.
4.2 Architecture
4.2.1 General
The vision of ebXML is to create a single global electronic marketplace where enterprises of
any size and in any geographical location can meet and conduct business with each other
through the exchange of XML based messages. ebXML is a complete set of specifications to
enable secure, global, electronic business using proven, open standards such as TCP/IP,
HTTP, SOAP, and XML. ebXML is also evolutionary in nature, built on 25 years of EDI
experience, designed to work with existing EDI solutions, or be used to develop an emerging
class of internet based electronic business applications based on XML.
Since systems integration and software interoperability are the cornerstones of any successful
IT infrastructure, ebXML is built on an infrastructure that ensures electronic interoperability.
This is accomplished by providing an open semantics framework that allows enterprises to
find each other, agree to become trading partners, and conduct business. The evolution of
many new business models will be enabled by ebXML, through business process patterns and
the 'commoditization' of such business processes.
The electronic business infrastructure provided by ebXML is broad in scope and well
integrated. And perhaps most importantly, ebXML is platform and vendor neutral, providing an
industry solution based on open standards, designed through a collaborative and open
process.
ebXML is a set of specifications that together enable a modular, yet complete electronic
business framework for using the Internet. The ebXML architecture provides:
ƒ A way to define business processes and their associated messages and content.
ƒ A way to register and discover business process sequences with related message
exchanges.
– 10 – TR 62325-501  IEC:2005(E)
ƒ A way to define company profiles.
ƒ A way to define trading partner agreements.
ƒ A uniform message transport layer.
The ebXML framework is designed for electronic interoperability, allowing businesses to find
each other, agree to become trading partners and conduct business. All of these operations
can be performed automatically, minimising, and in most cases completely eliminating the
need for human intervention. This streamlines electronic business through a low cost, open,
standard mechanism.
In order for enterprises to conduct electronic business with each other, they should:
ƒ Discover each other and the products and services they have to offer.
ƒ Determine which shared business processes, and associated document exchanges, to use
for obtaining products or services from each other.
ƒ Determine the contact points and form of communication for the exchange of information.
ƒ Agree on the contractual terms on the above chosen processes and associated
information.
ƒ They can then: exchange information and services in an automated fashion in accordance
with these agreements.
ebXML is designed to meet these needs and is built on three basic concepts: provide an
infrastructure that ensures data communication interoperability; provide a semantics
framework that ensures commercial interoperability; and provide a mechanism that allows
enterprises to find each other, agree to become trading partners and conduct business with
each other. The infrastructure to ensure data communication interoperability is provided
through:
ƒ A standard message transport mechanism with a well defined interface, packaging rules,
and a predictable delivery and security model.
ƒ A 'business service interface' that handles incoming and outgoing messages at either end
of the transport.
ƒ A semantic framework to ensure commercial interoperability is provided through a meta
model for defining business process and information models.
ƒ A set of re-useable business logic based on core components that reflect common
business processes and XML vocabularies.
ƒ A process for defining actual message structures and definitions as they relate to the
activities in the Business Process model.
ƒ A mechanism to allow enterprises to find each other, agree to establish business
relationships, and conduct business, is provided through shared repository where
enterprises can register and discover each other's business services via partner profile
information.
ƒ A process for defining and agreeing to a formal Collaboration Protocol Agreement (CPA),
if so desired or where required.
ƒ A shared repository for company profiles, business process models and related message
structures.
The ebXML implementation framework defines the ebXML Technical Architecture. The
technical architecture is composed of five main area of emphasis: Business Process and
Information Model, Collaboration Protocol Profiles Company Profiles, Messaging Services,
Registry and Repository, Collaborative Partner Agreements.

TR 62325-501  IEC:2005(E) – 11 –
4.2.2 Business process description
The Business Process models define how business processes are described. Business
Processes represent the "verbs" of electronic business and can be represented using
modelling tools. The specification for business process definition enables an organisation to
express its business processes so that they are understandable to other organisations. This
enables the integration of business processes within a company, or between companies.
Figure 1 shows the graphical presentation of the BPSS (Business Process Specification
Schema) process specification to provide a basic understanding of the technology. The main
elements are multiparty collaborations and binary collaborations. Both include (reference)
business transactions, which govern the business document flow.

IEC  150/05
Figure 1 – Process specification
Figure 2 shows the graphical presentation of the business transaction from the Business
Process Specification Schema (BPSS).
The business transaction consists of a requesting business activity and a responding
business activity each associated with a document envelope (which includes the business
documents and attachments).
– 12 – TR 62325-501  IEC:2005(E)

IEC  151/05
Figure 2 – Business transaction
Figure 3 shows the graphical presentation of the binary collaboration from the Business
Process Specification Schema (BPSS). Specific business process specifications are derived
from the UML activity diagram (see IEC 62325-502). The Business Process Specification
Instance uses the BPSS and is, besides the CPP/CPA, the most innovative part of ebXML.
BPSS, CPP/CPP are shared between business partners and are used for both documentation
and system configuration.
The binary collaboration is between two business partners with one partner in the initiating
role and the other partner in the responding role. It includes business transaction activities
and (nested) collaboration activities. These activities reference business transactions
respective collaborations. Collaborations have a start state (Start) and a completion state
(Success or Failure). From start to end there can be pseudo-states fork (Fork) and join (Join)
for parallel transactions. The transition state specifies that a given activity be followed by
another activity.
TR 62325-501  IEC:2005(E) – 13 –
IEC  152/05
Figure 3 – Binary collaboration
Figure 4 shows the graphical presentation of the multiparty collaboration from the Business
Process Specification Schema (BPSS). The multiparty collaboration is between more that two
partners and consists of multiple binary collaborations. It is defined by the business partner’s
role, which performs (Performs) one or more roles in various binary collaborations.
Transitions (Transition) can be added to define the transition from one business transaction
activity to the other.
IEC  153/05
Figure 4 – Multiparty collaboration

– 14 – TR 62325-501  IEC:2005(E)
4.2.3 Business documents
The Information models define reusable components that can be applied in a standard way
within a business context. These Core Components represent the "nouns and adjectives" of
electronic business. They are defined using identity items that are common across all
businesses. This enables users to define data that is meaningful to their business while also
maintaining interoperability with other business applications.

Figure 5 shows the graphical presentation of the business document from the Business
Process Specification Schema (BPSS). Business documents are derived in the UMM design
workflow from UML class diagrams of messages and incorporate information entities (re-
usable core components). Business documents can be of any syntax (also EDIFACT or X12)
but XML is the preferred syntax within ebXML.

IEC  154/05
Figure 5 – Business document
4.2.4 Business agreement
The Collaborative Partner Profiles (CPP) and Collaborative Partner Agreements (CPA, build
from the intersection of two CPP) captures critical information for communications between
applications and business processes and also records specific technical parameters for
conducting electronic business. IEC 62325-502 specifies the profile.
Figure 6 shows the graphical presentation of the collaboration protocol profile from the
Collaboration Protocol Profile (CPP) Schema. For collaboration role, delivery channel,
transport, and document exchange, see the following Figures 7 to 10. Party Identification
(PartyId) identifies and party reference (PartyRef) references the business partners.

TR 62325-501  IEC:2005(E) – 15 –
IEC  155/05
Figure 6 – Collaboration protocol profile
Figure 7 shows the graphical presentation of the collaboration role from the Collaboration
Protocol Profile (CPP) Schema. It defines the collaboration role (Role) and includes a
reference to the BPSS (ProcessSpecification)

IEC  156/05
Figure 7 – Collaboration rule
Figure 8 shows the graphical presentation of the delivery channel from the Collaboration
Protocol Profile Schema (CPP). It defines its characteristics with regard to reliability, non-
repudiation and security.
– 16 – TR 62325-501  IEC:2005(E)

IEC  157/05
Figure 8 – Delivery channel
Figure 9 shows the graphical presentation of the transport from the Collaboration Protocol
Profile (CPP) Schema. It defines the sending and receiving protocol (mostly the same) and its
endpoints. Transport security is an option.

IEC  158/05
Figure 9 – Transport
Figure 10 shows the graphical presentation of the document exchange from the Collaboration
Protocol Profile (CPP) Schema. It defines, with ebXML binding (see Figure 11), the reliability
and security features and parameters of the ebXML messaging.

IEC  159/05
Figure 10 – Document exchange
Figure 11 shows the graphical presentation of the ebXML binding from the Collaboration
Protocol Profile Schema (CPP). It defines reliable messaging (retry, retry interval, duration of
persistent storage), non-repudiation (signature, etc.), and the digital envelope (encryption,
etc.) including the associated certificates.

TR 62325-501  IEC:2005(E) – 17 –

IEC  160/05
Figure 11 – ebXML binding of reliability and security
4.2.5 ebXML message
4.2.5.1 SOAP envelope header and body
The ebXML message consists of the envelope, header, and body wrapped into the SOAP with
the Attachment container. A signed message is any message containing a Signature element.
Figure 12 shows the soap envelope header and body.

IEC  161/05
Figure 12 – SOAP envelope header and body
An ebMS message package consists of one or more MIME parts. The first MIME part contains
the SOAP envelope. The SOAP envelope header contains, besides the MessageHeader
element (see below) and other elements, the elements Signature and Acknowledgement. The
element Signature conforms to the XML DSIG specification and includes, besides the
methods and algorithms and the reference to the payload, the signature value (that is the
signed message digest for authentication) and the message digest value. The public key can
be optionally exchanged if not done by other means. It is configured by the CPA for all BPSS
profiles which require persistent digital signatures.

– 18 – TR 62325-501  IEC:2005(E)
The element Acknowledgement should be used in all BPSS profiles for the acknowledgement
of messages on messaging level and to allow retry.
The SOAP envelope body contains, besides other elements, the element deliveryReceipt,
which is used in the relevant BPSS profile (see IEC 62325-502) for persistent non-repudiation
with signed receipt on application level. The Manifest element makes reference to the
message payload and identifies some resource that describes the payload object or its
purpose.
4.2.5.2 Message header and payload
Within the SOAP envelope, the SOAP Header element contains the MessageHeader element.
The actual payload (XML documents or others, e.g. EDIFACT or X12 documents) is contained
in the second (and maybe also in the following) MIME parts.
Figure 13 shows the message header.

IEC  162/05
Figure 13 – Message header
The specific use of some elements in energy markets should be as follows (see also the
BPSS profile, and the CPA profile in IEC 62325-502):
The required From/PartyID and To/PartyID elements contain the market participant identifier
(e.g. market specific or EAN, DUNS) according to the Market Identification Schema (see
IEC 62325-101, Subclause 6.4). The type attribute indicates the domain of the PartyID to
differentiate, e.g. between more than one market identification schemas in use or to reference
other registries. If no type is specified, the PartyID element should be an URI. It is
recommended to specify the type (e.g. type value "DUNS", "EIC", or "EAN" according to the
Market Identification Schema).

TR 62325-501  IEC:2005(E) – 19 –
The required CPAId element references the CPA used in order to determine the reliability
parameters for the message exchange. These parameters of the optional (but in this case,
required) QualityOfServiceInfo element are configured with the CPA profile (see IEC 62325-
502). The deliverySemantics attribute of the CPA is identical with the QualityOfServiceInfo
element. The idempotency attribute of the CPA determines if the MSH checks for duplicated
messages and processes it. The messageOrderSemantics attribute of the CPA is identical
with the QualityOf ServiceInfo element’s attribute of same name. The retry attribute of the
CPA determines the maximum number of retries of an unacknowledged message. The
RetryInterval element contains a time value for the duration that a sender should wait
between retries. The PersistDuration element of the CPA determines the duration a message
is kept persistently in store by the receiving MSH. The deliveryReceiptRequested attribute of
the QualityOf ServiceInfo element is determined by the profile of the BPSS (see BPSS profile
in IEC 62325-502) referenced by the CPA.
The required Service element defines the service that acts on the message and is specified in
a project or market. The service is further specified by the type attribute. The required Action
element identifies the associated process activity within the service conforming to the BPSS.
The acknowledgement service should be used for reliable message transfer in all CPA
profiles.
The optional SequenceNumber element defines the sequence number of messages and
should be present, because in all CPA profiles, the messageOrderSemantics attribute of the
QualityOfServiceInfo element is set to the value “Guaranteed”.
The optional Description element can have a number of child elements, which can be
optionally used to describe the use of the message. For example, for a human readable
description of the message content, the supported process can be described.
4.2.6 Mapping of the UMM model to ebXML
The mapping of the UMM (UN/CEFACT Modelling Methodology) business process model to
ebXML is straightforward. Table 1 shows the relation of UMM with ebXML.
Table 1 – Relation of UMM with ebXML
UMM workflow ebXML component Elements Links
Business modelling BPSS MultiPartyCollaboration BusinessPartnerRole
Transition
Requirements BinaryCollaboration BusinessTransactionActivity
Fork, Join
Analysis BusinessTransaction
Design CPP/CPA CollaborationRole Role

The business process modelling goes over three workflows defining multiparty collaborations,
binary collaborations and business transactions. Its result is mapped to the Business Process
Specification (BPSS instance) based on the BPSS. The result of the design (business service
view) workflow is mapped to the Collaboration Protocol Profile (CPP). In the implementation
workflow, the negotiated CPP, called Collaboration Protocol Agreement (CPA) is used for
both documentation and configuration of the Business Service Interface (BSI).

– 20 – TR 62325-501  IEC:2005(E)
4.2.7 Registry and repository
The Registry and Repository (RR) provides a number of key functions. For the user
(application), it stores company profiles and trading partner specifications. These give access
to specific business processes and information models to allow updates and additions over
time. For the application developer, it will store not only the final business process definitions,
but also a library of core components. It allows to describe and search business partners, and
to update and retrieval the ebXML key artefacts BPSS, CPP, CPA besides UML models and
other textual descriptions.
4.2.8 Messaging services
The ebXML Messaging Service specification defines the set of services and protocols that
enables electronic business applications to exchange data. The specification allows any
application-level protocol to be used. These can include common protocols such as SMTP,
HTTP, and FTP, but at the moment, only HTTP and SMTP are included.
Well-established cryptographic techniques can be used to implement strong security. XML
Encryption is the preferred default encryption to guarantee persistent confidentiality. Other
secure protocols such as TLS or IPsec are optional. In addition, persistent digital signatures
can be applied with XML Digital Signature to individual messages or a group of related
messages to guarantee authenticity.
For profiles, see IEC 62325-502.
4.2.9 Transport of messages
The transport is over TCP/IP.
4.2.10 Configuration of agreed messaging services
The business service interface (BSI) provides the means to communicate with business
partners and is configured with the CPA.
4.2.11 Abstraction, binding and mapping
Figure 14 shows the ebXML configuration, abstraction, binding and mapping. The ebXML
Messaging Service (ebMS) is a service logically positioned between one or more business
applications and a communication service (transport protocols). This requires the definition of
an abstract business service interface of the BSI (Business Service Interface) between the
business applications and the Message Service Handler (MSH) to hide the ebMS technology
from the application. ebXML does not yet define this abstract business service interface, but it
may be included in future versions of the ebMS with the following functions:
• Send () – send an ebXML Message (values for the parameters are derived from the
ebXML message headers).
• Receive () – indicates willingness to receive an ebXML message.
• Notify () – provides notification of expected and unexpected events.
• Inquire () – provides a method of querying the status of the particular ebXML message
interchange.
The ebXML architecture uses the ebMS, but is not restricted to it. The abstract service
interface (to be specified) and the descriptive nature of ebXML (with BPSS, CPA) will allow
alternative reliable and secure messaging services in future, which may come for example
from W3C.
TR 62325-501  IEC:2005(E) – 21 –
Bindings and mappings to two communication protocols (HTTP and SMTP over TCP/IP) are
defined. However, the MSH is specified independent of any communication protocols. While
HTTP is the preferred solution, no preference is being provided to this protocol. Other
protocols may be used in future versions of the ebMS.
The ebMS relies on external configuration information. The CPA referencing the BPSS
provides this information. But this is not a requirement. If the CPA and BPSS are not used,
the ebMS should be configured manually.

application
application uses
references
Application BPSS BDSS
any payload
references
Business Service Interface
CPA
ebXML
configures
Message Service Handler
(MSH)
BPSS = Business Process Specification
Binding and Mapping
BDSS = Business Document Specification Schema
CPA = Collaboration Profile Agreement
Protocols (HTTP, SMTP, .)
TCP/IP
IEC  163/05
Figure 14 – ebXML configuration interfaces
The relative independence of the various ebXML specifications such as ebMS, BPSS, CPP/A
and the fact that the message payload can be of any format (but XML is preferred) ensures
their interoperability with alternative or future implementations, flexibility in choosing software
components to implement ebXML systems and protection of investment in ebXML solutions.
5 Comparison with other solutions
The ebXML e-business technology goes far beyond EDIFACT and X12: EDIFACT and X12
are message-centric and do not define transactions. Trading partner agreements (TPA) and
implementation guides are necessary to implement systems. With ebXML, these agreeme
...