SIF Association

This blog is run by the staff of the SIF (Schools/Systems Interoperability Framework) Association for the use of it's members and the general educational community.

It is specifically designed for those who are interested in understanding what SIF is about, where the standard is going and how Schools, Districts and State Educational Authorities will benefit.

Saturday, October 13, 2012

SIF v3.0 Infrastructure Revisited

This is admittedly a rather long post, but for those interested in understanding the three groundbreaking SIF infrastructure design decisions made at the SIF Fall Developer Camp in Dallas last month, it should definitely be worth the read.

 Each decision has had a huge impact on the capabilities of the SIF v3.0 release, and each is summarized below.

1.    REST is now a “co-equal” transport to SOAP

REST joins SOAP as the second technology that can be used to provide the foundation for exchanging SIF-compliant data.  The specific changes needed to make this happen are already underway, and include:

  •  The SIF v3.0 infrastructure Service Architecture has been aligned with the Get/Post/Put/Delete standard REST operations to make them more easily map-able to a set of standard REST resources.
  • A new “immediate return” alternative for Request / Response exchanges is expected to be heavily utilized by REST applications.
  •  A separate SIF v3.0 infrastructure volume will contain the agreed on set of REST Developer Guidelines (including URL allocation) that will guarantee REST applications can smoothly interoperate in a SIF v3.0 Zone.
  • An additional infrastructure volume targeted at SIF v3.0 Middleware providers will define the complete bridging instructions between REST and SOAP messages (similar to the SIF v2.x volume which bridged SOAP and the classic SIF transport).  This ensures the choice of transport will not fragment SIF application interoperability.
2.    There is a new Zone alternative in which the Client Application connects directly with the Service Provider

In addition to the Brokered (3-party) SIF Zone architecture which had previously defined all SIF v2.x deployments, there is now a new Direct (2-party) alternative in which a client and service can exchange SIF-conformant data directly without the need to interpose message broker middleware such as the ZIS.  Essentially a “very thin” Zone Provider wrapper is placed around an Object Service, to allow the “Direct Zone” to be provided by an SIS or LMS system.

This wrapper (the “Common API”) is a subset of the “Extended API” wrapper supported by all Brokered Zones, which provides access to a broader set of middleware services. As a result, every SIF v3.0 client application which was written to function in a Direct Zone will also function in a SIF v3.0 Brokered Zone.

Here are two use cases for a Direct Zone that are particularly illuminating:
  •  When an application wants to make its SIF-compliant data accessible to a user running a simple RESTful client application on a mobile device like an iPad (much as it might already be available to that user via a browser).
  • When an application only needs data from one other application.  An example is a Student Contact application needing to access Student Name and Addresses and Phone Numbers from an SIS system. If the SIS system provides a Direct Zone, it enables the Student Contact system to access its data directly without the need to install middleware.
All applications (client or service) in the above examples can be SIF-certified, and there is every expectation that each will interoperate “out of the box” with other partners supporting the Direct Zone APIs.
The differences between Direct and Brokered SIF v3.0 Zones are further detailed in a table below.

3.    Migration to SIF v3.0 will be a far cleaner 2-step process than earlier envisioned.  

While it was always the plan to eliminate any Data Model dependencies in the SIF v3.0 infrastructure, what is new (and which seems obvious in retrospect) is the realization that such a “data payload” independent infrastructure can also be used to support exchanges of SIF v2.x data.

As a result, migration to SIF v3.0 will now be a far cleaner 2-step process than earlier envisioned.  A SIF Zone administrator begins by first upgrading the existing Zones in her organization to the new infrastructure (benefiting from the new alternative choices described above).  Only at that point does the need arise to address legacy application migration from the SIF v2.x Data Model to the new CEDS-based (in the US) SIF v3.0 Data Model.

                           <And now ... for some details>
As promised, here is the table highlighting the detailed differences between the two SIF Zone types

Alternative / Functionality

SIF Direct Zone
SIF Brokered Zone
Targeted SIF Data Model Version Support

SIF v2.x or v3.0
SIF v3.0
Transport Support & Certification
REST only in support of the SIF v2.x Data Model.

