This website uses cookies to store information on your computer. Some of these cookies are used for visitor analysis, others are essential to making our site function properly and improve the user experience. By using this site, you consent to the placement of these cookies. Click Accept to consent and dismiss this message or Deny to leave this website. Read our Privacy Statement for more.
Print Page | Contact Us | Sign In | Join the A4L Community
Chapter/Locale: Global
Group HomeGroup Home Blog Home Group Blogs
All things relating to the overarching 'global' A4L Community.... don't forget to check out the blogs on the locale Communities too! | Australia: http://www.a4l.org/blogpost/1545371/Chapter-Locale-Australia | North America: http://www.a4l.org/blogpost/1545399/Chapter-Locale-North-America | United Kingdom: http://www.a4l.org/blogpost/1545553/Chapter-Locale-United-Kingdom

 

Search all posts for:   

 

Top tags: Infrastructure  Specification  2017  2018  2019  Community  SDPC  SIF 3  technical  data privacy  privacy  2016  A4L  API  Chromebook App Hub  community driven  Community Review  errata  GEPS  global  Google  grade pass back  interoperability  Just The Facts  newsletter  partnerships  REST  roster  Scalable  Secure 

SIF Infrastructure Specification 3.3: errata published

Posted By Administration, Friday, August 30, 2019

SIF Infrastructure Specification 3.3: errata published

SIFInfrastructureIt has been reported by A4L Community members that there were a few inconsistencies in the recent release of the SIF Infrastructure Specification 3.3, and the Community has been working hard to address them.  

 The change with the greatest impact comes for those doing privacy work, as the POD has been updated to follow our conventions when it comes to listing contacts. There were also unintentional changes from 3.2.1, around the number of times other fields may appear or where “nil” values are allowed.  Work was also focused to make some of the Infrastructure specific payload features more obvious, and JSON much more approachable.   

So, if you are doing any work with the 3.3 Infrastructure you will want to be sure you are using the August 15, 2019 version of the Infrastructure payloads.

To review the SIF Infrastructure Specification 3.3, please go to: https://www.a4l.org/page/Infrastructure3-3

Tags:  2019  errata  Infrastructure  Specification 

Share |
PermalinkComments (0)
 

SIF Infrastructure Implementation Specification 3.3 enters Community Review

Posted By Administration, Friday, March 29, 2019

SIF Infrastructure Implementation Specification 3.3 enters Community Review

 

SIFSPecThis may be our most impactful Infrastructure release since we switched to REST, due to the inclusion of components to express privacy controls over the wire, which even ensures the latest set is known by the receiving system.  This joint effort with the Student Data Privacy Consortium (SDPC), a Special Interest Group of the A4L Community, is just the biggest change in this landmark release. 

Members are encouraged to review the proposed Specification release and help us get it right!

Current Scope for this release includes: Privacy Integration, Version Indication/Negotiation, PESC JSON Adoption, Global Core Objects for Cloud/App integration, and clarifications* (not intended to change the meaning of the specification.)

The Community Review is currently slated to run from March 28 – April 14, 2019 (inclusive).  Members are encouraged to provide their approval/feedback before COB on April 14 and will need to login to the website to access the survey.  A link to the Specification documentation can be found via the survey here.

 

Tags:  2019  Community Review  Infrastructure  Specification 

Share |
Permalink
 

Doers Doing...

Posted By Penny Murray, Monday, February 18, 2019
Updated: Friday, February 15, 2019

Doers Doing...

This Photo is licensed under CC BY-SA-NC 

This Photo is licensed under CC BY-SA-NC

In one way I am glad that interoperability and privacy is once again becoming a “hot button” topic for conversation in the wild world of education.  While the two terms might make may in schools roll their eyes, throw up their hands, or turn a blind eye, they are becoming more and more a concern in the everyday lives of student data stewards globally.  Items in the news, new organizations playing a role in the topic and even additional funding opportunities from outside sources can help support the right data getting to the right place at the right time under local control.

