Skip to content.
Sections
Personal tools
You are here: Home » Features » SOCKET and the WAFFLE Bus for Beginners

SOCKET and the WAFFLE Bus for Beginners

Brian Clark and Andrew Booth
Last modified 23 Oct, 2006
Published 23 Oct, 2006
In this article Brian Clark and Andrew Booth give a non-technical introduction to the SOCKET (Service Oriented Consumer Kit for ELF tools) project which enables external resources to be plugged in to an existing VLE.

Introduction

For the last 18 months or so, in the Institute of Life Sciences Education at the University of Leeds, we have been investigating the concept of the WAFFLE Bus as one possible model for a platform that can deliver and manage the new wave of service-oriented teaching and learning tools [1],[2]. SOCKET [3], a third-round JISC ELF Toolkit project, provided some useful lessons on how the WAFFLE Bus might be developed.

The fundamental underlying technologies of the WAFFLE Bus are WSDL, SOAP, UDDI, Shibboleth/Guanxi, BPEL, JBI, WSRP, JSR168, JSR3&77 and many, many more. It would not be surprising, therefore, if a typical academic-in-the-cloister were to find difficulty in understanding the nature and benefits of the WAFFLE Bus. We were pleased, therefore, to accept an invitation to provide an introduction to SOCKET and the WAFFLE Bus that uses the minimum of technical detail. We start off with SOCKET.

SOCKET

SOCKET stands for Service-Oriented Consumer Kit for ELF Tools. In a nutshell, SOCKET makes it possible to plug in external resources to an existing, monolithic VLE. These resources can be Web applications or Web services. Figure 1 is a schematic diagram that illustrates the design.

Figure 1. The SOCKET architecture.

Figure 1. The SOCKET architecture.

The diagram shows a VLE that contains three intrinsic out-of-the-box resources: a pigeon hole; an MCQ application; and a calendar. A teacher constructing a course in this VLE would see these three resources in the Add Resource menu.

The items in red indicate the SOCKET elements. Say that there is a Wiki application that a teacher would like to integrate into an online course. This Wiki could be anywhere that is accessible using the Web i.e. something with a URL.

The SOCKET software contains a list (or registry) of external applications or services that are to be made available to the VLE along with their URLs. This is represented by the left-hand red box in the diagram: in this case there is only one item in this list, the Wiki, but there can be any number. When a teacher clicks the Add Resource button in a “socketized” VLE, then the external SOCKET resource appears on the menu and can be used in exactly the same way as any of the intrinsic resources, the pigeon hole, MCQ or calendar. Each SOCKET resource is subject to the same access control measures as the native VLE resources. In SOCKET, the VLE used was Bodington [4], but it should not prove difficult to introduce SOCKET services to any of the popular open source VLEs, regardless of programming language or platform.

Figure 2 below shows a screen capture from a socketized Bodington showing some links to SOCKET resources: a home grown chemical elements service, a Java applet connecting to an external Jabber chat server, and a client for the JISC SSRun project [5].

Figure 2.  Some SOCKET resources on a Bodington page.

Figure 2. Some SOCKET resources on a Bodington page.

If the external resource is a Web service rather than a Web application, then there is slightly more work to be done by SOCKET to create and package up a special Web application that can access the Web service. It is this client, or consumer, application that appears in the SOCKET registry.

A useful side-effect of this design using a registry of external resources is that the new resources can be “hot deployed” to the VLE. In other words, the VLE does not have to be stopped and re-started to make the new resources available. Another way of expressing this is to say that the resources are “pluggable”.

The final service that SOCKET can provide is single sign-on access to a protected external resource using Guanxi/Shibboleth technology [6], [7].

What if all resources are “pluggable”?

