SIF Association

This blog is run by the staff of the SIF (Schools/Systems Interoperability Framework) Association for the use of it's members and the general educational community.

It is specifically designed for those who are interested in understanding what SIF is about, where the standard is going and how Schools, Districts and State Educational Authorities will benefit.

Saturday, April 16, 2011

WSDL 2.0 vs. WSDL 1.1

In selecting the set of normative dependencies for the SIF v2.5 web services infrastructure, WSDL was the obvious choice for defining the interface (the set of operations) supported by the SIF Zone.  The issue was then which version of WSDL to adopt.

WSDL 2.0

The arguments for the adoption of WSDL v2.0 were primarily based on its areas of enhanced functionality.  Of these, the ones of possible importance to SIF were:
  • Support for additional message patterns (ex:  “Out – Multi In” could correspond to Register for Events, Receive 0-n Events)
  • Better and more powerful fault handling notation, allowing clearer and easier reuse of WSDL segments within the WSDL file.
  • Improved SOAP v1.2 bindings which default many formerly explicit parameters to reduce the likelihood of interoperability problems.
  • Support for interface inheritance
All of these would bring increased clarity and structure to any v2.0 WSDLs SIF might publish. In addition, since WSDL 2.0 migration is difficult (when a service updates to WSDL 2.0, all client stubs must be upgraded at that time), then if a normative WSDL v2.0 dependency were to eventually be decided on for SIF,  it would make great sense to do so at the beginning.

 WSDL 1.1

The arguments against the adoption of WSDL v2.0 included the following (of which the first was considered the decider).
  • WSDL 2.0 is  not supported by most Java and .NET based developer toolkits (Apache being a notable exception)
  • WSDL 2.0 had gained little industry traction in the 3 years since the specification was formally approved.  What little WSDL 2.0 adoption there is, is currently centered around REST and not SOAP.
  • All comparable industry standards in the Education space utilize WSDL v1.1
The Zone WSDLs for the SIF v2.5 release are provided in WSDL 1.1 only, and that is the only version the ZIS is required to support.


  There were 2 clear choices facing us regarding the selection of the transport layer to be used for the new SIF Web Service infrastructure appearing in the SIF v2.5 release:  SOAP or REST.  After some deliberation, the choice was made to go with SOAP.  The thinking behind that decision is discussed below,.


REST is growing in popularity in those architectures where the client and service relationship is “casual”.  An example of this would be a public web site accessed across the internet by a browser, which may not access the site again.  Probably the major advantages of REST web services are:
  • Lightweight - not a lot of extra XML on the wire
  • Human Readable Results (no intermediate layer)
  • Easy to construct - minimal toolkit / conventions required
REST is also targeted primarily at supporting simple CRUD service interfaces, whereas most existing toolsets (ex: Apache CXF) use a SOAP-based IDE to expose pieces of application logic (as opposed to data) as web services, and automatically generate services and server stubs from a supplied WSDL file.

SOAP and the WS-* technologies that leverage it are currently the leading choice for architects constructing a  B2B transport within the enterprise, especially for mission critical applications.  These generally have specific support requirements in the areas of security, reliable messaging and stateful (transactional) business process execution. 

Decision Points
It is this B2B paradigm for server connection which most closely parallels the environment of the existing SIF Zone.  In both the Zone and within an enterprise, services register centrally and there is standards-based administrative control of service message authentication and access authorization 

While the SIF Infrastructure Service WSDL wrapping the ZIS is currently a CRUD service, this is not likely to be the case for long, as the current SIF Services roadmap calls for web service equivalents of previously defined Zone Services such as Assessment, Student Locator and Student Record Exchange.  SOAP is a much better candidate transport for supporting this extension.

Interestingly, of the comparable educational industry standards (IMS, PESC, LETSI, ADL/SCORM) all currently have SOAP as part of their web service frameworks and none have REST, although several of them are investigating its use.

Finally, this decision is not irrevocable.  Should there be an unanticipated surge in REST adoption within the K-12 organization, it can conceivably be added as a 3rd reference infrastructure using the same ZIS-based transport bridge architecture used to integrate SOAP and the original HTTPS transport.