Although Man­aged Vir­tu­al Zones was ini­tial­ly invent­ed to solve con­cerns of the UK data mod­el where learn­er data is typ­i­cal­ly man­aged at the school lev­el to aid in its shar­ing at vary­ing lev­els of con­sol­i­da­tion, it is find­ing a great deal of use­ful­ness else­where as well. In the US and in Aus­tralia, stu­dent infor­ma­tion is typ­i­cal­ly man­aged a con­sol­i­dat­ed lev­el — in the US, the data is typ­i­cal­ly man­aged at the dis­trict lev­el and in AU, it is typ­i­cal­ly man­aged at the state lev­el. In both places, how­ev­er, there is a need to run sub­scrib­ing appli­ca­tions inde­pen­dent­ly at schools. So, the topol­o­gy might look some­thing like:

…or, at least the orga­ni­za­tion wished it looked like that.

The Problem

The prob­lem is that many SIF agents for these stu­dent man­age­ment sys­tems are writ­ten to pub­lish data into a sin­gle zone. This works well for the "Shared Sub­scrib­ing Appli­ca­tion" that was writ­ten to han­dle dis­trict-wide or state-wide data. But, what are the options for the "School-based Sub­scrib­ing Applications"if the Stu­dent Man­age­ment Sys­tem wasn't pro­grammed to sep­a­rate the data by school and pub­lish the data into sep­a­rate school zones as well as the con­sol­i­dat­ed dis­trict or state zone (those appli­ca­tions still need the data)? Well, some alter­na­tives might be:

1. Have all of the schools sub­scribe to the dis­trict zone and fil­ter out what­ev­er data isn't theirs. This is an awful alter­na­tive from many perspectives: 
   1. from a net­work traf­fic point of view, all infor­ma­tion would be sent to all schools
   2. from a security/privacy point of view, infor­ma­tion is being moved to many places (schools) where it is not need­ed — this is not acceptable
   3. from an appli­ca­tion cor­rect­ness point of view — the sub­scrib­ing appli­ca­tion is going to have dif­fi­cul­ties dif­fer­en­ti­at­ing between some students/events that look sim­i­lar, but are real­ly meant for the dif­fer­ent schools
2. Require that the sub­scrib­ing appli­ca­tions request their infor­ma­tion from the con­sol­i­dat­ed Stu­dent Man­age­ment Sys­tem instead of using events — sort of a semi-SIF solution.

Requirements

In order for a solu­tion to be work­able, it should, at a minimum:

• main­tain zones for the con­sol­i­dat­ed enti­ty (dis­trict or state), and sep­a­rate zones each school at the same time so that sub­scrib­ing appli­ca­tions can con­nect either at the con­sol­i­dat­ed lev­el or at the school level
• main­tain the pri­va­cy of stu­dent data. Nev­er pub­lish any stu­dent data from one school into the zone of anoth­er school.
• be SIS or stu­dent man­age­ment sys­tem inde­pen­dent, capa­ble of work­ing in either the US (with any ver­sion of the spec­i­fi­ca­tion, 2.*) or in Aus­tralia (with any ver­sion of their specification)
• not require any sub­scrib­ing appli­ca­tion to stop from expect­ing events or being able to send requests for infor­ma­tion. 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 pub­lished in a strange order) until accom­pa­ny­ing infor­ma­tion is published

Our Objectives in Solving the Problem

This prob­lem could have been solved in a num­ber of ways, but we want­ed to find the best, most reli­able way. The way we see it, the func­tion­al­i­ty to solve this issue could either be built into the SIF agents of each appli­ca­tion par­tic­i­pat­ing in the infra­struc­ture, or the prob­lem could be solved in one place:

This pic­ture rep­re­sents how the prob­lem could be solved by hav­ing each SIF agent include log­ic to sep­a­rate the SIF traf­fic by school or group of schools. The infra­struc­ture (ZIS) at the core would remain sim­ple, but each of the appli­ca­tions would need to be giv­en a strict set of guide­lines on how to build their appli­ca­tions to split apart the extra traf­fic. This sec­ond pic­ture rep­re­sents the solu­tion we rec­om­mend where we add a "helper agent" to the infrastructure.

This "helper agent" con­cen­trates on know­ing to which schools each object belong and stag­ing the objects in an oper­a­tional data store. It then acts as SIF provider for these objects in a flex­i­ble col­lec­tion of zones.

How We Solve the Problem

Visu­al Software's Envoy prod­uct is a SIF Vir­tu­al Zone Man­ag­er, capa­ble of tak­ing a sin­gle SIF zone and log­i­cal­ly split­ting it up into sev­er­al con­cur­rent vir­tu­al zones, each con­tain­ing one or more schools.

The School District Model

