Refining the Architecture Language

Architectural Background and Language

This specification defines message content and Actor interaction patterns. [EI] assumed web services for interactions. That specification and this assume a service orientation, which focus on focuses on the desired results rather than the requested processes. Service orientation complements loose integration. Service orientation organizes distributed capabilities that may be in different ownership domains. As in that document, no requirement or expectation of specific messaging implementation is assumed.

In modern cloud architecture, applications are decoupled into smaller, independent building blocks that are easier to develop, deploy and maintain. Message queues provide 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. Producers can add requests to the queue without waiting for them to be processed. Consumers 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 system that acts. The Actor may be a traditional computer, a cloud node, a human embodied behind a user interface, or any device in the Internet of things. The Actor model is used to provide a foundation for robust information integration.

In transactive energy, we see the diversity supported by the term Actor. 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. The common transactive services are intended to be common to all actors in Resource markets.

We use the term “facet” to name a set of interactions that an Actor may use in a market. An actor submits tenders to buy or to sell. An Actor may operate a market. An Actor may provide telemetry (meter information) either as a one facet of many on an Actor that is buying or selling power or as a stand-alone service on an Actor associated with an Actor that is buying or selling power. This specification makes no requirement as to how these facets will or should be distributed.

There is a growing use of the term “cloud-native computing” to name extending the architecture and technologies developed for use in central clouds beyond data centers to remote systems, including to IoT devices. This includes using zero trust for all interactions between Actors, even between distributed components within an application hosted in a common cloud [ZeroTrust]. Under zero trust, no Actor is inherently trustworthy and each should be treated as a potential threat. Every device and person accessing resources on your network must be authenticated and authorized.

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. The authors for this specification have been informed by cloud-native computing, just as the authors of [EI] were informed by SOA and web services.

[ZeroTrust]

NIST Special Publication 800-207

Zero Trust Architecture

Scott Rose, Oliver Borchert, Stu Mitchell, Sean Connelly

https://doi.org/10.6028/NIST.SP.800-20

August 2020

energyinterop message