The other side of this coin is that, like fashion, this has been a topic really since 1997 when the origins of many of the technical standards organizations were formed by various communities to support the needs around data interoperability and in some cases privacy.  The SIF Association, now the Access 4 Learning Community, was the first group focused and driven by K12 end users demanding marketplace providers to address their growing data management issues at the local and state level.  So, in essence the topics are not “new” but elevating the awareness factor can benefit us all.

But that is only part of the story.  I am very proud of the thousands of organizations, volunteer hours, membership dues support and the community involvement that has been driving the work of this Community for now more than 20 years.

 

I mentioned to an outstanding group of educational support agencies last week that in my tenure at A4L, I have seen more than 37 national projects, supported by hundreds of millions of dollars, fail in their attempts to move the marketplace, support schools and states, or systemically change how we address the roles of the data stewards.  Generally, they either had no established and vested community just an end product or they had a community with no clear “what does success look like” in mind.

 

A4L and the SIF Specifications are in that way VERY different.  With our tiny staff the community determines the technical issues to address, the community does the technical development and the community gets the word out on the need for standardized data interoperability strategies – not driven by a staff or one or two vendors.  It is written into our By-Laws!  It means the specification development might take longer but we have transparent governance, development processes and community resources allocations for any to view.

Look soon for the next Community technical blueprint, codenamed “Unity”, to be released which will allow the thousands of applications using the previous SIF Specifications an easy lift to a new modern infrastructure, a data model aligned to the Common Education Data Standard, additional privacy controls in a Global Educational Privacy Standard, and the inclusion of standardized xPress API functionalities currently being used on the ground for rostering, student records exchange, IEP and soon grade pass back.

I am proud of this Community.  The work is Community driven, Community resourced and Community developed around transparent processes – for over 20 years of learning impact!

 

 

 

Tags:  2019  API  Community  community driven  GEPS  grade pass back  interoperability  privacy  roster  security  Specification  student records exchange  Unity  xPress 

Share |
PermalinkComments (0)
 

A Technical Architects Guide to the SIF 3 Infrastructure: Reliably Standard

Posted By Penny Murray, Wednesday, October 18, 2017
Updated: Friday, October 6, 2017

A Technical Architects Guide to the SIF 3 Infrastructure: Reliably Standard

  • Pick your tools:
    • UUID
    •  REST
    •  Data Model
    •  Code Generation
  •  Choose your expert:
    • SIF 2 expertise can be hard to find.
    •  Most developers are comfortable with REST APIs.
    • Same tools, two hours instead of two days.

When I came on staff seven years ago, I was introduced to a vision for SIF 3 so obvious I instantly agreed to pursue it and I have ever since.  The idea was simple, instead of inventing things and behaving like an oxymoronic proprietary-standard, we would strive to first use other standards in our work.  The cry propelling us forward became a “standard of standards” and we have followed this mantra in the big things and the small.

Let’s start with something small but more impactful than we could have imagined.  Our attempt to use GUIDs styled after a dominant market player instead of standard UUIDs had gone from convince to pain point.  Rather than picking up a UUID library, developers were trying to meet the requirements on their own.  With solutions that did everything from violate the rules to leak personal identifiable information (PII).  Moving to UUIDs has proven easier for marketplace providers, safer for end users, and more enforceable by the community.  Plus it has given those with challenges keeping data unique, guidance and options to do so.  With out this seemingly small change, our ability to have a successful REST based standard would be compromised from the beginning.

Of course we also seek to be ready to move any data model necessary.  For models that do not use UUIDs like the infrastructure does, we will use the unique identifiers the data model does identify.  For data models that don’t have IDs, we have the option of wrapping the data in a service driven by an infrastructure standard job object.  To get a data model on and off the wire properly we have worked a lot with popular code generation tools and labor to ensure our infrastructure payloads and our data model are defined in XML schema using the venetian blind style and recommend others do as well.  While adhering to standards has yet to fail us, it has had an interesting indirect impact on the adopter.

