Besides passing messages from one application to another, managing security is the other main function of the ZIServer product. The following table illustrates some of these ZIServer features:

	ZIServer Accounts ZIServer provides web-based administration and management with separate roles for Global Administrators (all capabilities in all zones), Zone Administrators (most capabilities for specified zones) and Agent Viewers (limited capabilities for specified connections). This is a screen capture from a Global Administrator’s account which allows administration of all other accounts.
	ZIServer Zone Level Administrators This is a view from a Global Administrator’s account where a Zone Administrator’s account is being set up. In this example, the account ‘bwilde’ is given access to two zones.
	ZIServer Agent (connector) Level Administrators In this example, the account ‘opayne’ is given access to view some limited information from agents (connectors) in two zones. In the currently selected zone, access is only given to information about the ‘SubscriberB’ agent (connector).
	Object-Level Permissions ZIServer maintains object level privileges by application connector to send events (Add, Change or Delete), subscribe to events, make requests or respond to requests. Agents (connectors) need to be pre-authorized by the administrator before they can publish or receive data to or from a zone. The last column in the permissions table contains a button. If the button is green, there are element-level filters defined for this object (but none have been set). If the button is yellow, some filters have been set.
	Element-Level Filtering ZIServer supports element-level filtering by agent connection. This allows administrators to define privacy filters for object types by application, causing data to be removed from messages before delivering them to the application (based on a need-to-know basis). For example, in the SIF education standard, there is a “Medical Alert” field in the Student Demographics object. Since this is not needed by (and, for privacy reasons, should not be sent to a Library application, that one field can be removed before passing the message to the Library application. During the publication of the same event, the entire message would be forwarded to the Nurse’s office application. All versions of delivered messages are audited separately. In this screen, an administrator may choose to remove/replace certain elements (fields) from messages before they are sent to a receiving application. The administrator is also able to control globally whether elements are replaced (with a string such as “removed for privacy reasons”) or simply removed.
	HTTP/HTTPS Authentication ZIServer supports several authentication (including certificate pinning) and encryption models (including TLS 1.2 and 1.3) for bank-level security. The set-up is simple: install a certificate on the server where ZIServer is being installed, obtain a copy of the remote server’s certificate, and copy it to a secure place on the local server. Lastly, tell ZIServer where that local copy is, and it will configure the rest and handle all the difficult parts.

Although originally created for the education market (as were all other products in the Visual Software suite), ZIServer was designed to support any class of application from any industry, from a small, locally developed database system to a multi-server, line-of-business system. However, some environments will be easier to connect than others because they already have industry-wide standards available. A partial list of these include:

• Agriculture: AgXML (grain- and oilseed-related business processes)
• Automotive
  • STAR – STandards in Automotive Retail
  • OTX – Open Test sequence eXchange
• Business
  • B2MML (Business to Manufacturing)
  • CIDX (Chemical Industry Data Exchange)
  • FpML (set of Financial Products standards)
  • HR-XML (Human Resources related standards)
  • Mail.XML (Mailing, Addresses and Deliveries)
  • OASIS UBL (Business Documents, Processes)
  • RETS (Real Estate Transactions)
  • XBRL (Business Reporting)
•  Education
  • SIF (Systems Interoperability Framework)
  • IMS global learning consortium (a set of standards)
• Health Care: HL7 – Health Level 7
• Government – NIEM (set of standards)
• News
  • EventsML (News Exchange)
  • SportsML (Sports Data)
• Publishing
  • AdsML (Advertising)
  • papiNet (Paper and Forest Supply Chain)
  • Prism (Publishing Content)
  • RIXML (Global Investment Research)
• Scientific: DWML (Digital Weather)
• Security: OVAL (Open Vulnerability and Assessment Language)

ZIServer was designed from the ground up to support a hosted implementation model. In a single implementation, it supports thousands of zones (groups of related applications), each of which is capable of connecting dozens to hundreds of applications.

ZIServer also supports global administration as well as distributed administration. In a hosted environment, the global administrator would work for the hosting provider where a distributed administrator (or zone administrator) role would be given to a customer account. For more information on this, see “Security / Privacy Features” above.

A Little History

When we created our first version of ZIServer, we built it “on top of” a popular Enterprise Application Integration (EAI) platform. It did the same basic things that our current ZIServer product does (passed messages and managed permissions), but it required our customers to buy a copy of the EAI platform when they purchased our ZIServer product.

In 2007, we were working with an existing XML specification that was changing and not maintaining backwards compatibility. Because this also involved changes to the transport mechanism (how messages are passed between applications), it was forcing us into a ground-up rewrite. At the same time, we heard from the maker of the EAI platform that their next release was not going to be backwards-compatible. In addition, it was still over a year away from being released. This left us with reduced options.

Assessing Our Strengths and Market Needs

At that point, we saw that the current product worked well, but it lacked the performance needed by very large . In addition, because it required customers to also purchase an EAI platform, it excluded smaller potential customers who couldn’t administer or afford the EAI platform. Since we had an extensive background in operating system-level development already, we decided to create a new generation ZIServer from the ground up, based on the design principles we were most familiar with: . As a result of a significant development effort, our base model was ready. After a side-by-side comparison, we found that it was:

• significantly faster than the older version based on the EAI platform. It was roughly 8-15 times faster, depending on the mix of traffic.
• more scalable. The new version could handle load-balanced input as well as load-balanced output – an advantage it still offers even today.
• easier to administer. We were able to create an installer that allowed for a simple, “click-through” process and an easy-to-use GUI administrative interface.
• much more affordable. The new version didn’t require the purchase of the EAI platform.

Since Then

We have spent the years since then improving ZIServer’s speed, scalability and overall usability. We’ve improved the product in these ways without increasing its administrative complexity or system-level basic requirements. This allows us to still support implementations of all sizes without requiring dedicated administrative support, even in the largest installations.

The new ZIServer has many features to support large and/or hosted implementations:

• It supports a one-to-many model. This is ideal in situations where information published by one source needs to be distributed to several recipients. With this model
  1. the publisher doesn’t need to keep track of who needs to receive the message. (The list of subscribers can change without requiring that the publisher be notified.)
  2. the publisher only sends a single message (less network traffic).
  3. the speed at which the publisher sends messages is not dependent on the speed at which receivers are able to receive messages.
  4. messages can be screened for privacy at ZIServer if needed.

• It retains messages across agent and system failures. If any of the endpoints goes offline, ZIServer saves its messages and sends them when the application returns to an online state – even if it takes days to do so.
• It protects the environment against XML-based denial-of-service attacks (the only broker of its kind to offer this protection).
• It guarantees that messages are delivered in .
• It may be deployed as a high-availability server farm on as many servers as needed in single or multiple location (disaster recovery) configurations. ZIServer is the only message broker of its kind to offer load-balanced delivery of messages (others provide distributed message receiving capabilities). Providing load-balancing in both directions gives ZIServer a unique advantage in the areas of:

• • Overall throughput
  • Server failover and recovery – events in both directions are handled automatically within milliseconds
• It has been certified by the A4L organization.
• It supports incremental adoption; different models of ZIServer are available from Compact Edition (single small server) to large Enterprise Edition installations. Migrating from a smaller edition to a larger edition can be done without the loss of any information and can often be done without any downtime.

Typically, Enterprise Application Integration (EAI) software is referred to by terms such as “Point-to-Point” (P2P), “Enterprise Service Bus” (ESB) or “Hub and Spoke” (HAS).  ZIServer falls somewhere in the category of a “Federated Hub-and-Spoke” model, providing all of its advantages without the disadvantages for which other EAI models are criticized.  For more information, see:  EAI Models

ZIServer audits each message that is passed through it. The application maintains two “working databases” one for active messages and another for audits. They are separated so that the audits’ data can be stored on different storage from the active messages and also for performance reasons. It also stores different levels of audits The Administration utility has a convenient capability that allows administrators and designated users to be able to search through recently delivered messages and display their contents.

	The Audits Interface Some of the features of this interface are: Columns can be sorted by clicking on the column header Columns with a funnel icon in the column can be filtered Data can be grouped by any column by dragging the column header to the gray bar above the column header bar Message contents can be viewed by clicking on the message link at the end of any line Message contents can be searched by using the “Search Message Contents” feature at the top of the page This interface has been designed to work efficiently with hundreds of thousands to millions of audit records. In addition, it is also user-account sensitive. If a zone administrator views this page, the audit records displayed will only be from agents in the zones that he or she is allowed to access. This works similarly with agent viewers.
	The Audits Interface – Docking Messages Normally when an audit message is viewed, it is displayed in a pop-up window. If the user drags that window to the side of the screen, it can be docked, and the audit list will be resized accordingly.
	The Audits Interface – Viewing Multiple Messages If multiple messages are viewed simultaneously, the message window can be dragged (see below) to join an existing message and form a tab-card collection of such windows.