4 Zone Services

4.1 Introduction

This section documents the set of SIF Zone Services which are defined using the service message types added to the SIF v2.4 infrastructure, and which leverage the advantages of the service paradigm (encapsulation of object data and behavior) in support of complex data exchange processes.

Zone Services is the third major conceptual component to be introduced into the SIF architecture. This introduction provides the necessary context for understanding them in relation to the Object Data Model and the SIF Infrastructure.

4.1.1 Important Terms

The following terms will be used throughout the rest of this section. Wherever possible, they reflect common industry usage and consensus.

4.1.1.1 Service

A Service is a software application that responds to requests made of it by client applications. Any given application can be both a service used by multiple clients, and a client which itself uses other services.

Every service possesses a public interface defining exactly what operations may be initiated against the service. This interface specifies the operations the service supports, the data these operations accept and the results they return. Each service also has a private (unpublished) implementation that determines how the service will fulfill, or respond to, requests.

The fact that the service implementation is private (encapsulated) means that even if the details of that implementation radically change, the interface is unaffected and none of the clients of that service will be impacted. Ensuring that clients are independent of how a service is actually implemented is known as loose coupling, and a key enabler of the Zone Service architectural component.

4.1.1.2 SIF Object Provider Service

A SIF Object Provider can be considered an “Object Service”. The Service interface in this case is composed completely of CRUD (Create, Read, Update, and Delete) operations for the object data it provides. Making a SIF Request is equivalent to invoking a “Read” operation, and the SIF Event equates to the “Create”, “Update” and “Delete” service operations.

Neither the structures of the SIF Object hierarchy nor the behavioral aspects of an educational process can be encapsulated by these Object Services.

4.1.1.3 SIF Zone Service

The existing SIF infrastructure has been extended to support “non-CRUD” operations, which allow Zone Services to be constructed that encapsulate both the details of the object hierarchy and associated transactional behavior. Three SIF message types (ServiceInput, ServiceOutput and ServiceNotify) have been added to carry these non-CRUD operation requests, responses and event notifications respectively. As a result, any client of a Zone Service must support this extended SIF infrastructure.

All Zone Service interfaces will follow the “Document Literal” pattern. The payload of each of these message types will have its structure defined by an XML schema which can be validated using the corresponding schema definition supplied within this SIF specification.

Although Zone Services are “services” in the sense of encapsulating the details of the operations they perform for their clients, all communications with their clients MUST pass through the ZIS with the same communication mechanisms used by Object Clients and Object Providers. This provides the Zone Client to Zone Service link with the following “quality of service” (QoS) advantages:

• Messages are exchanged in a secure fashion (via message encryption and application authentication).
• A Zone Client or Service will never receive a message unless it has both been given permission to do so and the sender has been given the correct permission to provide it (typically via authorization from the Zone administrator).

  This permission is granular, and a given client subscriber can be granted permission to receive none, some or all of the notification types provided by a Zone Service.

• Any legally posted message is guaranteed to be delivered, in order, once only, error free, or a notification of delivery failure will be given to the sender.
• A Zone Client need not know the location of its Zone Service. Any operation invocations for a named Zone Service will arrive there due to the content based routing capabilities provided by the ZIS.
• A Zone Client need not worry about allocating enough buffer space to receive an unexpectedly large response or notification from the Zone Service. The Zone Service infrastructure extensions support message packetization for all three service message types.
• A Zone Service need not know the location or the number of subscribers to its named notifications. When it issues a Notification, all legal subscribers are guaranteed to receive it, even if they are offline at the time of its publication, unless a total subscriber failure occurs. The Zone Service is not informed of these types of errors.

In brief, if the need for application interoperability is limited to sharing data, the solution should utilize existing client access to one or more Object Provider Services over the basic SIF infrastructure. However, if there is a need to support a more complex (possibly stateful) process choreography that requires multiple systems to coordinate their actions, one or more Zone Services should be employed.

4.1.2 New Message Types

Content-based routing for the SIF_Request, SIF_Event, SIF_Response and SIF_CancelRequests messages is based solely on the identified object type in the header of the message. Together those message types provide the client with the same CRUD interface (Create, Read, Update and Delete operations) to every type of object.

A given service type on the other hand may support a unique set of interface operations, which can affect multiple objects of varying types, in support of complex transactions or process choreographies. The existing SIF message types were incapable of being extended to support this additional functionality.

