Web services stuff we can nick
From an education sector point of view, one of the nice things about a service oriented architecture (SOA) is that the commercial world is heading the same way. IT vendors have seen the signs and have been huddling together in a range of acronyms to bash out service specifications for all sorts of things- and implementing them too. We have a look at some of the latest specs that we could help ourselves to.
Because a SOA is essentially a loosely-coupled collection of services that are meant to do one thing, and do it well, a great many of those that you'd typically want in a Managed Learning Environment (MLE) are not specific to the educational or any other sector. Which is good, because then we don't have to worry about it ourselves, and there is a much greater chance that support for such service specifications is built into the basic server software on which the more specifically educational stuff is built.
Take this lot, for example:
Or: Web-Services Interoperability, Basic Security Profile Version 1.0 Working Group Draft, as it is currently known. The purpose of this one is simply to prevent sensitive data from being snooped on the way from a web service provider to a consumer. You wouldn't want anyone to mess with the messages that go between a grade book webservice and a high stakes assessment tool, for example, and implementing WS-I security can help prevent that.
WS-I security, like the WS-I basic profile, is not a service in its own right, but it is part of the infrastructure that can make up a specific web service such as the gradebook example. It isn't even a spec as such, but a profile of a whole grab-bag of existing specs that have something to do with securing web services, and that have been narrowed down and made to work together in a coherent fashion. The idea is to come up with something that simply says: if you want to make your webservice secure, and have it interoperate, this is what you need, and here's how you implement it.
To be slightly more specific: it takes the main specs in the area of transport layer security (HTTP over TLS- the sort of thing online banks and shops use) and message security (Web Services Security: SOAP Message Security- a method of encrypting and signing messages), and integrates it with the generic web services stuff defined in WS-I basic profile. The result is kind of webservice subassembly that may not offer the greatest flexibity, but satisfies most of the people most of the time.
WS-I generally is one to watch in this space, as it represents a kind of consensus in the IT world how the most important, free and open web service specs are to be implemented across different platforms, operating systems and programming languages. Implementation support is therefore quite broad and deep.
That is: the Liberty alliance's Identity Web Services Framework. This one is a bit more partisan, as the issue of identity federation (networks of trust that allow users access to resources) has split the IT world somewhat. The Liberty alliance is essentially the 'everyone but Microsoft' crowd (i.e. Sun, Nokia, Ericsson, HP, AOL, Vodafone) and the rival WS Federation is the rest (IBM, BEA, Verisign, RSA and Microsoft, of course). The latter is a follow-up to the slightly infamous, and not entirely successful launch of Microsoft's Passport service. That one was designed to hold all personal data in one central database in Redmond, which proved a little too much for both consumers and other vendors.
The purpose of both WS Federation and Liberty ID-WSF is similar though: provide a solution for the almost mythical single sign-on that everyone wants. With either of these, the idea is that networks can allow users from trusted other networks access to resources such as repositories or even student record systems, without needing to shuttle around private data. The user just authenticates with their homenetwork once, and the network of trust that is instantiated with the federated ID webservices takes care of the rest.
There is also a third, non-partisan spec for this area from OASIS- probably the most important spec body in the web services area. Security Assertion Mark-up Language (SAML) is a single spec rather than a bag of smaller ones since it only deals with format of security assertions. That is, it tells you how to say "user x has been authenticated by me in this way" or "user x is authorized to access this class of databases", but it doesn't automate the setting up or administration of networks of trust in the same way that the others do. It is likely to be the most widely implemented spec in the area, though.
This one just kind of happened, like the RSS spec that it is more or less designed to replace. Various people on web fora and mailing lists thought it was a good idea and recently formed an Atom working group in the Internet Engineering Task Force- the body that sets technology specifications for the internet.
The purpose of Atom is to provide a document format and an editing protocol for syndicated web content. Like RSS, it allows people to set up channels of content that other people can subscribe to via newsreading and aggregating software. The difference with the existing RSS specs is that it aims to be a bit more flexible than the most authoritative RSS version so far (1.0), but much more unambiguous than RSS 2.0. Also, it is specifically designed with rich data types such as video, audio or image formats in mind, and will have an HTTP based protocol to allow editing of content.
In a word, it is designed to allow anyone to share and edit whatever stuff they want in a more or less structured fashion, with a well defined, interoperable core.
The above specs are just three web service based technologies who happened to have come up with something new recently. There's loads more on anything from the deadly serious (electronic business XML), to the quite exciting (IETF SIMPLE instant messaging-based protocols) to the slightly alarming (OASIS Common Alerting Protocol- for public emergency warnings). Clearly, there's not many human concerns that aren't supported by some existing web service, or can't be supported by a new one. Which is also the danger: there's plenty such acronyms already, and no physical limit to many more. It behoves people in e-learning technology, then, to plunder the WS-Goodybag before pouring resources in the re-invention of tech that already exists. In the interest of everyone, of course.
More about WS-I Security and other profiles can be found on the WS-I website.
Liberty ID-WSF resources are available from the liberty alliance project. WS-Federation has its home on the IBM website. SAML has a number of pages on the OASIS site.
More about Atom can be found on the Atom Wiki. The IETF Atom charter working group wiki is specifically about the standardisation work.
By far the best way of keeping track of everything else in the webservices world is by reading the Coverpages- from whence most of the other links came.