Metadata and Services at the 2008 SIFA Annual Meeting

This year's SIFA Annual Meeting was held in Washington, D.C. Each day's agenda included both specification development work and end-user content. This forum is typical for SIF meetings; it provides great opportunities for end-users and developers to collaborate. The topics of metadata and services occupied quite a bit of my time during the meetings.
The primary focus of the Data Model Task Force meeting on day one was to make progress on the work that we are doing with pattern development for the Data Model. The general thought process is to develop and apply a pattern language for SIF data objects to increase the quality of the specification as it continues to grow and change. Patterns will hopefully arm our data experts with validated techniques for modeling and moving data. As the meeting actually unfolded, we were not able to spend a lot of time on patterns. The agenda item prior to patterns was metadata, and it actually occupied the majority of the meeting time.
Metadata in SIF tends to confuse most people. Metadata in SIF currently takes the form of learning-content-centric elements, plus a very general-purpose time element, that can be applied to any data object. The specification is loose about how to use metadata; it indicates that a specific contract must exist between suppliers and consumers of metadata. Metadata is always optional, and has no impact on operational systems; they simply ignore it if they don't want to use it. Metadata will increase in importance to SIF as more and more teaching and learning vendors use SIF. SIFA's intention is not to create a new specification for metadata but, rather, to leverage what is already out there. Elements of LOM have already been incorporated into SIF. Metadata will continue to evolve; new elements have been proposed for the 2.2 release. I think a good step in eliminating confusion and making metadata more useful will be to develop formal ways to define metadata contracts. Services will also likely have an impact on how we use metadata in SIF.
"Services" is a hot topic within SIFA. We have tried to take the time to clarify what we mean by services, and I have a previous blog post on what "SIF Services" are, and are not. It is most productive if you can wrap your mind around the fact that, today, SIF is primarily a message-based interoperability specification. Understanding message-based interoperability is really important. It is a recognized and valid approach to systems integration that falls in the general category of Enterprise Application Integration solutions. The current architecture of SIF as defined in the SIF Implementation Specification consists of a Zone Integration Server (ZIS) and Agents.
The ZIS is the message bus. Its main functions include guaranteed delivery of messages (queuing), providing a channel for transport, and providing access control to data. Agents are message gateways that sit between applications and the ZIS. Agents' main functions include moving messages to and from the message queue over SIF transport (which requires an understanding of Infrastructure) and translating between the SIF Data Model and the application's native data model. Many of the components of the SIF Infrastructure do not have mature, equivalent standards in the Web Services (note the intential caps) world. However, those standards are evolving and may, one day, provide an alternative to the SIF Infrastructure or, perhaps, replace it altogether. For various reasons, this will not happen over night. Today I believe that it is most advantageous to place "services" into two buckets: 1) intra-zone services, which will be based on the current Infrastructure, and 2) extra-zone services, which will be based on existing W3C standards.

Context of services in SIF

Intra-zone services are proposed for the 2.3 development cycle. The proposal, which seems to be well thought out, adds new message types to the SIF Infrastructure to allow for service invocation, response, and eventing. It is a good evolutionary step for SIF that allows us to solve problems using our current and widely deployed technology base. Adding support for intra-zone services to existing agents should be a relatively low level of effort.
I frame extra-zone services as SIFA sanctioned methods to get data (and functionality) into and out of a Zone. Extra-zone services would likely be built on SOAP and other standards (RSS, REST, JSON were also suggested "protocols"). Leading members of the association are working together to determine the best ways to explore the design and construction of extra-zone services.
Over time, we will hopefully end up with a unified services architecture. For now I think exploring intra-zone and extra-zone services as separate solutions to distinct problems is the best approach.