The three messages, which Zone Services use instead, are described below. All three have the name of the service and the operation being invoked as part of their message definition.

4.1.2.1 Service Input

This message is issued by a Zone Service client to invoke a defined Zone Service operation. It is routed by the ZIS to the default provider for that service, and like the Request can be directed to a specific destination as specified in the SIF_DestinationId in the ServiceInput header.

Service Inputs differ from Object Requests in the following ways:

• In addition to requesting object data, the ServiceInput message can also effect changes in one or more objects depending upon what elements are defined for the payload.
• Elements within the body of the ServiceInput can contain a detailed description of the changes (including state changes) that need to occur.
• The contents of the body of a Service Input message can range from no data at all to multiple elements, and are not restricted to elements from a single object.
• Service Input messages can be packetized if they are very large in size.

4.1.2.2 Service Output

This message is issued by a Zone Service in response to one of its operations being invoked by an arriving ServiceInput message, and is routed by the ZIS back to the issuing client. All internal implementation details of how the Zone Service processes the request to produce this response (potentially including sending multiple Change Events to a variety of Object Providers) are hidden from the client.

4.1.2.3 Service Notify

This message is used to notify subscribers that a service related event has occurred, and can optionally provide a detailed description of exactly what that event was. Service Notifications differ from Object Events in the following ways:

• In addition to simple event notification, the Service Notification can also contain a detailed description of the changes (including state changes) that occurred across multiple objects.
• The contents of the body of a Service Notification message can range from no data at all to multiple elements, and are not restricted to elements from a single object.
• Service Notification messages can be packetized if they are very large (implying a subscriber to several notification types could be receiving interspersed packets from multiple Service Notification messages).
• Service Notifications may only be published by the Service for which they are defined.
• Multiple notification types may be defined for a given Service type, and all can be subscribed to separately.
• Service Notifications cannot be blocked by agents invoking SMB.

4.1.3 SIF Design Requirements for Zone Service Technology

The following requirements apply to all Zone Services:

• All responses to invocations of Zone Service operations MUST be asynchronous.
• Zone Service operations MUST use a document-oriented messaging pattern and not RPC.
• Zone Services MAY expose any number of operations and Notification types.
• Zone Services MUST provision themselves in the Zone over the existing SIF Infrastructure.
• All Zone Service messages with large payloads exceeding the specified maximum buffer size MUST be packetized.

The following requirements apply to all Zone Service Clients:

• Clients MAY subscribe to individually named Notification types from the same Zone Service.
• Client access to Zone Service operations and Notifications MUST be governed by access control list (ACL) policies.

The following requirements, provided by the ZIS, apply to any zone in which Zone Services are deployed:

• Clients and Zone Service Providers MUST NOT communicate directly with each other.
• Zone Service Providers and their clients MUST be guaranteed the full quality of service (QOS) feature set provided by the SIF request/response protocol including:
  • Automatic message routing based on service name
  • Packet ordering
  • Guaranteed delivery or failure notification
  • Publish and subscribe message exchange pattern

4.1.4 Zone Service Design Best Practices

Best practices for designing a Zone Service include:

4.1.4.1 Error Handling

• Faults SHOULD be defined for known exceptional cases.
• SIF_Error MUST be used for error cases.
• Custom error codes MAY be defined for each service.

4.1.4.2 Data Model Reuse

• The SIF Data Model SHOULD be used wherever possible.
• Service-specific data elements SHOULD NOT be used unless absolutely necessary.
• All non-custom objects exchanged during a Zone Service operation MUST also be available using Request/Response calls to an Object Provider.
• An optional object element MAY be mandatory in the service interface.
• A Service Notification SHOULD NOT report on changes to data within a single SIF Data Model object, as it would directly duplicate a normal SIF_Event.
• Where applicable, service definitions can support the exchange of large quantities of data because all Zone Service messages support packetization.

4.1.4.3 General Zone Service Guidelines

• Any Zone Service interface whose operations update SIF Data Model object elements SHOULD be implemented by the Object Provider of those elements, to maintain the “single owner of record” for all SIF elements.
• Zone Service interfaces in the same “set” (ex: Student Record Exchange) SHOULD be implemented by a single application, to minimize deployment complexity.
• Zone Services SHOULD be stateless or use a state token where necessary.

4.1.5 Zone Service Usage Best Practices

Many interactions/transactions between participants in a business process are difficult to implement using a sequence of SIF_Request/SIF_Response and SIF_Event messages. This can be true for a number of reasons.

