These patterns include, but are certainly not limited to: • Synchronous request/reply – Web Service implementations use an operation with input and output messages – JMS implementations
Terms and definitions
For the purposes of this specification, the terms and definitions given in IEC 60050-300,
IEC/TS 61968-2, IEC 62051, IEC 62055-31 apply.
Abbreviations
The following terms and abbreviations are used within this document:
Application Programming Interface Advanced Message Queue Protocol CIM
Common Information Model Common Message Envelope Create, Read, Update, Delete Event Driven Architecture Enterprise Service Bus International Electrotechnical Commission Internet Engineering Task Force Request For Comments ISO
International Standards organization Java Enterprise Edition
Java Message Service Java Specification Request CIM master resource identifier Organization for the Advancement of Structured Information Standards RDF
Resource Description Framework REpresentational State Transfer Request for Comments
Simple Object Access Protocol Secured Socket Layer
Transport Layer Security Unified Modelling Language Uniform Resource Locators Universal Unique Identifier W3C World-Wide Web Consortium
Web Services Web Services standards Web Services Interoperability WSDL Web Services Definition Language
XML Schema XML Stylesheet Language
Terminology for common integration technologies
Event-Driven Architecture (EDA)
A query is a request aimed at obtaining information from a source, typically utilizing the 'get' verb This process is commonly executed through a request/reply pattern.
A transaction is a type of request where the target typically will modify information that it manages A transaction request will use verbs such as ‘create’, ‘change’, ‘delete’, ‘cancel’,
‘close’ or ‘execute’ This may be implemented using a variety of patterns If a pattern other than request/reply is used, there should be a delivery guarantee provided by the transport
The term 'Event' is multifaceted, carrying various meanings across different contexts Generally, an event is defined as 'something that occurs at a specific place and time' or 'a change of state that may be of interest.' Consequently, events can lead to significant outcomes or changes.
An 'event message' is generated by 'something' to indicate that a specific type of event has occurred at a particular time These messages are asynchronous and are usually distributed to interested subscribers through topic-based messaging.
Event messages represent a form of asynchronous communication, often generated by applications when specific conditions are met or transactions are completed Various integration patterns exist to facilitate the handling of these events.
Events are published asynchronously as messages by systems or applications to report significant conditions These conditions may be identified internally by the system or externally by devices Event messages typically utilize past tense verbs, such as 'created'.
‘changed’, ‘deleted’, ‘closed’, ‘canceled’ or ‘executed’
General
Clause 4 outlines various use cases that illustrate the interactions among components within systems working together to facilitate business processes It emphasizes the integration of systems rather than application-level use cases, with specific actors involved in these scenarios.
Three key terms related to messaging are request, reply and event Within the terminology of
IEC 61968, these are reflected in terms of the verbs used to define specific information flows
Central to the use cases is the assumption that a variety of integration technologies may be used, where the focus of this standard is JMS and web services.
Simple request/reply
The initial use case involves a straightforward request/reply interaction between a client and a server, often referred to as request/response In this scenario, the client initiates the request, which is then processed by the server This represents a basic view of the interaction, occurring without the integration of an Enterprise Service Bus (ESB).
This use case encompasses two scenarios: first, a client sends a query request to a server, which responds with a collection of objects filtered by specific criteria; second, a client initiates a transaction request to a server, resulting in the creation or modification of a set of objects.
Both cases are illustrated in Figure 2
In terms of IEC 61968, requests use verbs such as "get", "create", "change", "delete", "close",
Request/reply using an ESB
The simple request/reply use case can be enhanced by utilizing an Enterprise Service Bus (ESB), which allows intermediaries to perform various actions to support integration and decouple components, including transformations and routing.
Figure 3 – Request/reply using intermediaries
A crucial element of this use case is the separation of the client from the server, allowing the client to operate without needing to know the server's precise location or adhere to its specific interface This decoupling enables routing and mapping to occur within the integration layer.
It is also recommended that ESB intermediaries be stateless The use of stateless intermediaries simplifies the implementation of load balancing and high availability.
Events
There is often the need for client processes to be informed of an event of potential interest
Many client processes can listen (subscribe) for events One example of this is
EndDeviceEvents messages can be generated by a metering system, including notifications about the execution of controls or transactions, such as the creation or updating of work orders.
In terms of IEC 61968, events use the ‘past tense’ verbs "created", "changed", "deleted",
In a one-way communication pattern, the sender does not anticipate a response at the application level, even though the transport layer may permit lower-level acknowledgments to ensure delivery guarantees when necessary.
Listeners utilizing web services must have a publicly accessible interface at a known URL for effective event distribution by intermediaries Additionally, it is essential to establish rules for retry processing to ensure guaranteed delivery Furthermore, the importance of message ordering should not be overlooked, as it is a critical aspect that may warrant further exploration in future discussions.
Transactions
A transaction often involves a request/reply interaction between a client and a server, leading to the publication of events It's crucial to note that clients and services may utilize different transport mechanisms; for instance, a client might employ web services while a server could use JMS An intermediary within the Enterprise Service Bus (ESB) can facilitate the required routing functions.
Transactions typically follow a request/reply pattern, but they can also be executed using a point-to-point or one-way approach The one-way pattern may utilize present tense verbs for transactions or past tense verbs for events, depending on the specific requirements of the implementation.
Figure 5 – Point-to-Point (One Way) Pattern
The one-way pattern is utilized when a record system needs to send a transaction to a peer system for application If the target system identifies any errors, these will be logged for resolution An example illustrating this process shows how a transaction can trigger events that are communicated to interested subscribers.
According to IEC 61968, transaction requests utilize verbs such as create, change, delete, cancel, close, and execute, while event-related verbs are expressed in the past tense The term "execute" indicates a complex transaction and involves the Payload.OperationSet element, as outlined in section 6.9.
Callback
A callback is an asynchronous process for message exchange It is made of two request/response (initial and final) synchronous calls The two are correlated in a way that
According to IEC 1774/13, each party can clearly identify the correspondence between callbacks and initial requests The process begins when the client sends an initial request to the server, which then responds, completing the initial transaction and allowing the client application to continue other tasks After the server finishes processing, it initiates the final request/response sequence The entire callback process concludes when the client responds to this final request, as illustrated in the accompanying sequence diagram.
In the callback process, clients must provide the server with a callback address, typically a URL, where the final response will be sent This information is included in the initial request message, and Section 6.3.2 outlines the specific message elements used to manage this type of interaction.
Callbacks are typically implemented through asynchronous replies when using JMS.
Adapters
In situations where an application, whether client or server, cannot establish a direct connection to an Enterprise Service Bus (ESB) or another application, an adapter serves to bridge the 'impedance mismatch' between them This scenario often involves applications such as databases or file directories The diagram illustrates how an adapter facilitates the connection between a server and the ESB.
The adapter plays a crucial role by executing various functions on behalf of the application, including generating events that are vital for transaction success Its primary task is to facilitate data conversion between the application model and the enterprise canonical model.
Complex messaging
Certain scenarios necessitate intricate messaging patterns, particularly when a transaction leads to multiple consequential events These events can be communicated to the client as asynchronous notifications.
In applications like metering, obtaining results can be time-consuming, particularly in scenarios involving disconnections or load control.
EndDeviceControls message might be issued, but the results may be reported after some delay using an EndDeviceEvents message
This variation of the callback pattern involves an initial request that can either be a query, yielding asynchronous results, or a transaction that may generate one or more subsequent events.
Orchestration
This specification does not cover use cases involving the orchestration or choreography of business processes, nor does it address short or long-running distributed transactions However, the integration approaches outlined in this document can be utilized for more complex integrations that fulfill these requirements.
Application-level use cases
The use cases described in 4.1 to 4.9 can be applied to end use application-level use cases
In this application-level use case, messages are structured using IEC 61968 verbs and nouns in the format ‘()’ Additionally, specific types of systems are identified, distinguishing them from more generic types of actors.
Figure 10 – Application-level use case example
General
This document identifies fundamental service integration patterns that align with the previously outlined use cases Additionally, it facilitates the implementation of more intricate integration patterns by utilizing intermediaries within an enterprise service bus (ESB) or through applications acting as intermediaries.
Client and server perspectives
From the perspective clients and servers there are several basic integration patterns described within this document These patterns include, but are certainly not limited to:
– Web Service implementations use an operation with input and output messages
– JMS implementations exchange messages on queues
– Web Service implementations use separate operations for request and callback reply messages
– JMS implementations exchange messages on queues
• Publish/subscribe, where potentially many targets are listening for messages
– Web Service implementations will involve a client listening on specified URLs for events that are sent to multiple targets by an ESB intermediary
– JMS implementations will involve targets listening for messages on a topic
From the viewpoint of either the client or the server, the method of communication—whether direct or through intermediaries—does not affect the outcome, as long as the results are returned effectively.
IEC 1778/13 utilizes a unified transport mechanism, allowing for a flexible integration architecture This enables clients to select from web services, topics, or queues, while target services can independently choose their preferred method Such an approach isolates technology choices within enterprise applications, ensuring that bridging technologies do not directly affect individual applications, thereby preserving application migration options.
The following diagram illustrates a basic request/reply pattern using web services
Figure 11 – Basic request/reply using web services
In this pattern the client issues a request to a web service interface exposed by some service
This interface is defined using a WSDL However, this interaction pattern may also be realized using REST The client should expect one of several outcomes:
• The request is successfully processed, where a reply message is returned in a timely manner (Result=OK)
• The request is accepted, but results in a reply message that returns an application level error code (ResultLED)
• The request is accepted, but results in a reply message with a partial set of results
• The request results in a fault being returned to the client
• After sending the request, no reply or fault is returned in a timely manner
When implementing a service, it's crucial to consider the varying levels of security required, especially in cases where a client communicates over a public network In such scenarios, key security measures like authentication, authorization, encryption, and signing become essential.
In the case where a reply is not required, this is called a ‘one way’ pattern However care should be taken with respect to any required delivery guarantees
Basic JMS request/reply pattern
Figure 12 illustrates a fundamental request/reply pattern in which a client transmits a JMS message to a topic or queue In this scenario, the reply message is optional, and there are instances where a reply may not be sent at all.
Topic or JMS Queue Request
Figure 12 – Basic request/reply using JMS
A service listens on a message destination, such as a topic or queue, to consume request messages and send replies to clients This message destination is managed by the JMS implementation, often integrated within an ESB Clients have the flexibility to consume reply messages either synchronously or asynchronously, depending on their specific implementation choices.
In JMS, a 'message destination' can refer to either topics or queues for request/reply messaging When utilizing topics, it is essential to implement a durable subscription to ensure that request messages are not lost.
The client initiating the request can expect one of the following results:
• The request message is successfully sent to a topic (or queue), where a reply message
(correlated to the request using an ID) is returned in a timely manner (Result=OK)
• The request message is sent, but results in a reply message that returns an application level error code (ResultLED)
• The request is accepted, but results in a reply message with a partial set of results
• The attempt to send a request message to the topic (or queue) fails
• After sending the request message, no reply message is ever received (which may or may not be normal behaviour depending upon the service)
Reply messages are dispatched through designated topics or queues, which can be defined either statically or dynamically For clarity, upcoming diagrams will omit explicit references to these reply topics or queues JMS implementations offer delivery guarantees that allow clients to make transaction requests without necessitating replies, a method often referred to as a one-way pattern.
JMS is primarily utilized in secure, private enterprise networks, but there are exceptions where security becomes a critical issue It can be easily configured to implement SSL/TLS and client authentication for enhanced security.
This pattern does not necessitate a complete Enterprise Service Bus (ESB) implementation; instead, only a Java Message Service (JMS) implementation is required It's crucial to recognize that JMS implementations from various vendors often lack interoperability, which may necessitate a 'bridge' when clients are unable to utilize a shared JMS implementation.
Another integration pattern is that of a process that listens for events that may be published
There are many cases where a service may publish event messages that are of potential interest to many other processes
Figure 13 – Event listeners using JMS
Events are generally published on topics rather than queues, as there are usually multiple consumers for each event Listeners must subscribe to one or more JMS topics that interest them, and some may opt for durable subscriptions to ensure that events are not lost Event messages are transmitted to consumers asynchronously.
There is no acknowledgement message of any kind returned to the service
There may be issues related to the number of topics (or queues) and the fan out (i.e number of event listeners) that can be supported using a given JMS implementation
The architecture outlined in this document can be enhanced by incorporating WS-Eventing for event publication and subscription by web service clients An open-source version of WS-Eventing is available through the Apache project, but this document will not delve into the specific implementation details or usage of WS-Eventing.
This document also provides another example of routing events using web services
Asynchronous request/reply enables multiple replies to be sent back to a requesting client without waiting for a response, making it a complex integration pattern Implementing this pattern through web services is more challenging compared to using Java Message Service (JMS).
Figure 14 – Asynchronous request/reply pattern
In this pattern, a client submits a request to a service that may not be able to provide an immediate response Instead, the service acknowledges the request promptly Once the processing is complete or the requested information is available, the service sends one or more asynchronous replies to the client via a designated URL, topic, or queue.
Clause 6) used to control this exchange include:
• Header.CorrelationID is used to logically link all messages together Where a
CorrelationID is provided by the client on the initial request, the server shall include it on all related response and event messages
• Header.AsyncReplyFlag is set to ‘true’ on the initial request
• Header.ReplyAddress is set on the initial request to identify the destination where replies should be set
Reply.Result indicates the status of responses, where 'PARTIAL' signifies that additional responses may follow, 'OK' confirms that processing is complete with no further responses expected, and 'FAILED' denotes an error condition.
One use of this pattern is to obtain meter readings, where a metering system head end shall request the desired information from one or more meters.
Bus perspective
Clients and servers can communicate directly or through intermediaries, with the enterprise service bus (ESB) facilitating the management of these intermediaries Utilizing an ESB allows for diverse communication patterns, while the client perceives the ESB as an integral part of the communication process.
IEC 1782/13 no different than a server Similarly, the server sees the ESB as being no different than any other client
This is important in that:
• No knowledge of the ESB is imposed upon any client or server implementation of an
• There is no requirement for an ESB product placed upon any IEC 61968 interface, except that a JMS server is needed where JMS messages are to be used
• A project implementation using IEC 61968 can use an ESB and freely implement integration patterns that are appropriate for the project and the associated integrations
Given that an ESB is not required for the implementation of an IEC 61968 interface, the remainder of 5.3 describes recommendations only, and is provided as informative material
ESB messaging pattern using JMS
The basic ESB messaging pattern using JMS introduces the option for routing of requests
The implementation of a Content-Based Router integration pattern enhances the separation between the client and server, allowing the bus to make informed decisions regarding request handling This process is illustrated in the accompanying diagram.
Figure 15 – ESB content-based routing
When a client sends a request to a specific topic or queue, a router on the bus can choose to forward the message to a different topic or queue The router's decision may consider various factors.
• Contents of a message payload (although this should be avoided)
• The status of a destination service instance
• The need to balance load
One key benefit of the loosely coupled approach outlined in this document is that routing components remain independent of specific payload types This flexibility allows the router to be configured with XPath expressions, enabling it to identify message content for effective routing decisions.
ESB messaging patterns using web service request
The following diagram extends the previously described pattern to permit a request to be initiated by a web service client as well as a JMS client
Figure 16 – ESB with smart proxy and content-based routing
A proxy, often called a 'Smart Proxy' integration pattern, is implemented on the Enterprise Service Bus (ESB) to expose a web service defined by a WSDL This Smart Proxy is capable of making decisions regarding the dispatching of requests and the correlation of responses The information conveyed through the WSDL is converted into a JMS message, which is then routed accordingly.
ESB request handling to web service
The following diagram extends the previous pattern to allow for a service to expose its interface as a web service with an appropriately defined WSDL
Figure 17 – ESB with proxies, routers and adapters
Within this pattern, an adapter is implemented within the ESB to convert the internal JMS message to an appropriate web service request
ESB request handling via adapter
The diagram illustrates a modified integration pattern where a server utilizes an interface that does not conform to the specified interface profile This demonstrates that an IEC 61968 compliant interface can effectively integrate with various data sources or sinks, such as servers, databases, or file systems, even if they do not meet compliance standards.
IEC 61968 through the use of an adapter within the ESB Adapters may also be independent of an ESB
Service, Database, File System, etc.
Figure 18 – ESB Integration to non-compliant resources
The integration of the adapter with a non-compliant interface can utilize various integration mechanisms, which depend on the specific capabilities of the ESB product These mechanisms may encompass a range of options.
• File read and/or writes
While JMS and JDBC specifications suggest the use of a Java Enterprise Edition (JEE) framework, they do not mandate it Most databases compatible with JDBC can also be accessed via Open Database Connectivity (ODBC), either directly or through bridge products Additionally, many Enterprise Service Bus (ESB) products that support JMS offer APIs for sending and receiving JMS messages in languages other than Java, such as C and C++ However, utilizing the JEE framework ensures a high level of platform independence.
An integration project often requires the implementation of various custom integration patterns, as referenced in subclauses 5.3.1 to 5.3.5, which highlight the potential use of these patterns as intermediary processes within the Enterprise Service Bus (ESB) These patterns may encompass a range of options, including but not limited to those outlined in the Enterprise Integration Patterns (EIP).
• Content-Based Router, where messages are routed based upon message content typically referenced using XPath expressions
• Smart Proxy, where messages may be re-dispatched to a specific destination service, where replies are accepted from the service and passed back to the client
A Claim Check is a document that retains a copy of a typically large file for use by various processes It tracks the current status of the document, although the document itself is usually transferred through methods other than messaging.
• Transformation, where transformations usually defined by XSL are used to reformat message contents
A bridge facilitates the forwarding and receiving of messages between different messaging infrastructures, allowing for seamless communication across various platforms This functionality can often be achieved through third-party products or straightforward configuration settings.
This standard does not require the use of any specific custom integration pattern Additionally, there are two main philosophies to consider when implementing integration patterns.
1) Patterns are implemented as a single process definition that may be instantiated one or more times to support potentially many information flows, where there are no type constraints
2) Patterns are templates, where the template is used to implement a process to support a specific information flow, resulting in a ‘type-specific’ implementation
This specification advocates for the first option, emphasizing the use of a common message envelope This approach facilitates the utilization of shared implementations of specific integration patterns, rather than relying on type-specific instances of those patterns, highlighting the significant trade-offs between the two philosophies.
General
Each service interface is designed to process messages containing a verb and a noun, where the noun specifies the payload type for requests, responses, or event messages This design promotes loose coupling between the interfaces.
The service interfaces are defined using one or both of the following:
• Web Services Definition Language (WSDL), where request, response and fault messages are defined for one or more operations
XML Schemas (XSDs) are essential for defining the structure of message envelopes and payloads, with the specifics of message payload content detailed in Clause 7.
IEC 61968 messages
IEC 61968-1 prescribes information exchanges in terms of a verb, noun and payload Figure
19 shows the directional flow of messages between clients, servers and the ESB based upon the verb
(applications issuing requests and/ or listening for replies and/or events)
Applications that accept requests and generate replies can create, change, cancel, or delete events These processes involve executing various actions, including creating, changing, canceling, or deleting items as needed.
Figure 19 – Messaging between clients, servers and an ESB Verbs
IEC 61968-1 identifies a set of verbs, where annex B of this standard defines a normative list
This sub-clause clarifies the usage of specific verbs, highlighting deprecated verbs and their synonyms Table 1 links request verbs to appropriate response verbs, which are essential for publishing events that typically result from the successful completion of a transaction initiated by a request.
Table 1 – Verbs and their Usage
The article outlines the usage of various verbs associated with request and reply actions in transaction management The verbs include "get" for querying replies, "create" for initiating a transaction, "change" for modifying a transaction, "cancel" for halting a transaction, "close" for finalizing a transaction, "delete" for removing a transaction, and "execute" for carrying out a transaction Each verb is paired with its corresponding reply status, such as "reply created" for a new transaction and "reply executed" for a completed transaction.
The usage of request verbs are as follows
• ‘get’ is used to query for objects of the type specified by the message noun
• ‘create’ is used to create objects of the type specified by the noun
• ‘delete’ is used to delete objects, although sometimes an object is never truly deleted in the target system in order to maintain a history
• ‘close’ and ‘cancel’ imply actions related to business processes, such as the closure of a work order or the cancellation of a control request
Change is utilized to modify objects, but ambiguities may arise that require clarification through business rules, particularly with complex data sets These data sets often exhibit N:1 relationships, making it crucial to specify whether relationships are additive or should be replaced by an update.
• ‘execute’ is used when a complex transaction is being conveyed using an OperationSet, which potentially contains more than one verb
Each request is addressed using the verb 'reply,' while event verbs typically arise as a result of a request For instance, a 'create' action can lead to the occurrence of a 'created' event.
Events are described using the past tense form of the related request verb It is important to note that events do not necessarily need to be initiated by a request; they can also occur independently of any specific request.
Validation and business rules must be established for the application of verbs in specific scenarios, as many rules exceed the descriptive capabilities of UML and XML Schema.
It is also important to note that the enumerations for verbs in the standard Message XML
Schema use the lower case form The uppercase form is otherwise convenient for documentation purposes
IEC 61968-1 previously identified verbs ‘update’, ‘updated’, ‘show’, ‘subscribe’, ‘unsubscribe’ and ‘publish’, all of which have been deprecated The reason is that ‘show’ is a synonym for
‘reply’, and the verbs ‘subscribe’, ‘unsubscribe’ and ‘publish’ are functions that are performed within the transport layer (e.g using JMS)
Nouns serve to identify the type of information being exchanged, often referred to as profiles Each noun is associated with a unique XML Schema definition defined by a specific namespace Typically, nouns are identified based on their use cases.
In a message, nouns serve to specify the type of payload or the object that is being acted upon or has already been acted upon Common examples of such nouns, as outlined in IEC 61968-9, include various classifications relevant to the context.
Nouns can be defined as needed to distinguish the contents of different information flows
They need not be defined as classes in a UML model, but instead the contents and structure of the noun are defined using classes, attributes and relationships from a UML model
Nouns represent payload structures usually expressed through XML documents adhering to an XML Schema These payload structures are often outlined as contextual profiles derived from UML models, following the methodology established by IEC 61968-9 for defining message structures.
Figure 20 is an example payload structure that results from the contextual profile definition:
Depending upon the situation, a payload may or may not be required in a message A message payload is required for the following cases:
• When issuing an ‘change’ request
• When issuing an ‘execute’ request
• In a reply message for a successful ‘get’ request
• For any event message (‘created’, ‘changed’, ‘deleted’, ‘closed’, ‘canceled’ or ‘executed’)
When an event results from a transactional request and both share the same noun, the request's payload is duplicated as the event's payload.
A message payload should not be used in the following cases:
• In a reply message for an unsuccessful ‘get’ request in which no results are returned
• In a reply to a ‘create’, ‘change’, ‘delete’, ‘close’, ‘cancel’ or ‘execute’ request
• In a ‘delete’, ‘close’ or ‘cancel’ request, since the ID of the object(s) is specified using the
• In a ‘get’ request, as the parameters used to filter the request are supplied in the message
Request element, optionally using a ‘Get’ profile in the Request.any element.
Common message envelope
Unless otherwise specified, all messages use a common message envelope (CME), where a predefined stereotype is used for requests and another stereotype is used for responses
There are also stereotypes for events and faults This structure is based upon the
IEC 61968-1 recommendations Messages are constructed with several sections, including:
• Header:Required for all messages (except for fault response messages), using a common structure for all service interfaces
The request parameter is optional and is used to define commonly utilized qualifiers for 'get' queries or to identify specific objects for 'delete', 'cancel', or 'close' requests It allows for the inclusion of a complex structure through the Payload.any element For instance, when requesting MeterReadings, a profile named 'GetMeterReadings' can be established to pass the necessary request qualifiers, following the naming convention 'Get' This parameter is not applicable for event or response messages.
• Reply: Required only for response messages to indicate success, failure and error details
Not used for request or event messages
The payload is essential for conveying message information derived from the combination of the 'Verb' and 'Noun' in the message header It is mandatory for 'create', 'change', and 'execute' requests, as well as for event messages In other scenarios, as detailed later in this document and in annex B, the payload is optional Additionally, the payload structure allows for options regarding payload compression.
Figure 21 provides a generalize view of the high-level message structure:
From this common message envelope there are four stereotypes which identify the specific subset of elements that are used for requests, responses, events and faults:
Stereotypes are valuable for defining interfaces that distinguish between requests, responses, events, and faults However, it is common practice to utilize a more generic Message structure internally within software, including common services and intermediaries.
Common to request, response and event messages is a header structure The header currently has two required fields that must be populated, these include:
To identify specific actions, a defined set of valid verbs is utilized, including 'get', 'create', 'change', 'cancel', 'close', 'execute', and 'reply' In event notification messages, past tense verbs such as 'created', 'changed', 'canceled', 'closed', and 'executed' are employed Additionally, implementations should consider the deprecated verbs 'update' and 'updated' as synonymous with 'change' and 'changed'.
• Noun: to identify the subject of the action and/or the type of the payload, such as
Field that can be optionally supplied include the following:
• Revision: To indicate the revision of the message definition This should be ‘1’ by default
ReplayDetection is a crucial security feature designed to prevent replay attacks by utilizing a timestamp and a nonce The timestamp, generated by the source system, marks the creation time of the message, while the nonce serves as either a sequence number or a randomly generated string to ensure uniqueness.
(e.g UUID) that would not be repeated by the source system for at least a day This serves to improve encryption
A context string serves to identify the message's context, offering an application-level safeguard against improper message consumption in environments where multiple systems operate on the same messaging infrastructure Examples of context values include PRODUCTION, TESTING, STUDY, and TRAINING.
• Timestamp: An ISO 8601 compliant string that identifies the time the message was sent
This is analogous to the JMSTimestamp provided by JMS Either Zulu (‘Z’) time or time with a time zone offset may be used
• Source: identifying the source of the message, which should be the name of the system or organization
• AsyncReplyFlag: A Boolean (‘true’ or ‘false’) that indicates whether a reply message will be sent asynchronously Replies are assumed to be sent synchronously by default
The ReplyAddress is the designated location for sending replies, primarily utilized for asynchronous communication It can be formatted as a URL, topic name, or queue name, similar to the JMSReplyTo field in JMS This address is not applicable in one-way integration patterns, such as AckRequiredse When specifying a topic, it should be prefixed with 'topic:', while a queue name should be prefixed with 'queue:' For web services, the ReplyAddress must be a URL that starts with 'http://' or 'https://'.
AckRequired is a Boolean value that signifies whether an acknowledgement is necessary When set to false, it indicates the use of a one-way integration pattern for transmitting transactional messages.
The User structure is essential for identifying both the user and their associated organization, and it may be necessary for certain interfaces based on the underlying implementations This structure includes a UsersID string and an optional Organization string as sub-elements.
A MessageID is a unique string that identifies a message, and it is advisable to use a UUID or a sequence number for this purpose This concept is similar to the JMSMessageID in JMS It is crucial that a process does not send two messages with the same MessageID value.
The CorrelationID serves to connect related messages, allowing clients to associate replies with their corresponding requests When a request includes a CorrelationID, the server will use this value in the outgoing reply If the request does not provide a CorrelationID, the server will set the reply's CorrelationID to the MessageID from the request, if available This mechanism ensures effective tracking and management of message exchanges.
The JMSCorrelationID, supplied by JMS, serves to connect related messages, allowing for its reuse across multiple messages It is advisable to utilize a UUID or sequence number for this purpose.
• Comment: Any descriptive text, but shall never be used for any processing logic
A property is a complex type that facilitates the communication of custom name/value pairs, requiring agreement on usage between the source and targets This concept is similar to the definition of a property in JMS.
• any: Can be used for custom extensions
Figure 22 describes the header structure used for request, response and event messages
Figure 22 – Common message header structure
Where there are only two required elements, verb and noun, there are many optional elements that may be populated In Figure 22, the optional items are represented using dashed borders
The following is an XML example for a message that populates all header fields
dcd98b7102dd2f0e8b11d0f600bfb0c093
queue:EMS.ReplyQueue
When using transport methods like SOAP or JMS, there is often redundancy between the optional fields in the message envelope and the transport-level header In such instances, both fields can be assigned the same value However, if the values differ, they should be utilized appropriately for the transport-level and application-level message envelope.
Figure 23 describes the structure of a request message that would be used in conjunction with a message or WSDL operation
The RequestMessage may include an optional element known as Request, which contains parameters pertinent to the request A significant advantage of using RequestType is that it helps prevent the inclusion of application-specific request parameters in the header or within the payload definitions.
There are no required elements in the Request element The usage of elements within the
Request element is described as follows:
• StartTime: Used when a query needs to specify a start time as a filter, but no such parameter is provided in a ‘Get’ profile If both exist, this will be ignored
• EndTime: Used when a query needs to specify an end time as a filter, but no such parameter is provided in a ‘Get’ profile If both exist, this will be ignored
Payload structures
Subclause 6.4 outlines two types of payload structures: generic and type-specific The common message envelope indicates a generic payload, which is typically used in both JMS and generic web services Conversely, strongly-typed web services defined by WSDLs may necessitate a type-specific payload definition within a variant message envelope.
Certain message types require a Payload, particularly request messages with 'create' or 'change' verbs, along with some response and event messages Typically, these Payloads consist of XML documents that adhere to a specified XML schema However, exceptions exist; for instance, some XML payloads may lack meaningful schemas, such as RDF files or dynamic query results, and non-XML formats like CSV and PDF may also be used.
In situations where a large payload needs to be compressed to prevent excessive network bandwidth consumption, it is essential to utilize a flexible payload structure that can support various format options.
Figure 35 – Message payload container – Generic
Subclause 6.10 discusses the use of the OperationSet element for complex transactions in more detail
The generic message payload container allows for the inclusion of any XML document through the XML 'any' structure, facilitating loose coupling Additionally, it supports the use of specific complex types defined by XML schemas (XSDs).
In certain situations, a zipped, base64 encoded string is required and is indicated by the 'Compressed' tag in the message It is essential to perform base64 encoding after compression, and the 'Compressed' element is utilized even when binary data is not compressed To ensure compatibility with both Java and Microsoft Net implementations, Gnu Zip compression should be employed For practical guidance, a Java example can be found in Annex F Payload compression is particularly useful in specific scenarios.
• An XML payload, conforming to a recognized XML schema exceeds a predefined size (e.g
1 MB, 5 MB, 10 MB, etc.) This would be common for model exchanges and energy market transactions
• A payload has a non-XML format, such as PDF, Excel spread sheet, CSV file or binary image
• A payload is formatted using XML, but has no XML schema and exceeds a predefined size
(e.g 1 MB, 5 MB, 10 MB, etc.) An example of this would be the case of dynamic XML generated as a consequence of a SQL XML query that would return an XML result set
When a payload is compressed and base64 encoded, it is stored within the
To ensure efficient transfer of binary data, it can be base64 encoded without compression, particularly for high-speed data where XML formatting may not suffice.
The ID element and its attributes serve to provide object or transaction identifiers, particularly in scenarios where a payload lacks these identifiers This is often the case for requests or responses related to cancel, close, or delete actions, as well as events associated with the canceled, closed, or deleted verbs.
The Format element can be used to identify specific data formats, such as XML, RDF, SVG,
The use of various file formats such as BINARY, PDF, DOC, and CSV is particularly beneficial for handling base64 encoded and potentially compressed payloads This tag is optional and is generally applied when the payload is stored using the Payload/Compressed message element Table 2 illustrates the relationships between elements in the Payload, highlighting a diverse range of payload options.
Any OperationSet Compressed Format Interpretation
XML null null Null or
‘XML’ Message payload is contained within the
The article discusses the common usage of the term 'any' in relation to the header Noun It highlights that the XML message payload is compressed and encoded in base64 within the Compressed element, with its contents also described by the header Noun.
‘XML’ Complex transaction is being conveyed using the OperationSet element, where the header Verb is ‘execute’ or
The message payload can include various document formats conveyed through the 'Compressed' element These formats include RDF, which can be either a standard RDF document or a compressed version; PDF, XLS, DOC, and TEXT files, all of which are compressed; as well as CSV files and JSON objects Additionally, a GZIP archive may contain one or more files, while a BINARY structure is base64 encoded but not compressed The system also allows for the definition of custom format values for other compressed file types.
These payload options offer a simpler alternative to SOAP attachments, which are harder to secure due to the SOAP envelope signature only covering the body and not the attachment This necessitates separate processing of the payload from the SOAP message, involving additional parsing steps In contrast, our implementation approach is less complex than that of using SOAP attachments.
Strongly-typed payloads
When defining strongly-typed WSDLs for operations that combine specific verbs and nouns, the common message envelope is modified through two key substitutions.
• Root element “Message” replaced with a WSDL operation name such as
“CreateEndDeviceControls” This address a Web service “wire signature” issue if multiple operations reference a same XSD element
• Payload contains a concrete message type element such as EndDeviceControls
As a result, a message structure for CreateEndDeviceControl request service operation is then redefined as shown in Figure 36:
Figure 36 – Message payload container – Type specific example
The Message element has been renamed to CreateEndDeviceControls in this service definition, with the Payload element now containing a specific object called "EndDeviceControls," which is based on a CIM profile A significant distinction is the strong typing of the payload element, contrasting with the use of 'any' in the standard.
Message.xsd This results in a type-specific version of Message.xsd per each IEC 61968 profile in use See section
8.3 and annex C for further details.
SOAP message envelope
SOAP has been widely used as a standard protocol specification for exchanging XML information using web services It provides an envelope that contains a header and a body
How a SOAP message is structured can be defined in WSDL binding section as an example listed in Figure 37:
CreatedEndDeviceControl binding
In this WSDL, it is specified that where an input / output payload is located (soap:body – highlighted) and what binding style (=document – highlighted) it follows
Based on the WSDL binding information, a SOAP message (see below) can be constructed
When using SOAP the message structure will appear within the context of the SOAP Body
This is shown in Figure 38
Figure 38 – SOAP envelope example for strong typing
Request processing
A request message is sent from a client to a service to initiate a query or transaction, where a response message is typically expected The basic sequence of request processing is as follows:
1) Client constructs a request message using a common message envelope and specifying a verb and a noun The noun identifies the type of the payload
The client initiates a request by sending a message to the relevant service interface, utilizing transport technologies like JMS or web services The Enterprise Service Bus (ESB) implementation can seamlessly incorporate intermediaries, including proxies, routers, and adapters, to effectively route the request to the correct service instance.
3) The server accepts the message
4) If the request message is invalid (e.g incomplete, XML not well formed, etc.), a fault message may be returned to the client and processing terminates
The service analyzes the combination of verbs and nouns to assess whether the request can be processed If the request is deemed unprocessable, an error response message is sent to the client.
IEC 1806/13 processing terminates This step can also consider checks for authentication and authorization
The service efficiently processes and parses the payload as required, utilizing an appropriate XML schema to define the payload type indicated by the message noun It employs various methods such as XPath expressions, XSL transformations, and other mechanisms for parsing Additionally, the service takes into account parameters provided in the message header and request packages during processing.
A response message is generated with a payload corresponding to the noun type required, typically in reaction to a 'get' request The message reply element should indicate either a Result of 'OK' or an appropriate error code.
8) The response message is returned to the client This can use web services, JMS or other transport technologies as expected by the client
9) The client processes the response message, parsing the payload as needed The client should examine the reply element of the message to see if the request was successful
(i.e Result=’OK’) or encountered one or more errors
Clients must be prepared to manage various failure scenarios that may arise between steps 2 and 8, particularly when dealing with faults or timeouts while awaiting responses to requests.
Event processing
An event message is a message that is published by a service (or more generally any event publisher) to potentially many listeners Events may also be referred to as ‘notifications’
Event listeners are entities that subscribe to various JMS topics of interest In the context of web services, an intermediary is utilized to relay events to subscribers who are listening through these services.
The basic sequence of event processing is as follows:
A service generates an event message by utilizing a standard message envelope, which includes a specified verb and noun The noun serves to identify the payload type, although it's important to note that not every event message will contain a payload.
The service transmits the event message to the designated JMS topic, while the ESB implementation can seamlessly utilize intermediaries like routers and adapters to deliver the event to the correct event listeners.
3) The listener accepts the message
4) If the event message is invalid (e.g incomplete, XML not well formed, etc.), processing terminates (typically after an error is logged)
5) The listener looks at the verb and noun combination, determining if the event can (or should) be processed, if not, processing terminates
The listener processes the payload by parsing it according to the required specifications This may involve utilizing an appropriate XML schema to define the payload type, employing XPath expressions, applying XSL transformations, or using other relevant methods.
When transactional request messages (see 4.5) are processed on the bus that use the verb
‘create’, ‘change, ‘close’, ‘cancel’ or ‘delete’, a corresponding event should be published using the corresponding past tense verb (e.g ‘created’, ‘changed, ‘closed’, ‘canceled’, ‘deleted’ or
After the successful execution of a transaction, a confirmation should be issued by either the service that processed the request or a bus component In such instances, the payload will be identical to that of the original request message used to initiate the transaction.
The delivery guarantees are a consequence of the definition of the specific JMS topic or queue, as well as the means by which a listener subscribes (e.g durable subscription).