Terms & Definitions
Term | Definition |
|---|---|
BROKERED Mode/Architecture | The Brokered Architecture securely and reliably connects N Service Consumers to a dynamically changing list of M Service Providers through a centrally secure, separate and discrete Message Broker. The Brokered Architecture offers a superset (rather than replaces) the functionality of the DIRECT Architecture. As a result, any Service Consumer interoperating successfully in a Direct Architecture can be redeployed into a Brokered Architecture without reprogramming. |
Context or SIF Context | A Context is optional Data Model-specific metadata that may accompany a Consumer Request as a way of further scoping and restricting the respond data. For example, a supplied Context might indicate that the Student Provider Service being requested in Zone XYZ is the one dealing with currently enrolled students, rather than the formerly enrolled students. More details can be found on the SIF Context page. |
DELAYED Request/Response | The Consumer issues the Request which is replied to with an “Accept” (HTTP status code 202) in the immediate HTTP response, which indicates “Request is legal and can and will be delivered to the indicated Service Provider”. This frees a single-threaded Consumer to do other things. The Response issued by the Service Provider arrives asynchronously at a later time, in a manner identical with that of an incoming Event. It contains the Message ID of the original Request it completes. See also https://a4ldocumentation.atlassian.net/wiki/spaces/ARCHITECTU/pages/56000581 page. |
DIRECT Mode/Architecture | A Direct Architecture connects a single Consumer to a fixed set of one or more directly accessible Service Providers. A Direct Architecture conceptually does not leverage middleware. All Consumer to Provider connections are direct (no intermediary). Each Service Consumer is operating in an Environment of its own, and has no knowledge of any other Service Consumers. Direct Architecture standardizes SIF-compliant message exchanges between Service Consumer and Service Provider in the absence of a central Message Broker. |
Entity Service | See Object Service |
Functional Service | A Functional Service encapsulates stateful process behavior as well as the data exchanged between applications implementing that process. It does this by supporting all four methods of a Data Object Service Provider interface but applies them to Jobs Phases rather than Data Objects. When a Consumer issues a “create” Request to a Functional Service, it results in the creation of a new executing instance of the Service (a “Job”) rather than a new instance of a data object. From a conceptual point of view, each Job instance contains a set of named “phases”, identical to every other Job created by that Function Service. These discrete phases define and encapsulate the sub actions, which need to be done, but they do not explicitly determine the ordering (since the phases defining a Function may be executed in different order, depending upon the implementation and the needs of the site where the Functional Service is deployed). Once created, the Job instance can be queried to find out where in the process it is (what is happening, what is the current status of each completed phase), and the Job instance may issue Events. For more details refer to https://a4ldocumentation.atlassian.net/wiki/spaces/ARCHITECTU/pages/121995388. |
IMMEDIATE Request/Response | The Response to a Request is provided synchronously in the immediate HTTP response, and the Requester thread for that connection “blocks” until the Response arrives. It matches the standard RESTful Client design pattern and must be supported in both Direct and Brokered Architectures. See also https://a4ldocumentation.atlassian.net/wiki/spaces/ARCHITECTU/pages/56000581 page. |
Object Service | While the SIF 3 infrastructure is independent of the Data Model defining the payloads it carries, all Service Providers must support the following general Object Service framework. An Object Service is the “authoritative source” for all data elements contained in all data objects of a specific type, and services some or all of the following requests:
Depending upon the object type, the corresponding Data Object Service may:
Whenever an Object Service receives a request for an operation it does not support, it must return an error. |
Service Provider | A Service Provider implementation accepts, processes and responds to requests from Service Consumers for object type or function-specific services, and publishes related Events in accordance with the type of Service Provider Interface it is implementing. |
Service Consumer | A Service Consumer implementation makes requests of, and subscribes to and receives Events from, one or more Service Provider components. Ex: A Teaching & Learning cloud application, supporting a course, requesting records of enrolled students. |
Service Paths | This is an alternative to Service Name, and where defined and available its use can greatly enhance the efficiency at which the Consumer obtains the desired result. The service path typically names a series of data objects that are joined according to a shared attribute, intermixed with the ID of a specific object that all subsequent objects named are to be related to. The last segment of the service path is typically a data object name, so that the Service Path counts as an Object Service Request with some built in object joins and conditions to constrain the result set. For example, to obtain all the Sections in which Student 1234 is currently enrolled, the single Query Request URL to do that would contain the string: ../students/1234/sections More details can be found on the Service Paths page. |
SIF Adapter | There are two basic varieties of Adapter:
Essentially each Service Consumer and Service Provider application may include one or many separate adapter component(s) to communicate with other applications. This communication may happen in a DIRECT or BROKERED architecture. For example, a SIF 3 Brokered Architecture may integrate a student information application, a learning management application, and a library automation application. An adapter component acts as a bridge between all these applications. |
Workflow | See Functional Service |
Zone or SIF Zone | A Zone is a collection of Application Services within the Consumer’s Environment, to correspond to discrete components within the owning educational organization (such as a school or district) or other conceptual groupings (ex: Special Ed students; Utility Services). Each Service “instance” accessible within the Consumer’s Environment is scoped to a Zone, although a given Service Provider implementation may support the same Service Provider interface in several Zones. More details can be found on the SIF Zone page. |