SIF Zone Partitioning Using Managed Virtual Zones
Although Managed Virtual Zones was initially invented to solve concerns of the UK data model where learner data is typically managed at the school level to aid in its sharing at varying levels of consolidation, it is finding a great deal of usefulness elsewhere as well. In the US and in Australia, student information is typically managed a consolidated level — in the US, the data is typically managed at the district level and in AU, it is typically managed at the state level. In both places, however, there is a need to run subscribing applications independently at schools. So, the topology might look something like:
…or, at least the organization wished it looked like that.
The problem is that many SIF agents for these student management systems are written to publish data into a single zone. This works well for the "Shared Subscribing Application" that was written to handle district-wide or state-wide data. But, what are the options for the "School-based Subscribing Applications"if the Student Management System wasn't programmed to separate the data by school and publish the data into separate school zones as well as the consolidated district or state zone (those applications still need the data)? Well, some alternatives might be:
- Have all of the schools subscribe to the district zone and filter out whatever data isn't theirs. This is an awful alternative from many perspectives:
- from a network traffic point of view, all information would be sent to all schools
- from a security/privacy point of view, information is being moved to many places (schools) where it is not needed — this is not acceptable
- from an application correctness point of view — the subscribing application is going to have difficulties differentiating between some students/events that look similar, but are really meant for the different schools
- Require that the subscribing applications request their information from the consolidated Student Management System instead of using events — sort of a semi-SIF solution.
In order for a solution to be workable, it should, at a minimum:
- maintain zones for the consolidated entity (district or state), and separate zones each school at the same time so that subscribing applications can connect either at the consolidated level or at the school level
- maintain the privacy of student data. Never publish any student data from one school into the zone of another school.
- be SIS or student management system independent, capable of working in either the US (with any version of the specification, 2.*) or in Australia (with any version of their specification)
- not require any subscribing application to stop from expecting events or being able to send requests for information. Because of the way that objects will need to be traced back to the school they belong to, some records may need to be held for a short time (if they are published in a strange order) until accompanying information is published
Our Objectives in Solving the Problem
This problem could have been solved in a number of ways, but we wanted to find the best, most reliable way. The way we see it, the functionality to solve this issue could either be built into the SIF agents of each application participating in the infrastructure, or the problem could be solved in one place:
This picture represents how the problem could be solved by having each SIF agent include logic to separate the SIF traffic by school or group of schools. The infrastructure (ZIS) at the core would remain simple, but each of the applications would need to be given a strict set of guidelines on how to build their applications to split apart the extra traffic. This second picture represents the solution we recommend where we add a "helper agent" to the infrastructure.
This "helper agent" concentrates on knowing to which schools each object belong and staging the objects in an operational data store. It then acts as SIF provider for these objects in a flexible collection of zones.
How We Solve the Problem
Visual Software's Envoy product is a SIF Virtual Zone Manager, capable of taking a single SIF zone and logically splitting it up into several concurrent virtual zones, each containing one or more schools.
The School District Model
In the district model, Envoy would become a subscriber in the district level zone and would subscribe to everything being published. It would then dynamically split the data by school and become the publisher of all events to the individual school zones. It would relay events back and forth, would respond to SIF requests from the school zones and it would make sure that no school receives data meant for any other school.
The diagram to the right is a logical representation:
- The shaded area represents the original district-level zone. The only change that would be made here would be to have Envoy be added as a subscriber.
- New zones are created on the Zone Integration Server for each school. Envoy becomes the publisher for all objects in each of these zones.
- School-based applications subscribe to these School Zones just as if there was a SIS providing data directly to them. If they make SIF requests, those requests are responded to by Envoy instead of the original Student Information System.
- If the school-based application publishes an object or events for an existing object, those events will be relayed back to the district-level zone.
The State Model
This would be the model seen in Australia, except that there might also be another level larger than a school but smaller than the state. For example, a state might want to create a zone for a special education school containing those other schools that send students to it. That zone will receive events and data for all of the students in those schools.
How Envoy Works
Internally, what Envoy does is to trace every object back to the school (or schools) it is related to. Some objects are easier than others. SchoolInfo and StudentSchoolEnrollment are easy because the school information is stored directly in the object. StudentPersonal is a little more difficult. Almost all of the current SIF objects in all of the specifications can be mapped back to a school they're related to (some exceptions, like SEAInfo can't and would be passed through transparently). Envoy operates as a SIF agent using standard SIF objects, messages and protocols. It works with any Zone Integration Server and works with existing SIF agents that follow standard rules of operation as defined in the SIF specifications (no non-SIF shortcuts). Since it runs as a SIF agent, it can be used to subscribe in different zones (hosted on different Zone Integration Servers), allowing implementations to bridge regions in real time. Envoy's operation is based on business rules that are visible to the customer through a web interface. This allows the customer to know what is happening, how decisions are being made and also gives the customer the ability to enhance these rules if necessary. Examples of enhancements might be things like testing the data to make sure it meets certain basic levels of quality before distributing it or automatically resolving problems if messages are received by Envoy in the incorrect order.
Differences Between This Solution and The UK Envoy Version
For two reasons, the version of Envoy we sell in the United Kingdom is more complex than the version we are describing here.
- In the UK, student data is typically managed at the school level instead of at a combined level, but many applications are shared at a combined level. Furthermore, these applications store data for all these students in a common database.
- In the UK, when a learner becomes 14 years of age, he or she becomes eligible for a type of learning not available in most other countries. This causes them to go to school part time in one school and part time in another. Because each school has its own student management system and the learner's record is managed in both places, there is a need to be able to give these shared applications a unified view of the learner's records, eliminating the need for them to juggle records from the different schools.
The UK Version of Envoy is more complex in that it not only manages virtual zones, but it also manages virtual student records. For more information on Envoy, see Envoy, for more technical details on Managed Virtual Zones, see Managed Virtual Zones.
See It Work
The following is a demonstration of some of the capabilities of the Envoy US/AU product for splitting the output of one consolidated provider in a number of situations. To see the image full screen, double click the video screen as it is playing or right-click the image and choose to zoom to full screen (hit Escape to return to the small screen).
Finding Out More Information
If you would like to find out more information, give us a call at: USA (215) 493‑8210 x114 London, UK: +44 (0) 20 8816 8012 Melbourne, AU: +61 3 9018 5081