• The data that needs to be exchanged consists of elements that span multiple object types and a complex choreography results between the Object Providers and the client.
• An application must be relied on to process data that it doesn’t own.

  A special Object Event can be issued, but there is no standard way to detect if the application accepted the data since the subscriber to an Event does not respond to the publisher. So a complex exchange of Events with essentially the same elements duplicated in multiple “process objects” generally results.

• Multiple responses to a single request can occur.

  While the second and subsequent responses can be issued as Events, there is no way to distinguish their differences since all events for a given object type are essentially requests to update the data in a specific object. A Zone Service supports multiple named Notifications which:

  • Are clearly distinguishable,
  • can be subscribed to separately,
  • and can contain whatever data is required (including state data).

Where one or more of the above situations is true, development of a Zone Service should be considered. Otherwise the primary design effort should be focused on defining additional data elements and/or SIF Data Model object types.

4.2 Agency Identifier Services

The Agency Identifier Services replace and generalize data model objects currently in the Specification. The current StudentLocator object and its required request/response choreography are deprecated and will be removed from the specification in the next major release of the SIF Implementation Specification. Although the Identifier Services have been generalized from a state to any kind of agency, many of the examples refer to district and state agencies in order to retain clarity around the transactions.

The data-model-based functionality has been refactored into student Agency Identifier Services:

• Agency Student Identifier Request Service
• Agency Student Identifier Management Service

In addition, an equivalent pair of “StaffLocator” equivalent services has been defined:

• Agency Staff Identifier Request Service
• Agency Staff Identifier Management Service

With an identical set of functionality, the Staff services are involved in a fully parallel identification process. They differ from the Student services only in the Characteristics element that communicates the identifying characteristics of a staff member/employee, vs. a student.

4.2.1 Interface Overview

Both Agency Identifier Request Services provide the following operations:

• RequestIdentifier
• CancelTransaction

RequestIdentifier provides equivalent functionality to a Locator SIF_Query sent from a district to a state, with an identifying IdStatus of “Request Locator”.

The Agency Identifier Management Service provides four operations:

• AssignIdentifier
• ResolveIdentifier
• ReleaseIdentifier
• CancelTransaction

AssignIdentifier is used by a district to instruct the state to assign a new identifier to a student or staff member when no matches supplied by the Request Service are appropriate. It provides equivalent functionality to a StudentLocator SIF_Query sent from a district to a state, with an identifying IdStatus of “New Locator”.

ResolveIdentifier is used to instruct the state that a given identifier from a list of ambiguous matches does indeed uniquely identify a student or staff member. It provides the equivalent functionality to a StudentLocator SIF_Query sent from a district to a state with an identifying IdStatus of “Resolve Locator”.

ReleaseIdentifier is used by a district to instruct the state that a student or staff member has left the district and that the state may release the binding with the district. It provides equivalent functionality to a StudentLocator SIF_Query sent from a district to a state with an identifying IdStatus of “Release Locator”.

The Cancel functionality of the StudentLocator object is provided by a CancelTransaction operation in each service.

Neither the Agency Identifier Request nor the Agency Identifier Management Zone Services define a SIF_MaxBufferSize distinct from the infrastructure default. If an Agency Identifier Zone Service message is large enough to require packetization, the packet “break” can occur only at the end of a RequestIdentifierResponse/Match element.

4.2.1.1 Use Case: Initial Agency Student Id Assignment

This use case process describes the Zone Service choreography used in support of state Id assignment to an enrolling student.

• A student enrolls in a school district for the first time, or re-enrolls but doesn’t know his/her state student Id.
• The district SIS instructs its agent to issue a request for a StudentLocator.
• The state agent registered in the same SIF zone as the StudentLocator provider searches its database using the provided student query parameters.
• If no match is found, a “Valid” response is returned to the district by the state agent containing a new state-assigned student Id.
• If a valid match is found, a “Valid” response is returned to the district by the state agent containing the valid state student Id.
• If more than one student match is found, no state student Id is returned. Instead, an “Ambiguous” response is returned. The district and state must resolve this ambiguity outside of SIF. Alternatively if the district SIS agent supports it, the state agent can return an “Ambiguous” response containing a list of StudentLocator objects with match candidates.

4.2.2 Zone Service Operations

4.2.2.1 Student Identifier Request

4.2.2.2 Student Identifier Management

