Skip to content.
Sections
Personal tools
You are here: Home » Features » SOAs and SOLAs

SOAs and SOLAs

Brian Clark and Andrew Booth
Last modified 21 Dec, 2006
Published 20 Dec, 2006
In this article Brian Clark and Andrew Booth of the SOCKET toolkit project introduce the concept of the Service Oriented Learning Architecture (SOLA). "the vision of a SOLA presented here is one with a large number of diverse services that are micro-managed in an academic domain structure that is integrated using federated Web service registries. The means to quickly introduce and edit, new service compositions must be readily available with close working relationships between academics and developers."

Introduction

In a recent article in e-Learning Focus on the WAFFLE Bus [1], we made the statement that the flavour of an educational Service-Oriented Architecture (SOA) deployment will be different from that of a typical business implementation. This essay provides some support for the claim.

The implementation of a SOA (so-ah) starts with the identification of the key, core business processes that can be modelled as Web services.

The basic difference between a SOA and a Service-Oriented Learning Architecture (SOLA) is that the former is "aligned with" the business processes of a company, while the latter is "aligned with" the teaching and learning processes in a university. The SOLA is different in that the business of teaching and learning is to a large extent a business within a business. What an individual academic does as a teacher of a specific discipline is only loosely coupled to the business processes of the university centre (within the obvious budgetary constraints and contractual obligations).

This "business within a business" view places the academic, the subject expert, at the centre of the process for identifying key teaching and learning processes. While JISC can fund important Web service projects on general subjects such as e-portfolios, online assessment and security, the vast majority of services in a mature SOLA will emerge from individual academics out of the specific and often unique requirements of their specialist disciplines. To see this, one only has to take a brief look at the Web services that are mushrooming up in subjects such as astronomy & space science, environmental sciences, computational biology and physics, for example. We give a short, almost unremarkable, case study below as an example [2].

One of the activities in an online bioinformatics course on which the authors teach involves a group of students performing a phylogenetic analysis on a family of proteins. In other words, they have to deduce a "family tree". First they have to search the public protein sequence databases to find all the latest family members. The whole activity spreads over 6 or 7 weeks. One of the aspects of the activity that provided cause for concern was the need for what was termed a scriba, a clerk who would maintain an official annotated list of all the sequences that the group had found. The job of scriba was becoming too big a burden to place on a group member as the number of sequences grew rapidly each year. It was obvious that some sort of electronic scriba was required, a database that students could populate and search from a Web interface. Using the JISC SOCKET software [3], a Web service that solved the problem was produced in about 3 days. What's more, the socketized scriba appears as a new resource in the Bodington VLE which is being used to deliver the course.

And it gets better. Using the integration properties of Web services, it will be straightforward to extend the range of scriba operations by feeding their output directly into other Web services required to produce the family trees.

This is just one Web service in one module making a big difference to the teaching and learning process. Just as there is said to be a book in everyone, there is at least one Web service in everyone, too. This is one of the reasons that the number of Web services in a SOLA will become very large.

Before going on to look at the differences between a SOA in SOLA in more detail, here is a brief reprise on Web services and service-oriented architecture.

Web services

Web service technology attempts to solve the problem of interoperability between applications running on different software and platforms by introducing common abstract definitions for program interfaces together with common transport protocols and message formats. It is the SOAP-over-HTTP Web service that has formed the growing focus in the business sector over the last 5 or 6 years. JISC now recommends a service-oriented approach as a basis for developing its e-framework [4].

Service-oriented architecture

The term service-oriented architecture was first coined by a Gartner analyst in 1994, and is not exclusive to the brand of SOAP/HTTP service that is dominant today. Several other technologies can serve as a basis for SOA such as Common Object Request Broker Architecture (CORBA), but these have failed to become universally adopted. In the CORBA case, the technology is not easy to apply.

There are many definitions of SOA in the literature: a good representative is provided by BEA Systems [5]

"Service-Oriented Architecture is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs."

The business of teaching