REST or SOAP in support of the SIF v3.0 Data Model.
REST and SOAP in any given SIF v3.0 Brokered Zone

SIF Zone without the middleware
Fully functioned SIF v3.0 Zone

Middleware required?

No.  All connections are 2-Party
Yes.  All data exchanges are mediated by a 3rd Party Broker

Client to Service connections supported
One Client to one or more Services from a single Provider

Many Clients to many Services from many Providers
The Application supplying the Direct Zone may be written to simultaneously provide Direct Zones to multiple clients.

New concept of “subzones” effectively allows single middleware module to support (and a single Zone administrator to manage) hierarchical groupings of communicating clients and services

Client to Service(s) session supported

Yes. Secure session support provided by single Application Service
Yes.  Secure session support provided by the Broker

Client flexibility


The Registered Client in a Direct SIF v2.x Zone must use the REST transport.  .

The Registered Client in a Direct SIF v3.0 Zone must use a transport which matches that of the Application offering the Zone (i.e. either SOAP or REST).

JSON to XML converters may be used by REST clients before sending or after reception, but only XML Payloads will be transmitted “over the wire”.

All Request / Response exchanges are immediate (Response is returned in the HTTP Response rather than “ACK of Request”)).

High.  Registered Clients in any given Brokered Zone can be:

REST and / or SOAP.  The Broker does all transport bridging

As with Direct Zones, only XML-formatted Payloads are exchanged “over the wire”. 

Request / Response exchanges are either immediate or delayed depending upon client and service preference at registration time.  The Broker does any necessary bridging.

Client Functionality


The Client can access the Direct Zone to query and update only those data objects provided by the Application implementing the Zone. The Client cannot declare itself as a Service.

Even if the application providing the Direct Zone supports multiple Clients, each client is effectively placed in its own Zone.

Cross-client communication is only possible through Events ... if one client updates a supported Service object, every client in every other Direct Zone supported by the Service Application will see the corresponding Change Event.

Very high.

As with the Direct Zone, Clients can see the Events resulting from each other’s Service invocations, 

Clients can also dynamically provision themselves as services and can then be queried and updated by all registered clients in the Brokered Zone with the proper Authorization rights.

Clients can discover other clients in the Zone.

They can open multiple queues to prioritize certain message types and increase Zone scalability.

Multiple Subzones (with multiple default providers) are supported, as are additional Utility Services like Extended XQuery and Alert Log.

A “Zone Management” Client can discover and verify the access settings of all other Clients and Services, monitor their performance, and detect their errors.

Reduces barriers for new vendors


A SIF v2.x application can put a thin interface in front of itself by slightly extending the existing SIF Agent  APIs, whereupon it can directly service requests and post events to other SIF compliant clients in a Direct Zone without needing a middleware component.


Infrastructure APIs are repackaged to correspond to middleware architectural components.

This promotes possible construction of the SIF v3.0 Message Broker functionality from individual components in a middleware product suite as well as from an upgraded SIF v2.x ZIS.

Relation to other alternatives
The Direct Zone supports a clearly defined subset of the Brokered Zone API. 

Since it is independent of the Data Model defining the payloads it transports, it can be applied to conveying SIF v2.x data and well as SIF v3.0 data.
The Brokered Zone “bridges” between the SOAP and REST transports, and extends but does not replace the functionality provided to Direct Zone clients.

As a result, an application (REST or SOAP) which is a client of any Direct Zone should seamlessly interoperate with all other applications in any Brokered Zone supporting the same SIF version of the data payloads.


Low to medium.

Basically management tools are whatever the application developers provide, and traditionally this is less extensive than management functionality provided by a ZIS, ESB or Service Registry.
Very High. The SIF v3.0 Brokered Zone extends the remote management functionality of earlier releases (including both preventative maintenance and security) to allow effective central administration of multiple Zones by providing:

* Retrieval of Alert Log information through straightforward Queries (ex: it is now possible to find out what errors were logged by or against application X)

* Query capability of the Queue Manager statistics to determine the number and total size of pending messages, and the time of last message delivery for each client and service.

This should be extremely useful in predicting and then isolating application-specific problems within the Zone.