4.2.2.3 Staff Identifier Request

4.2.2.4 Staff Identifier Management

4.2.3 Service Body Definitions

4.3 Assessment Services

The Assessment Services define the role of the assessment scoring system within the overall assessment process. The service interfaces encapsulate a process choreography and a set of data exchanges that are not restricted to object-level Request/Response or Change Event messages. They utilize the existing SIF Data Model with no extensions.

4.3.1 Student Assessment Process

There are three different systems that are involved in scoring a student assessment.

• Online Assessment System (OAS)
• Assessment Processing System (APS)
• Student Information System (SIS)

The assessment process is designed to decouple these systems in time, so that no one system can block another. In brief, the choreography of the assessment process is:

• The Online Assessment System Service (serviceAssessmentAdministration) gives assessments to students and collects their responses.
• These responses are documented in a StudentResponseSet and sent, via a ServiceInput message to the Assessment Processing System Service (serviceAssessmentProcessing). A ServiceOutput message back to the OAS confirms their reception and acceptance.
• The APS adds ItemScores to the StudentResponseSet responses. These scored responses are then reported to the Online Assessment System via a ServiceInput message. A ServiceOutput message back to the APS confirms their reception and acceptance.
• The Online Assessment System uses these responses to create StudentScoreSets for the test and its psychological constructs. When complete, it issues an AdministrationScored Service Notification message to its subscribers informing them of the availability of the new student scores.
• The Student Information System or any other subscribers to this OAS notification can then chose to issue a targeted Request message with the DestinationId set to the SourceId of the AdministrationScored Notification message (the OAS is usually the Assessment Object Provider, but it doesn’t have to be). This Request asks for the completed StudentScoreSets indicated in the notification. The Response message from the OAS contains them.

The exact system interaction during the assessment process is shown in the Collaboration Diagram below and described more fully in the following subsections.

Collaboration Diagram

Assessment results (responses then scores) for an administration are passed from one Online Assessment System Service to one or more Assessment Processing System Services, and then to a single SIS. The process flow is difficult to model without using Zone Services to hide the choreography and avoid bending infrastructure rules, since the SIS should not hold scores for any given administration of an assessment until all the related StudentResponseSets and AssessmentItems have been scored. This means the APS needs to be triggered only after all the responses for a given assessment administration have been committed; otherwise it will not know what comprises the complete set. Having the OAS issue a “ScoreItems” SIF Event wouldn’t be enough because the OAS needs to know that the assessment results have been stored correctly, but Events have no response, whereas ServiceInput requests do.

4.3.1.2 Communication of the collected responses to the system(s) responsible for their scoring.

1. The OAS administers an assessment to a set of students, capturing the raw student responses.
2. The OAS submits the raw responses to one or more Assessment Processing System Service(s).

   A ServiceInput message for the Assessment Processing System Service is sent to the zone. The request invokes the service operation ScoreItems. This request contains multiple packets of data and includes the AssessmentAdministration object, the raw responses of all of the students that took the assessment, and additional demographic data. It may or may not include a list of RefIds for the items to be scored by the receiving service.

3. The ZIS forwards the ServiceInput message to the APS agent that provides the Assessment Processing System Service.
4. The APS Service responds with the ScoreItemsResponse packet.

The APS Service issues a ScoreItemsResponse ServiceOutput message which indicates the request was accepted, which the ZIS routes back to the OAS.

4.3.1.3 Communication of the items' scores 'back' to the OAS.

1. The APS processes the raw responses and calculates scores for each specified item.
2. The APS Service issues an ItemsScored ServiceInput message to the OAS that carries the item scores for the targeted responses. The OAS processes the updated StudentResponseSet to add the ItemScores to its data.

The OAS sends an ItemsScoredResponse ServiceOutput message acknowledging delivery of the scores.

4.3.1.4 Communication of the scores to the system responsible for reporting.

1. The OAS combines the item scores and calculates score totals for each student.
2. The OAS Service publishes an AdministrationScored Service Notification message to the zone which indicates to subscribers that a complete assessment administration has been scored and includes the AssessmentAdministration SIF object.
3. The SIS requests the results from the OAS (by equating the SIF_DestinationId to the SIFSourceId of the AdministrationScored Notification ) using a SIF_Request which specifies the AssessmentAdministrationRefId.
4. The OAS Service returns the results in a Response message and the SIS stores the results.

4.3.2 Service Interfaces

