Ohara Lab

SUSANOO System Architecture

Back to the home page

DeviceClass and transparent proxies

The DeviceClass running on the instrument side performs the actual instrument operations. A network client invokes its exposed API through a DeviceProxy or communication client. This provides a Python-like calling interface, often described as a transparent proxy, but does not replicate the DeviceClass instance on the client.

Direct local use of a DeviceClass requires no communication Frame. Network use introduces boundaries for execution location, file I/O, serialization, disconnections, timeouts, and error propagation.

Execution location and side effects

For example, a file-save method implemented on a server-side DeviceClass normally writes to the server’s filesystem. To save data on the client, design an API that returns the data for the client to save, or otherwise explicitly defines where the operation runs. A transparent proxy does not automatically relocate side effects.

Responsibilities of the communication Frame

Client side                             Instrument side
Application
    ↓
DeviceProxy / Client ── Network ── Frame / Server
                                          ↓
                                       DeviceClass
                                          ↓
                                       Instrument

ese774 Frame uses FastAPI/HTTP; gRPC Frame uses gRPC. DeviceClass implements instrument behavior; Frame handles request/response conversion and error propagation at the transport boundary. Instrument-specific error handling need not be moved into the communication layer.

Dynamic dispatch and explicit APIs are not mutually exclusive. ese774 Frame can combine dynamic exposure with dedicated routers and Pydantic API definitions. gRPC Describe is a method-discovery mechanism distinct from OpenAPI.

References

Author