SIF Environment

The “SIF 3 Environment” is made available to a Service Consumer when it initially registers. It comprises the totality of every service the Service Consumer might possibly provision itself to access.  Based upon authentication constraints however, the Service Consumer’s access to some services might be restricted. 

The Environment is defined by the set of Infrastructure Service URLs returned to a Service Consumer in response to a successful Registration Request, or referenced by URI when making a data request, whether pre-registered or automatically registered or dynamically created. These URLs allow the Environments Provider to provide a “customized” environment for each Service Consumer.  For example, depending on the authentication provided by the Service Consumer at registration time, the URLs returned might insert it into either a production or test environment, or one that provides access to only a limited subset of authorized available Service Providers.

There are two distinct topologies for a SIF environment: DIRECT or BROKERED. Each topology is shortly described in the next two sections.

DIRECT

A Direct Architecture connects a single Service Consumer to a fixed set of one or more directly accessible Service Providers. These include, at a minimum, the mandatory set of Infrastructure Services, all mandatory Utility Services and at least one Data Object or Functional Service.

A Direct Architecture conceptually does not leverage middleware. All Service Consumer to Service Provider connections are direct (no intermediary), because the Environments Provider Interface and all Service Provider Interfaces are implemented by an Environments Provider Adapter front-ending a single application (such as an SIS or LMS).  This means that a Service Consumer cannot dynamically provision itself as a Service Provider when registered in a Direct Architecture.

Such an Adapter implementation could simultaneously provide a separate Environment to each of several Service Consumers, to enable them to directly access and update the data of its provided application. In that common case:

• Each Service Consumer is operating in an Environment of its own, and has no knowledge of any other Service Consumers

• When any Service Consumer request causes a change to the data in the service application, every appropriately subscribed Service Consumer in every Environment supported by the Environments Provider Adapter receives the identical corresponding Event.

Details:

A DIRECT Architecture standardizes SIF-compliant message exchanges between Consumer and Provider in the absence of a central Message Broker.

As described earlier, the typical Service Consumer registered in a SIS-provided Environment could be a simple data entry application running on a mobile device, or a Student Contact system that only needed to access the Student’s ID, Name, Addresses and Phone Numbers.

BROKERED

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.

Unlike the Direct Architecture, any Service Consumer with the proper authorization rights can provision itself as a Service Provider, and receive Requests from and publish Events to, other Service Consumers with the appropriate authorization rights.

Details: 

The “Message Broker” functionality requirements of a SIF 3 Brokered Architecture can be implemented (among other alternatives) by SIF “business logic” layered on top of an Enterprise Service Bus (ESB), by internally coupled middleware components etc.

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.