Whenever an academic listens to an evangelist from the world of business Web services, a useful mental trick to employ is to replace the word business, each time it is mentioned, by the phrase teaching and learning before it is processed by the brain. In this way it is possible to identify those concepts and working practices that do or do not transfer fruitfully from the general world of business to the specialist business of education. Those with a bit more mental agility might substitute the phrase teaching, learning, research and administration.

For example, a frequently-given definition for the term business service is

a reusable business process

This becomes

a reusable teaching and learning process

which works passably well.

The same trick can be applied to the SOA definition given above:

"Service-Oriented Learning Architecture is an IT strategy that organizes the discrete functions contained in an educational network into interoperable, standards-based services that can be combined and reused quickly to meet teaching, learning, research and administration needs."

The SOLA fingerprint

A list is given below of the characteristics of a SOLA that, taken together, will distinguish it from most other SOAs. Note that these differences are not all categorical in nature. They are more to do with the scope, scale and relative importance of different aspects of the SOA which, taken over all the items in the list, form a distinct SOLA fingerprint.

  1. The total number of services will be large, often much larger than other SOAs.
  2. The diversity of services will be greater.
  3. A domain management structure will be required, linked by federated Web service registries and a central identity management service.
  4. A core requirement exists for turnkey teaching service aggregation and composition tools.
  5. Services will have to be integrated into a virtual learning environment.
  6. A major proportion of services will have external providers.
  7. There will be more extensive federation requirements (a higher WAFFLE index).
  8. SOA policies and governance will be shaped by the points mentioned above.

We do not claim that the list is exhaustive: no doubt it can be extended by those with different perspectives on the subject. In the sections below we provide some justification for the points made in the list together with some suggestions as to what consequences there might be on a SOLA deployment.

1&2, Number and diversity of services

A recent report from Gartner referred to "midsize-to-large" SOAs as having 50 services or more [6].

What about very large companies? One of the most well-known institutional implementations of SOA belongs to the Standard Life Assurance Company, the largest mutual assurance company in Europe with over 7 million customers and over £100 billion in assets. After around 10 years of development, Standard Life has about 300 Web services in commission, with around 50% of these being reused producing estimated development savings of at least £3 million [7].

How might a university compare to these two rough benchmarks? On the briefest of trawls through the Web for possible candidates for bioinformatics Web services that might be of use for our online bioinformatics course, over 130 WSDL documents were harvested [8], [9], [10]. This is from one domain (albeit a highly multi-disciplinary and calculation-oriented one) in one faculty. Over a whole university or university federation, the number of academic services alone could quite easily rise into the thousands, eclipsing even Standard Life. A thousand services is only about 100 services per faculty in a big university, after all.

Allied with the likely high number of services in a mature SOLA, the diversity of the functionality is likely to be much greater than with a typical business SOA. This is true almost by definition of the concept of a university. Yet even within this diversity of academic disciplines, the SOLA services have a unifying factor formed by the common aims of teaching, learning and research.

The high numbers and diversity of services leads to what seems to be an inescapable conclusion.

It will be impossible for all the services in a SOLA to be managed by a central IT authority.

The management architecture must evolve to match the service architecture. Similar sentiments have been expressed in the past [11].

The consequence of a large number of services must be devolution of the ownership of specialist services to the faculties.

With new loosely-coupled, pluggable, service-oriented VLE designs [1], it will be possible to deploy new services at the flick of a switch. This should become a hugely important mechanism for injecting current research into teaching, but it has to be done locally, near to the academic and technical teams that own the services.

One of the touted advantages of a SOA is to create a more agile institution, one that is more responsive to rapidly changing external stimuli. Any hope of an agility gain will be lost without devolution. The organs at the centre of a university are not agile, but the teachers and researchers in the faculties and research institutes can be. The agile technology must lie in the hands of those who can take advantage of it.

The central IT department, then, is relieved of the duty of micro-management of Web services, and can concentrate on the macro-management of the network.

3, Federated registries and identity management

Of course, the result of devolution cannot be a spray of unconnected faculty servers. This devolved structure must retain organisational integrity and security. One suggestion for achieving this is a central identity management service and federated service registries.