This is a natural question to ask after playing with the SOCKET architecture. What if there are now NO intrinsic or native applications in the “VLE”. What if all resources or tools are pluggable (and hot-deployable)? This includes things like group management and access control tools. Now a VLE can be assembled using a set of resources optimised for each user base. Old tools can be dropped and new tools can be added on demand. Now there is no need for all resources to be on the same computer or even to belong to the same university. This leads to the idea of federation: the sharing of resources between groups of institutions through single sign-on technology.

WAFFLE stands for Wide Area Freely-Federated Learning Environment in which distributed learning environments are built up by multiple federations [8]. These federations can be intra-institutional, inter-institutional, national or international (see Figure 3 for an example). Members of each federation agree to make certain resources available to specified groups of people from their federated partners and Guanxi/Shibboleth looks after the security/privacy issues that arise. The WAFFLE, then, deals with federation.

Figure 3.  Schematic diagram of an example WAFFLE

Figure 3. Schematic diagram of an example WAFFLE

Clearly, in any large WAFFLE, the number of connections could be very large and managing the integration of its pluggable resources could be a major headache. This is where the Bus comes in, or, to give it its full title, the Enterprise Service Bus (ESB) [9]. The ESB facilitates the integration of Web services (and Web applications) which might be written in different programming languages and delivered from different technological platforms. The ESB also provides a natural home for essential processes such as data transformation and the combination of Web services to produce composite services.

So, in summary,

WAFFLE = federation

and

Bus = integration.

Let’s now look at the WAFFLE Bus in a bit more detail.

The WAFFLE Bus

A remarkable feature about the WAFFLE Bus design is its flexibility. If, for example, you take away all the federation and all the distributed learning ESB elements, then you are not left with just thin air. Rather, what remains is a VLE whose composition is completely configurable and which has the ability to embrace more applications and services as and when required. We call this core structure the Service-Oriented Virtual Learning Environment (SOVLE). Because of the flexible and dynamic nature of the SOVLE, specialist technology is required to manage it (the management processes being to install, deploy, configure, control and monitor). This management unit is centred on the SOVLE kernel, the programmatic entity into which the pluggable resources are actually plugged. The kernel is interrogated by a management console from which the WAFFLE Bus can be controlled and monitored. Figure 4 provides a schematic overview of the structure of the SOVLE.

Figure 4.  Schematic diagram of SOVLE

Figure 4. Schematic diagram of SOVLE

The resources plug into the SOVLE Resource Kernel. Some representative resources are shown. The kernel will talk to a management application, which is not shown.

On top of the Resource Kernel is the Resource Group Manager. This is the tool used by an educator to create groups of resources that constitute a course of instruction. Technically, this might consist of a series of XML elements holding the names, descriptions and URLs of a set of resources, but the precise form will depend on the implementation.

Data from the Resource Group Manager is sent to the View Layer where it can be rendered according to the chosen view platform. This could be a PC, a portal or a mobile device. Note that the model used to create the resource groups is completely configurable. This could be modules and courses; or buildings, floors and rooms; or anything.

It is worthwhile mentioning here that the ESB is more a way of doing things, rather than a widget conforming to a set of standard specifications. The ESB methodology is characterized by providing a system that takes charge of Web service messages and routes them safely to their targets. This process can involve reliable messaging techniques, service location, message routing and data transformation. An ESB can be implemented using a variety of approaches. For example, it might be formed from a managed cluster of SOVLEs, each with its own ESB module which is responsible for linking up with all the other SOVLEs in the cluster and performing the ESB message-handling tasks.

Another option is to use ESB modules that are not attached to any SOVLE. These modules might take the form of a cluster of message servers, for example, with responsibilities for routing messages to their correct destinations. In this case the ESB module in a SOVLE would post its Web services to the appropriate message server in the external ESB. A schematic description of this sort of ESB is given in Figure 5.

Figure 5. SOVLE connected to message server ESB.

Figure 5. SOVLE connected to message server ESB.

In this case, each service attached to the ESB can have access to all the other services. Normally, the service registry would have the role of providing a list of available services and how they can be called. The diagram also shows a typical array of services that might be connected to the ESB, such as federated portals and service composition tools.

