What is DIS?
DIS stands for Data Interchange Service, and it facilitates communication between applications using XML messages sent over https connections. The DIS system primarily allows communication between state and district editions. For example, District 1 might send a student locator request, which would go through the state edition. The state edition could potentially return the information requested to District 1 or send requests to other districts. At this point, the request might end up in an administrative queue, awaiting approval. This system can be used when a student has moved and is transferring to a new school district.
DIS and ZIS
DIS facilitates communication between applications using XML messages sent over https connections. At the core of this system is the Zone Integration Server (ZIS). Infinite Campus provides a free built in SIF Zone Integration Server (ZIS), which acts as a data integration broker between applications.
Things to note:
- Each district has its own zone in the state application.
- Each district application creates a zone to communicate with the state app.
- A zone can emulate an agent to communicate with another zone.
Our ZIS system allows the creation of scoped zones. This allows districts, for example, to only send specific groups of students, such as those enrolled in certain years or at certain schools.
The ZIS is used to communicate with several different agents. These agents include SIF, DIS (which is communication between a district and a state edition), Food Service, and others.
SIF
SIF stands for Schools Interoperability Framework. Infinite Campus comes with a free built-in SIF Zone Integration Server.
In our system, SIF is simply implemented as an XSL transformation. Our standard XML is stripped down via an XSL transformation into the format required by SIF.
Agent Modes
From the Spec
'Push' refers to the action by a ZIS to actively deliver messages to an agent without the agent having to initiate contact with the ZIS. When the ZIS receives a message for an agent and the agent is not in 'Sleep' mode; the ZIS will initiate contact with the agent and send the message to the agent.
'Pull' refers to the action by an agent to explicitly request a single message from the ZIS. When an agent is ready to receive a message, it sends a 'Pull' request to the ZIS, to obtain a message that the ZIS has saved in the queue for the agent. After receiving the pull request, the ZIS will examine the agent's queue and either returns a message or a status code indicating that no messages are available for the agent.
Pull Agent
Pull agents periodically send a message checking to see if any new information is waiting to be sent. If it is, a big chunk of xml data is returned. This has the advantage of never going faster than the pulling agent can handle, since it decides when to send the requests.
Think of a pull agent as if it's a web browser on some random teacher's machine; it's allowed to send requests from the outside and get responses exactly like what a web browser does. Since their firewalls are already configured to handle browser requests, they usually don't have to change the rules to support pull based agents.
Push Agent
When a change occurs, the relevant information is sent up to the destination. This mode has the advantage of being quick to update; there is no waiting for a poll. However, not all computers can keep up with large amounts of data being pushed onto them.
Several districts do not let internal machines initiate connections from inside the district to the outside world. They only allow web access through a proxy so that they can do filtering/caching. At this point, a push agent is configured to use a proxy and a special rule specifically for each of our server machines needs to be set up to be able to create an external connection to a specific IP/Range of IPs on a specific port.
DIS Objects
