Service Types

Service Type Description

The following table describes the full range of SIF 3 Service types provided to SIF 3 service consumers. They are distinguished in a consumer request by the value of the “serviceType” HTTP Header Field.

Service Type

Description

HTTP Header servcieType value

Service Type

Description

HTTP Header servcieType value

Object Service

An Object Service relates to a service of a specific data object. A data object is typically defined in a locale’s data model and is made up of a self-contained collection of XML/JSON data elements.  Its format is standardized in an XML Schema that is part of the locale-specific Data Model rather than the SIF 3 Infrastructure. 

The Data Object Service is the “authoritative source” for all data elements contained in all data objects of a specific type.

Each Object Service has a well defined set of REST endpoints. Please refer to the Open API page for more details on each locale’s specific endpoint definition.

For details of the object definition (XML/JSON elements) please refer to the locale’s specific SIF Data Model Specifications page.

serviceType = OBJECT

This is the default if not provided by the service consumer

Utility Object

A Utility object is also a self-contained collection of XML/JSON data elements.  Its format is standardized in an XML Schema that is defined by the SIF 3.x infrastructure and is independent of any locale-specific Data Model.

The Utility Service (and by implication the Environments Provider which often implements it) is the “authoritative source” for all data elements contained in all Utility Service objects of a specific type.

For further details refer to the Utility Services page.

serviceType = UTILITY

Named eXtended Query

eXtended Query technology is used to standardize the way in which Query Responses can be defined to meet important service consumer requirements.  When the token representing an Named eXtended Query is specified in a Query Request, the Response can do some or all of the following:

  • Contain a subset of expected object elements (ex: no Student Health or Discipline information)

  • Include calculated aggregates based on the data in multiple objects of the same type

  • Represent a combination of data elements contained in multiple objects of multiple types

The format of the Named eXtended Query Response is specified in an XML schema such as object in the data model or one specifically defined to match that eXtended Query.  In terms of validation however, all elements of the schema are generally considered optional. In addition, the inclusion of the template itself in the Data Model binding standardizes how the defined elements of the Response must be produced.

For further details refer to the Named eXtended Query page

serviceType = XQUERYTEMPLATE

Service Path

Service Paths are predefined URL segments that are used to optimize Consumer Queries in important use cases, by expressing object joins succinctly.  For example, a Query made to a URL containing “sections/1234/students” will return all Students enrolled in Section 1234.

Such Service Paths are typically defined as part of the of a locale’s specific Data Model. Each locale is responsible to define and publish its supported service paths.  The XML schema defining the formats of the objects contained in the Response payload is determined by the last segment of the Service Path (“students” in this case.).

serviceType = SERVICEPATH

Functional Service

(Job Object)

A Functional (or Job Object) Service encapsulates stateful process behavior as well as the data exchanged between applications implementing that process.

It does this by supporting some or all of the methods of a Data Object Service Provider interface but applying them to educational processes such as StudentLocator and EndOfYearRollover rather than Object data elements.

When a service consumer issues a “Create” request to a Functional Service, it results in the creation of a new executing instance of the Function (a “Job Object instance”) rather than a new 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 that 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 may issue Events as its internal phases are completed.

Each Job Phase is represented by:

  • A Phase name

  • A status (NotStarted, InProgress, Completed, Failed)

  • A defined Object Service corresponding to that Phase (which supports some or all of the set of service operations)

The creator of the Job can therefore:

  • Monitor the status of the Job (through querying the Job instance or by receiving Job level Events)

  • Indirectly impact the Job through creating individual phase states.

  • Receive Events (where supported) from the various Phases of the Job.

  • Where appropriate Delete the Job.

serviceType = FUNCTIONAL

Privacy Service

The Data Protection Enforcer Service applies those data protection obligation rules to a payload which are appropriate for the given consumer and provider. It operates as a filter, and invoking it is optional in SIF implementations—although SIF implementations are expected to observe the rules captured in Privacy Obligation Documents somehow.

The Data Protection Enforcer Service requires Service Consumers to obtain a token (Data Privacy Marker) associated with the latest form of the applicable Privacy Obligation Document, and to include it with their request. The service will confirm that the Data Privacy Marker is current (which can be used to cache responses), and if so, will apply the current Privacy Obligation Document ruleset to the submitted payload as a filter.

serviceType = SERVICE

Supported Functionality

Verious service types support a number of functional concepts such as events, delayed request/response, batch operations etc. This table below summarises which core concepts and functionality each service type supports. This is intended as a overview only. Additional details can be found in respect sections.

CRUD: (C)reate, (R)ead, (U)pdate, (D)elete.

NA: Not applicable

Functionality

OBJECT

SERVICEPATH

FUNCTIONAL

XQUERYTEMPLATE

UTILITY

SERVICE

Functionality

OBJECT

SERVICEPATH

FUNCTIONAL

XQUERYTEMPLATE

UTILITY

SERVICE

CRUD Operations - Single Object

C,R,U,D

NA

C,R,D on Service,

C,R,U,D on Phase

NA

Depends on service.

 

CRUD Operations - Batch

C,R,U,D

R

C,R,D

R

Depends on service.

 

Events

Yes

No

Yes

No

Yes

 

Query By Example (QBE)

Yes

No

No

NA

No

 

DELAYED Request/Response

Yes

Yes

Yes

Yes

No

 

Admin Directives Support

Yes

No

Yes

No

No

No