The WAFFLE Bus and Web 2.0

Given the popularity of the Web 2.0 phenomenon, educators might be interested to know how the architecture of the WAFFLE Bus might fit in with the Web 2.0 approach. A central notion of Web 2.0 is the “mashup” in which different applications are integrated to produce new composite applications. The Bus technology in the WAFFLE Bus provides a standards-based mechanism for integrating Web services and applications. Another strand of Web 2.0 is the devolution to the user of the choice of technology to access a particular service. Again, one of the core ESB functions is to mediate service message content to suit different client applications. It seems that the WAFFLE Bus and Web 2.0 are natural bedfellows. One interesting possibility involves Outline Processor Markup Language (OPML) [10] which is used to create lists of RSS feeds. The roles of the Resource Group Manager and View Layer could be taken over by a tool that manages OPML lists containing RSS feeds linking to WAFFLE Bus resources.

WAFFLE or waffle?

Fine architectures butter no parsnips, and the big question is “Can we build it?”

As mentioned above, useful lessons were learned during the SOCKET project. For example, the hot-deployment design pattern emerged. Also, we now have a rudimentary, standards-based Web service registry that can gradually be extended to act as the system of record for the whole Service-Oriented Learning Architecture (SOLA) that is built up around the SOVLE. Incidentally, the acronym SOLA has not been introduced lightly. Through close monitoring of the way Service-Oriented Architecture (SOA) has developed in the business sector since the millennium, it is clear that the flavour of SOA required by the higher education sector will be sufficiently different to warrant the distinction. There is a major essay in the justification of this last statement but the key differentiators lie in the large number of services that might be deployed, the extent and nature of federation, the domain structure of universities, the diversity of specialist disciplines, the style of governance, and the character of the academic staff.

The core WAFFLE Bus technology is mature. The Resource Kernel, for example, uses standard, well-established technology that lies at the heart of important applications such as JBoss [11] and Apache Geronimo [12].

The Resource Group Manager could be a simple application based on an XML text editor.

The View Layer is classic Web application fare.

All the other management tools and resources are plugged in. For example, the open source Sun Access Manager could be used for group management and access control.

To paraphrase Mr R. Builder: “Can we build it?” “Yes, we can.”

In Conclusion

The WAFFLE Bus represents a powerful option as a platform from which to deliver and manage the emerging host of JISC services. Based on mature Java and Web service technology, and using proven design principles from SOA, it can provide a complete SOVLE solution for a higher education institution, or a managed Web services gateway for existing monolithic VLEs.

References

[1] Booth and Clark (2006), The WAFFLE Bus: a model for a service-oriented learning architecture (word), in Whitelock, D. & Wheeler, S. (Eds). The next generation. Research Proceedings of the 13th Association for Learning Technology Conference (ALT-C 2006). Held 5-7 September 2006, Heriot-Watt University, Scotland, UK. PDF Update

[2] The WAFFLE Bus, Retrieved 17/10/06 (ppt)

[3] The SOCKET project, Retrieved online 17/10/06

[4] The Bodington.org web site, Retrieved online 17/10/06

[5] ASSIS SSRun, Retrieved online 17/10/06

[6] Shibboleth Project, Retrieved online 17/10/06

[7] Guanxi, Project Web Site, Retrieved online 17/10/06

[8] Mehan, S., Young, A. and Booth, A.G. (2005), Guanxi: Shibboleth in AAA Elearning, JISC Middleware Meeting, [PDF document]

[9] Chappell, D.A. (2004), Enterprise Service Bus, O’Reilly.

[10] OPML, Retrieved online 17/10/06

[11] JBoss, Retrieved online 17/10/06

[12] Apache Geronimo Project, Retrieved online 17/10/06

 

Supported by JISC Supported by CETIS
Powered by Plone