It is generally agreed that to succeed with SIF 2 you should engage a company (or at least an individual) familiar with the SIF 2 infrastructure.  It turns out there is a lot more people that are familiar with REST, XML, UUID, OAuth, and other standard technologies.  This means there are a lot more people ready to dive into SIF 3 projects.  Once these people are engaged, they have choices.  Just as they can code directly to the data model or leverage code generation tools, they can start with their favorite tools or grab ones already built out to make SIF 3 development even easier.  The bottom line is it is simpler to find experts and they can usually produce solutions faster.

So by seeking and leveraging the usual, you should find the SIF 3 infrastructure a standard of standards.  By building on these standards, you should find it scalable.  Yet our next topic will make keeping true to this formula, significantly harder.

Great SIF 3 developers are out there please let them know it.

To find out more about the SIF 3 Infrastructure Specification, please go to: http://www.a4l.org/page/Infrastructure


Tags:  2017  Infrastructure  SIF 3  Specification  technical 

Share |
PermalinkComments (0)
 

A Technical Architects Guide to the SIF 3 Infrastructure: High Performance

Posted By Penny Murray, Wednesday, October 11, 2017
Updated: Tuesday, October 3, 2017

A Technical Architects Guide to the SIF 3 Infrastructure: High Performance

  • For everyone:
    •  Clean encapsulation accelerates development and performance by simplifying logic.
    • Support for multiple data objects in the same payload move more data at once in many situations.
    •  Fewer overhead messages increases throughput, especially in high latency environments.
  • Taken to the max:
    • Multiple connections are defined for both synchronous and asynchronous data exchanges.
    • Long polling brings real time responsiveness to new levels.
    • eTag and similar support for multiple object queries help you get only the data that has changed.
    • Same use case 400 times faster.

The rules for web services have changed.  In 2005 it seemed things had matured around SOAP, WSDL, and highly dependable asynchronous message flows wherever they may be needed.  Fast-forward to today and we have REST, API Sandboxes, and the occasional timeout is seen as preferable to an always-delayed response.  The SIF 3 infrastructure both operates in this world and is designed to make the most of it.

First we set out to have clear encapsulation or delineation between where the infrastructure ends and data begins.  Fortunately REST makes this evident with a consistent place for headers and another for the body of data.  The result is accelerated development and a reduction of errors by simplifying logic.  Put another way, it is easier to find the data when it is always in the same place.

Next we considered our rich history bundling data for transport.  We had certainly gone the one object at a time route; while simple, it also proved to limit overall performance.  Our initial attempt at packages didn’t go much better; while performance could be gained our efforts to set limits sometimes resulted in failure.  By the time we designed SIF 3 both capabilities had matured and patters had emerged on how to best handle this situation.  Now pages of responses mirror online search or shopping results and tunable queues do the same thing for events.  Interoperability works best, when both sides coordinate.

Once these things were tightened up we went looking for other inefficiencies and discovered with a little thought we could eliminate many messages from our flow entirely.  Fewer overhead messages increases throughput, especially in high latency situations.  Every trip back and forth counts, with SIF 3 you simply make less.

Now the changes above are fundamental and expected to reach everyone.  However, if you need more performance the SIF 3 infrastructure has options.  From multiple connections for increased throughput to long pulling for closer to real time events, you have options.  Taken together for a well-selected use case in a low latency environment we have seen data flow up to 400 times faster than SIF 2.

It is time to start planning your upgrade: http://www.a4l.org/page/Infrastructure

 

Tags:  2017  Infrastructure  SIF 3  Specification  technical 

Share |
PermalinkComments (0)
 

A Community Developed Blueprint to Modernize and Simplify Information Exchange

Posted By Penny Murray, Wednesday, October 4, 2017
Updated: Tuesday, October 3, 2017

A Community Developed Blueprint to Modernize and Simplify Information Exchange

The Access 4 Learning (A4L) Community’s SIF 3 Infrastructure is the latest release of an open standard infrastructure, bringing SIF into the modern era by leveraging a REST based approach to data exchange. The key contribution the SIF 3.x Infrastructure Specification defines, coordinates and standardizes the ways in which multiple RESTful clients can access a RESTful educational service securely, robustly, and in real time.