The Assessment Services interface consists of two Methods and one Notification event.

4.3.2.1 Zone Service Operations

4.3.2.2 Zone Service Notifications

4.3.3 Service Body Definitions

4.4 Student Record Exchange Services

4.4.1 Overview

Student Record Exchange (SRE) Services functionality is comprised of six SIF Zone Services that enable trading partners to publish, exchange, and consume electronic transcripts and student records over the SIF infrastructure. The services support both direct and brokered models of student record exchange.

The primary goals of the Student Record Exchange Services are:

• To enable Student Record Exchange choreography between trading partners and brokers, accommodating all of the use cases identified by the Student Record Exchange Task Force. Using the set of core services defined here, an agent should be able to participate in any of these use cases without knowledge of how a broader student record exchange system is constructed or deployed.

• To enable Student Record Exchange choreography in a way that can be accomplished with or without an intermediary broker. Brokers are used to conduct electronic transcript and student records transfer between trading partners that do not know of one another; for example, to implement LEA-to-LEA student transfer or LEA-to-Postsecondary transcript exchange.

• Provide an unambiguous method of implementing the “last mile” of student record exchange – specifically LEA-to-LEA student records transfer – whereby applications that are authoritative for student records must also be able to consume those records.

4.4.2 Terminology

The term trading partner in this document encompasses all types of organizations that might wish to participate in student record exchanges, including LEAs, SEAs, colleges and universities, non-educational organizations, and so on. Student Record Exchanges are carried out between trading partners. It’s important to keep in mind that a trading partner might represent more than one agency; for example, a data warehouse maintained by a SEA might contain transcript data for many students from many LEAs.

The term broker means an intermediary system that acts as a value-add intermediary between trading partners for the purpose of exchanging transcripts or student records. A broker may itself be considered a trading partner.

In this document, the term agency usually means an LEA. The sending agency is the LEA that is furnishing student records, and the receiving agency is the LEA that is receiving those records.

4.4.3 Student and Agency Identifiers

All service messages and objects defined in this document identify students and agencies by StateProvinceId.

A StateProvinceId is a unique identifier that is assigned outside the scope of SIF, typically by a state department of education. For students, the StateProvinceId can be obtained from the StudentPersonal/StateProvinceId element, as well as from the StudentRecordExchange/StateProvinceId element. For agencies that are represented by a LEAInfo object, it can be obtained from the LEAInfo/StateProvinceId element.

It is the responsibility of agents implementing these services to resolve StateProvinceId to a local identifier when needed. Further, because local identifiers are not unique outside of the organization that assigns them, it is not feasible to use local identifiers or SIF RefIds in student record exchange transactions, which span multiple trading partners. It is therefore assumed that any trading partner participating in a student record exchange program has obtained unique StateProvinceId identifiers for students involved in SRE transactions.

4.4.4 SRE Services Overview

Student Record Exchange Services are divided into two categories: Transaction Services and Consumer Services.

Transaction Services allow trading partners to publish and receive StudentRecordExchange objects at the request of another trading partner or broker. They offer a transactional, service-oriented alternative to the data-oriented SIF_Request/SIF_Response model of exchanging data. Transaction Services are intended to be implemented by intermediary agents that collaborate to form a comprehensive student record exchange system; providers of student data such as SIS systems do not typically implement these services. Transaction Services include:

• SRE Publisher
• SRE Consumer
• SRE Broker

Consumer Services offer fine-grain control over importing student data into target systems such as SIS and special education packages. Whereas the Transaction Services deal in StudentRecordExchange objects, the optional Consumer Services each address a specific record type contained in that object. The services are organized by record type so that different consumer systems can import select parts of a StudentRecordExchange object independent of other consumers in a zone. Consumer Services are intended to be implemented by local providers of student data such as SIS systems. They include:

• SRE Student Demographic Record Consumer
• SRE Student Academic Record Consumer
• SRE Student Special Education Record Consumer

The minimum SIF_MaxBufferSize recommended for SIF Zone Services is 64K. In order for service messages to packetize StudentRecordExchangeData elements, the buffer size used must be large enough to accommodate the largest element of that object. StudentRecordPackage objects in particular can be larger than 64K if they contain Base64-encoded binary files such as photographs and documents that are transmitted with a student’s transcript or records.

