SOCKET - OVERVIEW

  1. Introduction
  2. Creating a SOCKET Resource in Bodington
  3. The SOCKET Software Modules

1. Introduction

Starting from a Web service WSDL document, SOCKET creates consumer software and makes the service available as a resource in the Bodington Virtual Learning Environment (VLE).

The steps in the socketization process are as follows.

1. A WSDL document is imported into SOCKET filespace.

2. A consumer factory produces consumer software for the Web service.

3. A view layer is created that uses XSLT to transform the Graphical User Interface Descriptor (GUID) files produced by the consumer software into XHTML documents.

4. The consumer and view software is packaged in a war file that can be deployed in a servlet container such as Apache Tomcat.

1.1 SOCKET status

On socketization of a WSDL, an entry is made in the SOCKET jUDDI registry for the service with status set to socketized indicating that the consumer software has been created.

When the software is made available to external users, in this case the Bodington VLE, its status is changed to available.

When a user decides to create a SOCKET resource in Bodington, a list of available SOCKET services is presented.

Ultimately, the runtime status of a SOCKET service will be monitored using a Java Management eXtensions (JMX) MBean.

The software modules that comprise SOCKET are listed below together with brief descriptions.

2. Creating a SOCKET Resource in Bodington

On a SOCKET enabled Bodington, the Create Resource link now leads to a list containing the Create SOCKET Link option.

Selecting this option provides a drop-down list of the SOCKET services that are available. Selecting one of these leads to a normal Bodington Create Resource page.

3. The SOCKET software modules

3.1 socket-engine

The engine consists of a simple interface that each consumer factory must implement.

It also uses the SOCKET engine client to receive instructions from the console pertaining to the production of consumer software.

3.2 socket-consumer-factory

The consumer factory is responsible for producing the Web service consumer software and packaging it in a suitable form for use in a VLE. The Rose consumer factory, for example, produces a Java WAR file containing the consumer software along with an XSLT view layer that produces HTML output from the abstract XML data produced by the SOCKET code.

The code generation is carried out using Freemarker templates.

3.3 socket-engine-client

The socket-engine-client module provides an API through which the SOCKET console (and other applications) can communicate with the engine in order to produce SOCKET consumer software.

In the 1.0 release the API requires the locations of the SOCKET engine and the Web service WSDL document. In future there will be the option of choosing which consumer factory to use and the ability to provide a destination for the consumer software.

3.4 socket-common

This module contains SOCKET classes that are common to two or more modules. The only member presently is the exception, SocketProjectException, which extends the Exception class.

A SocketProjectException is thrown, for example, when the consumer engine is unable to process the WSDL document or extract the data from the service stubs produced by the WSDL2Java software.

3.5 socket-view

The socket-view module is based on a servlet filter, ViewFilter, which carries out XSLT transformations of the XML out put from consumer software produced by the Rose consumer factory.

The following views exist:

  1. operation list
  2. service input
  3. service output
  4. exception pages

3.5.1 operation list

This is the view produced on selecting a link to a SOCKET service. It consists of a list of names and descriptions for the operations that make up the service. Each operation name is a hyperlink to the input page for that operation. The operation names are taken from the WSDL. In release 1.0 the XSLT files must be edited manually to populate the description fields.

In the next release it is planned that there will be programmatic editing of the operation name and description fields from the console.

3.5.2 service input

Each hyperlink from the operation list leads to a page containing an HTML form with input fields corresponding to each of the input parameter of the operation.

Under each input box is given the datatype expected for the parameter and there is client-side validation where possible.

Integers are checked for type and range in the case of byte (-128 to 127) and short (-32 xxx to 32,xxx).

Floats and doubles are checked for non-numerical input.

Booleans are entered by means of a pair of radio boxes.

Calendar input is effected using selection boxes for day and month and an input box for the year.

All the simple datatypes have array equivalents. The number of input elements required is user-selectable.

Any operation can have a parameter list consisting of any combination of simple datatypes and arrays. The order in which they appear follows the ordering in the WSDL document.

Descriptive labels for each input parameter in an operation can be added by manual editing of the XSLT style sheets.

It is planned that it will be possible in the next release to perform this editing from the Web console.

3.6 socket-console

The console in 1.0 provides basic functionality for managing the SOCKET applications. The WSDL Manager is used to import and inspect WSDL documents. The Service Manager is used to produce SOCKET consumer software, obtain lists of SOCKET services, and to change the status of these services.

The console also provides a hyperlink to the jUDDI console attached to the SOCKET system. This can be used for UDDI management functions that are not available from the console.

3.7 socket-deployer

The deployer uses the Apache Ant tool to deploy consumer war files to a remote Tomcat installation. The deployer requires a username and password for a Tomcat user with a manager role.

The deployer is not implemented in 1.0. Consumer war files are downloaded to the local file system from where they can be deployed manually to the location given in the socketization form. This destination can be checked by obtaining a list of services from the console Services Manager.

3.8 socket-schemas

The XML schemas used by the SOCKET project are stored here.

The schemas are as follows.

  1. service-input.xsd
  2. service-output.xsd
  3. operation-list.xsd
  4. consumer-exception.xsd
  5. soap-exception.xsd
  6. remote-exception.xsd
3.9 QMShibb

QMShibb is a set of Java servlets that enables single sign-on (SSO) from Bodington to the Questionmark Perception assessment package using the Guanxi/Shibboleth security system. QMShibb communicates with Perception through its Web service interface, QMWISe.

3.10 socket-docs

The socket-docs module contains a copy of the latest versions of all documents relating to the SOCKET project. These are listed below.

  1. Overview
  2. User Guide
  3. Developer Guide
  4. SOCKET XSLT
  5. The Console
  6. Future Directions

SOCKET, A JISC ELF Toolkit Project, February - August 2006.

b.p.clark@leeds.ac.uk, September 2006

Document last modified 23 September 2006