The federated registry creates a Web services information network that binds a whole institution together. You can only re-use something if you know it's there in the first place. Each major service domain will be responsible for maintaining its own registry. The data in the registries will pertain not only to services that are in commission, but also those that are in the planning and design phases, and those that have been taken out of service. This will facilitate reuse or adaptation of services and help to minimise duplication of effort.

4, The need for turnkey service composition tools

As one investigates Web services from an educational perspective, one almost automatically begins to talk about them in an identical syntactical and semantic manner to that employed by educational technologists with learning objects. Web services are interoperable. Web services are reusable. Web services can be combined to form composite services. There is one big difference, however. Web services have well-defined interfaces which enable this interoperability, reusability and composability in a universal way that has never been possible with learning objects. As the number of useful services and tools rises rapidly, teaching and learning services will usurp the role presently held by learning objects as the primitive entities in educational technology. Initially, this will be a de facto process until new practices and iconclatures emerge that are adaptations of the results of workflow gurus such as W.M.P. van der Aalst [12].

Teachers (and researchers) will need to be able to change service compositions frequently and easily in the process of creating and maintaining educational material. The SOLA services, building blocks for creating complex teaching services, need to become more lightweight, locally-managed commodities. Hence there will have to be close, well-oiled working practices developed between the subject experts and the developer teams.

There is, in fact, a new educational design space exposed by Web services that appears just at the point where the consumer software strips SOAP messages of their envelopes to produce the naked service payloads before they are dressed again in new outfits and sent to the browser. In this space the payloads can be combined, transformed, or used as input data for other Web services.

It is this space that teams of teachers and developers working together must exploit to create a course through the composition of simple services to form more complex teaching and learning services. It might be said that the central business process of teaching is service composition. This seems also to contribute to the overall impression of a difference between SOAs and SOLAs.

It is important to note that in the Java world there is a standard that governs this very space - it is called Java for Business Integration (JBI). If the substitution trick mentioned at the start of the article is employed here, Java for Business Integration becomes Java for Teaching and Learning Integration. It will not suffice for the next generation of VLEs to be simply consumers and providers of Web services: they need to be designed around the process of forming educational composite applications and workflows.

The argument above applies to WSDL-based Web services: it is the WSDL document that defines the abstract interface. Representational State Transfer (REST) is another type of web service based on the GET, POST, PUT and DELETE methods of the HTTP application protocol [13]. The great advantage of REST services is that they are easier to implement and will be more appropriate in many circumstances in a SOLA, for "heavy lifting" of large datasets from one location to another, for example. One drawback to REST services in a SOLA is that secure REST services will be implemented using the HTTPS protocol which is a point-to-point solution that does not sit well in a loosely-coupled architecture based on message-oriented middleware, such as the ESB.

5, Integration with a VLE

Even in the heady new world of Web services and Web 2.0, some sort of VLE will still be required. The structures, procedures and aims of a university must still be mapped onto its virtual educational environment. Course management, security, privacy and identity are all issues that are best addressed through the VLE. The monolithic VLE of the past, however, becomes the dynamic, distributed service-oriented VLE (SOVLE) of the future. The SOVLE will be able to manage Web applications and services in a homogenous manner with features such as hot-deployment and runtime configuration. Again, Java provides a good solution for the kernel of such a system. Java Management Extensions (JMX) is a tried and tested management technology underlying many of the most successful open source projects such as JBoss and Apache Geronimo.

Fortunately, since Web services are HTTP-based it causes no great problem to introduce Web services into a managed VLE environment. SOCKET has shown one way of doing this [6]. SOCKET would be too heavyweight a solution for a system with a very large number of services, but the next generation of SOCKET-type tools will be implemented as JBI "service engines" [14] which will provide more lightweight, more manageable processes for the incorporation of Web services into the VLE.

6, External providers

In a SOLA, there will normally be a large proportion of services that have external providers, that is, the SOLA is not in direct control of the service itself, only the client software. One reason for this is that there have been many teaching and research initiatives whose resultants have been made available to the whole educational community. Also, the universities are, as a class, less proprietorial than the business sector.

