Enterprise
Integration Using
IEC 61968-100
(Implementation
Profile)
Margaret Goodrich, SISCO
Introduction
• The purpose of this presentation is to describe
enterprise integration using the IEC 61968-100
(draft) standard
• IEC 61968-100 is reflective of best practices and
integration experiences, and has effectively been in
use since 2006
• Approach published several years ago as an EPRI
report
• IEC 61968-100 is set for IEC distribution in 2013
Integration Choices
• Depending upon the integration scenario, there are many factors that may
drive the implementation of an information flow
• Some of the implementation options include:
– Transactions through an ESB to create, change or delete objects
– Event notification messages through an ESB that indicate the create, change or delete of
objects
– Messages through an ESB that support query requests, potentially with asynchronous replies
– Web service requests for queries or transactions
– Data set exchanges via CIM/XML files
– Data set updates using incremental CIM/XML
– Information transfer to a data warehouse using ETL mechanisms
– HTTP requests
• There are also a wide variety of technical, performance, availability and
security considerations that would need to be factored/addressed for any
integration choice
Scope of IEC 61968-100
• IEC 61968-100 focuses on message-based integration using transport
technologies such as JMS and web services
4
ESB
Integration
Layer
Web Service
Client
Web Service
Service
WS - Direct Interaction w/o Integration Layer
Application
using JMS
Application
using JMS
JMS JMS
WS WS
JMS – Direct integration using a JMS server
Client or Server
using another
integration
technology
???
Client or Server
using another
integration
technology
???
Integration Patterns
• There are many possible integration patterns, but there are
several that provide basic building blocks
• These basic patterns include:
– Synchronous request/reply
– Point to point
– Publish/subscribe
– Asynchronous request/reply
• Request/reply patterns can be used to support queries as well
as transactions
Basic Integration Patterns
Synchronous Request/Reply Callback
This is the sort of stuff you can do with even the most basic RPC and
functionally limited technologies. Modern integration needs more
than this, which is why we see ESBs.
Basic ESB Integration Patterns
Publish/Subscribe
Synchronous Request/Reply
Asynchronous Request/Reply
Point-to-Point (One Way)
Request/Reply Implementations
• Basic examples using
web services and JMS
• Web services can either
have generic interfaces
or be strongly typed
• JMS can use topics or
queues
8
Web Service Client
Service
WS Interface
ReplyRequest
WS Interface
ESB or standalone JMS
JMS Client
JMS Service
JMS Interface
JMS
Topic or
Queue
Request
Request
Reply
JMS Interface
Reply
Topic or
Queue
Reply
Events
• Events are used to notify
potentially interested
processes that something has
happened
• Events are best
communicated using a
publish/subscribe
infrastructure such as a JMS
implementation
• Web services need an
intermediary service to
distribute events
9
ESB or standalone JMS
Event Listener
Service
JMS Interface
JMS
Topic
Event
Event
Event Listener
JMS Interface
Event
JMS Interface
Integration Using an ESB
• Target service uses JMS
• Could be topics or queues
10
JMS Client Event Listener
Service
JMS Interfaces
JMS Interface
Topic
Request
Router
Topic
or
Queue
Request
Topic
or
Queue
Event
Event
Reply
WS Client
WS Interface
Request
Prioxy
Reply
Reply
WS Interface JMS Interface
Event Listener
JMS Interface
Event
Another Integration Example
• Target service uses web services
• Targets could use other integration
technologies as well
11
JMS Client Event Listener
Service
WS Interfaces
JMS Interface
Topic
Request
Router
Topic
or
Queue
Request
Topic
or
Queue
Event
Event
Reply
WS Client
WS Interface
Request
Proxy
Request
Reply
Reply
WS Interface
Event
Adapter
Reply
Request
JMS Interface
Event Listener
JMS Interface
Event
Event Publisher
WS Interface
Common Message Envelope
• IEC 61968-100 defines a general
approach for transport
independent messages that
minimally consist of a verb, noun
and payload
• IEC 61968-100 defines a common
message envelope (CME) in the
form of an XML schema
• Messages using the CME can be
wrapped within other wrappers
(e.g. SOAP, WSDL, JMS)
• Usage of different parts of the
CME (e.g. Request, Reply
Payload) are dependent upon
messaging pattern and verb
• Payload is defined using an XML
Schema ‘any’
Message Example
<soapenv:Envelope>
<soapenv:Header>
</soapenv:Header>
<soapenv:Body>
<ns:Message>
<ns:Header>
<ns:Verb>created</ns:Verb>
<ns:Noun>MyBusinessObject</ns:Noun>
<ns:Source>SourceApp</ns:Source>
<ns:MessageID>35337</ns:MessageID>
<ns:/Header>
<ns:Payload>
<bo:MyBusinessObject>
<bo:stuff>1</bo:stuff>
<bo:moreStuff>More stuff</bo:moreStuff>
</bo:MyBusinessObject>
<ns:/Payload>
<ns:/Message>
</soapenv:Body>
</soapenv:Envelope>
• This design wraps a
CME inside the SOAP
body
• This example shows
what would be seen ‘on
the wire’
• You can’t tell if this
message was generated
using a WSDL or not!
• The CME even allows
for payloads that do not
have a corresponding
XSD
Verbs
• Verbs support queries,
transactions and events
• Get verb is used for queries
• Create, change, cancel, close
and delete verbs are used
for transactions
• Reply verb is used to
respond to query and
transaction requests
• Past tense verbs are used to
indicate events
• Execute verb is used for a
special case of complex
transactions
14
Enterprise
Service
Bus
using
IEC 61968-100
Clients
(applications
issuing
requests and/
or listening for
events)
Servers
(applications
accepting
requests
and/or
generating
events)
get
create
change
cancel
delete
create
change
cancel
delete
get
created
changed
canceled
deleted
created
changed
canceled
deleted
replyreply
execute execute
executed executed
Verb Usage
Request
Verb
Reply
Verb
Event Verb
Usage
get
reply
(none)
query
create
reply
created
transaction
change
reply
changed
transaction
cancel
reply
canceled
transaction
close
reply
closed
transaction
delete
reply
deleted
transaction
execute
reply
executed
transaction
15
Patterns and Verbs
• Queries are indicated by the use of a ‘get’ verb on the request
in a request/reply pattern, where the payload of the response
message should return the requested information
• Transactions are indicated by the use of verbs such as ‘create’,
‘change’, ‘close’, ‘cancel’, ‘delete’, and could use request/reply
or point-to-point patterns
• Both queries and transactions may result in responses
(verb=‘reply’), which may indicate success or errors
• Events are indications that something has happened of
potential interest, using past tense verbs such as ‘created’,
‘changed’, ‘closed’, ‘canceled’, ‘deleted’ and typically use a
multicast pattern
Nouns
• Nouns identify the type of the payload
• Many nouns are defined by parts of IEC 61968 (e.g.
IEC 61968-9 for integration of metering systems)
• Nouns may also be defined as needed for products
and custom integration projects
• The data related to a noun is typically, but not
always, defined using an XML schema
• Other XML forms and Non-XML forms are also
supported
17
Noun Example
18
Example with Verbs and Nouns
19
Message Correlation
• CorrelationID is set on initial request
• Initial CorrelationID is returned on related messages
20
Transactions
21
Transports
• IEC 61968 is by definition transport independent, but the reality is
that a wide range of messaging technologies have largely given way
to JMS and HTTP
• JMS provides a powerful messaging API, where the worst thing about
JMS is the name, as it is not limited to use by Java applications
• HTTP and JMS have some trade-offs:
– JMS provides a reliable transport with the capability to queue and multicast
messages
– HTTP provides a standard ‘on the wire’ protocol, but JMS does not
• SOAP may be layered on both of these transports, where the IEC
61968 message envelope may be placed within the SOAP body
• When SOAP is used, it can be possible to define a WSDL that also
provides a description of the interface
• Other transports can also be considered, such as AMQP and REST
• ESBs support the use of intermediaries
• IEC 61968-100 is being drafted to define specific, transport-
dependent implementation profiles and integration patterns
Web Services
• IEC 61968 messages can be ‘wrapped’ by a WSDL
• Two basic approaches: Loose coupled (coarse grained) or tightly coupled
(strongly typed, fine grained)
• For broadest compatibility, WSDL should be WS-I compliant and use
document-wrapped style
• Remember that HTTP is not the only transport possible… as JMS can be
used to provide delivery guarantees, multicasting and other features not
possible with HTTP
• The use of a SOAP envelope enables the use of many security tools
Names
• Object naming is an important aspect of integration that is often overlooked
especially where all systems do not use common mRIDs
• Issues:
– The same object may be known in different system by different names
– Messages need to use an identified that is known by source and targets
– Some systems may need to be aware of multiple identifiers for a single object (e.g. local
ID and external ID)
• Sources and targets MUST agree upon names to be used, or rely upon the use of
bilateral mapping tables for object names
• A naming service could be used for allocating and managing names
• The performance implications of name lookups needs to be carefully considered
• Name class introduced in CIM v15 to help address these issues, providing a more
realistic and useful model of object naming
• In theory, an mRID is just another type of name!
CIM Name Class
• Identified Objects can have many Names
• Each Name.name instance can be associated with a different
NameType
• NameTypes can be associated with a NameTypeAuthority that can
be responsible for allocating Name.name values within a
NameType
• IdentifiedObject.name preserved for legacy reasons
Names in Messages
• Common usage of Name class in a message XSD
• NameType often option, but should be provided by source if more
than one Name instance provided
• Target process will map the object using one of the names, as the
name is either used locally or defined within a bilateral mapping table
Name Mapping Example
• Source sends a
message related to
object ‘ABC’
• Within message
Name.name value
is set to ‘ABC’
• Name.NameType.n
ame can be used to
specifically identify
the type of name
• Target receives the
message
• Given that the
Name.name value is
unknown, a table lookup is
required to know that
object named ‘ABC’ as
provided by the external
system is equivalent to
locally named object ‘1’
• This is a bilateral
agreement required for
integration where all
systems do not share a
globally unique ID
External
ID
Local ID
ABC
1
XYZ
2
RTY
345
INB
67433
MJG
222
ECV
555
GGG
225
Note: This is one example, there are many options