Each service method defined here accepts a minimum of three input parameters: StudentId, SendingAgencyId, and ReceivingAgencyId. While these parameters are sufficient for all implementations to identify the student and agencies involved in a student record exchange, systems may need to be able to convey additional vendor-specific parameters. The optional ExtendedParameters element can be used for this purpose.

4.4.5 Intermediary Agents

In much the same way as SIF Vertical Reporting solutions rely on intermediary agents that collaborate to implement the overall vertical reporting choreography, a comprehensive student record exchange solution will also make use of intermediary agents in most cases. For example, a commercial state-wide solution might employ several components that collaborate to implement electronic transcript and student records transfer:

• A "broker" at the state level to manage communication between trading partners that do not directly know of one another
• A "publisher agent" at the LEA level to publish student record exchanges at the request of the broker, or directly from other consumer agents. This intermediary might work with local SIF Zones to query and gather data that is needed to fulfil a StudentRecordExchange request.
• A "consumer agent" at the LEA level to consume student record exchanges received from the broker, or directly from other publisher agents. This agent might work with local SIF Zones to consume data into target systems such as student information systems.

While the Student Record Exchange Services defined here do not require intermediary agents – any two agents that implement the SRE Publisher and SRE Consumer services can directly exchange student records – they are designed to not only accommodate but to promote their use.

There are numerous benefits to using intermediary agents. First and foremost, intermediary agents remove the burden of specializing in Student Record Exchange choreography from the broader audience of SIF Agents. By implementing only the SRE Student Demographic Record Consumer service, for example, a student information system SIF Agent can participate in basic LEA-to-LEA student records transfer without the vendor having to know anything about how the overall system is implemented (which may vary widely from state to state). This is particularly important in realizing widespread adoption of student record exchange capabilities in the marketplace.

Another important benefit to using intermediary agents is that they make it possible to build a comprehensive student record exchange solution with a consistent feature set, user experience, and level of service regardless of the mix of SIF Agents that are used in the overall solution.

Figure 1 illustrates the use of intermediary agents in an overall student record exchange solution:

4.4.6 Transaction Services

The SRE Transaction Services are comprised of the SRE Publisher, SRE Consumer, and SRE Broker services.

The SRE Publisher and SRE Consumer services allow for direct exchange of student records between trading partners or the indirect exchange between trading partners and a broker. The SRE Publisher service represents a trading partner that can furnish student records. Its GetRecordExchange method is called to request the records for a given student and sending agency. The SRE Consumer service represents a trading partner that can consume student records. Its SetRecordExchange method is called to “push” student records to the trading partner. It is worth repeating here that trading partners do not always represent LEAs, nor do they always represent the ultimate source or destination of data. A state department of education, for example, might act as a trading partner to furnish student records from a data warehouse. In this scenario the SEA might implement both the SRE Publisher and SRE Consumer services (in addition to LEAs implementing these services as well).

The SRE Broker service allows for brokered exchanges between trading partners that do not know of one another. Its GetRecordExchange method is called to request that records be retrieved for a given student and sending agency. Depending on the business rules and capabilities of the overall student record exchange system, a transaction with a broker can move data from a sending agency to a receiving agency either at the request of the sender or at the request of the receiver. Initiating a request from the receiving agency is by far the most common scenario.

4.4.7 Requesting Student Records Directly from a Trading Partner

When a trading partner wishes to request a StudentRecordExchange object set from another trading partner, it calls the GetRecordExchange method of the SRE Publisher service. The method parameters include:

1. StateProvinceId of the student
2. StateProvinceId of the sending agency (the agency supplying the data)
3. StateProvinceId of the receiving agency (the agency requesting the data)

The SRE Publisher service returns a SIF_ServiceOutput message that contains a StudentRecordExchange object set, or in the case of error, a SIF_Error element. The entire set of student records is returned as the single response to this method invocation. Because StudentRecordExchanges can be very large in size, the results may span multiple packets. The packetizing rules described by SIF Zone Services apply.

Figure 3 illustrates a requestor calling the GetRecordExchange method of a publisher agent that implements the SRE Publisher service (step 1). The publisher agent issues SIF_Requests to its local zone to construct a StudentRecordExchange object set (step 2) or otherwise obtains the data according to its business rules. The results are returned back to the requesting agent (step 3).

4.4.8 Requesting Student Records via a Broker

When a trading partner wishes to request a StudentRecordExchange object set from a broker, it calls the GetRecordExchange method of the SRE Broker service. The method parameters include:

