Clients and Consumers in EDA Freeze 3
The standards in EDA Freeze 2 use the terms “Client” and “Consumer” interchangeably, as the most common scenario described is a software application that is both a Client and a Consumer. In real life, equipment users want to support scenarios where this functionality is separate, so this interchangeability causes confusion. EDA Freeze 3 will better distinguish these scenarios so interactions and expectations are clear.
At a high level, the difference between Clients and Consumers is this:
- A Client Session looks after management functions and is associated with one SessionID. For example, the E132 Client Session will call EstablishSession(), send SessionPing() to the Equipment Server, etc. The E134 Client Session will call GetActivePlanIds(), DefinePlan(), ActivatePlan(), etc.
- A Client Application is a software application that implements one or more Client Sessions.
- Consumer Sessions get notifications from equipment. Each Consumer Session is associated with an endpoint and one SessionID. For example, the E132 Consumer Session will respond to SessionPing messages from the Equipment Server and receives notification messages. The E134 Consumer Session will receive NewData messages.
- A Consumer Application is a software application that implements one or more Consumer Sessions.
The Security Admin Agent is simply a special version of the Client Session that is allowed to use the SecurityAdmin interface via the security administration account.
There are three use cases that will be supported.
Use Case 1 – Client and Consumer are together
This is the traditional scenario, where EDA Client and Consumer are run together in the same software application. In this situation:
- The user connects to the Equipment Server, defines collection plans, and activates them.
- The Equipment Server starts sending the data to that same computer.
- The Client Session and Consumer Session can easily share information (such as SessionID).
Use Case 2 – Client and Consumer are separate
Clients and Consumers could be on different machines or in different software applications.
In this situation,
- The User decides which Consumer (Endpoint) should receive the data. They establish a session on the Equipment Server, define collection plans, and activate them.
- Equipment Server starts sending the data to the Consumer Session on that endpoint.
This scenario is good for situations where the Consumer Session does not need to know anything about the data it is receiving. For example, a database backup utility that simply takes all the data it receives and records it, or a simple analytics component. The Consumer Session is unable to do any management functionality (including activating the data collection plans). If it needs any information from the Client Session (for example, the SessionId), it will need to be shared by the software outside of the EDA Standards (this is an implementation detail).
Use Case 3 – Only Configuration
In this scenario, the Client Session will only do configuration work. It is not interested in receiving any data from the Equipment Server, and does not want to deal with any SessionPing messages from the Equipment Server. In this situation, the User establishes the connection to the Equipment Server and does configuration work (such as defining collection plans).
The Primary Standards (SEMI E132, E134, E125) are being updated by the DDA Task Force to correctly reference Client Session and Consumer Session. Additionally, there will be better support added for the dedicated Consumer Session use case scenarios by defining the ChangeSessionEndpoint() operation that Client Sessions can use to redirect data to a different endpoint, and by updating the SessionPing error handling scenarios.
Contact us to learn more.