COMMON SERVICES
OBEDA comprises simple common application services to manage event-defined objects (EDOs) within a system of interoperable systems. These systems can span the subsystems of IoT devices, businesses, humans, vehicles, and cities. To scale, these services must be stable, unchanging, transport-independent, and embeddable in any type of machine, from edge controllers to cloud servers.
Common application services provide the proper encapsulation, abstraction, and decoupling of contextual event producers and consumers, and the required mechanisms for append-read, pub-sub, request-reply, and system discovery and addressing for both device and business systems.
The same common services that alter the state of connected devices (e.g., controllers and actuators) can also be used to alter the state of information objects (such as an order) associated with connected business systems. The services can also manage event-defined ontology objects, transcending legacy modeling tools.
Identifiers of core ontology objects within EDOM are tightly coupled to the common application services to effectively support the semantic heterogeneity of events in large and open implementations such as supply chains and smart cities. Together, the common ontology and application services manage system connections, unified data exchange, event and query processing, unit and identifier conversion, and microservice orchestration.
COMMON API GATEWAY
Rather than exposing a myriad of application-defined services (typical SOA services), the common API gateway is implemented within a controller device as the single entry point for all inbound messages from other devices. By exposing a single common API as the “front door” for all controller devices, the complexity of different device types and partitioning of microservices is abstracted away. The device can then be turned into a service (information system) and used by other services.
The gateway authenticates each message and forwards the de-serialized payload to an application service, which might in turn invoke other services that generate outbound messages handled by the gateway.
Based on the type of message payload (specified in the message header), the gateway invokes separate event and query-processing services, which can append and read the state of objects that persist in an event store. The gateway can also invoke a service adapter to process a payload based on a disparate data standard and return a conforming format for the common application services.
EVENT PROCESSOR
The common API gateway invokes the Event Processor service to process an inbound BEAMevents grid which can produce outbound event grids published to connected device systems via the system registrar.
The event processor is a consumer of contextual events and can orchestrate the processing of events among all system processes (domain microservices) based on their rules, which can lead to additional contextual events being produced and processed.
Upon receiving a BEAMevents grid, the event processor replaces any repeated value (ditto) marks with the actual value of an element from the previous row and invokes identifier and unit convertor services to normalize contextual events prior to rule evaluation.
The event processor appends contextual events, and any supplemental elements, to an event store to persist state. Supplemental elements can comprise data integrity/traceability values such as a connection or process identifier or blockchain hash.
QUERY PROCESSOR
The Common API Gateway invokes the Query Processor service to process an inbound BEAMqueries grid and return an outbound BEAMresults grid to the gateway to return to the requesting service.
The query processor reads contextual events within one or more event store to generate query results that reflect the state of one or more objects at a specific point in time (e.g., current). Query responses can comprise the state of device and information objects based on these contextual events.
UNIT CONVERTER
The Event Process service invokes the Unit Converter service to convert alternate measurement units within an inbound BEAMevents grid to primary units based on the common ontology. A materialized view (Values Grid B) coupled to the Unit Converter comprises values of the “Base Unit”, “Conversion Factor”, and “Conversion Offset” attributes of Unit objects.
For example, the “Unit” element within a BEAMevents grid identifies a Unit object representing the temperature measure unit “Fahrenheit”. The Unit Converter filters the materialized view based on this identifier and converts the values of the “Value” and “Unit” elements of the contextual event based on the filtered element values within the view. The “Value” element is converted from 76 to 58.2 and the “Unit” element is converted from Fahrenheit to the primary temperature unit “Celsius”.
IDENTIFIER CONVERTER
The event processor invokes the identifier converter service to convert alternate object identifiers within an inbound BEAMevents grid to primary identifiers based on the common ontology.
For example, the conversion service can convert alternate identifiers generated by an RFID sensor driver based on GS1’s EPCIS standard. In this example, the “Object” element within a BEAMevents grid comprises the value (“urn:epc:id:sgtin”) of the “Namespace” attribute for an Identifier attribute (“GTIN+Serial”) in addition to the alternate identifier (“…107346.2017”) of an Inventory object. The “Value” element comprises the value (“urn:epc:id:sgln”) of the “Namespace” attribute for an Identifier attribute (“GLN”) in addition to the alternate identifier (“…00001.0”) of a Location object.
A materialized view (Values Grid C) coupled to the identifier converter comprises values of the “Identifier” and “Namespace” attributes of Identifier objects. The identifier converter filters the materialized view based on the namespace values and converts the value of the “Object” and “Value” elements of the contextual event to the corresponding “Identifier” element value within the view. The “Object” element is converted from the alternate identifier “…107346.2017” to the primary identifier “H023…” and the “Value” element is converted from the alternate identifier “…00001.0” to the primary identifier “277F…”.
SYSTEM REGISTRAR
The system registrar service produces events defining system connections based on the common ontology. The common API gateway invokes the system registrar to validate authentication credentials within message headers based on these system connections, and the system registrar invokes the common API gateway to distribute contextual events to connected systems based on shared attributes.
Ad-hoc networks of smart devices and services need to be constantly formed and re-formed to manifest transient value systems. The system registrar provides a mechanism to create an interoperability context which does not rely on prior knowledge. An event store acts as a service registry that stores contextual events defining system connections and the attributes of connected systems.
As illustrated, the system registrar of an HVAC system controller can produce contextual events defining a requested system connection with an Airflow system controller. These events comprise a BEAMevents grid that is transported via gateways to the system registrar of the Airflow system controller.
The system registrar of the Airflow system controller approves the requested connection by producing a contextual event within a BEAMevents grid that sets the value of a “Key” attribute of the new System Connection object. (The key value is included in authentication credentials). The system registrar also retrieves contextual events defining System Attributes of its Airflow system and includes them in the BEAMevents grid which is transported back to the system registrar of the HVAC system controller. The event processor on both devices appends the events defining the reciprocal system connection and attribute objects to its event store (as the system registry) which triggers an update to the materialized view coupled to their system registrars.