1. StateProvinceId of the student
2. StateProvinceId of the sending agency (the agency supplying the data)
3. StateProvinceId of the receiving agency (the agency requesting the data)

The broker works with the SRE Publisher service of the trading partner representing the sending agency in order to obtain the requested data. The trading partner that’s contacted by the broker could be the LEA identified as the sending agency, or it could be a third party such as a data warehouse hosted by a SEA or other service provider. It is also possible that the broker itself can supply the student’s data from a local repository.

When the student’s records are available for delivery back to the requestor, or if the transaction has failed with an error, the broker responds with a SIF_ServiceOutput message that contains either a set of StudentRecordExchange objects or a SIF_Error element with error information. The entire set of student records is returned as the single response to this method invocation. Because StudentRecordExchanges can be very large in size, the results may span multiple packets. The packetizing rules described by SIF Zone Services apply.

If the broker cannot satisfy the request for any reason, it responds with a SIF_ServiceOutput message with a SIF_Error element. Possible reasons for failure include: the broker does not know how to get in touch with a trading partner representing the sending agency; that trading partner does not implement the SRE Publisher service; a communication error occurred while calling the SRE Publisher service of the trading partner; the service input parameters are invalid; and so on.

Figure 4 illustrates a requestor calling the GetRecordExchange service method of a broker agent, which implements the SRE Broker service (step 1). The broker then calls the GetRecordExchange service method of a publisher agent that implements the SRE Publisher service to obtain student records (step 2). The publisher agent issues SIF_Requests to its local zone to construct a StudentRecordExchange object set (step 3) or otherwise obtains the data according to its business rules. The results are returned back to the broker agent (step 4), and then back to the requestor (step 5).

4.4.9 End-to-End Student Record Exchange from a Broker

A common feature of commercial broker solutions is to provide a central user interface from which registrars manage electronic transcript and student record exchanges. Such brokers can act as the initiator of end-to-end student record exchanges, and therefore require a way to deliver student records to a receiving agency without the receiving agency having previously requested of those records. The SRE Consumer service enables this interaction.

When a broker wishes to perform an end-to-end student record exchange, it first interacts with the SRE Publisher service of the trading partner representing the sending agency in order to obtain the student’s records. The trading partner that’s contacted by the broker could be the LEA identified as the sending agency, or it could be a third party such as a data warehouse hosted by a SEA or other service provider. It is also possible that the broker itself can supply the student’s data from a local repository.

When the student’s records are available for delivery, the broker calls the SetRecordExchange method of the SRE Consumer service of the trading partner that represents the receiving agency. If the receiving agency does not implement the SRE Consumer service, it does not accept unrequested student record exchanges.

The method parameters include:

1. StateProvinceId of the student
2. StateProvinceId of the sending agency (the agency supplying the data)
3. StateProvinceId of the receiving agency (the agency requesting the data)
4. The StudentRecordExchange object set to deliver

The entire set of student records is provided as a parameter to the method. Because StudentRecordExchanges can be very large in size, the method invocation may span multiple SIF_ServiceInput packets. The packetizing rules described by SIF Zone Services apply.

Figure 5 illustrates a broker calling the GetRecordExchange method of a publisher agent at the sending agency, which implements the SRE Publisher service (step 1). The publisher agent issues SIF_Requests to its local zone to construct a StudentRecordExchange object set (step 2) or otherwise obtains the data according to its business rules. The results are returned back to the broker agent (step 3). The broker then calls the SetRecordExchange method of a consumer agent at the receiving agency (step 4) to deliver the data to its destination. No data is returned in the response to this method (step 5), but it may contain a SIF_Error if an error occurred at the receiving agency.

4.4.10 Consumer Services

Whereas the Transaction Services above describe how to move student data between trading partners and brokers, the optional Consumer Services define how to consume or import student record exchange data into target systems such as student information systems. Agents that implement the Consumer Services unambiguously declare that they can consume StudentRecordExchange data in whole or part.

The StudentRecordExchange object is designed as a content package. It is comprised of several types of records (e.g. StudentDemographicRecord, StudentAcademicRecord, etc.), each of which may be provided by a different authoritative source in a zone. When consuming StudentRecordExchange data into a zone, then, it is possible that different systems will be interested in different parts of that content package. An SIS may need to import the StudentDemographicRecord into its database, and a separate special education package import StudentSpecialEducationRecord.

Consumer Services are comprised of:

• SRE Student Demographic Record Consumer
• SRE Student Academic Record Consumer
• SRE Special Education Record Consumer

All SIF Agents that supply student demographic, academic, or special education records are encouraged to implement the appropriate Consumer Services. Doing so enables the agent to participate in state-wide student record exchange initiatives, particularly LEA-to-LEA student transfer. In addition, these agents are encouraged to provide SIF_Request support for the applicable StudentDemograpicRecord, StudentAcadmicRecord, or StudentSpecialEducationRecord objects that apply to them. Doing so will make it considerably easier for intermediary publisher agents (i.e. those that implement the SRE Publisher service) to obtain the data needed to satisfy a request.

If an application is capable of consuming an entire StudentRecordExchange object, it can do so via the SRE Consumer service and choose to not implement the individual record-specific Consumer Services. However, as most applications are only interested or capable of processing a subset of StudentRecordExchange, each should implement the specific Consumer Services that it supports as a best practice. This makes it clear the role each SIF Agent in a zone plays in consuming StudentRecordExchange data. It should also be noted that the SRE Consumer service is part of Transaction Services, which are intended to be implemented by intermediary agents in a comprehensive student record exchange solution. It is therefore envisioned that intermediary agents will implement the SRE Consumer service, delegating to the various Consumer Services in a zone to actually import data into target systems.

4.4.11 Rules for Calling Consumer Services

When an intermediary agent that implements the SRE Consumer service receives a StudentRecordExchange object set and wishes to import the data into target systems, it follows the rules below.

By employing these rules, it is possible for system integrators to install consumer agents of various types in a local district zone, such that each agent can import all or part of a StudentRecordExchange object set received as part of a larger student record exchange transaction. Agents that wish to import all of a StudentRecordExchange object set can implement the single SRE Consumer service instead of the individual record-level Consumer Services. Agents that wish to import StudentRecordPackage data, for which no Consumer Service exists, should also implement the SRE Consumer service.

For each local zone the intermediary agent is connected to:

1. It obtains a SIF_ZoneStatus object to determine the agents in the zone that implement the SRE Consumer service or the individual record-level Consumer Services.
2. For each agent that implements the SRE Consumer service (excluding itself), the intermediary agent invokes the SetRecordExchange method.
3. For each agent that implements the SRE Student Demographic Record Consumer service, the intermediary agent invokes the SetDemographicRecord method, supplying only the StudentDemographicRecord portion of the student data.
4. For each agent that implements the SRE Student Academic Record Consumer service, the intermediary agent invokes the SetAcademicRecord method, supplying only the StudentAcademicRecord portion of the student data.
5. For each agent that implements the SRE Student Special Education Record Consumer service, the intermediary agent invokes the SetSpecialEducationRecord method, supplying only the StudentSpecialEducationRecord portion of the student data.

4.4.12 Consuming Student Records into Target Applications

Figure 7 illustrates how the Consumer Services can be employed in a comprehensive student record exchange solution to import data received from an intermediary agent into target applications like the student information system. Here, the LEA-to-LEA Student Records Transfer use case is demonstrated.

A consumer agent at the receiving agency calls the GetRecordExchange method of the broker agent’s SRE Broker service (step 1). Student records are obtained from a publisher agent at the sending agency via the SRE Publisher service (step 2). The publisher agent issues SIF_Requests to its local zone to construct a StudentRecordExchange object set (step 3) and returns the data back to the requestor (step 4 and 5). The consumer agent then consults the SIF_ZoneStatus object of its local district zone and learns that two applications are capable of consuming student record exchange data. It asks the student information system’s agent, which implements the SRE Student Demographic Record Consumer and SRE Student Academic Record Consumer services, to import those portions of the student data (step 6 and 7). Next, it asks the special education package, which implements the SRE Student Special Education RecordConsumer service, to import the special education record (step 8).

Figure 8 depicts a variation of the above, where the SIS Agent implements the SRE Consumer service instead of the individual record-level Consumer Services. It might do this, for example, if it needs to process StudentRecordPackage data, for which no record-level Consumer Service exists.

4.4.13 Zone Service Operations

4.4.13.1 SRE Broker

4.4.13.2 SRE Publisher

4.4.13.3 SRE Consumer

4.4.13.4 SRE Student Academic Record Consumer

4.4.13.5 SRE Student Demographic Record Consumer

4.4.13.6 SRE Student Special Education Record Consumer

4.4.14 Service Body Definitions