In the dis­trict mod­el, Envoy would become a sub­scriber in the dis­trict lev­el zone and would sub­scribe to every­thing being pub­lished. It would then dynam­i­cal­ly split the data by school and become the pub­lish­er of all events to the indi­vid­ual 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 oth­er school.

The dia­gram to the right is a log­i­cal representation:

• The shad­ed area rep­re­sents the orig­i­nal dis­trict-lev­el zone. The only change that would be made here would be to have Envoy be added as a subscriber.
• New zones are cre­at­ed on the Zone Inte­gra­tion Serv­er for each school. Envoy becomes the pub­lish­er for all objects in each of these zones.
• School-based appli­ca­tions sub­scribe to these School Zones just as if there was a SIS pro­vid­ing data direct­ly to them. If they make SIF requests, those requests are respond­ed to by Envoy instead of the orig­i­nal Stu­dent Infor­ma­tion System.
• If the school-based appli­ca­tion pub­lish­es an object or events for an exist­ing object, those events will be relayed back to the dis­trict-lev­el zone.

The State Model

This would be the mod­el seen in Aus­tralia, except that there might also be anoth­er lev­el larg­er than a school but small­er than the state. For exam­ple, a state might want to cre­ate a zone for a spe­cial edu­ca­tion school con­tain­ing those oth­er schools that send stu­dents to it. That zone will receive events and data for all of the stu­dents in those schools.

How Envoy Works

Inter­nal­ly, what Envoy does is to trace every object back to the school (or schools) it is relat­ed to. Some objects are eas­i­er than oth­ers. SchoolIn­fo and Stu­dentSchoolEn­roll­ment are easy because the school infor­ma­tion is stored direct­ly in the object. Stu­dent­Per­son­al is a lit­tle more dif­fi­cult. Almost all of the cur­rent SIF objects in all of the spec­i­fi­ca­tions can be mapped back to a school they're relat­ed to (some excep­tions, like SEAIn­fo can't and would be passed through trans­par­ent­ly). Envoy oper­ates as a SIF agent using stan­dard SIF objects, mes­sages and pro­to­cols. It works with any Zone Inte­gra­tion Serv­er and works with exist­ing SIF agents that fol­low stan­dard rules of oper­a­tion as defined in the SIF spec­i­fi­ca­tions (no non-SIF short­cuts). Since it runs as a SIF agent, it can be used to sub­scribe in dif­fer­ent zones (host­ed on dif­fer­ent Zone Inte­gra­tion Servers), allow­ing imple­men­ta­tions to bridge regions in real time. Envoy's oper­a­tion is based on busi­ness rules that are vis­i­ble to the cus­tomer through a web inter­face. This allows the cus­tomer to know what is hap­pen­ing, how deci­sions are being made and also gives the cus­tomer the abil­i­ty to enhance these rules if nec­es­sary. Exam­ples of enhance­ments might be things like test­ing the data to make sure it meets cer­tain basic lev­els of qual­i­ty before dis­trib­ut­ing it or auto­mat­i­cal­ly resolv­ing prob­lems if mes­sages are received by Envoy in the incor­rect order.

Differences Between This Solution and The UK Envoy Version

For two rea­sons, the ver­sion of Envoy we sell in the Unit­ed King­dom is more com­plex than the ver­sion we are describ­ing here.

1. In the UK, stu­dent data is typ­i­cal­ly man­aged at the school lev­el instead of at a com­bined lev­el, but many appli­ca­tions are shared at a com­bined lev­el. Fur­ther­more, these appli­ca­tions store data for all these stu­dents in a com­mon database.
2. In the UK, when a learn­er becomes 14 years of age, he or she becomes eli­gi­ble for a type of learn­ing not avail­able in most oth­er coun­tries. This caus­es them to go to school part time in one school and part time in anoth­er. Because each school has its own stu­dent man­age­ment sys­tem and the learner's record is man­aged in both places, there is a need to be able to give these shared appli­ca­tions a uni­fied view of the learner's records, elim­i­nat­ing the need for them to jug­gle records from the dif­fer­ent schools.

The UK Ver­sion of Envoy is more com­plex in that it not only man­ages vir­tu­al zones, but it also man­ages vir­tu­al stu­dent records. For more infor­ma­tion on Envoy, see Envoy, for more tech­ni­cal details on Man­aged Vir­tu­al Zones, see Man­aged Vir­tu­al Zones.

See It Work

The fol­low­ing is a demon­stra­tion of some of the capa­bil­i­ties of the Envoy US/AU prod­uct for split­ting the out­put of one con­sol­i­dat­ed provider in a num­ber of sit­u­a­tions. To see the image full screen, dou­ble click the video screen as it is play­ing 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 infor­ma­tion, give us a call at: USA (215) 493‑8210 x114 Lon­don, UK: +44 (0) 20 8816 8012 Mel­bourne, AU: +61 3 9018 5081