The clear problem with external services is to ensure that the SOLA management has proper access to Quality of Service (QoS) information from the external providers. For example, an external service might announce that it has to go off line for a week for essential maintenance. It mustn't happen that the first the SOLA management hears about this is through emails from disgruntled students.

Accordingly, as part of the SOLA policy system there must be a QoS protocol tailored for each individual service. This might entail human or computer monitoring of RSS feeds from each service, or it might mean regular visits to the service Website.

As part of this QoS protocol, alternative, equivalent services ought be identified, if possible, and these should be used in the event of the unavailability of the primary provider. Note that the intelligent routing facility associated with the Enterprise Service Bus (ESB) design methodology allows seamless runtime re-direction of service requests to alternative services, with the possibility of introducing data transformations that might be required to suit the alternative Web service interface.

7, More extensive federation

The WAFFLE is a Wide Area Freely Federated Learning Environment [1]. It is reasonable to suggest that SOLAs will tend to be federated more freely and over a wider area than a SOA. Shared access to libraries, image repositories, and teaching and research collaborations, both formal and informal, will make federation hugely important in the higher education sector. One might say that the WAFFLE index of a SOLA will be higher than that of most SOAs.

8, Governance

There is one statement about the success or failure of a SOA that is universally trumpeted: good governance is essential from the outset. Governance here is taken to mean ensuring compliance with institutional policy.

For example, in a SOLA comprised of a thousand services, many with dependencies on other services, and many with external providers, the primary governance requirement will be at runtime. If something goes wrong, or something is about to go wrong, a red light has got to flash somewhere and notifications have to be sent to those who are academically and technically responsible for the services involved.

Of course, this monitoring and notification system must be linked to the information in the Web services registry, and if this information is not kept up-to-date then the governance will have failed and the SOLA will not be far behind it.

Other governance procedures might relate to Web service naming and versioning conventions, software quality control methods, accessibility, security and documentation.

Might governance be the Achilles heel in the ability to sustain a SOLA? Would the system crumble into largely isolated domains because monitoring efficiency, interoperability and reusability have been frittered away due to widespread disregard for policy? One person's free spirit is another's loose cannon.

Some concluding remarks

So the vision of a SOLA presented here is one with a large number of diverse services that are micro-managed in an academic domain structure that is integrated using federated Web service registries. The means to quickly introduce and edit, new service compositions must be readily available with close working relationships between academics and developers. The WAFFLE index will be high.

It is often said in the SOA press that implementing a SOA is not an easy thing to do, changes being required at all levels in an organisation. If the observations made in this essay are accurate, then a SOLA will operate near the higher size and complexity end of the SOA spectrum. The minimum requirement for success will be good runtime governance in the form of a service-based health monitoring and notification system that is founded on the information from a well-maintained service registry.

References

[1] SOCKET and the WAFFLE Bus for Beginners, e-Learning Focus, Retrieved online 14/12/06

[2] SOCKET - Case Studies, Retrieved online 14/12/06

[3] SOCKET web site, Retrieved online 14/12/06

[4] The e-Framework briefing paper, Retrieved online 14/12/06

[5] BEA Systems - The ABC of SOA, Retrieved online 14/12/06

[6] Jess Thompson, Yefim V. Natis, Massimo Pezzini and Paolo Malinverno, Management Update: Predicts 2006: The Strategic Impact of SOA Broadens, Gartner, Inc., November 23, 2005.

[7] Standard Life's implementation of a SOA is a sound investment, Retrieved online 14/12/06

[8] Taverna Project Website, Biological Web Services, Retrieved online 14/12/06

[9] WSDL List, DDBJ, Retrieved online 14/12/06

[10] Web Services Documentation, EBI, Retrieved online 14/12/06

[11] Frank Vercoulen, Towards Service-Oriented Learning Environments, ALT-C 2005, Retrieved online 14/12/06

[12] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros, Workflow Patterns, Distributed and Parallel Databases, 14, 5 (2003)

[13] Roger L. Costello, Building Web Services the REST Way, Retrieved online 14/12/06

[14] Steve Vinoski, Java for Business Integration, Retrieved online 14/12/06

 

Supported by JISC Supported by CETIS
Powered by Plone