Actors and the Specification

Why do they use the term Actor in the CTS specification?

Does this mandate a particular architecture?

Why are there facets instead of WSDL?

Several comments are in this space. Please add your own comments on these thoughts.

From: Holmberg, David G. (Fed) <david.holmberg@nist.gov>
Sent: Thursday, January 27, 2022 10:14 AM
To: Toby Considine <toby.considine@outlook.com>; William Cox <wtcox@coxsoftwarearchitects.com>
Subject: RE: IEEE (and modern systems) use of Actor - references and guidance

Seems this would be a conversation that belongs on the list to engage a few others maybe.

From: Toby Considine <toby.considine@outlook.com>
Sent: Thursday, January 27, 2022 10:07 AM
To: William Cox <wtcox@coxsoftwarearchitects.com>; Holmberg, David G. (Fed) <david.holmberg@nist.gov>
Subject: RE: IEEE (and modern systems) use of Actor - references and guidance

Too long, but I believe accurate…

The Actor model treats "Actors" as the universal primitives of concurrent digital computation. The model provides both a framework for a theoretical understanding of concurrency and a basis for implementations of concurrent systems. Principles of the Actor model include:

Persistence. Information is collected and indexed.
Concurrency: Work proceeds interactively and concurrently, overlapping in time.
Quasi-commutativity: Information can be used regardless of whether it initiates new work or becomes relevant to ongoing work.
Sponsorship: Sponsors provide resources for computation, i.e., processing, storage, and communications.
Pluralism: Information is heterogeneous, overlapping and often inconsistent.
Provenance: The provenance of information is carefully tracked and recorded

The advent of massive concurrency through client-cloud computing and many-core computer architectures has increased the use of the Actor model.

In the Internet of Things (IoT), the term Actor is used 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 inconsistency robust information integration.

In transactive energy, we see the diversity supported by the Actor model. 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 a 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 resource market. An actor submits tenders to buy or to sell. An Actor may operate a market. An Actor may provide telemetry on metering; that telemetry may be collocated with the Actor buying or selling, or it may be on another Actor, perhaps owned by another party, that is registered as associated with the market participating Actor. This specification makes no requirement as to how these facets

This specification defines message content and Actor interaction patterns. [EI] assumed web services for interactions. 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.

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. As best practices in the cloud evolve to zero-trust within distributed applications, the distinctions of within or without the cloud become less important. 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 cloud-native computing. The authors of this specification have been informed by cloud-native computing, and we use the term “facet” to indicate message end-points that an implementer may distribute over one or more Actors to build a conforming application.

From: William Cox <wtcox@coxsoftwarearchitects.com>
Sent: Monday, January 24, 2022 5:28 PM
To: Toby Considine <toby.considine@outlook.com>; Holmberg, David G. (Fed) <david.holmberg@nist.gov>
Subject: Re: IEEE (and modern systems) use of Actor - references and guidance
Importance: High

BTW the paper you sent earlier was from the Association for Computing Machinery (ACM) Design Automation Conference 1999, not an IEEE event, and is at a useful level. Reference (in the paper) is

ACM Reference Format:
Marten Lohstroh, Martin Schoeberl, Andrés Goens, ArminWasicek, Christopher
Gill, Marjan Sirjani, and Edward A. Lee. 2019. Invited: Actors Revisited
for Time-Critical Systems. In The 56th Annual Design Automation Conference
2019 (DAC ’19), June 2–6, 2019, Las Vegas, NV, USA. ACM, New York, NY,
USA, 4 pages. https://doi.org/10.1145/3316781.3323469

Note the narrow focus of the actor history on realtime systems, which I think is a defect.

The IEEE draft is not IMO very compelling - I don't think it's easily referenceable, and it's convoluted. given all of the metadata, in fact I think it's confusing. (Smells a bit of TOGAF as well). And its focus (when it gets to a reviewable state) is describing multidimensional spaces of actors. References are largely useless for actor system practitioners.

Of the two, the ACM DAC paper is far superior as a reference, as the succinct early section has decent references.

With a broader search, there's the original formulation by Hewitt 1973 (mis-cited in Lohstroh unless there actually is a "Standford, CA"), paper attached. I don't think this (though first) is a very useful reference. Paper attached.

I find Hewitt 2010-2015 to be a better introduction - attached. Updated to include IOT discussion and more, and a more general introduction/backgrounder than Lohstroh.

Thanks!

bill

On 1/21/22 10:55 AM, Toby Considine wrote:

I am thinking of stealing some language from this:

See sections 5.3 and 5.4

William Cox

Email: wtcox@CoxSoftwareArchitects.com

Web: http://www.CoxSoftwareArchitects.com

+1 862 485 3696 mobile

energyinterop message