Zones
Definition
A “zone” in SIF is a logical place or container where two or more agents can share data, isolated from data in any other zone. There can be many zones hosted on a typical Zone Integration Server and one agent may be registered in more than one zone concurrently (but to be useful at all it must be registered in at least one zone).
Zone Architecture
To understand where zones will be needed in an architecture, the needs and capabilities of the subscribing applications that will be used must be properly considered.
The reason why this is necessary is that, on occasion (when initializing, at end-of-year rollover and if they the want to re-sync) , subscribers will make a “request all” for certain object types. What they will get in return are all records of that type in the zone.
- Is this application allowed to see all the information returned? For example, if this application was a library system installed at a school and the information returned to it contained information from other schools, then the answer would be “no”. One school should only receive information for students from that school.
It has been a common practice to create a zone for each Student Management System (or SIS (US), or MIS (UK)); sometimes this works well , other times it doesn’t. Ideally, it should probably be more like: create a zone at the lowest level where there will be a subscribing SIF application.
Zone Architecture Examples
The following sections give some examples of SIF zone architectures that might be appropriate, depending on where student information is managed and where it is needed by subscribing applications.
United Kingdom Example
In the UK, data is typically managed in Management Information Systems (MIS) that are installed and run from individual schools. The Zone Integration Servers may reside at the school or may be centrally hosted and the subscribing applications may run locally from the schools, from a local authority or may be centrally hosted from a Regional Broadband Consortium (RBC).
In the UK, when a learner reaches age 14, he or she may begin to attend more than one school during the course of a day, causing his or her records to be managed in more than one of these MIS systems. It shouldn’t be assumed that the SIF RefIds from any of these MIS systems are synchronized, so it should also be assumed that if a learner attends two different schools, his or her school records will look like those from two different people.
NOTE: technically, the same thing will happen for special education learners who attend more than one school – their records will be maintained in more than one MIS.
(click image to open in separate window)
In this example, three schools each have their own independent zone (they could be hosted on the same Zone Integration Server) containing information provided by the school’s MIS. The subscribing application, also installed at the school, gets its information from the zone through its SIF agent. Because of the way the ZIS manages zones, it is guaranteed that information from one zone will never be mixed with that from another zone.
UK Example – Shared Applications
The above example is simple, but not all applications are installed at schools – many are hosted either at a Local Authority or at an RBC and shared by several schools.
This presents a problem. One of the most basic rules in SIF is that in a given zone, there may be only a single provider for each object. This makes sense since a provider is defined as the agent who, by default, receives requests for a given object when a subscriber agent makes a request and doesn’t specify where to send the request (it is sent to the provider agent).
So, what you can’t do is to have all of the MIS (SIS) agents be providers in a common zone. But, there are alternatives:
- Multi-zoned agents: these are agents that register in more than one zone. For subscribing applications, writing one of these agents is somewhat difficult; for publishers it is very difficult. These agents must be able to keep track of many sets of RefId values, one for each school and if a learner appears in more than one school, it gets even more complex.
- Managed Virtual Zones (MVZ): when Visual Software entered the UK market, it realized that a problem existed with currently available facilities using SIF as implemented with multi-zoned agents. To address these problems, it invented Managed Virtual Zones and created the Envoy product to implement it. With this architecture, the application agents do not need to be written with the complex multi-zone logic – all of the complexities are centralized in one place and can be tested independently and verified before other agents are connected.
The following is a picture of how applications would be connected using a MVZ architecture and Envoy:
(click image to open in separate window)
In this example, the subscriber in the combined zone would not need to know any details about who is providing what object or learners that go to two different schools – the details would be “ironed out” and the combined community would appear as if it was being maintained by a single MIS (SIS). For more information on Envoy and MVZ, see Managed Virtual Zones.
