Removed "Implied Architecture" sub-section from Section 2.
Updated introduction on use of Actor and Facet terminology throughout
This specification defines message content and interaction patterns.
The Energy Interoperation specification [EI], now a decade old, presumed web services for interactions. That specification described a Service-Oriented Architecture (SOA) approach. SOA focuses on the requested results rather than the specific process used. Service orientation complements loose integration and organizes distributed capabilities that may be in different ownership domains. [EI] uses the language of web services to describe all interactions.
There is a growing use of the descriptive term “cloud-native computing” for extending the architecture and technologies developed for use in clouds not only in data centers but to edge computing, where IoT devices reside. A discussion of the rapidly-evolving topics of cloud-native computing and edge computing is beyond the scope of this specification.
At the time of this specification, typical architectures decompose applications into smaller, independent building blocks that are easier to develop, deploy and maintain. Message queues provide loosely-coupled communication and coordination within and among these distributed applications. Message queues enable asynchronous communication, i.e., the endpoints that are producing and consuming messages interact with the queue, not each other. Publishers can add requests to the queue without waiting for their processing. Subscribers process messages only when they are available.
In the Internet of Things (IoT), the term Actor is preferred as it makes no assumptions of the mechanisms or even motives internal to an Actor. An Actor is simply a thing that acts. The Actor implementation may be by a traditional computer, a cloud node, a human behind a user interface, or any device in the Internet of things.
In transactive energy, we see the diversity supported by the term Actor in the IoT. An energy seller may be a generator or a solar panel or a virtual power plant or a demand responsive facility or a financial entity. An energy buyer may be home or a commercial facility or an embedded device or a microgrid or an energy district. A marketplace acts to match tenders, but may also buy or sell power. An energy storage system may act as a buyer or as a seller at any time.
Architectures MAY decompose applications into smaller independent Actors. We use the term “Facet” to name a coherent se of interactions that such an Actor may use to communicate with other Actors. An Actor submits tenders to buy or to sell. An Actor may operate a market. If the architecture requires telemetry for resource flow (metering), one of many facets supported by a resource-consuming Actor MAY provide it, or separate Actor MAY present only the telemetry, logically and physically separated from the resource-consuming Actor. This specification makes no requirement as to how to distribute these facets.
While this specification discusses messages between Actor, directed by and to Facets, it establishes no requirement or expectation of specific implementation. While this specification uses the language of Actor and Facet, there is no architectural expectation linked to this language. One could apply the terms Actor and Facet throughout the [EI] specification. A traditional [EI] application consisting of a several unitary systems each presenting all facets as web services described by WSDL can be conformant so long as it uses a compatible set of information payloads.
A discussion of the rapidly-evolving topic of cloud-native computing is beyond the scope of this specification. This specification does not require that implementations conform to any specific implementation of cloud-native computing. Cloud-native and edge computing have informed the language of this specification, just as web services and SOA informed [EI].
Expanded existing text on when and how to use a market ID as a counterparty, including when a group matching approach is used.
The essence of any transaction is the agreement of a party to sell, and a party to buy. The identity of the buyer and the identity of the seller are each part of the transaction. Some transaction notifications may hide the identity of the buyer from the seller. Some transaction notifications may hide the identity of the seller from the buyer. Some transactions, such as double auction, may be between the market as a whole, and not with any particular counterparty. Where this is required, the market itself may be designated as the counterparty in a notification.
Critical