There are three ground-breaking design advances which satisfy long standing requests from SIF 2.x developers and implementers:

  • Scalability Designed In.
    • From the simplest exchange to the most advanced, SIF 3 design seeks to first do more with less, then do more with more.  The result is an efficient cloud friendly infrastructure.
  •  Start Simple and Build on Your Integration.
    • First, the message broker functionality has been broken up into a set of multiple, separately implementable Infrastructure Services. Second, the SIF 3 architecture makes it possible to construct and deploy SIF-compliant solutions in a ‘Direct Environment’ without utilizing any middleware!
  •  Infrastructure independent of the Data Model.
    • All current data model dependencies have been removed allowing the SIF 3 infrastructure to carry SIF object data from any locale (North America, UK, Australia), or other major data standards, without change.

These changes allow SIF 3 solutions to be deployed in any Education Data Center using the identical technologies that are already present and known to IT personnel.

 
How Scalable are SIF 3 deployments?

SIF 2 solutions have been deployed in every setting from a single school to an entire State, depending on need.  Performance limits in large deployments during reporting periods were analyzed leading to major performance enhancements for the SIF 3 Infrastructure.

Let’s Focus on the scalability features anyone using the SIF 3 infrastructure will encounter:

  • Fewer Trips:  Every exchange has been scrutinized for messages that can be done without.  The result is whether you are requesting objects or publishing events, efficiency has been maximized.
  •  More Data Per Trip:  From the ability to negotiate pages of data on the fly, to events that convey many similar changes, more data moved per trip means less waiting.

For those requiring even more scalability:

  • Just the Changes:  One scheme that has matured throughout the life of the SIF 3 infrastructure is the ability to request just the desired changes.  This was first done at the object level, and then expanded to collections.  Moving less data overall, means the data you need gets there faster.
  •  Multiple Connections:  While this is available in a few different places within the specification the overall approach and result is consistent.  By having parallel streams of data, more data can be delivered in the same amount of time.

 

How Does an Integration Grow?

The SIF 3 Infrastructure is an enabler for direct, brokered or hybrid environments to exchange data.

Direct Environment – single source for all data.

o    Connects Data Consumers to Data Providers with no middleware - can be multiple connections.

o    Supports cloud based environments

o    Example: SIS accessed by students via mobile devices OR SLDS seeded by multiple District SIS and accessed by data analytic and reporting applications

 Direct-Environ        Direct_Env

 

 Brokered Environment – multiple data sources. 

o    Connects Consumers to multiple Providers leveraging existing IT middleware (Enterprise Service Bus (ESB))

o    All ‘direct’ Data Consumers can run in brokered environmentsExternal applications register to provide their data – highly scalable to meet current and future IT requirements

o    Centralized enforcement of site data security and privacy policies – YOU are in control of YOUR data.

Brokered-Environ     Brokered-Env

 

Hybrid Environment - a combination of environments.

o    In production:  SIF 2 and SIF 3 infrastructures

o    Shown:  direct and brokered

 

Hybrid_Env

 

 

How reliable are SIF 3 Solutions?

Overall system reliability is of course dependent on the quality of the set of applications deployed in a given solution, and the extent to which these applications successfully interact.  The SIF Certification Program provides the primary way to ensure seamless interoperability between SIF-certified components. 

In addition, the SIF 3 architecture enhances robustness in one revolutionary way.  When one system attempts to impact data in its provider, the requester now receives a set of results.  This can be used to prevent applications’ data becoming out of synchronization.

 

 

To find out more about the SIF 3 Infrastructure, please review the Specification and supporting documentation: http://www.a4l.org/page/Infrastructure

To review the list of SIF Certified applications on the SIF Certification Registry: http://www.a4l.org/page/SIFCertification

 

Additional reading:

 

Download the white paper:  A Community Developed Blueprint to Modernize and Simplify Information Exchange

 

Tags:  2017  Infrastructure  REST  Scalable  Secure  Simple  Specification  Standard 

Share |
PermalinkComments (0)
 
  • SIF Association (dba Access 4 Learning (A4L) Community)

  • PO Box 1024, New Albany, Ohio 43054-1024

  • Phone: +1.202.621.0547

  • staff@A4L.org