Visual Software Support

“Push” vs. “Pull” mode is probably the most misunderstood concept in the world of SIF integration and many times makes conversations between those who have done implementations and those who haven’t unnecessarily difficult.

What People Usually Think These Terms Mean

Well, the words do have typical English meanings – one might think that “Pull” mode might indicate that an agent receives information from the ZIS, like a subscribing agent does. Well, this is not what “Pull” means to SIF.

One might think that “Push” means that an agent sends information to the zone, but it doesn’t. You can call such an application a “publisher” if you would like, but we’ll get into all the proper terminology shortly.

Pull vs. Push Mode

The difference between Push and Pull mode for an agent is more like the difference between real-time and batch for a process.

If a ZIS has information for an agent or needs to deliver a request to an agent, the mode of the agent makes a difference:

• If the agent is registered in Push mode, the ZIS contacts the agent and sends the message (event, response or request) to it as soon as possible.
• If the agent is registered in Pull mode, the ZIS will not contact the agent. Occasionally the agent will contact the ZIS and ask “Got anything for me?”. If there is anything waiting, the ZIS will return the next message as the answer to that request. Usually this “ZIS Poll” is done periodically, perhaps once every minute or every 5 minutes or every hour, depending on how the agent is administered.

Advantages of Pull Agents

• They work when the client application is hosted behind a firewall – this is because all of its traffic is outbound
• They are simpler to write than Push agents

Advantages of Push Agents

• They are much more efficient than pull agents: messages are only sent when data needs to be sent
• They are faster in that a message is delivered as soon as it is available to be delivered – it does not need to wait until the next time the receiver does a poll for the message to be delivered.
• They are potentially more secure (if set up correctly). We suggest that if a SIF connection is made over the open Internet, then certificates be installed on both sides. Furthermore, the subject of the certificate should be made known to both the ZIS and the agent. Both sides should check each incoming message to make sure that everything matches. This way, each side knows for sure who is on the other side. With pull mode, there is no such assurance possible.

Large Network Issues

When there is a large SIF implementation with many zones (such as is common in the UK and perhaps in Australia), and each of these zones have several agents attached, there will be many agent-to-ZIS connections.

If each of these agents are registered in Pull mode and if each of them poll the ZIS frequently to see if there are any waiting messages, the collective “idle state”  of these agents can waste a large amount of bandwidth (24 hours a day, 365 days a year).

“Chatty Agents”

Over the years, we’ve seen several subscribing agents that created accounts for students and teachers through a process something like the following:

1. Subscribe to StudentSchoolEnrollment
2. When a students’s StudentSchoolEnrollment is received, request the corresponding StudentPersonal message
3. If the student’s Advisor or Counselor isn’t known, request the StaffPersonal records for those staff members
4. Now that the StudentPersonal RefId is known, request the StudentContactRelationship objects for this student
5. When these are received, then take the StudentContactPersonalRefId value from each of them and request each of the StudentContactPersonal objects to find who this student’s parents are.
6. If it wants to receive information about the classes in which this student is enrolled, this will involve a “back and forth” with several more objects.
7. …and so on…

The problem with having conversations like this is that every time there is a “turn-around” in the conversation, the subscribing agent will have to wait until the providing agent does its next “check for messages” (if it is a Pull agent). Likewise, if the subscriber is a Pull agent, it will not receive an answer until the next “check for messages” interval.

Recommendation

Although we support Pull mode, we always recommend using Push mode if at all possible. It might mean a little extra work in setting it up, but it is almost always worth the added effort – in terms of speed, security and network efficiency.