YaWSA: Final Project Report

8/14/2019 YaWSA: Final Project Report

http://slidepdf.com/reader/full/yawsa-final-project-report 1/133

University of St Andrews

Service Composition with

Hyper-programming SH Project Deliverable, Final Report

Angus Macdonald

4/17/2007



Angus Macdonald Service Composition with Hyper-Programming

Page | 2

Abstract

This report introduces YaWSA (Yet another Web Service Acronym) - a web-based system designed to

simplify the orchestration and testing of Web Service compositions.

The current trend in software architecture is towards building platform-independent components

made available as Web Services. In enterprise computing the composition of such services is viewed

as important in automating business processes, thus helping to streamline application integration.

Current approaches to Web Service composition require considerable knowledge of either low level

XML syntax or model based descriptions in UML. Interactive component integration and composition

testing is challenging in these frameworks, as compositions must be created statically then compiled

into a flow specification before they can be run. The general scarcity of public Web Services seems to

highlight the need for a tool that makes their invocation and composition simpler.

YaWSA provides a more accessible approach to Web Service composition, allowing users to compose

services from a web-based interface rather than using a UML or XML editor. The result and structure

of invocations can then be stored, allowing users to interactively compose and test Web Services. This

is achieved through the application hyper-programming, a paradigm for system construction, in the

creation of compositions.

This report identifies the motivations behind YaWSA and discusses its implementation.




Page | 3

Declaration

I declare that the material submitted for assessment is my work except where credit is explicitly given

to others by citation or acknowledgement.

The main text of this project report is 19,999 words long.

In submitting this project report to the University of St Andrews, I give permission for it to be made

available for use in accordance with the regulations of the University Library. I also give permission

for the title and abstract to be published and for copies of the report to be made and supplied at cost

to any bona fide library or research worker, and to be made available on the World Wide Web.

I retain the copyright in this work.

Angus Macdonald.




Page | 4

Contents

Abstract .......................................................................................................................... 2

Declaration .................................................................................................................... 3

Table of Figures ............................................................................................................ 8

Introduction ............................................................................................................... 10

Existing Approaches ................................................................................................................. 10

YaWSA ..................................................................................................................................... 10

Use Case................................................................................................................................... 11

Report Structure....................................................................................................................... 12

Context Survey ........................................................................................................... 13

Hyper-Programming ................................................................................................................ 14

Introduction ........................................................................................................................ 14

Hyper-Programming on the Internet .................................................................................... 15

Current Research ...................................................................................................................... 16

Web Service Composition .................................................................................................... 16

Interactive Composition ........................................................................................................... 17

Web Service Modeling ............................................................................................................. 17

Existing Applications ................................................................................................................ 18

Mindreef SOAPscope ........................................................................................................... 18

Yahoo! Pipes ....................................................................................................................... 18

Web Service Invocation Libraries.............................................................................................. 18

Other Technologies .................................................................................................................. 18

Apache Tomcat ................................................................................................................... 18

Java Dynamic Compiler ........................................................................................................ 19

Conclusion ................................................................................................................................ 19

Project Details ........................................................................................................... 20

Software Engineering Practices ................................................................................................ 20

Requirements Engineering .................................................................................................. 20

Development Methodology ................................................................................................. 20




Page | 5

Testing ................................................................................................................................ 21

System Overview...................................................................................................................... 21

Design Decisions ...................................................................................................................... 23

Server Language .................................................................................................................. 23

Web Service Invocation ....................................................................................................... 23

User Interface ..................................................................................................................... 24

Conclusion .......................................................................................................................... 25

Design Overview ...................................................................................................................... 25

Use Cases ................................................................................................................................. 26

Use Case A .......................................................................................................................... 26

Use Case B .......................................................................................................................... 28

Use Case C .......................................................................................................................... 31

System Walkthrough ................................................................................................................ 34

Introduction ........................................................................................................................ 34

Step 1: User Input (Enter Service Address) .......................................................................... 34

Step 2: Interpretation of Compositions ................................................................................ 35

Step 3: Serializing Data ........................................................................................................ 44

Step 4: Invocation of Compositions ...................................................................................... 47

Step 5: Web Service Responses - Results Decomposition ..................................................... 50

Step 6: Post-Invocation Storage ........................................................................................... 52

Novel Features ......................................................................................................................... 54

User Interface ..................................................................................................................... 54

Serialization of Data ............................................................................................................ 55

Testing ......................................................................................................................... 56

Unit Testing.............................................................................................................................. 56

Prototyping .............................................................................................................................. 56

Usability Testing ...................................................................................................................... 57

Functionality to Test ............................................................................................................ 57

Target Audience .................................................................................................................. 57

Questions and Results ......................................................................................................... 57




Page | 6

Conclusion .......................................................................................................................... 59

Heuristic Evaluation ................................................................................................................. 59

Efficiency Testing ..................................................................................................................... 60

System Startup .................................................................................................................... 60

Proxy Generation – Single Operation Service ....................................................................... 60

Proxy Generation – Multiple Operation Service ................................................................... 60

Conclusion .......................................................................................................................... 61

Evaluation and Critical Appraisal ........................................................................ 61

Software Engineering ............................................................................................................... 61

Development Model............................................................................................................ 61

Testing ................................................................................................................................ 62

Objectives ................................................................................................................................ 62

Primary ............................................................................................................................... 62

Secondary ........................................................................................................................... 63

Tertiary ............................................................................................................................... 63

Conclusion .......................................................................................................................... 63

Requirements ........................................................................................................................... 64

Functional Requirements..................................................................................................... 64

Non-Functional Requirements ............................................................................................. 65

Conclusion .......................................................................................................................... 67

Design Decisions ...................................................................................................................... 67

Server ................................................................................................................................. 67

Web Service Invocation ....................................................................................................... 67

User Interface ..................................................................................................................... 68

Comparison with Existing Systems ........................................................................................... 68

Web-based Invocation......................................................................................................... 68

Service Composition ............................................................................................................ 68

Conclusion .......................................................................................................................... 69

Conclusion .................................................................................................................. 70

Achievements of Project ........................................................................................................... 70




Page | 7

Future Direction of Work .......................................................................................................... 70

Persistent Storage ............................................................................................................... 70

Flexible Service Invocation................................................................................................... 71

Description of Compositions ................................................................................................ 71

Integration into Middleware ................................................................................................ 72

Separate Content from Interface ......................................................................................... 73

Visualization of Compositions .............................................................................................. 73

General Comments................................................................................................................... 73

Bibliography ............................................................................................................... 74

Appendices ................................................................................................................. 78

Appendix A: Maintenance Documentation ........................................................................... 79

Appendix B: Project Specification and Plan .......................................................................... 82

Appendix C: Literature Review and Design ........................................................................... 98

Appendix D: Status Report ................................................................................................... 121

Appendix E: Testing Summary ............................................................................................. 123




Page | 8

Table of Figures

Figure 1: Web Services programming stack . Web Services operate over a standard network layer

protocol (generally HTTP), generally being serialized in SOAP, but not limited to this. ...... ...... .. 13

Figure 2: Prototype One; Command-Line Invocation. The system consists of a single component,which communicates across the network to the Web Service being called. ................................. 21

Figure 3: Prototype Two; Server-Side Compositions. A composition component is added to the server,

allowing users to build up interactions between Web Services. The original ‘Web Service

Invocation’ component is still responsible for invoking individual services provide d by the new

component. ............................................................................................................................... 22

Figure 4: Prototype three, final System; user interface added. ........................................................... 22

Figure 5: User's Conceptual Experience. The system now provides a conceptual viewpoint that is

different from its actual operation; from a user’s viewpoint, they are interfacing directly with a

Web Service, but, in reality, their request is passing through the system. ...... ...... ...... ...... ...... ...... 23

Figure 6: Data flow through the system. Starting with the client (at A) a user’s communication with a

Web Service is handled through a Tomcat servlet (B) and a back-end server (C). Finally, the back-

end server communicates directly with the Web Service. ........................................................... 25

Figure 7: The YaWSA homepage. Users see this page when they first connect go to the website. .... ... 26

Figure 8: YaWSA Screenshot. The user is given a list of available operations..................................... 27

Figure 9: YaWSA screenshot . Having chosen the 'add' operation the user can enter values for the two

parameters................................................................................................................................. 27

Figure 10: YaWSA screenshot. The webpage returns the result of a user's invocation. ...... ...... ...... ...... 28

Figure 11: YaWSA screenshot. The screen displayed to the user once they have decided to invoke the

'divide' operation. ...................................................................................................................... 29

Figure 12: YaWSA screenshot. The page now allows the user to enter the address of the service they

wish to use in the composition. .................................................................................................. 29

Figure 13: YaWSA screenshot . The page returned once the user has chosen to use the 'add' operation.

They can now enter parameters for the add operation; the result of which will be returned to be

used as a parameter to 'divide'. ................................................................................................... 30

Figure 14: YaWSA screenshot . The system displays the result of invoking the AddWS-DivideWS

composition. ............................................................................................................................. 31

Figure 15: YaWSA screenshot . The user can tag an object with information so that it can be stored and

used at a later date. .................................................................................................................... 32

Figure 16: YaWSA screenshot . The form given when a user chooses the add operation in AddWS. .... 32

Figure 17: YaWSA screenshot . The user is given a choice of suitable objects for this parameter. They

must choose from one of these. .................................................................................................. 33




Page | 9

Figure 18: YaWSA screenshot . The user has chosen the stored object that they wish to use in the

invocation. ................................................................................................................................ 33

Figure 19: Left - State of the tree once a user has chosen to invoke the DivideWS service. ...... ...... .... 36

Figure 20: Function Wrapper. The format of the data structure used to represent references to Web

Services in composition. ............................................................................................................ 36

Figure 21: Tree structure now that the user has chosen an operation. The form (right) is the result of

traversing this tree. .................................................................................................................... 37

Figure 22: Tree structure updated to reflect the user's decision to use a Web Service Reference as a

method of input. ........................................................................................................................ 39

Figure 23: Tree structure now that the user has selected the AddWS service, and the add operation. . 40

Figure 24: UML Inheritance Diagram for Tree. Illustrates how the tree structure has been

implemented in YaWSA. ........................................................................................................... 41

Figure 25: View of the DivideWS-AddWS invocation tree as implemented in YaWSA ......................... 42

Figure 26: Flattening/Restoration of Tree Structure. A user’s input on the webpage is serialized in the

form shown, making it possible to reconstruct its original structure on the server. ...... ...... ...... ..... 45

Figure 27: Representation of a composition client-side (left) and server-side (right). This figure shows

how node IDs can be used to place values into the appropriate place on the server. The YaWSA

screenshot (left) shows the IDs of text-boxes in italicized red text. In reality these IDs are not

visible to the user. ..................................................................................................................... 46

Figure 28: Form Data sent from Client. The serialized structure of the form data sent to the server.

Each form field is stored, by including the ID of that field, and its value..................................... 46

Figure 29: Data flow through the system for an AddWS-DivideWS composition. The client submits

their composition at A, which is sent to the system at B. This is passed onto the back-end server at

C, where the composition is traversed, and the Web Service at D invoked. ...... ...... ...... ...... ...... ... 47

Figure 30: Invocation tree, with all values entered . This tree is ready to be invoked. ...... ...... ...... ...... . 48

Figure 31: State of the DivideWS-AddWS invocation tree after AddWS has been invoked................... 49

Figure 32: Object Store Structure. The object store is a map, containing key->value pairs of type-

>map, where the map contains stored objects of the given type. ................................................. 52

Figure 33: Node ID Replacement. When an existing composition (Tree B) is added to a new

composition (Tree A) the node IDs for the existing composition must be updated to reflect their

new position in the tree. ............................................................................................................. 54

Figure 34: Atomic (left) and Composite (right) Services. Composite services are externally identical to

atomic services, but encapsulate some kind of Web Service composition.................................... 71




Page | 10

Introduction

The current trend in software architecture is towards building platform-independent components

made available as Web Services. These services, defined in open protocols, are self-describing, and

aim to ease the integration of components on disparate computers.

In enterprise computing the composition of such services is viewed as important in automating

business processes, thus helping to streamline application integration. There have been considerable

efforts in industry and academia to this end, with flow specification languages such as BPEL4WS

(Andrews, et al., 2001) becoming common in service-oriented architectures. Existing research has

focused on model-based approaches to composition (Skogan, et al., 2004)(Baresi, et al., 2001) though

these are limited in their accessibility, as they require knowledge of model based descriptions in UML

and several distinct toolsets to create and invoke compositions.

Existing Approaches

The academic and commercial focus on Web Services has produced numerous systems facilitating

their invocation. Of the websites that allow services to be invoked, most offer limited functionality.

For example, Microsoft ASMX files allow invocation of operations with primitive parameters, but are

not capable of invoking services with arbitrary data types or arrays. This makes the testing and

invocation of these services difficult. To be able to thoroughly test Web Services a more advanced

tool is needed; one that can test all operations.

No toolset currently allows for web-based composition of Web Services, though sites such as Yahoo!

Pipes (Yahoo!, 2007) have shown the potential for such an approach1. Web Service composition is still

inaccessible for the average user

Existing tools are aimed at enterprise computing2, neglecting the needs of small companies and

individuals who represent a large potential market for Web Service consumption. The general scarcity

of public Web Services seems to highlight the need for a tool that makes their invocation and

composition simpler.

Tim O’Reilly argues that Yahoo Pipes is “a milestone in the history of the internet … *with+ enormous

promise in turning the web into a programmable environment for everyone” (O'Reilly, 2007). While

Pipes has made great progress in feed orchestration, it is not capable of Web Service invocation, and

consequently ill-equipped to handle the move towards a semantic web (Berners-Lee, et al., 2001).

This vision relies on a large number of publicly available Web Services, yet the current complexity in

1Yahoo Pipes allows for the web-based composition of RSS feeds, not Web Services.

2For example, Borland Together Developer supports the creation of business processes in BPEL4WS, a flow specification

language. Other toolsets offer similar approaches, generally using modelling languages such as UML to support composition.




Page | 11

using these services has meant that few are available. Accessibility must become a key concern, if

Web Services are to reach their potential.

To move significantly towards this goal, a web-based tool for service composition is needed, to give

impetus to the creation and use of open Web Services.

YaWSA

This report introduces YaWSA (Yet another Web Service Acronym) - a system designed to simplify the

orchestration and testing of Web Service compositions through a web-based interface.

YaWSA is the realization of the original project specification (Appendix B, page 82), which required

the creation of a system “ permit[ting] Web Services that have been deployed … to be invoked and

composed from a standard Web Browser ” , and more specifically “the incorporation of hyper -

programming technology permitting arbitrary objects from multiple address spaces to be passed to

the services” . This sets YaWSA apart from many contemporary systems in allowing the invocation of

services with arbitrary types, arrays, and enumerations.

YaWSA provides a more accessible approach to Web Service composition than enterprise flow

specifications, allowing users to compose services from a web-based interface rather than through a

UML or XML editor. The system also allows the result and structure of invocations to be stored, thus

providing a means for the interactive testing and construction service compositions.

There is a need for such a system because existing approaches focus on commercial flow

specifications, overlooking the need for service composition on the internet. Current approaches are

either too complex or ill equipped to be used by Web developers, as integration and composition in

existing systems is difficult.

This report shows how YaWSA attempts to rectify these deficiencies, and presents an analysis of areas

where further work is needed.

Use Case

The original project specification defined a use case which will be used throughout this report as a

motivating example. It is reprinted below:

A company provides two web services; AddWS , which adds two numbers (given as

parameters) then returns the result, and DivideWS that divides one parameter from another

then returns the result. An employee wishing to find the average of two numbers has to

invoke AddWS and DivideWS in sequence, creating an individual web services client for each

task.

The proposed system helps this employee in two ways. Firstly, to invoke these services the

user doesn’t have to create a web services client – they simply give the system a link to the

services description file. Having done this the employee can now chain the services by piping




Page | 12

the output from AddWS into DivideWS as a parameter, removing the need for the results to

be copied manually.

If this is a task that has to be performed frequently the employee can save the newly created

composite Web Service and return to use it when required.

There are three pieces of distinct functionality that this use case covers:

1. Service Invocation. How Web Services will be invoked by the system. This could be handled

by an existing Web Service library, or by creating a component to handle serialization and

derserialization into SOAP.

2. The representation of compositions on the server prior to and during invocations. The

system has to allow for an appropriate level of flexibility, while keeping the data format

manageable and accessible.

3. The method of displaying information on the webpage. Both Java Applets and HTML areoptions here. The key issue here is the difficulty in serializing and deserializing data to and

from the webpage, and the system’s method of handling this.

These issues, and the solutions to them, are discussed in the project details section on page 20.

Report Structure

This report provides an account of the problem being solved, the work done towards this goal, and an

analysis of the resultant system. It is divided into five sections.

The Project Details section presents an overview of the system, discussing the main achievements of

the project along with the main elements of the design and novel features of the implementation. A

use case is used to clarify these points and to illustrate the reasoning behind, and need for, particular

aspects of the implementation.

The Testing section details the steps taken to ensure reliability and quality within the system, and

introduces the results of usability testing, used to evaluate the system’s user interface.

YaWSA is assessed against the original system objectives and requirements (Appendix B, page 82) in

the Evaluation section. This section presents a critical analysis of the system, with respect to related

work in the public domain.

The report finishes with a Conclusion, which summarises the achievements of this project, and

reflects on significant accomplishments and remaining weaknesses. This summary is used as a basis to

discuss future directions for the project, and possible avenues of research.

Finally a set of Appendices contain previously published deliverables including the project

specification, project plan, literature review and design. Also included is a status report summarizing

the state of the delivered software and a summary of the testing strategy used during development.




Page | 13

Context Survey

This section is based on the context survey and literature review contained within the project ’s

specification and literature review (Appendices B & C, page 82). It is included here to introduce some

of the domain specific terminology used throughout this document.

Web Services

A web service is any service available over the Internet that uses a standardized XML messaging

system, is self-describing, and is not tied to any one operating system or programming language

(Cerami, 2002). Web Services differ from existing service oriented architectures by being defined

through open standards, which means that developers are not obliged to use proprietary

applications.

The Web Services architecture consists of a set of protocols, each used for a distinct purpose. Figure 1

gives examples of these protocols and the functions that they perform.

SERVICE DESCRIPTION LAYER

XML-BASED MESSAGING LAYER

NETWORK LAYER

WSDL

SOAP

HTTP, FTP, SMTP,

etc.

PUBLICATION &

DISCOVERYSERVICE FLOWBPEL4WS

Figure 1: Web Services programming stack. Web Services operate over a standard network layer protocol

(generally HTTP), generally being serialized in SOAP, but not limited to this.

The bottom three layers of this stack are required in order to have interoperable web services, with

the remaining two providing desirable but optional functionality. The following sections describe the

protocols that have become standards for the service description layer and messaging layer.

Web Service Description Language (WSDL)

WSDL (Christensen, et al., 2001) is the standard for the service description layer of the Web Services

stack, allowing descriptions of the methods provided by particular Web Services. These services are

defined by abstract method definitions, transport protocols employed for communication with the

service, and the location of the service in the form of a URL. While WSDL is in some ways limited (e.g.

it isn't able to describe transactions), it has become the de facto standard for the service description

layer, with higher layers in the stack utilizing it.

SOAP

SOAP (Box, et al., 2000) is a message layout specification that describes a model for passing queries

and responses in XML. It originally stood for Simple Object Access Protocol, but later specifications

dropped the acronym.




Page | 14

Like WSDL, SOAP remains a W3C recommendation, but is the most common protocol in use at the

messaging layer. It's only direct competitor is XML-RPC, but Representational State Transfer (REST) is

SOAPs most widely used challenger. Not a specification, but an architectural style, REST is often used

without being realized or the technology understood (Burnham, 2004). Examples of REST web

services include Google's Ad-sense network and Amazon's Affiliate network which only require a few

lines of HTML to call.

Hyper-Programming

Introduction

Hyper-programming is a paradigm for system construction, where a source program (a hyper-

program) contains both text and links to objects. Contrast this with traditional programs that are

limited to referring to purely textual data (Kirby, et al., 1992).

Hyper-programs contain denotations to data that will be resolved to the actual data prior to

execution. This resolution is made possible through three items contained within these denotations

(Kirby, 1992):

Data Item: The value to be resolved. In Web Services composition this corresponds to the

data returned by a service.

Access Path: This is a description of the position of a data item. The access path of a Web

Service is its URI.

Access Specification: Contains the access path of an item along with a description of its

expected type. The Service Description layer of the Web Services Architecture performs this

function with WSDL.

The first implementation of a hyper-programming system was created in the Napier88 persistent

programming environment (Morrison, et al., 1989), with a Java implementation created later

(Zirintsis, et al., 1994).

A major motivation for providing such a system is to allow the application programmer to compose

programs interactively, selecting items to be incorporated into their programs (Farkas, et al.,

1992)(Kirby, et al., 1992). Users should be able to navigate the value space, selecting data items for

inclusion to their source. In doing this the complexity is reduced, as access specifications have no

need to be written for data items used by the program. This enables type checking to be performed

earlier at compile-time, ensuring that all items can be accessed at run-time (the access specification

can change).

If incorporated into the web services architecture, hyper-programming could help reduce the need to

write complex process specifications, by allowing services to be composed interactively.




Page | 15

Hyper-Programming on the Internet

Hyper-Programming requires the presence of an external value space where bindings can be

constructed during program composition. While this is typically provided by a persistent store, a file

system or other mechanism such as the World Wide Web is equally valid (Morrison, et al., 1999).

A proposal for hyper-programming on the internet was first discussed by Morrison et al. in 1999, but

the technology required to extend the paradigm was inadequate at the time. There were significant

technical difficulties, including how to integrate data from external web sources in a typed

computation, and how to integrate typed data with the HTTP protocol. Since then the standardisation

of XML and the creation of Web Services standards such as WSDL have helped to alleviate these

problems, though there is no accepted solution for making the potential failure of references

tolerable. A hyper-programming implementation for the internet, HyperWeb (Fox, et al., 2004), has

been developed and attempts to solve a number of these problems through a model of web

application program safety that aims to ensure referential integrity.

Other research outwith hyper-programming has focused on adapting existing internet fault tolerance

techniques, such as load balancing and data replication (Anderson, 1996)(Aghdaie, et al.,

2001)(Aghdaie, et al., 2002), to Web Services. A client-transparent implementation of such a system

by Aghdaie & Tamir works on a three-tier architecture, where server failure is detected by a front-end

server and requests are routed to a backup server. The scheme ensures that requests being processed

at the time of a crash are completed through use of TCP’s error control protocols.

Asynchronous JavaScript + XML (AJAX)

AJAX refers to the XMLHttpRequest technology in JavaScript that allows asynchronous

communication from web-pages, outwith the normal confines of HTTP page requests.

The recent explosion in the number of AJAX web pages would not have been possible without the

AJAX and DOM libraries that have abstracted away from the intricacies of JavaScript. This section

looks at some of the most prominent libraries available , as they could form a basis for the system’s

interface.

AJAX libraries can be broadly split into three categories: those that abstract over commonly used

JavaScript functionality; those that provide functions for developing widgets and visual effects in web

pages; those that make asynchronous communication with server languages (e.g. Java) easier by

wrapping the XMLHttpRequest object.

Prototype

Packaged as a 45kb JavaScript file, Prototype (Protopage, 2005) aims to ease the development of

dynamic web pages. It provides various programming shortcuts to commonly used functions such as

XMLHttpRequest, but requires users to program higher-level visual interfaces commonly associated




Page | 16

with AJAX applications. As a result a number of other frameworks have been built on top of

Prototype, providing programmers with more support for interface design.

script.aculo.us

script.aculo.us is one of a number of toolkits using Prototype. It offers support for various effects and

controls such as drag-and-drop lists, visual effects, and AJAX interaction. At the time of writing it is

one of the most popular AJAX libraries available (Gottipati, 2006).

Current Research

Web Service Composition

Web Services Composition is the chaining of a set of appropriate web services to produce an

application. Researchers in the field see great potential in reducing overheads for enterprise

application integration, by automating the integration of components (Srivastava, et al., 2003).

Two approaches have emerged to describe the functionality of web services (beyond the provision of

WSDL), extending into descriptions of compositions - semantic annotation identifies what a service

does, while functional annotation describes how a service behaves (Srivastava, et al., 2003).

Functional Annotation (e.g. BPEL4WS)

Functional annotation is used in Web Service composition to express how a service behaves. Services

using this approach are expressed within flow specifications that define the order in which messages

are exchanged between services.

There are an excess of Web Services standards vying for standardization at present (LaMonica, 2004),

however the Business Process Execution Language for Web Services (Andrews, et al., 2001) is

currently gaining most ground amongst flow specifications. Formed from a collaboration between

IBM and Microsoft, BPEL4WS superseded both corporations’ previous attempts at a flow language;

WSFL (Laymann, 2001) and XLANG (Thatte, 2001) respectively. The result of combining features from

both specifications is a language which is very complex (Staab, et al., 2003). Despite this it is fast

becoming a standard among functional annotation languages.

Semantic Annotation (e.g. DAML-S)

Semantic Annotation languages specify pre-conditions and the effects of services, using standard

ontologies. While this technique hasn’t found the kind of commercial support that functional

annotation languages have, it has been widely discussed within the semantic web community

(Berners-Lee, et al., 2001).

Currently semantic annotation efforts have focused on describing web services using the Resource

Description Language (RDF), and using the DARPA Agent Mark-up Language [DAML] (Ankolenkar, et

al., 2001) to provide a sufficiently expressive ontology to represent the properties of web services.




Page | 17

Comparison

Semantic annotation, if fully realized, takes most of the work of composing services away from human

operators. In this sense functional annotation protocols are limited, as they can only describe how a

service will behave, leaving creating compositions as additional work. Despite this, semantic

annotation protocols are largely unproven, so remains a need for tools facilitating manual

composition.

Interactive Composition

Several efforts are underway to create a method of interactively composing semantic Web Services.

These raise a number of issues relevant to both semantic and functional compositions. Kim and Gil

(Kim, et al., 2004) found that, even for a small number of services, users would benefit from the

assistance of tools that allowed them to specify complete and correct pathways in compositions. This

underlines the importance of guiding users – first by showing available compositions, and then

preventing invalid invocations.

Wenjun et al. (2005) break web service composition into three stages: designing process, binding

activities with concrete Web Services, and assigning data flow in the process. In assigning data flow it

has to be assumed that all services in a flow use coincident message types, so that the output of one

service is of the same type as the input of another. This assumption is flawed, as it is common for two

messages to be subtly heterogeneous, despite both representing similar semantics (Wenjun, et al.,

2005). Many composition frameworks simply rule out communication between services with

heterogeneous but similar types. Others such as SEWSIP (Semantic Based Web Service Integration

Platform) include a message transforming service that converts the output from one service to be

compatible with the input of another service.

Extending this concept to allow another intermediate state would create an additional layer to Web

Service composition. This has not been covered in any existing Web Services research.

Web Service Modeling

There have been various efforts to create applications that visualize web services and compositions of

web services; most focusing on description using UML (Baresi, et al., 2001)(Johnston, 2005).

Numerous other attempts at visualizing web services are either defunct ( WSUI) or early in

development [KWSDL + Kung, WSGUI (Web061)].

The primary benefit of graphically modeling web services is that the structure of compositions can be

separated from specific composition languages (such as BPEL4WS), and converted based on user

preference.




Page | 18

Existing Applications

Mindreef SOAPscope

Of all the current web based Web Service tools, Mindreef SOAPscope (Min06) is the most complete.

Users can invoke any web service provided they can provide the corresponding WSDL file, even when

parameters are non-scalar values. The site allows users to customize HTTP headers and SOAP sent to

the service, and provides comparison and analysis tools for WSDL files.

Yahoo! Pipes

Released in February 2007, Yahoo Pipes is a realization for early interface designs for this project,

applied to RSS feeds not Web Services. Registered Yahoo users can create compositions from RSS

feeds, get requests, and user input. The site’s interface is of particular interest as it uses various drag

and drop AJAX components, and has been praised by numerous respected Web 2.0 commentators asbeing innovative (O'Reilly, 2007)(Techcrunch, 2007).

Web Service Invocation Libraries

A number of libraries are available that assist in the creation of Web Services and Web Services

Clients. This section looks at two such programs.

Apache Axis

A part of the Web Services project at the Apache Software Foundation, Axis (Apache, 2006) is an

implementation of the SOAP submission to W3C. It was originally based on IBM’s SOAP4J library but

has since been redesigned, and versions now exist for Java and C++. Axis is the most complete Java

implementation of SOAP, allowing programmers to create Web Services and client proxies for Web

Services that handle the generation and transport of SOAP messages.

.NET Framework

Microsoft provide support for sending SOAP via HTTP(S) in the .NET framework (Microsoft, 2006), and

give IDE support through Visual Studio .NET. These tools provide similar functionality to Apache Axis.

Other Technologies

This section describes a number of technologies relevant to the YaWSA implementation of the

project.

Apache Tomcat

Tomcat (Apache, 2005) is a web container that implements the Servlet and JSP specification from Sun

Microsystems. It can function as a standalone Web Server or in combination with another, such as an

Apache HTTP Server. Its suitability for integration with Java programs has made it a popular program

to the extent that it became a top-level Apache project in September 2005.




Page | 19

As the server-side section of the system will be written in Java, Tomcat provides useful functionality

for integration with a dynamic webpage.

Java Dynamic Compiler

The Java Dynamic Compiler, developed at the University of St Andrews, allows java files to be

compiled and used by a Java program at runtime (Kirby, et al., 1998) (Kirby, 2006).

Conclusion

There are a number of systems (such as SOAPscope) which fulfill the basic criteria of this project.

However none of these systems allow for the interactive composition of Web Services, or consider

the possibility of an intermediate data store, as set out in this project.

The system allows interactive composition of services. At present there is no other software in the

public domain that achieves this, as business processes are written by hand, or with less interactive

toolsets. No other system considers the temporary storage of data for use among Web Service

invocations. This is, in part, a result of the desire for automation of processes, making such a system

unattractive. However a system providing a data store gives advantages in testing – where services

are being configured and linked – and provides a useful tool where no pre-set composition will

suffice. Such a system would make the process of creating compositions considerably easier.




Page | 20

Project Details

YaWSA is an adventurous and well planned realization of the system described in project design

documents ( Appendix C , Page 98). This section presents an outline of the system, broken down into

five areas:

Software Engineering Practices (page 20). A discussion of the software development

practices used in the project.

System Overview (page 21). A brief introduction to the overall structure of the system.

Design Decisions (page 23). A summary of decisions made before work on YaWSA began.

These decisions include the choice of programming language for the server and interface.

Design Overview (page 25). An overview of the system structure, incorporating design

decisions from the previous section.

Use Cases (page 26). The section introduces three use cases that are used to showcase

YaWSA’s interface and provide an example of typical interactions with the system.

System Walkthrough (page 34). A detailed examination of the YaWSA implementation. This

section first presents an overview of the entire system, before looking at individual

components in more detail.

Novel Features (page 54). A summary of the features that distinguish YaWSA from

comparable existing systems.

Software Engineering Practices

Requirements Engineering

Robert Glass noted that “ r equirement deficiencies are the prime source of project failures” (Glass,

1998). Consequently the initial focus of work on the project was in developing adventurous but

achievable requirements. These were validated using checks for consistency, completeness and

realism, as advocated by Sommerville (2004). Once finalized, these requirements were used as the

basis of development on the system.

Development Methodology

Development models are integral to the software engineering process, in helping to guide

development, and compensate for risks. Accordingly, the choice of development model for YaWSA

was well-considered and reasoned.

The waterfall model was considered due to its close match to course deliverables, but was deemed

too inflexible, being unable to cope with a number of risks identified in the system plan (Macdonald,

2006). Ultimately Extreme Programming (Wells, 2006) was chosen, as it factors risk well, while

allowing for the prototyping necessary for end of semester deliverables. In recent years it has become




Page | 21

one of the most prominent agile development methodologies, by promoting simplicity and feedback

through test-based development.

The system plan (Appendix B, page 82) made Extreme Programming integral to the success of the

system, by proposing the creation of operational prototypes for required deliverables and internal

deadlines; and introducing plans for the regular testing process.

Testing

Extreme Programming was chosen partly as a result of its emphasis on test-driven development.

However, this alone was not sufficient for testing of the system, and so other complementary

strategies were chosen.

The Nielsen-Norman law states that “usability is quantifiable” (Endres, et al., 2003). In view of this a

set of usability tests were designed to help identify the effectiveness of the proposed interface. In

addition to this and unit testing, program profiling was planned to ensure the system met certain

speed requirements.

These points are discussed further in the testing chapter on page 55, and the model itself is evaluated

on page 61.

System Overview

Initially, the system’s design was split into three key areas to aid the prototyping effort (described in

Testing, page 56) and to focus development at crucial stages. These areas were:

1. Web Service invocation. The initial prototype allowed users to invoke arbitrary services from

a command line interface. Figure 2 (below) shows the state of system at this stage in

prototyping. The user interacts with the system’s command line interface to invoke a service:

they provide the address of the service they wish to invoke, and then the system gives them

a series of options allowing them to select an operation and enter values for its parameters.

System

Web Service

InvocationWeb Services

Command

Line Interface

User

Figure 2: Prototype One; Command-Line Invocation. The system consists of a single component,

which communicates across the network to the Web Service being called.

At this point the system consists of two components – a temporary interface (to be replaced

later), and a module capable of making calls across the network to a given Web Service.




Page | 22

2. Composition. The second prototype added the ability to compose Web Services. This

required extending the system to allow compositions to be built up before being invoked.

Figure 3 illustrates the progression from the first prototype.

System

Web Service

InvocationWeb Services

Command

Line Interface

User

Composition

Representation

Figure 3: Prototype Two; Server-Side Compositions. A composition component is added to the server,

allowing users to build up interactions between Web Services. The original ‘Web Service Invocation’

component is still responsible for invoking individual services provided by the new component.

Now, instead of a single invocation, the system can handle multiple invocations within a

composition, by allowing users to build up interactions between services. To invoke an

interaction the system traverses its representation of the composition, making a call to the

Web Service Invocation component every time a Web Service is to be called in the

composition. The result of this call can then be used for further invocations.

3. User Interface; the final prototype. Work on this component concerned the creation of a

usable interface for composition. Figure 4 shows this interface as being outside the system,

as it resides within the client’s Web Browser - unlike previous prototypes where the user

interacted with a command line interface in the system. Users now access the system

indirectly, through their Web Browser.

User

Systemresponse

Web Service

Invocation

Composition

Representation

Web Services

User Interface

Figure 4: Prototype three, final System; user interface added.

The final prototype (Figure 4) is the first to provide a suitable interface to the end user. This

introduces a novel conceptual viewpoint, around which the system is based. The user’s conceptual

experience is of a direct communication with the Web Services they are invoking (through the

interface) - though they are working through the system, which is acting as a silent intermediary.

Figure 5 illustrates this model below.




Page | 23

response

response

request

System

Web Services

Users Conceptual Model

Actual Communication

User Interface

User

Figure 5: User's Conceptual Experience. The system now provides a conceptual viewpoint that is different from

its actual operation; from a user’s viewpoint, they are interfacing directly with a Web Service, but, in reality,

their request is passing through the system.

YaWSA supports this conceptual view of the system, as it provides a useful abstraction from the

underlying intricacy of structuring compositions. Existing systems fail to do this, as they often require

transformation from a modeling language (such as UML) to a flow specification language (such as

BPEL4WS) before this specification can be used in a separate process to run a composition. This

makes composition unnecessarily difficult, as they are inaccessible to the average user.

Design Decisions

Before development began a number of critical design decisions were made. These are discussed

here, and then evaluated along with the rest of the system on page 67.

Server Language

The server (termed the ‘system’ in Figure 5) could be implemented in either Java or C#. Both

languages have support for Web Service invocation, though C#’s is better integrated into the main

language specification. However, the developer has over three years of experience in Java, and a Java

solution would be more portable (C# server programs can only be run on the Microsoft IIS server3).

As a result of the issues of portability and experience, Java was chosen to implement the back-end

server solution. This choice was critical, as all other design decisions had to be compatible with a Java

back-end solution.

Web Service Invocation

Web Services could be invoked from a Java back-end in one of two ways: via a Web Service library

(which handles serialization), or a custom-made component, tailored for this system. The latter

option would be preferable as it would give the solution a flexibility not offered by existing libraries

3Linux implementations have been created, but are not supported by Microsoft.




Page | 24

that are not aimed at dynamic invocation. However, due to the tight schedule imposed by course

deadlines it was not possible to implement a bespoke solution, so Apache Axis (Apache, 2006) – a

Web Service library – was chosen.

The decision to use Apache Axis over other Web Service invocation frameworks was made as a result

of Axis’ ability to parse WSDL and generate proxies for individual web-pages. This helped to focus

development on core requirements, rather than issues relating to message description and

serialization. It also ensured that compositions were strongly typed server-side, as invocations are

handled using Java classes.

By representing proxies and their parameters as Java objects they were intrinsically strongly typed,

ensuring the system is capable of differentiating between heterogeneous types, and can validate user

input to services. However, this comes at a cost, as use of the framework requires a series of

computationally expensive reflective operations to be performed server-side. These operations are

necessary to find the operations provided by a service, and to perform the invocation. Another

problem is the inability to obtain parameter names from the proxies, as it is not possible to access

them using reflection.

An alternative to this approach would be using lower level libraries such as WSDL4J and SOAPJ4 -

which were the initial basis of Apache Axis - or another toolset such as the Web Services Invocation

Framework (WSIF). These would have required the creation of a program to parse the contents of

WSDL files, and create code for serializing data into SOAP, meaning the typing of values would have to

be considered.

User Interface

The choice of interface was critical to the system’s effectiveness, as it is the only component visible to

the user. The system specification stated that the interface had to be accessible from a website,

limiting the range of available options. As Java was chosen as the language of the back-end, two

approaches were considered: an AJAX based HTML page, or a Java Applet.

The eventual decision to use an AJAX based front-end to the system over a more standard approach

(such as Java SWING) was not taken lightly, but it has been justified by the final systems’ utility and

accessibility.

AJAX presented a more adventurous task, as issues related to the serialization of messages to and

from the Web Browser introduced a measure of complexity to the implementation. However, AJAX

implementations are generally more accessible than Java SWING equivalents, as they require no more

than the standard JavaScript functionality of a modern browser, rather than a Java installation.

Indeed, recent statistics show that around 94% of internet users have a JavaScript enabled browser

(W3Schools, 2007), most of which would be capable of rendering the YaWSA site.




Page | 25

Given the choice of AJAX a decision was taken to use the Apache Tomcat servlet container as an

intermediary between the server and the user’s browser. Specifically the DWR servlet (an open-

source AJAX library) would be used to facilitate asynchronous communication on the system.

Conclusion

These design decisions were critical to the development of the system, as they defined the languages

which could be used during development, thus limiting the range of available tools to those offered

supported in those languages.

Design Overview

Having decided on the tools that would be used to implement the system, the design was updated

accordingly (shown in Figure 6). This diagram adds a new element, the tomcat servlet (B), and

encapsulates the invocation and composition of services behind the back-end server (C).

Having made the decision to use AJAX and a Java back-end it was initially decided that all server-side

functionality should reside within a Tomcat servlet, as this would make communication with the client

simpler. However, due to bugs in Apache Axis it became necessary to move proxy generation into a

separate Java application (C)4.

System

B

C

Tomcat Servlet

Back-end Server

Java RMI

AJAX

D

A

SOAP

Client

DivideWSdivide()

AddWSadd()

Figure 6: Data flow through the system. Starting with the client (at A) a user’s communication with a Web

Service is handled through a Tomcat servlet (B) and a back-end server (C). Finally, the back-end server

communicates directly with the Web Service.

The following sections walk through the system to illustrate the reasons behind this structure.

4When attempting to dynamically instantiate arbitrary proxy objects within a servlet environment Axis periodically fails to

recognize its current environment, causing an error in the Internationalization code. This problem proved to be deep-rooted,

and could not be fixed without altering the Axis source code, making the system less portable as a consequence.




Page | 26

Use Cases

This section introduces three use cases that are used to walk through YaWSA’s functionality. It also

helps to illustrate how users may build up and invoke compositions using the web-based interface.

To recap, a user has access to two services - AddWS and DivideWS – which allow them to add two

numbers and divide two numbers respectively. Using these services YaWSA should allow the user to:

Use Case A Use the AddWS service to find the result of adding 25 and 175

(page 26, below)

Use Case B Use AddWS and DivideWS together (in a composition) to find the average of 36 and

48 (page 28)

Use Case C Store the result and structure of the invocation above, to re-use them in another

composition (page 31).

These use cases are devised to cover the three main areas of the system’s functionality: service

invocation, service composition, and object storage respectively. This section goes through each case

to illustrate a typical interaction with the YaWSA interface.

Use Case A

A user must invoke a simple service in this use case. The AddWS service returns the result of adding

two parameters, in this case 25 and 17. This invocation takes place in eight stages:

1. User connects to the system via A, the YaWSA homepage. Through this interface they provide

the system with the address of the AddWS service, as shown below in Figure 7.

Figure 7: The YaWSA homepage. Users see this page when they first connect go to the website.

2. The user’s request is submitted via Tomcat (B), to the backend server (C ).

3. Using Apache Axis, the server (C ) generates proxy classes to access this chosen service, and

performs reflection on these to find the operations provided by the service. These are returned

5An arbitrary choice on numbers, used to illustrate the systems functionality.




Page | 27

to the user as options, allowing them to choose the operation they wish to invoke from the form

shown below (Figure 8).

Figure 8: YaWSA Screenshot. The user is given a list of available operations.

This page shows that AddWS has one operation, add , which takes two integers and returns a

double.

4. The user chooses to invoke the add operation.

5. The server (C ) receives this choice and starts building a server-side representation of the user’s

composition. Initially, this representation is used to return a webpage allowing the user to enter

values for the two parameters, as shown by Figure 9 below.

Figure 9: YaWSA screenshot. Having chosen the 'add' operation the user can enter values for the two

parameters.




Page | 28

It is important to note that each update to this page is asynchronous, so the webpage never has

to be reloaded – the only elements to be updated are those whose server-side representation

has changed.

6. Seeing the new page (Figure 9) the user enters the values 25 and 17 , and then presses the Invoke

Service button.

7. Only now, at step 7, the system communicates with the AddWS Web Service (D). This is done

through the proxy class (created in step 3) residing on the server (C ).

8. The result, 42, is then returned to the user via the proxy classes on C , and displayed on-screen as

shown by Figure 10 below.

Figure 10: YaWSA screenshot. The webpage returns the result of a user's invocation.

This page provides some other functionality – such as the ability to store the result of invocations –

that is discussed in Use Case C (page 26).

Use Case B

This use case extends its predecessor by introducing service composition. A user wants to find the

average of two numbers, 36 and 48, by adding them with AddWS and dividing the result by two with a

new service, DivideWS.

1. The user begins by entering the address of DivideWS on the YaWSA homepage (as in Figure 7),

and then deciding to use the divide operation. This action returns the following page:




Page | 29

Figure 11: YaWSA screenshot. The screen displayed to the user once they have decided to invoke the 'divide'

operation.

2. To perform this use case, the user must tell the system to pipe in the result of an addition as the

first parameter of divide. They select WS Ref from the Method of Input options shown in Figure

11 (above). This tells YaWSA that they wish to use the result of another Web Service as the

method of inputting a value for this for this parameter, and results in the following update to the

page:

Figure 12: YaWSA screenshot. The page now allows the user to enter the address of the service they wish to

use in the composition.




Page | 30

As Figure 12 shows, the user is given space to enter the address of the service that will provide

the double object (the parameter required for the divide operation).

3. The user enters the address of the AddWS service and selects the add operation (as in Figure 8).

This produces a page allowing the user to enter parameters for the add operation, and the

second parameter for the divide operation (the first being provided by the result of add ). Figure

13 shows this page (below).

Figure 13: YaWSA screenshot. The page returned once the user has chosen to use the 'add' operation.

They can now enter parameters for the add operation; the result of which will be returned to be used as

a parameter to 'divide'.

This update means that the result of invoking the AddWS service will be used as the first

parameter in the invocation of divide.

4. The user can now enter parameters for the services (36 and 48 for add , 2 for divide) and press

the Invoke Service button. The system invokes AddWS first, using the result (84) in the invocation

of DivideWS. The result is returned to the user in the following screen:




Page | 31

Figure 14: YaWSA screenshot. The system displays the result of invoking the AddWS-DivideWS composition.

The final result of the composition is displayed, but not the intermediate invocations such as the

result of invoking AddWS.

Use Case C

This use case starts where the previous two cases finished – with the system showing the result of aninvocation. YaWSA allows users to store values returned by Web Services, and the structure of

compositions used to get those values. It provides this functionality below the result of an invocation,

as shown in Figure 14 (above). The user has the option of tagging an object or composition with a

name and description, but they can bypass this step using the Quick Add function. In this case the

system automatically tags the item with relevant information.

1. This use case begins with the user attempting to store the result of the composition in Use Case

B. From the page shown in Figure 14 they begin by clicking the show button next to the Show

Value in Object Store title, which gives them the following form:




Page | 32

Figure 15: YaWSA screenshot. The user can tag an object with information so that it can be stored and used at

a later date.

The values they enter in this form are important, as they will help the user identify the stored

object at a later date.

2. The user enters a name and description of the object then presses the ‘Yes, Store Result’ button.

The system returns a message stating that the object has been successfully stored.

3. To use the stored value the user goes back to the YaWSA homepage and selects the divide

operation from DivideWS (as in Figure 7 and Figure 8 for AddWS). This produces the following

form:

Figure 16: YaWSA screenshot. The form given when a user chooses the add operation in AddWS.




Page | 33

4. To use the stored value the user must change the ‘Method of Input’ from the current setting

(User Input ) to ‘Object Ref ’ , indicating that they wish to provide a reference to a previously

stored value. Selecting this option produces the following form:

Figure 17: YaWSA screenshot. The user is given a choice of suitable objects for this parameter. They must

choose from one of these.

5. The system gives the user a list of objects (see Figure 17 above) that can be used for this

parameter. Having chosen an object the page is updated again, as shown below.

Figure 18: YaWSA screenshot. The user has chosen the stored object that they wish to use in the invocation.

6. The user is now in a position to invoke the service as in previous use cases. They enter a value

for the second parameter and press the ‘Invoke Service’ button, completing the use case.

These use cases are the basis for the structure of the next section. However, unlike this section, it

goes through a walkthrough of the system from the perspective of the system, not the user.




Page | 34

System Walkthrough

Introduction

This section describes the issues involved in the design of YaWSA by stepping through Use Cases B

and C . As before (Use Case B, page 28) a user wishes to use two services – AddWS and DivideWS – to

find the average of two numbers. From the system’s perspective there are six distinct stages in

facilitating composition from a webpage. These are:

Step 1. User Input (page 34). User enters the address of the Web Service they wish to invoke.

Step 2. Construction of Compositions (page 35). The system presents the user with available

options (such as ‘choose operation and ‘enter parameters’), allowing them to build up a

composition. While they do this the system maintains a representation of the

composition on the server.

Step 3. Serializing Data (page 44). User input for an operations parameters must be serialized

before being sent across the network from the browser to the Tomcat servlet.

Step 4. Invocation of Services (page 50). Once the server has received the user’s input it can

begin invoking services sequentially. This step deals with the ordering of invocations in a

composition, and the method of communicating with the Web Services being invoked.

Step 5. Post-Invocation Display (page 50). When a Web Service returns the result of an

invocation the system must display this to the user.

Step 6. Post-Invocation Storage (page 52). A user may want to re-use the result of a service

invocation, or the composition which produced this result. The system stores these

values, making this possible.

The following section expands on each of these steps, in the process describing the YaWSA

implementation. To the right of each heading is a diagram, showing the areas of the system involved

in the given step.

Step 1: User Input (Enter Service Address)

Use Case: User enters the address of the DivideWS service, and submits

this to the server.

The process of composing services begins on the client’s browser with the YaWSA homepage (as in

Figure 7). This page allows users to enter the address of a service they wish to invoke – the root

service in their composition. When a user submits this address into a form on the webpage, it is sent

asynchronously to the tomcat servlet and then onto the server.

On the server Apache Axis is used to generate proxy classes for the given service. These proxy classes

will later be used to invoke the service, but the user must first select the operation they wish to use.

To do this the system uses linguistic reflection on the proxy classes to get the names, requiredparameters, and return types of the service’s operations.

WS

Client Tomcat

Server




Page | 35

These details are then returned to the user via tomcat, allowing them to choose the operation they

wish to invoke. In the meantime the proxy classes are cached.

Users are assigned a globally unique identifier (GUID) that is used as a session ID, identifying them in

calls to the server. Because the system doesn’t use conventional servlet functionality (most

communication is asynchronous), it is not possible to use standard HTTP session functionality.

Instead, YaWSA implements its own session handler, mapping a user’s GUID to an Interaction object,

and storing all data related to the users current interaction in this object. This includes the current

server-side form of a user’s composition.

Step 2: Interpretation of Compositions

Use Case: The user selects the operation they wish to invoke ( divide , an

operation of DivideWS ), and is given a form allowing them to create a

composition that starts with a single call to DivideWS.

For example, a user invoking the DivideWS service might choose to get the input of one parameter

from another Web Service. The webpage updates, allowing them to enter the address of this

secondary service. It will update again when they enter this address, and when they choose the

operation they wish to invoke from the service.

Challenge: While the user is creating this composition, the structure and content of their web form is

constantly being updated to give new, more relevant, options. The server must be able to represent

users’ compositions in a way that allows it to be easily expanded, altered, and subsequently invoked.

The system maintains a representation of a user’s composition on the server, which is continually

updated to match the client-side state of the composition. This server-side representation is updated

every time the user makes a decision, by sending each choice asynchronously to the server.

The biggest challenge in creating YaWSA was in finding a method of representing compositions on the

server that was both efficient and sufficiently flexible to meet the requirements of the system. A tree

structure was chosen. When modified, this structure automatically generates HTML allowing the

user to make further updates to the composition. These updates are then reflected in the tree,

where the process begins again.

This tree structure uses the concept of hyper-programming, as each reference maintains a data item

(value returned by the service), access path (location of the service), and access specification (service

description). This gives flexibility in linking services and values in compositions.

Use Case: Our user wishes to create a composition where the result of AddWS is used as the first

parameter in DivideWS. Through this composition our user wishes to find the average of two numbers:

36 and 48. They have entered the address of the service they wish to invoke (DivideWS).

In step 1 the user began creating a composition by selecting to invoke the DivideWS service. Whenthey made this choice the service began to create a tree – the server-side representation of the user’s

WS

Client Tomcat

Server




Page | 36

composition. Initially this tree has one node, the root node, which contains a reference to DivideWS.

This signifies that DivideWS is to be invoked, and as it is on the root node, the value returned by this

service will be returned to the user. Figure 19 (below, left) shows the tree structure at this point.

While this structure is maintained on the server, the user’s webpage is updated, allowing them to

select the operation they wish to invoke. The relevant part of this webpage is shown to the right of

Figure 19 below. This HTML was generated by traversing the tree structure on the left.

INVOKE

DivideWS

Wrapper

divide

Operation to be called

Function

Wrapper

Service

Wrapper

Figure 19: Left - State of the tree once a user has chosen to invoke the DivideWS service.

Right – HTML returned to the user as a result of this traversal.

In its current state the tree contains a reference to DivideWS within a function wrapper . This wrapper

contains references to the information required to invoke a Web Service. It allows the server to

specify a Web Service6, the name of an operation in that service, and any parameters to be used in a

call to that operation (as illustrated by Figure 20).

Web ServiceOperation

Name Parameters

Figure 20: Function Wrapper. The format of the data structure used to represent references to Web Services in

composition.

However, at this stage in our use case the function wrapper has no link to any parameters, as the user

hasn’t chosen the operation they wish to invoke. During a traversal of the server-side tree the system

notes that that no operation has been selected, so it returns HTML allowing users to chose from one

of the available operations (as shown in Figure 19).

6References to Web Services are stored within service wrappers – objects that cache proxy objects. This provides

an interface that the system can use to make invocations, while ensuring that the underlying method of

invocation (Axis proxy objects) remains distinct from the rest of the system. The same service wrapper can be

used in multiple places within an invocation, as it maintains no state.




Page | 37

Use Case: The user now selects the divide operation.

Having made this choice the tree on the server is updated. It is then traversed so that the system can

generate HTML to return to the user’s webpage.

As the tree now contains the name of the operation to be invoked, child nodes representing the

parameters required to invoke the service can be added. By default these nodes allow users to

directly input values into textboxes on the webpage.

As a result of this change to the tree (seen on the left of Figure 21 below) a server-side tree traversal

returns an HTML form to the user, allowing them to enter parameters for the divide operation. This

webpage form is shown on the right of Figure 21 below.

INVOKE

DivideWS

Wrapper

divide

“divide”

Parameter(s)

DoubleDouble

Figure 21: Tree structure now that the user has chosen an operation. The form (right) is the result of traversing

this tree.

The above figure shows the relevant part of the page returned to the user - Figure 11 on page 29

shows the full page at this stage. This page is the client-side representation of the tree structure

shown in Figure 21 above. The challenge in this is keeping these representations synchronized so that

the server knows what to expect once the user presses the ‘Invoke Service’ button.

Recap: The user has chosen to invoke the divide operation in DivideWS. In doing so the system has

created a server-side representation of their composition that specifies the service being invoked and

the required parameters. This representation is being used to update the form on the client’s

webpage, which allows them to add to their composition.

The DivideWS service can now be invoked without any further updates to the tree. The user can enter

values in the provided textboxes and press the ‘Invoke Service’ button. Our user, however, wishes to

make a composition with the AddWS service. As we are now at step 2 of Use Case B (see page 28) the

user is now in a position to link AddWS to the composition.




Page | 38

To do this they must select from one of the ‘Method of Input’ buttons on the form (see Figure 21,

right). These allow the user to select how they wish to provide a value for the given parameter. The

following methods of inputting values are available:

User Input. This is the default option. It allows users to enter values for the parameter

directly into textboxes on the webpage. In our use case the user could enter two numbers in

the textboxes provided to calculate the result of dividing one from the other.

Web Service Reference. This allows users to provide a reference to another Web Service, in

effect creating a composition. The value returned by invoking this service will be used as a

parameter in the invocation of DivideWS. Our user wants to use this option, to use the result

of adding two numbers (in the AddWS service) in our composition.

Object Reference. This allows users to use a previously stored value. The user will be

presented with a list of available objects of the correct type. For more on this option, see

page 52.

Composition Reference. This allows users to add a previously stored composition to the

current composition. This is discussed on page 53.

Use Case: Our user chooses ‘Web Service Reference’ for the first parameter, as they wish to use the

result of AddWS as the first parameter of DivideWS.

The server-side tree is updated as a result of the user ’s input. The user has chosen to provide a

reference to another Web Service rather than enter the value for a parameter, so the first parameter

in the tree now points to a Web Service reference instead of the object reference that was therebefore. Figure 22 illustrates this update (left), and the resulting HTML form returned to the user

(right). The form in the user’s webpage now allows them to enter the location of the service they wish

to invoke – AddWS in our use case.




Page | 39

INVOKE

DivideWS

Wrapper

divide

“divide”

DoubleINVOKE

Figure 22: Tree structure updated to reflect the user's decision to use a Web Service Reference as a method of

input.

In this example the parameter nodes in the server-side tree (one for each parameter in the operation)

contain references to another Web Service ( AddWS) and to user input (the parameter will be entered

directly on the form) respectively, but the system is capable of more. Parameter nodes can also

contain references to stored values or compositions. The representation of each of these differs on

the server, and consequently on the client. In Use Case B the user has chosen a Web Service reference

as a method of input, meaning the user’s webpage allows them to specify the name of a service that

will return the value required for another service invocation.

The only requirement for parameter nodes is that they return the data type required for the given

parameter. So, for example, to use a Web Service result as input to the DivideWS service the selected

service must return a value of type Double.

The newly created Web Service reference is treated in the same way as any other on the tree,

including the root service. Consequently the user must go through the same options that they went

through at the outset: they provide the address of the AddWS service, then choose the add operation

when asked. The server-side tree is updated through each of these choices, and is shown below

(Figure 23) in its final state.




Page | 40

INVOKE

DivideWS

Wrapper

divide

“divide”

Double

INVOKE

“add”

AddWS

Wrapper

add

Figure 23: Tree structure now that the user has selected the AddWS service, and the add operation.

As with every previous step, the HTML returned to the user’s webpage has been generated from a

tree traversal. To complete our use case the user needs to enter the numbers 36, 48, and 2 into the

appropriate text-boxes, then press ‘invoke service’.

The ensuing process of serializing this data is discussed in Step 3: Serializing Data (page 44). To

prevent excessive refreshing of the user’s webpage the server only calls the traverse function is only

called at the level of the highest node that has been modified. For example, if a user decides to

change their method of input from entering parameters on a web form to piping the result of another

service, the system will traverse the tree only from the ParameterRef being changed.

Step 3: Serializing Data (page 44) looks at how user input is serialized and sent across the network

when they press ‘Invoke Service’, with service invocation discussed in Step 4: Invocation of

Compositions (page 47). Before this, the Java implementation of the tree structure is discussed.

Implementation

Up until now this document has looked at the server-side implementation of composition trees in an

abstract manner. The concrete implementation of this structure follows these abstract designs

closely, making full use of Java’s object-oriented capabilities. This method of representing

compositions has been named the Web Services Interactive Composition Model (WSICM).




Page | 41

The abstract class Node provides generic tree operations that apply to every node in its tree. Seven

classes extend Node, each covering a specific aspect of a composition, ranging from references to

Web Services (WebServiceRef ), to values from the object store (StoreRef ).

Figure 24 (below) shows Node and the sub-classes used to create the server-side composition tree.

Figure 24: UML Inheritance Diagram for Tree. Illustrates how the tree structure has been implemented in

YaWSA.

There are seven sub-classes to Node, each representing a different aspect of a composition. So, for

example, when the user decides to invoke the divide operation (as in Use Case B) the system creates

two ParameterRef objects – one for each parameter required to invoke the service. When they

decide that the ‘Method of Input’ for a parameter should be a Web Service reference (as in Figure 12)

the system creates an instance of the WebServiceRef class that will become the child of a

ParameterRef object in the tree. This can be seen in Figure 25 below, which shows concrete

implementation of the final composition in Use Case B. The abstract version of this tree can be seen in

Figure 23.




Page | 42

Figure 25: View of the DivideWS-AddWS invocation tree as implemented in YaWSA

Of particular note in this diagram is the representation of the Double parameter ‘2’ in the diagram.

Unlike the two ObjectRef objects of type int , Double is a complex type. As complex types may havemultiple constructors, they will have children once the user has chosen the constructor they wish to

use. In these circumstances an ObjectRef will not contain a value (this only happens for primitive

types) but will point to children that will later be used to instantiate the complex object it represents.

While Figure 25 shows some of the functionality supported by the system, it omits other areas. For

example, the system uses ArrayRef as a node in the tree when an array is a parameter to a service.

This is required as arrays are distinct from other parameters in that their size cannot be determined.

For completeness, the following classes can be used in a server-side tree:

WebServiceRef: A reference to a Web Service.

o Initially this will allow the user to select the operation they wish to invoke.

o Once an operation has been chosen, the system creates child nodes (of type

ParameterRef ) that represent parameters required for invocation.

ParameterRef: Used as the children of WebServiceRef objects – they represent the

parameters required to invoke a service. This is done to abstract away from the method of

input for that parameter. For example, a ParameterRef node may have another

WebServiceRef as its child, indicating that the result of that invocation will be used as a

parameter to the parent node.

RootNode

WebServiceRef “divide”

ParameterRef “Double” ParameterRef “Double”

WebServiceRef “add”

ServiceWrapper

Reference to

proxy class

“AddWS”

Reference to

proxy class

ServiceWrapper “DivideWS”

ObjectRef “int” 36

ObjectRef “int” 48

ObjectRef double 2

ObjectRef “Double”




Page | 43

ObjectRef: Represents any value or object that is required to invoke a Web Service. For

example, with the AddWS service, two ObjectRef objects would be required – one for each

primitive parameter. ObjectRef objects can also be used to represent parameters of other

objects; complex types that require constructors for instantiation are an example of where

this is applicable.

ArrayRef: A subtype of ObjectRef , this represents a special case. It is used for array

parameters, and differs from normal objects as the length of an array cannot be pre-

determined.

StoreRef: Represents an item held by the system within the object store.

CompositionStoreRef: A subtype of StoreRef , this is a specialized store item. This stores

compositions, not objects.

Of the remaining classes in Figure 24, Interpreter is used to access the tree, while Generator is used

by Node and its subclasses to generate HTML code to be displayed to the user.

As with Web Service references, other types of node maintain the hyper-programming approach of

the tree structure by providing methods for accessing their data item (value), location (for example, in

the object store), and specification (type) for a given reference. This allows a great amount of

flexibility in constructing compositions, as nodes can be placed in the tree in nearly any order,

irrespective of their type. For example, parameters can be references to store items, Web Services, or

user input.

Tree Traversal

To make use of these compositions efficiently the server must provide functionality to access data

within the tree with a minimum of method calls. The Node class provides a number of methods

designed with this in mind. Of particular importance are the following:

traverse(): Performs a post-order traversal of the tree, creating an HTML form from the

contents of each node. Each type of node overrides the traverse method, as they all maintain

a different structure dependant on their purpose. A node will return HTML code allowing the

user to further modify its state, and reverse their actions.

isComplete(): Used to ascertain whether the tree is in a state ready for invocation. If no

more user input is required to get the tree into a state where it can successfully invoke a

service, this will return true; otherwise false. To achieve this method performs a post-order

traversal of the tree. If all of a node’s children are complete then that node is complete; if a

node is a leaf node, the method must check whether a value has been entered (as with

object store references), or could be entered when the form is submitted (as with primitive

input).

invoke(): Performs a post-order traversal constructing objects and invoking services where

possible. A more detailed description of this method is given in step 4 (page 47).




Page | 44

To prevent excessive refreshing of the user’s webpage the server only calls the traverse function is

only called at the level of the highest node that has been modified. For example, if a user decides to

change their method of input from direct input to a Web Service reference the system will traverse

the tree only from the ParameterRef being changed.

Step 3: Serializing Data

Use Case: Once the user has created their composition, and entered the

required parameters, they invoke it by pressing the ‘Invoke Service’

button.

Challenge: The system must be capable of serializing the user’s par ameter input in such a way that it

can be sent to the backend server, reformed and placed into the invocation tree when it reaches the

server.

Data Transfer

Data is sent asynchronously between client and server using the Direct Web Remoting7

AJAX library.

This library handles this communication through its own Tomcat servlet, allowing Java objects to be

serialized and used client-side (in JavaScript).

Data Scraping

As form details on the client are submitted asynchronously it is not possible to use a standard submit

operation to obtain all form details. This problem is further compounded by the inability to determinethe form structure prior to invocation. The solution is to use a JavaScript function which iterates

recursively through HTML elements, and returns the contents of all form elements in the tree,

matched to their respective element IDs.

As AJAX forms become more prevalent on the Internet, a function of this type is likely to become

necessary for more applications, making this implementation useful outwith the YaWSA system. Of

the open source solutions currently available none of those found are recursive, meaning they are

only capable of finding top level form elements, and not those found within an underlying tag.

Serialization

Maintaining the structure of submitted form data is a requirement of serialization. If this were not

met it would not be possible to place values in the correct place on the server-side composition. To

this end YaWSA makes use of the server’s tree structure to create unique IDs for each element. This

means that, when submitted, form data, sent with the corresponding ID, can be accurately

reconstructed server-side.

7 Direct Web Remoting (DWR), version 1.1.4: http://getahead.org/dwr

WS

Client Tomcat

Server

http://getahead.org/dwr







Page | 45

Encoding the Data

Data is encoded using the following technique, ensuring it can be restored server-side. Letters in

Figure 26 represent textbox values and options in the form, with the ID being that assigned in the

elements HTML tag.

Webpage Structure

A [id=1]

B [1] C [2]

D [1] E [2]

[A, 1], [B,11], [C,12],

[D,121], [E,122]

Encoded Format

Reformed Structure

A [id=1]

B [1] C [2]

D [1] E [2]

Figure 26: Flattening/Restoration of Tree Structure. A user’s input on the webpage is serialized in the form

shown, making it possible to reconstruct its original structure on the server.

The root letter, A, represents a parameter of the Web Service. A’s children are the parameters

required to instantiate A, and so on. When the form is submitted an ID is generated for each node in

the tree based on its position. For example, C is the second child of A, meaning it is given the ID ‘12’,

where ‘1’ is the ID of A. This process continues for every element, until the entire form is encoded. It

is then sent across the network where it can be reformed by reversing the process.

Data is encoded into an array-based format. Each value in the web form is transmitted, along with the

ID given to that form element.

Use Case: A user submits a form containing the values 36, 48, and 2. These values are sent along with

their corresponding ID to the server, which uses the ID to place values in the correct place in the

composition.

Figure 27 (below) shows another screenshot from YaWSA (left), this time annotated with the ID

assigned to each textbox. This ID isn’t visible to the user, but is stored within the HTML ID tag for the

respective textbox element. To the right of this diagram is a segment of the server-side

representation of the composition. Again, this is annotated with the ID given to each individual node

in the tree.




Page | 46

INVOKE

2

Double

36 48

ID: 1ID: 0

ID: 0 ID: 1

ID: 0

Resolved ID: 01

Figure 27: Representation of a composition client-side (left) and server-side (right). This figure shows how node

IDs can be used to place values into the appropriate place on the server. The YaWSA screenshot (left) shows

the IDs of text-boxes in italicized red text. In reality these IDs are not visible to the user.

As this example demonstrates, only the node IDs are required to find the correct position for a value

on the server. For example, consider the process to find the position of the second parameter (ID =

01) in the server-side tree. The first number in the ID is 0, so the tree is traversed to the root node.

The second number is 1, so the traversal goes to the second child of the current node. As the ID is

complete, the traversal has found the related node. The value (in this case 48) can now be placed into

the tree.

In view of this, IDs and values are sent to the server together in an array-based format (shown below;

Figure 28). The array being sent contains more arrays, each with two elements. The first element is

the ID of an element, while the second is the corresponding value.

Figure 28: Form Data sent from Client. The serialized structure of the form data sent to the server. Each form

field is stored, by including the ID of that field, and its value.

ID

Value

01

48

00

36

10

2




Page | 47

This structure was chosen over other, more defined, approaches, due to its simplicity; messages sent

between client and server are serialized in JavaScript and deserialized in Java, so minimal approaches

require less serialization.

This serialization is the first of three points where data must be sent across the network, as Figure 29

illustrates. Building on previous diagrams, this shows data flow during an invocation based on the use

case.

System

B

C

Tomcat Servlet

Back-end Server

Java RMI

AJAX

D

A

SOAP

<divide>

<num1>

84

</num1>

<num2>2

</num2>

</divide>DivideWS

divide()

AddWS

add()

2

Num 1 Add:

Invoke

Divide:

31Num 1

Num 2

Client

53Num 2

Figure 29: Data flow through the system for an AddWS-DivideWS composition. The client submits their

composition at A, which is sent to the system at B. This is passed onto the back-end server at C, where the

composition is traversed, and the Web Service at D invoked.

Each of the three areas of communication is handled differently:

A to B Data is encoded (client-side) in the array based format described earlier, and then

sent asynchronously, using AJAX , to the Tomcat servlet.

B to C Tomcat does some minor error checking then passes the message, unaltered, onto

the back-end server (C). This communication is handled over Java RMI , with a well

defined interface used.

C to D Finally, during the invocation of a Web Service, the back-end server sends a SOAP-

encoded request to the Web Service, returning the response through the servlet

and back to the client at A.

Step 4: Invocation of Compositions

Use Case: The back-end system now has all the parameters required to

invoke the composition of the AddWS and DivideWS. It will now

perform the invocation.

WS

Client Tomcat

Server




Page | 48

Challenge: The tree must be invoked in sequence to ensure services have the parameters they require.

During service invocation the system must reflect on the proxy classes to instantiate them and use the

resulting objects to make a Web Service call.

Now on the server, the process of invoking compositions can be broken down into two areas: from a

coarse-grain, how services are invoked from the perspective of an encompassing composition; from a

fine-grain, how individual services are invoked across the network using Apache Axis. This section first

discusses the coarse-grain view – composition invocation.

Composition Invocation

When executing a composition, services are invoked sequentially by a post-order traversal of the

composition tree. Consider again our use case:

Use Case: A user wishes to find the average of two numbers through a composition of DivideWS and

AddWS.

This example begins with a complete invocation tree, as shown below. The user’s input is now on the

server.

INVOKE

DivideWS

Wrapper divide

“divide”

INVOKE

Method to be called

Invocation of a Service

“add”

Parameter(s)

AddWS

Wrapper add

Service in Wrapper

2

Double

36 48

Figure 30: Invocation tree, with all values entered. This tree is ready to be invoked.

The invocation process is described below. Note that all of these steps take place on the server, which

is solely responsible for interacting with the given Web Services. The result of this invocation is the

only information returned to the client, ensuring the user’s conceptual model is sustained.




Page | 49

First we perform a traversal of this tree, eventually reaching the value ‘36’. This is a primitive

value, so it remains untouched8, along with the other child node ‘48’. These are complete, as

they are leaf nodes (so incomplete children are not a concern), and the values don’t require

instantiation.

Now all of the children of the AddWS node are complete, so we can invoke the Web Service.

The value returned by this service is stored in place of the reference to AddWS9. At this stage

the tree looks like this:

INVOKE

DivideWS

Wrapper divide

“divide”

Method to be called


Parameter(s)

Service in Wrapper

2

Double

84

Double

Figure 31: State of the DivideWS-AddWS invocation tree after AddWS has been invoked.

Following this update we are now at the children of the DivideWS invocation. The Double

value ‘84’ was returned by another service, so has already been instantiated. This node is

complete.

The other parameter, containing ‘2’, requires instantiation. Double is not a primitive type, so

must be instantiated as a Java object. All child nodes of Double are present and complete, so

the object can be instantiated.

All parameters are now complete, so the DivideWS operation can be invoked. Following this

invocation the value ‘42’ is returned to the root node, signaling that invocation is complete.

8 Primitive types don’t need to be instantiated, so they are always leaf nodes in the tree. Complex objects require

instantiation through a constructor in Java, and may require more than one parameter for instantiation. As a

result complex objects in the tree have parameter child nodes in the same way as Web Service references.

9The actual implementation differs slightly from this account, as the reference to AddWS is not removed; it is

marked as complete and has the return value stored within it. This allows for later re-use of the composition, but

makes the composition’s diagrammatic representation unnecessarily complex.




Page | 50

The root node is a special sub-type of Node, which deals with providing this response to the end-user.

Before this can happen the response must be decomposed into a readable format.

Service Invocation

The system uses Apache Axis (Apache, 2006), a Web Services library for Java, to handle invocations to

Web Services. Using Axis, the system generates Java proxy classes from the WSDL file provided by the

user. These classes are used to provide the user with a list of operations to choose from (done prior to

Step 2: Interpretation of Compositions, page 35), and are required here to actually perform the

invocation. In both steps YaWSA must use linguistic reflection to establish, and make use of, the

operations provided by the proxy classes.

Web Service libraries often use heterogeneous naming conventions in the WSDL files they create;

proxy classes reflect these differences, as they use names and information provided in WSDL. The

system can deal with proxy classes in various formats, notably proxy classes:

generated from an Apache Axis Web Service, or a Microsoft .NET Web Service

generated from WSDL files of type ‘document’ or ‘rpc’

containing a single, or multiple, operation(s)

containing operations with no parameters, one parameter, or many parameters

containing operations with parameters that are:

o primitive types

o complex types

o enumerations

o arrays

While this is not an exhaustive list, it shows the system’s flexibility in handling proxy classes.

Once proxy classes have been dynamically compiled they are cached in a ServiceWrapper object. This

allows the proxies to be used multiple times within the same composition (or at a later point),

ensuring the same reflective operations are not performed more than is necessary, as they are

computationally expensive operations.

Step 5: Web Service Responses - Results Decomposition

Use Case: The composition has been invoked and the system now has a

result to return to the user.

Challenge: Returning a primitive result is relatively simple; however the system must be able to return

arrays and arbitrary complex types, knowing only that the returned value is a Java Object.

A Web Service’s response to an invocation must be returned to the user. This is a trivial task for

primitive types as the returned value can be immediately obtained, and then sent from the server via

WS

Client Tomcat

Server




Page | 51

Tomcat to the browser. However, arbitrary complex types, arrays, and enumerations are more

difficult.

Apache Axis returns Web Service responses as Java objects, meaning, for example, that an object of

type Person would be returned in a Java object, Person. Obtaining the contents of these classes is

relatively simple if the system is expecting an object of that type prior to system creation. However,

for arbitrary complex types the system cannot determine the structure of objects returned by Web

Services, meaning a generic method - capable of getting information from any object - had to be

created.

The YaWSA implementation of this method is able to print out the contents of any Java class which

extends java.lang.Object . It performs a recursive reflective decomposition of the object, returning its

contents formatted in HTML. The following pseudo-code summarises the function, named

toDescriptiveHTMLString , below.

Input: obj: object to be deconstructed

Output: HTML formatted string of object contents

Variables: arrLen: array length

objField: array of fields in this object

fieldLen: number of fields in object

toDescriptiveHTMLString(obj):

1. If obj = null

2. Return <object name, object is null > 3. If obj is array

4. for i from 0 to arrLen

5. toDescriptiveHTMLString( obj[i] )

6. If (obj is primitive or obj is string)

7. Return <object name, object value>

8. If (obj is enum)

9. Return <object name, object value>

10. Else

11. for i from 0 to fieldLen

12. objField[i] = accessible (remove security restrictions)

13. if field = null

14.

Return <field name, field is null > 15. if objField[i] is obj

16. Return <field name, field value>

17. Else

18. toDescriptiveHTMLString( objField[i] )

Essentially, the values of primitive types are outputted directly, whereas for complex types the

method recurses over all of the fields in the object. It also handles arrays and enumerations.

Using this method the system is able to serialize object data into a format that can be displayed on

the YaWSA webpage. Object data, structured in HTML tables, is generated ready to be sent to the

user interface.




Page | 52

Step 6: Post-Invocation Storage

Use Case: The system has displayed the result of the invocation to the

user. The user may now want to use this result in another invocation, or

use their composition as part of another invocation.

Challenge: The system should allow users to store the results and

structure of invocations and allow them to use these again, where the expected value is of the same

type.

When building a composition is it desirable to be able to test progress gradually, rather than waiting

till completion. This task can be made easier by allowing user’s compositions to be stored on the

server, meaning they can be tested then added to a larger composition later. Similarly, values

returned by compositions can be stored on the server, helping users to create dynamic compositions

(not specified prior to invocation), or to maintain a record of important data.

Stored items can be tagged with a name and description, making them easier to identify at a later

date; an auto-complete function is provided for users not wishing to do this manually.

Objects and compositions are stored within a map, with a key-value pairing of type->map; the type of

the object being stored, to a map of all objects of this type. Therefore, this map (as shown in Figure

32, below) stores references to other maps, differentiated by the type of object they store.

Figure 32: Object Store Structure. The object store is a map, containing key->value pairs of type->map, where

the map contains stored objects of the given type.

Figure 32 shows an object store that is initially empty, before two items are added in turn. Instead of

being added directly into the map, the first value, “forty -two”, is added to another map along with a

name and description used to identify it. Similarly the second value, 42, is added to a separate map,

as it is of type Double. The object store map contains references to these other maps, with the key

being the type of object stored.

This structure is used to permit the fastest possible retrieval of values. When a user decides to use a

stored value, the system must present a list of applicable options; items that are of the correct type

Object Store Map

String Double

Name

Desc

Val

Its YAWSA

A String

“forty-two”

12419

String Map

Name

Desc

Val

Its a double

A number

42

23465

Double Map

Object Store Map

String

Name

Desc

Val

Its YAWSA

A String

“forty-two”

12419

String Map

<empty>

Object Store Map

1: Empty Map 2: String Added 3: Double Added

WS

Client Tomcat

Server




Page | 53

for the given parameter. For example, when used with the DivideWS service, which takes two

Doubles, the system must return all stored values that can be used for the given parameter – all

values in the Double map. This is easily achieved if all items are in a single map. For example, if this

query was performed on the map in Figure 32, the Double map would be returned immediately,

without reference to individual items. If all items were stored in a single map they would have to be

individually checked before being serialized.

Conflicts

Each value is assigned a unique ID; ensuring values do not conflict when placed in the map. This

prevents items being overwritten by others that may have been given the same name or description,

but means that duplicate values could enter the system.

At present when a value is placed in the object store it is accessible to all users of the system;

however YaWSA could easily be adapted to provide privacy for individual users, as a session ID is

maintained for each person. To implement this, the current store structure would be replicated for

each user, instead of using one for the whole system.

Compositions

Compositions are stored in the same way as objects, but the return type of the composition is used

when placing them into type-specific maps.

Composition store elements must be altered prior to entry into a new tree, unlike objects that can be

entered directly. This is an issue due to the structure of Node IDs in the system. Each node’s ID is

based on that of its parent, so when stored compositions are placed into a current composition tree

the ID of nodes in the stored composition must be updated to represent that of the current

composition.

Figure 33 (next page) shows two trees: tree A, a new composition; and tree B, a composition that has

been stored previously. A user wants to replace node 01 in tree A, with the old composition, tree B.

This operation can’t be performed immediately, as the resultant tree would be invalid; the node ID for

each node would not be unique, as both tree A and tree B have nodes labeled 0, 00, and 01. To

correct this, the node IDs in tree B are updated to reflect their new position within tree A.




Page | 54

0

00 01

010 011

Tree B

0

00 01

Tree A

01 in Tree A replaced with Tree B

0

00 01

010 011

0110 0111

Figure 33: Node ID Replacement. When an existing composition (Tree B) is added to a new composition (Tree

A) the node IDs for the existing composition must be updated to reflect their new position in the tree.

This method of ID replacement is necessary as nodes have an ID allocated to them upon creation,

meaning the system doesn’t need to traverse the tree every time the ID is required. This is considered

more efficient than dynamically calculating the node ID for every use, as the number of times the ID

will change is far less than the number of times the node will be accessed.

Novel Features

As the previous section has shown, YaWSA is an ambitious realization of the original system

requirements, using a number of novel features to achieve these targets. This section summarises the

key achievements of the project, highlighting areas worthy of special merit.

User Interface

The use of AJAX in the web-based interface sets YaWSA apart from

similar contemporaries such as Microsoft’s ASMX files, providing a

more intuitive interface. Elements can be updated quickly without

reloading the entire webpage, thus providing an increased level of

continuity in compositions, and creating a more efficient interface.

AJAX represented a more adventurous choice of interface than Java SWING as it required the use of

another set of languages, and libraries used to facilitate communication between them. The result is a

more complex implementation, but one which successfully achieves the project’s requirements for

usability.

WS

Client Tomcat

Server




Page | 55

Hyper-programming Composition

Project requirements expressed the need for a flexible method of

composing services. YaWSA achieves this using a hyper-programming

tree structure that allows any part of an operation’s parameters to be

linked with the result of another service. When modified, this tree

structure automatically generates code allowing the user to make further updates to the

composition, and consequently the tree itself. In this way minimal calls are required to edit the

structure, which maintains its own state and allows for the reversal of actions.

The flexibility of the invocation tree is notable. Any parameter – whether for Web Service operations

or complex types – can be provided via direct user input, a reference to another Web Service, a

previously stored value, or a previously stored composition. Any composition resulting in a successful

invocation can be stored and used again, either as part of a larger composition or on its own.

This flexibility is possible as a result of the application of hyper-programming to service composition.

The tree structure uses the hyper-programming paradigm, as each reference maintains a data item

(value returned by the service), access path (location of the service), and access specification (service

description). This allows services to be interactively composed and represented in the tree structure.

Serialization of Data

YaWSA is the first web-based tool allowing for the composition of Web

Services, making it ground-breaking in this regard. The biggest

challenge in implementing the system was in successfully representing

compositions client-side, and in allowing users to send parameter input

from this representation. When serializing data to the server it was necessary to prevent structural

information loss, as lost data could not be restored to the invocation tree. To this end YaWSA gives

every node in the tree a unique ID.

Each node’s ID is based on that of its parent, which itself has an ID based on its parent. Using this

method the uniqueness of IDs can be guaranteed within the tree, and used in the client-side HTML to

identify individual elements. When a user invokes a service their primitive type entries and

respective ID are sent together to the server, enabling the information to be reconstructed into the

tree. This method allows compositions represented client-side to interact with their matching server-

side counterpart.

Server

Tomcat

WS

Client

WS

Client Tomcat

Server




Page | 56

Testing

Testing is a critical part of any software engineering project, and was consequently made an integral

part of development. A test-based development model – Extreme Programming - was used to enforce

this philosophy during development. This section discusses the strategy used in Unit testing, and theuse of prototypes throughout development.

Unit Testing

Unit testing is used to validate individual units of source code, and is core to the practice of extreme

programming. Unit tests were created for functionality related to the invocation of services,

particularly where interaction with proxy objects is required. These tests were critical to ensuring

reliability of a component on which the system is reliant.

A bottom-up testing strategy was chosen, as such an approach can help to highlight major flaws

before they spread to the rest of the system, and makes observing the results of test cases simpler

(Myers, et al., 2004). Extreme programming requires this approach as it extols a more radical

approach to testing - creating unit tests before coding. Unit tests were applied for a number of critical

sections of the Service Invocation code, and through other areas of the system, but were not applied

across the whole development.

A testing report detailing specific test cases can be found in Appendix D on page 123.

Prototyping

Four YaWSA prototypes were built during development. Each prototype was created to provide a new

piece of the system’s primary functionality, as shown below.

Prototype 1 Command-line invocation of Web Services. This prototype was used during the

semester one demonstration and presentation.

Prototype 2 Invocation of Web Services through a Web-based interface. This prototype

required invocation through the systems website, but did not require service

composition or an object store.

Prototype 3 Composition of Web Services through a Web-based interface.

Prototype 4 Inclusion of object store and composition store on the web-based interface.

By setting these milestones it was possible to focus development on key features, and ensure that

these were well tested and fully functional before moving on to the next prototype. This meant that,

by the end of development, the severity and incidence of errors was fairly low.

CVS was used during this process to maintain a record of progress, and allow for rollbacks in the event

of errors.




Page | 57

Usability Testing

No amount of prototyping and unit testing can determine usability. To this end the system was tested

and evaluated by a group of testers, with the aim of improving usability. The complete results of these

tests are contained within the appendix, but are analysed here.

Functionality to Test

Before carrying out usability testing it was important to establish two key areas: the system ’s target

audience, and its primary purpose. The latter refers to the functionality within the system that is

considered core to its operation. Of this functionality it was decided that the following areas should

be tested:

Invocation of a simple web service directly through user input.

The use of a previously returned value through interaction with the object store.

The composition and subsequent invocation of two services.

Target Audience

The system specification (Macdonald, 2006) stated that prior knowledge of Web Services or service

composition should not be a requirement for using the system. The target user group reflects this, in

consisting of:

Two Senior Honours Computer Scientists (with prior knowledge of Web Services)

One Senior Honours Computer Scientists

One Junior Honours Computer Scientist (with prior knowledge of Web Services)

One Second Year Medical Science Student

This group provides a cross-section of potential users: those with technical knowledge, though not

necessarily about Web Services; and others providing a non-technical viewpoint.

None of the test group were given any advice during the test, or told anything about the system prior

to using it. Questions were directed to the available on-screen documentation.

Questions and Results

Test questions were based on W3C defined Usability Testing Questions (W3C, 2003), and designed to

be relevant to the design and purpose of the system. These questions were divided into a survey

section (where participants are invited to give a mark out of ten), and another section allowing

participants to give more detailed thoughts on the system. The following table shows the average

results from the survey section (where 1 is very bad, and 10 is very good):




Page | 58

Questions Average Median Mode

It is easy to find my way around the site. 7.8 7 7

It is easy to remember where to find things. 8.2 8 8

Screens have the right amount of information. 8.6 8 8

The site is well-suited to first-time visitors. 5.4 5 5

The site is well-suited to repeat visitors. 7.8 8 8

The site has a clear purpose. 7.4 8 8

I always felt I knew what it was possible to do next. 7.2 7 7

It is clear how screen elements work 6.8 6 6

My mistakes were easy to correct 6.6 7 7

Totals Average Median Mode

Average 7.31 7.11 7.11

Median 7.40 7 7

Mode 7.8 8 8

Table 1: Average, mean, and mode results from user evaluation forms.

These results indicate that the system performs well overall - particularly in terms of site navigation

and screen content – but also highlighted areas that could be improved.

It was noted during tests that numerous users had difficulty accessing relevant help sections;

particularly those designed to provide a good introduction to the system. As a result of this apparent

deficiency the YaWSA homepage was subsequently updated to include more details of how to begin

using the system.

The second section of the form allows users to give a more detailed evaluation of the system. A cross-

section of answers to these questions is printed below, with questions being shown in bold italics.

What are your overall impressions of the Web site?

“Very good all round site; the help section needs more examples”

“1. Once you are committed you can’t go back – HCI reversibility thing, temporal locality or

something. 2. Had to go back to beginning; screwed up”

“Well organized. Enjoyed the layout. Could use some more GUI pipes.”

If you had to give the site a grade, from A to F, where A was exemplary and F was failing, what

grade would you give it, and why?




Page | 59

“B. Very good interface, yet some areas need more explanation.”

If you could make one significant change to this Web site, what change would you make?

“Visualization of recursive web service calls.”

“Working back button.”

Conclusion

The general consensus from this evaluation is that the system is usable in its current form, particularly

for users with a Computer Science background and knowledge of Web Services. However the results

also identified some problems with the interface – issues that are discussed later in the evaluation

section (page 68).

Heuristic Evaluation

The system design (Macdonald, 2007) noted the need for heuristic evaluation of the interface both

during and after development to ensure the usability of the system. This report cited the cognitive

dimensions framework (Green, et al., 1998), which can be used for both formative and summative

evaluation of interfaces.

The cognitive dimensions were used during development for guidance, particularly when creating

new interface components. Each component was analysed using these dimensions to examine its

usability, and to allow the possibility of providing ideas for improvements.

For example, when designing the invocation page it was apparent that the system was highly viscous.

The cognitive dimension of viscosity is an indicator of the ease in which actions can be completed (or

undone). An initial prototype of service composition had a high degree of repetition viscosity as

mistakes could not be undone in a single action. For example, if a user chose to enter a Web Service

composition but later decided they wanted to input data manually, they would be forced to start

again from the beginning. As a result of this analysis subsequent prototypes included the ability to

go back on decisions, thus reducing the system’s viscosity.

Another dimension, visibility , was equally important. This refers to the ability to see components

clearly, as it is important that particular aspects of functionality are visible when they are required,

and not hidden away. This proved useful when creating help documentation. Early prototypes

contained a number of use cases and FAQs in the help section, but these were not easily accessible

when invoking a service. To correct this deficiency a feature was added to allow users to view help

documentation at the bottom of the screen during invocation. This not only improves visibility, but

also juxtaposability , another cognitive dimension.

These examples highlight the need for, and benefits of, heuristic evaluation. When combined with

usability testing it formed the basis of a strong testing framework for user interfaces, and was used to

great effect in the development of YaWSA.




Page | 60

Efficiency Testing

Non-functional requirements for the system specified that “User event response time will be less than

5 seconds [5,000 ms], assuming normal load conditions on the host server”. This was set to ensure

that users understood the effect their actions had on the system. A common problem with AJAX

websites is the lack of perceptible responses to users’ actions. To tackle this in YaWSA the system

displays a loading message while the server is performing computation, and testing was carried out to

ensure that the system returned most other results in a reasonable time period. This testing is

described below.

System Startup

Profiling10

showed that starting the backend system takes around 2,121ms. This time can be broken

down into:

1,814ms initiating RMI registry

306ms registering server with registry

Startup is a one-time operation, and so doesn’t contribute to any other connections.

Proxy Generation – Single Operation Service

Proxy generation and invocation takes up a large proportion of server-side CPU time. Profiling showed

that generating proxies for a Web Service with one operation ( AddWS) took 1353ms, which can be

broken down into:

954ms (70.5%) compiling proxy classes (using Dynamic Compiler)

326ms (24.1%) generating proxy files (using Apache Axis)

43,296µs (3.2%) loading proxy files

29,762µs (2.2%) remaining computation

This shows that the system response is well under the required 5000ms. Other than the unavoidable

cost of creating and compiling proxy classes, the system manages users’ sessions and the serialization

of HTML efficiently.

Proxy Generation – Multiple Operation Service

Proxy generation for a service with five operations (including complex types as parameters) takes

longer, with profiling showing the process taking 2205ms. Notably, this time has a different

breakdown from that of the single operation service:

1,149ms (52.1%) generating proxy files (using Apache Axis)

873ms (39.6%) compiling proxy classes (using Dynamic Compiler)

10

All profiling was done using JProfiler (http://www.ej-technologies.com/products/jprofiler/overview.html), running on a

computer with: Windows Vista Business, 2GHz Intel M Processor, 2Gb RAM, 128Mb ATi Mobility Radeon X600.




Page | 61

148ms (6.7%) loading proxy files

35,280µs (1.6%) remaining computation

Note: these results are anomalous in showing that dynamic compilation was faster for larger proxies.

This is likely a result of the program being given a higher priority by the operating system than earlier

profiling. Despite this, this profiling data is relevant for comparison within the data set.

The results show that proxy generation is now the most intensive operation, surpassing dynamic

compilation. While the basic cost of dynamically compiling proxies is large, it is quickly surpassed by

the cost of proxy generation for more complex services.

Conclusion

This testing helps to demonstrate two points. First, the system responds to user input in less than

5000ms in all tested cases. Second, the generation and manipulation of Axis proxies is the dominant

cost in CPU time on the server. The latter point identifies the major bottleneck in the system as

Apache Axis, and provides a basis for analysis of design decisions on page 67.

Evaluation and Critical Appraisal

This section provides a critical evaluation of the work carried out on this project in the design and

creation of the YaWSA system. Original system objectives and requirements are analysed and

compared against the final implementation, to establish fitness for purpose.

Software Engineering

Development Model

The initial System Plan (Macdonald, 2006) identified the use of recognised software engineering

practices as being critical to the success of the project. The plan specified that YaWSA should be built

using the Extreme Programming development model, making use of unit testing and prototyping. The

use of this model during development can be considered a success, but for a few exceptions.

As stated in the testing section (see page 56) Extreme Programming was used effectively in the

design and creation of system prototypes. These prototypes were designed to meet specific aspects

of system functionality, and focused development on key areas during production.

Unit testing was also used effectively during development of the initial prototype, with tests being

created alongside production code. The result of this effort is an invocation system which has been

tested under numerous circumstances and has been proven to perform well, handling expected

errors gracefully. However, the rest of development made little use of unit tests until after the code

had been written; failing to adhere to a number of the core values of Extreme Programming. While

unit tests were eventually created the majority of tests were carried out informally, making regression

testing difficult. This arose as a result of challenges in creating tests for components returning data




Page | 62

and information to the user interface. These components constitute a large part of the system, and

could only be tested by running constant tests on the interface rather than through programmatic

test suites.

Some criticisms are inherent in Extreme Programming itself, with numerous commentators arguing

that it cannot be successfully applied unless all practices are adopted, as they are interdependent

(Stephens, et al., 2003). This was a potential issue in this project, as it was not possible to use a

number of Extreme Programming values such as pair-programming due to this being an individual

project.

It is clear that use of Extreme Programming came at a cost; however it also provided a good model on

which to base development. Development successfully focused on consecutive prototypes enabling a

gradual build-up of well-tested functionality, and the initial use of unit testing helped with these

goals. While this success was partially tempered by later problems, the use of Extreme Programming

was important in the achievement of project objectives and requirements. Other more rigid

approaches such as the Waterfall model would have struggled to meet the demands of a short and

dynamic development schedule. Similar agile contemporaries such as the spiral model may have met

with some of these pressures, but would not have contributed to such a successful project.

Testing

Testing was prioritised during development through use of Extreme Programming, though other steps

were taken to ensure quality within the system. Of these, usability testing was particularly successful

in identifying problems and areas where improvements could be made. This feedback resulted in a

few bug fixes and numerous additional features to aid usability within YaWSA, consequently

increasing the quality of the final system.

Usability testing combined with the unit testing and prototyping of extreme programming produced a

solid development cycle that allowed development to prosper. The next section evaluates the degree

to which this is true by comparing YaWSA against original project objectives.

Objectives

This section reviews the objectives provided in the Project Specification (Macdonald, 2006), and

assesses whether the system achieved them. Objectives are shown in bold italics.

Primary

“Provide access to HTTP invocable services by allowing invocation through an interface to the

service provision domain.”

Achieved. Both the initial command line prototype and the final system (web-based) allow invocation

of services.




Page | 63

“ Invocation should be possible for scalar types (e.g. integers), and arbitrary data types defined in

the service description (WSDL file).”

Achieved. All versions of the system, from the command-line prototype onwards, allow the

invocation of service operations with primitive types, complex types, enumerations and arrays.

Secondary

“The interface should provide flexibility of input, potentially extending to further textual

representations, URLs, and XML representations.”

Achieved. The final system allows users to choose from the following types of input: textual, service

reference, object reference and composition reference. However the system does not allow for the

direct input of SOAP, or other XML representations.

“It should be possible, through the interface, to ‘chain’ web services. This involves passing the result

of one web service as a parameter to another.”

Achieved. The final system allows users to chain services through the web-based interface.

“The system should incorporate hyper -programming technology enabling services to be composed

out of existing services.”

Achieved. The results of invocations can be stored in the system ’s object store to be linked into later

compositions. This design is based on the hyper programming paradigm.

Tertiary

“ Users should be able to describe their compositions, allowing them to be saved and run again at a

later date.”

Achieved. Compositions can be stored within the system’s store to be used again at a later date.

These compositions (the flow between various Web Service operations) can then be re-used within

the system at a later date.

“ The system should be able to cope with the failure of services by providing meaningful, relevant

messages to the end user .”

Achieved. As a result of the separation between Tomcat and the back-end server, the system is able

to return an error message in the event of a back-end server failure. Context-dependant messages are

also returned for invalid input, session expiry, and missing pages (a customised 404 error page).

Conclusion

All project objectives have been achieved in full, despite the ambitious nature of the work. This is a

reflection on the success of the software engineering model used, and the effectiveness of the work

carried out, and not on the scope of the original objectives.




Page | 64

Requirements

This section reviews the functional and non-functional requirements created in the specification of

the system (Macdonald, 2006), and assesses the system’s conformance to them. Original

requirements are shown in bold italics.

Functional Requirements

Web Service Interpretation

“ The system will be able to parse Web Service Description (Version 1.1) files, to extract the

information specified within each file. This information should be sufficient to create proxy classes

for the web service being described.”

Achieved. The system uses Apache Axis (version 1.4) to parse WSDL files and to create proxy classes.


“ The user will be able to invoke web services through a webpage, provided that a description file

has been correctly interpreted ”

Achieved. The final system allows users to invoke services through a web-based interface.

“ The system shall allow users to invoke service with custom defined data types. ”

Achieved. From the initial prototype (command line interface) onwards the system allows users to

invoke services with: primitive types, custom types, enumerations, and arrays. This represents the

complete set of types that can be defined through a Web Service.


“ The user will be able to compose linear sequences of web service interactions through a webpage. ”

Achieved. Users are able to compose services in a linear sequence, and the system goes beyond this,

allowing any number of services to be chained for any of the required parameters.

“ Having specified a series of interactions the user will be able to invoke the specified composition. ”

Achieved. Users are able to invoke the compositions that they have created, displaying the result of

the invocation through the web-based interface.

“ It should be possible to store the results of Web Service invocations on the system, for use at a

later date.”

Achieved. The system maintains an object store, allowing users to store the results of invocations for

later use. These objects can be used at a later date, provided they match the type of parameter

expected.




Page | 65

Non-Functional Requirements

Efficiency

“ User event response time will be less than 5 seconds, assuming normal load conditions on the host

server.“

Achieved. The system provides feedback of a load action in less than 100ms (under normal load

conditions) in the form of a loading bar at the top right of the screen. Users receive feedback in

similar time for most other actions, with the exception of finding a new service. In this instance the

system takes around 4.5s to create and compile a services proxy files. To improve efficiency in this

regard the system caches proxy files for services, reducing loading time for finding a service to around

one second.

Scalability

“ The system should be able to support more than one person using the system at a given point in

time.”

Achieved. Users are each given a session ID allowing the system to differentiate between

compositions. As the system is implemented using an AJAX toolkit it was not possible to use built-in

servlet session functionality. Instead, the system implements its own session system, generating a 64

digit hexadecimal number for each user, and sending this in every communication with the server.

Usability

“ A user new to the system will be able to invoke a web service with reference to the immediate

onscreen documentation provided.”

Achieved. The system provides a number of help pages containing frequently asked questions and

three use cases. In addition, users can opt to receive on-screen help during invocations, which is

designed to be relevant to their current position.

The success of this requirement is measured on the results of user tests carried out on the final

system. The results of these tests are provided in the testing section (page 57), and were generally

very positive with regard to usability.

“ A user new to the system will be able to use the remaining functionality of the system with the

documentation provided.”

Achieved. As with the previous requirement the success of this requirement is measured on the

results of user tests carried out on the final system. The results of these tests are provided in the

testing section (page 57), and were generally very positive with regard to usability.

The system provides a set of frequently asked questions and three use cases in order to achieve this

requirement.




Page | 66

Documentation

“ Users should be provided with documentation on the webpage including, but not limited to:

Description of how to invoke services and use case supporting this.

Description of how to chain services and use case supporting this.”

Achieved. The system provides three use cases. The first covers the requirement of invoking services,

with the last two discussing chaining services from two different perspectives. Together they cover

the functionality provided by the system.

“Documentation should assume nothing about the users’ knowledge of Web Services”

Achieved. The system provides a help page that makes no assumptions about previous knowledge of

Web Services. This page is written with minimal reference to technical terminology, in an attempt to

make the concepts easier to understand.

Standards

“ The system should be able to invoke all web services provided they:

Are described by a WSDL V1.1 compatible file

Send and receive messages in valid SOAP V1.1

Are publicly available, thus accessible from the systems server.”

Achieved. The system is able to invoke services that conform to these standards.

Portability

“ Users should be able to view the webpage and use its full functionality on Firefox (version 2.0) and

Internet Explorer (versi on 7), with JavaScript enabled.”

Achieved. All functionality within the system has been tested on Firefox (version 2.0) and Internet

Explorer (version 7) and has been found to be fully functional.

Organization

“ The webpage will be written in HTML and JavaScript.”

Achieved. This system is compliant with this requirement. Web-pages are XHTML 1.1 compliant,

where possible; however it is not possible to validate this due to the dynamic nature of the form

content.

“ The backend to the system will be written in Java 1.5, and may make use of third-party libraries

and applications (such as Apache Tomcat).”

Achieved. The back-end system is written in Java 1.5, using a number of third-party libraries. These

are: Apache Tomcat 5.5, Apache Axis 1.4, Direct Web Remoting (Tomcat AJAX Tool), and Java UUID

Generator (JUG).




Page | 67

Delivery

“ The final solution must be handed in on the 27 th

March 2007.”

Outdated. Due to changes in the final hand-in date for the system it is no longer necessary to adhere

to this date. The system will be handed in on time, on the new hand-in date of 17th

April 2007.

Conclusion

Functional requirements were well scoped and helped focus development on key areas during

development. Similarly, non-functional requirements set standards of quality that the system was

built to meet.

As with the project objectives, all requirements have been achieved (excluding changes to the final

delivery date). In addition, no changes had to be made to requirements (or objectives) at any point

during the project, indicating the success of these plans.

Design Decisions

The design decisions made before development had a major influence in the direction and

achievements of YaWSA. This section evaluates these decisions.

Server

The decision to use Java as a backend language was an easy one, due to the available technologies

and the developer’s experience in the language. This has been justified by the success of the project

in achieving all objectives and requirements.


The use of Apache Axis over other available toolkits allowed a successful implementation, but limited

the system in a number of ways. It was recognized at the time that there were limitations with what

could be done using Axis generated proxies, including the inability to display parameter names for

invocations. Despite this limitation Axis was the best choice available, as other solutions could not

have been implemented within the project’s stringent timeframe.

If more time was given to implement a solution, an alternative library such as the Web Service

Invocation Framework (Duftler, et al., 2001) may have been used. This would have benefited the

project by allowing parameter names to be displayed on the web-based form, providing more

information to the user as to the purpose of the service. It would have also provided a more efficient

solution as profiling (page 60) showed that proxy generation and compilation were by far the most

CPU intensive operations.

However this approach would have taken more time to implement and would have weakened the

typing of compositions, as SOAP would have to be manually created and stored. Consequently, while




Page | 68

no option was of outright benefit, Axis was the best choice available, given the constraints placed on

the project.

User Interface

AJAX was chosen over a Java Applet based implementation due to the former ’s availability in modern

browsers and its effectiveness in creating efficient, dynamic interfaces. This decision has been

justified by the fluidity of the YaWSA interface, which minimizes the number of required page loads,

whilst presenting an attractive interface for composition.

Comparison with Existing Systems

YaWSA can be compared against two distinct types of system: online systems allowing Web Services

to be invoked, and approaches to service composition. These are distinct as no other system available

today allows for the web-based composition of Web Services.

Web-based Invocation

The most common approach to Web Service invocation is through Microsoft’s ASMX files. An

individual ASMX file is generated for each .NET Web Service, allowing a user to invoke any of the

operations on this service. This approach is severely limited as the system does not allow operations

with arbitrary complex types (as parameters) to be invoked. YaWSA corrects this shortcoming by

allowing all services to be invoked irrespective of the type of parameter required.

Various commercial offerings support this functionality, the best being Mindreef SOAPscope (Min06).This site presents an extremely flexible solution to Web Service invocation, allowing data to be edited

at different levels. Users can edit the HTTP headers and SOAP messages of requests before invoking a

service, or choose to input data in a form (as in the YaWSA solution). This results in a very flexible

implementation, useful for developers wishing to test their services. Additionally, descriptive text

included in the service description is provided on the webpage, unlike the YaWSA solution. As

discussed previously, YaWSA’s weakness in this area is born from the decision to use Apache Axis to

handle service description and invocation.

YaWSA compares well to similar commercial offerings by supporting the invocation of services with

arbitrary complex types. Despite this, it is understandably limited in comparison with commercial

offerings such as SOAPscope, as it lacks the flexibility to edit requests at a fine grain level. It is

however also important to recognize that this flexibility was not the focus of development on YaWSA,

and the real focus – service composition – cannot be performed in SOAPscope.

Service Composition

There are no other web-based composition tools, making YaWSA unique in this respect.

Most approaches to service composition involve modeling flow in UML, with this being converted intoa flow specification (such as BPEL4WS) by an interpreter. Systems such as SEWSIP (Wenjun, et al.,




Page | 69

2005) offer more functionality than YaWSA, though they only provide the ability to view compositions

at a fine grain. YaWSA provides a more accessible approach to Web Service composition, allowing

users to compose services from a web-based interface. At present YaWSA is limited by its inability to

describe compositions outwith the system, meaning it can’t be used in the creation of business

processes, as SEWSIP and other contemporaries are able to.

YaWSA’s interface is limited in comparison to commercial sites such as Yahoo! Pipes. The latter site

presents a more intuitive approach to composition, conforming more effectively to users’ conceptual

model of composition.

Conclusion

The aforementioned applications are some of the most advanced commercial and academic

applications available today. It is understandable that, given the sophisticated nature of these

applications, YaWSA is limited in some areas; however it compares well against basic invocation

systems, and offers a clean interface for composition, proving that web-based composition is viable

and providing a framework for further research.




Page | 70

Conclusion

Achievements of Project

The project specification required the creation of a system “ permit[ting] Web Services that have been

deployed, … to be invoked and composed from a standard Web Browser” . The project has been

enormously successful in this regard, creating the first online Web Service composition tool, and

opening new avenues of research. All of the original project objectives and requirements have been

achieved, despite their ambitious scope and bold design decisions, such as the use of AJAX. This

success is a result of careful planning and the use of tried and tested software development practices

throughout development.

The system uses a novel approach to composition in the WSICM implementation. This tree structure

based, on hyper-programming, offers a high level of flexibility and a clear composition model. It also

facilitates interaction with users through tree traversal (that generates HTML), meaning compositions

can be easily modified from a web-based interface. This user interaction is extremely fluid as

asynchronous requests through AJAX reduce the need to reload web-pages, allowing users to build up

compositions gradually on a single page, rather than through stunted page reloads. This approach is

incomparable, as no other web-based solutions to service composition exist.

The project identified areas worthy of further research, ranging from augmentations to adaptive

middleware to a fully fledged composition website. These areas are discussed later in this section, and

show the potential scope of the project. Given this scope it is worth noting that all of the original

objectives were met, and no changes were made to these during development. This serves to

highlight the quality of the set objectives.

Finally, it is planned that this project will form the basis of an academic paper on interactive service

composition. This underlines the quality and scale of the work undertaken on YaWSA.

Future Direction of Work

This project has provided scope for new areas of research. This section summarises potential

improvements to YaWSA and the future direction of research in this area.

Persistent Storage

The current system store exhibits notional persistence, in that it allows users to save data on the

server for later re-use, but this data is only stored for the lifetime of the back-end server. This means

that users wanting to use the system for an extended period of time will lose data.

To resolve this, objects could be serialized and placed in a MySQL database, or stored using

Hibernate11

.

11 http://www.hibernate.org/ : Relational Persistence in Java

http://www.hibernate.org/







Page | 71

Flexible Service Invocation

YaWSA is, as discussed on page 68, more limited than some commercial websites as users cannot edit

requests at a fine grain level. In this respect YaWSA could be expanded to allow users to edit HTTP

headers and SOAP envelopes prior to service invocation. This would make the tool more attractive for

testers of Web Services, allowing them to tailor requests to their desired format. It would also make

the process of invocation more transparent to the user, allowing them to better understand the

internal invocation process, if necessary.

Description of Compositions

The system allows users to create and use compositions from within the system, but it is not possible

to use these outwith YaWSA’s sandbox environment. The system could be expanded in one of two

ways: to allow for incremental composition of services, or to describe compositions in an existing flow

specification such as BPEL4WS.

Incremental Composition

Incremental approaches to service composition build up interactions through encapsulation (Granell,

et al., 2004), in contrast to process-based flow specifications. With incremental composition, Web

Services can be viewed as being either atomic or compound entities, with both being conceptually

identical. A number of services can be linked together to become a compound service, described by

WSDL in the same way as an atomic service. In this way complex compositions can be built up with

the ability to view the interaction at a coarse-grain level. Moreover, this enables composite

component re-use as they can now be used as any atomic service would.

Figure 34 shows an atomic service (A), and a composite service (BC). Both are described by WSDL,

making them externally equivalent, but BC is made up of two existing services (B and C).

BC

C

B

WSDL

AWSDL

Figure 34: Atomic (left) and Composite (right) Services. Composite services are externally identical to atomic

services, but encapsulate some kind of Web Service composition.

Existing approaches, such as BPEL4WS, force the developer to work at a fine-grain level, producing

sprawling descriptions when working on intricate systems. Incremental composition allows these

interactions to be hidden behind a WSDL interface. While some research has gone into this area

(Granell, et al., 2003) (Granell, et al., 2004), a number of questions remain.




Page | 72

YaWSA could become an effective tool for incremental composition of services, provided it was

capable of encapsulating compositions behind a single WSDL file. For example, if the use case

identified in this document was to be adapted into a composite service (allowing a user to find the

average of two numbers) it could then be used in further compositions under a single interface).

As well as providing a useful tool, such a service could provide answers to a number of open

questions. For example, despite composite services being externally equivalent to atomic services, the

actual internal process may be distributed across a wide network. Moreover, there may be multiple

internal processes within a composition. An expanded system could help find the best method of

determining the location and synchronisation of these processes, and the amount of flexibility a user

should be given in these choices.

Additionally, the encapsulation provided by incremental composition creates new possibilities for

data linkage. Existing composition languages allow values to be hard-coded into a process, but it is not

possible to link to data outside the definition. Another approach would allow a service to point to a

value in a pre-determined data store outwith the encapsulation of the composite service. This link

could itself be hidden behind a composite service interface. Such a system would improve the

separation of data and process, without increasing the complexity of a composition. Furthermore,

such a system provides flexibility in allowing compositions to be viewed at either a fine or coarse

grain. It is currently unclear whether such an approach offers benefits over existing systems, and the

extent to which it could be adopted in a Web Services framework. These are areas worthy of further

research.

This proposal is the basis of pending applications for funding to the Carnegie Trust and the

Engineering and Physical Sciences Research Council.

Flow Specification

YaWSA could be adapted to create flow specifications, used to describe compositions outwith the

system in a standard flow specification protocol such as BPEL4WS. This would move YaWSA beyond

its current role as a sandbox testing tool, and into the realm of existing Web Service composition

tools, allowing its compositions to be enacted in real business environments.

Integration into Middleware

YaWSA could also be integrated into an existing middleware system, giving another dimension to

service integration.

Current third generation middleware systems attempt to abstract over the complexity inherent in

distributed application creation and the configuration of the underlying infrastructure (Walker, 2005).

If YaWSA were to be integrated with such a system, it would allow for flexible composition of services

across the network. This could occur either programmatically (another possible extension to YaWSA)

or through the existing web-based interface. Allowing service composition at the middleware layer is




Page | 73

beneficial to the composition system (YaWSA) as it allows more flexibility in being able to assign

disparate transmission policies to heterogeneous systems. It is also beneficial to the middleware,

allowing programmers to abstract away from issues relating to service-oriented compositions.

Such a proposal could be implemented into the RAFDA Run Time (Walker, 2005), a Web Service based

middleware system, with the following modifications:

The RAFDA Run Time would need to be adapted to allow it to function as a client to Web

Services outwith its control.

YaWSA would have to be moved away from the current Tomcat server implementation. The

most succinct method of doing this would involve switching from the current Tomcat-based

AJAX framework to a Web Service based framework. This would mean Web Services were

used for all cross-address space calls made by the system, potentially enabling the

composition of YaWSA operations themselves.

These additions potentially open up new avenues of research in middleware technologies, and may

be worthy of further research.

Separate Content from Interface

The current method of providing help documentation, and other on-screen content, is slightly flawed,

as content is not separated from its’ on-screen format. Storing help documentation and other

changeable assets in a standard format such as XML would provide an adequate separation, and

make maintenance of the system an easier task.

Visualization of Compositions

The release of Yahoo Pipes (pipes.yahoo.com) during development proved the potential for a web-

based composition system (albeit for RSS feeds). YaWSA could be extended to allow for the kind of

graphical composition supported by Yahoo Pipes, making the conceptual model of composition much

cleaner than with the current stacked interface. Such an implementation would require some

structural changes to be made to the server-side program, but would be entirely feasible given more

development time.

General Comments

Work on the project can be considered a real success given the achievement in full of requirements

and objectives. These were well scoped as the above section shows how much more work could have

been undertaken in this area. It is hoped that this will be explored through postgraduate research.




Page | 74

Bibliography

[Online] // Mindreef SOAPscope. - Mindreef. - October 28, 2006. - http://www.mindreef.net.

[Online] // script.aculo.us. - 2005. - October 26, 2006. - http://script.aculo.us/.

Aghdaie N. and Tamir Y. Client-Transparent Fault-Tolerant Web Services [Conference] // Proceedings

of the 20th IEEE International Performance, Computing, and Communications Conference. - Phoenix,

AZ : [s.n.], 2001.

Aghdaie N. and Tamir Y. Implementation and Evaluation of Transparent Fault-Tolerant Web Service

with Kernel-Level Support [Conference] // Proceeding of the IEEE International Conference on

Computer Communications and Networks. - Miami, FL : [s.n.], 2002.

Anderson E. The Magicrouter, an Application of Fast Packet Interposing [Online]. - 1996. - October 28,

2006. - http://www.cs.berkeley.edu/~eanders/projects/magicrouter/.

Andrews T [et al.] Business Process Execution Language for Web Services (BPEL4WS) [Report]. - 2001.

Ankolenkar A [et al.] DAML-S: A Semantic Markup Language for Web Services [Conference] //

Proceedings of Semantic Web Working Symposium (SWWS). - 2001.

Apache Apache Axis 1.4. - [s.l.] : Apache Software Foundation, 22 April 2006.

Apache Apache Tomcat 5.5. - 2005.

Baresi L, Garzotti F and Paolini P Extending UML for Modelling Web Applications [Conference] //

Proceedings of the 34th Annual Hawaii International Conference on System Sciences. - Hawaii : [s.n.],

2001. - Vol. 3. - p. 3055.

Berkeley CS The Invsible Web [Online] // Berkeley - Teaching Library, Tutorials. - 2005. - October 26,

2006. - http://www.lib.berkeley.edu/TeachingLib/Guides/Internet/InvisibleWeb.html.

Berners-Lee T, Hendler J and Lassila O The Semantic Web [Journal]. - [s.l.] : Scientific American,

2001. - 5 : Vol. 284. - pp. 34-43.

Box D [et al.] Simple Object Access Protocol SOAP [W3C Specification] [Online] // W3C. - 2000. -

http://www.w3.org/TR/SOAP, 2000.

Burnham B REST vs. SOAP: Which SOA is more popular? [Online]. - December 2004. -

http://billburnham.blogs.com/burnhamsbeat/2004/12/rest_vs_soap_wh.html.

Cerami E Web Service Essentials [Book]. - [s.l.] : O'Reilly, 2002.

Christensen E [et al.] Web Services Description Language WSDL [Specification] [Online] // W3C Note. -

March 15, 2001. - http://www.w3c.org/TR/wsdl.

Conallen J and Larsen G Modeling Web Application Architectures with UML [Article]. - 1999. - 10 :

Vol. 42. - pp. 63-70.




Page | 75

Duftler M.J [et al.] Web Services Invocation Framework (WSIF) [Report]. - [s.l.] : IBM T.J. Watson

Research Center, 2001.

Endres A and Rombach D A Handbook of Software and Systems Engineering [Book]. - [s.l.] : Pearson,

Addison Wesley, 2003.

Farkas A.M. [et al.] Persistent Program Construction through Browsing and User Gesture with some

Typing [Conference] // Proc. 5th International Workshop on Persistent Object Systems. - San Miniato :

[s.n.], 1992.

Fox J.D., Detmold H. and Falkner K. Hyper-Programming Web Applications [Conference] //

Proceedings of the Second Australian Undergraduate Students' Computing Conference. - 2004.

Garrett J.J Ajax: A new approach to Web Applications [Online] // Adaptive Path. - 2005. -

http://www.adaptivepath.com/publications/essays/archives/000385.php.

Glass R.L Software Runaways. Lessons Learned from Massive Software Project Failures. [Book]. -

Upper Saddle River, NJ : Prentice Hall, 1998.

Google AJAXSLT [Online] // Google at Sourceforge. - October 26, 2006. - http://goog-

ajaxslt.sourceforge.net/.

Google Web Toolkit [GWT] [Online] // Google. - October 26, 2006. -

http://code.google.com/webtoolkit/.

Gottipati H.K Survery says Prototype is the most used AJAX toolkit/framework [Online]. - July 28,

2006. - http://www.oreillynet.com/xml/blog/2006/07/whats_the_best_ajax_toolkitfra.html .

Granell C, Poveda J and Gould M An Incremental Approach to Web Service Composition [Report]. -

2004.

Granell C, Poveda J and Gould M Incremental Composition of Geographic Web Services: An

Emergency Management Context [Report]. - 2003.

Green T and Blackwell A Cognitive Dimensions of Information Artefacts: a tutorial [Report]. - 1998.

JBoss Inc. JBoss Enterprise Middleware System. - 2005.

Johnston S Modelling Web Services [Online] // IBM. - 2005. - http://www-

128.ibm.com/developerworks/rational/library/05/1129_johnston/ .

Kim J and Gil Y Towards Interactive Composition of Semantic Web Services [Conference] //

Proceedings of the AAAI Spring Symposium on Semantic Web Services. - 2004.

Kirby G.N.C [et al.] Persistent Hyper-Programs [Conference] // In Proc. 5th International Workshop on

Persistent Object Systems. - San Miniato : [s.n.], 1992.

Kirby G.N.C Java Dynamic Compiler [Version 1.5] [Online]. - 2006. - http://www-systems.cs.st-

andrews.ac.uk/wiki/Dynamic_Java_Compiler.




Page | 76

Kirby G.N.C Reflection and Hyper-Programming in Persistent Programming Systems [Journal]. - [s.l.] :

Ph.D Thesis, University of St Andrews, 1992.

Kirby G.N.C, Morrison R and Stemple D.W Linguistic Reflection in Java. [Article] // Software Practice

and Experience. - 1998. - 10 : Vol. 28.

Kirby G.N.C. [et al.] Persistent Object Systems [Conference] // Proc. 5th International Workshop on

Persistent Object Systems (POS5). - San Miniato : Springe-Verlag, 1992. - pp. 86-106.

LaMonica M Trying to make Web Services make sense [Online] // ZNet. - 2004. -

http://news.zdnet.com/2100-3513_22-5242747.html.

Laymann F Web Services Flow Language (WSFL 1.0) [Report]. - [s.l.] : IBM Software Group, 2001.

Macdonald A Literature Review and Design [Report]. - 2007.

Macdonald A. D. Project Specification and Plan [Report]. - 2006.

Microsoft Microsoft .NET Framework, Web Services Functionality [Online] // MSDN. - June 2006. -

http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-

us/dnwebsrv/html/wsmsplatform.asp.

Morrison R. [et al.] Current Directions in Hyper-Programming [Conference] // Ershov Memorial

Conference. - 1999. - pp. 316-340.

Morrison R. [et al.] The Napier88 Reference Manual [Report]. - St Andrews : University of St Andrews

Technical Report PPRR-77-89, 1989.

Myers G.J. [et al.] The Art of Software Testing [Book]. - [s.l.] : John Wiley & Sons Inc, 2004. - 2nd

Edition. - ISBN 978-0471469124.

O'Reilly T Pipes and Filters for the Internet [Online] // O'Reilly Radar. - February 7, 2007. -

http://radar.oreilly.com/archives/2007/02/pipes_and_filte.html.

Protopage Protopage [AJAX Web Application] [Online]. - 2005. - http://www.protopage.com.

Prototype JavaScript Framework [Online]. - http://prototype.conio.net/.

Skogan D, Gronmo R and Solheim I Web Service Composition in UML [Conference] // Proceedings of

the Eigth IEEE International Enterprise Distributed Object Computing Conference. - 2004. - pp. 47-57.

Sommerville Ian Software Engineering [Book]. - [s.l.] : Pearson Addison Wesley, 2004. - Vol. 7th.

Srivastava B and Koehler J Web Service Composition - Current Solutions and Open Problems

[Journal]. - [s.l.] : ICAPS 2003, 2003.

Staab S [et al.] Web Services: Been There, Done That? [Journal]. - [s.l.] : IEEE Intelligent Systems,

January/February 2003. - 1 : Vol. 18. - pp. 72-85.

Stephens M and Rosenberg D Extreme Programming Refactored: The Case Against XP [Book]. - [s.l.] :

APress, US, 2003.




Page | 77

Tabor R. Microsoft .NET XML Web Services [Book]. - [s.l.] : Sams, 2002. - Vol. 1.

Techcrunch Yahoo! Launches Pipes [Online] // Techcrunch. - February 7, 2007. - March 29, 2007. -

http://www.techcrunch.com/2007/02/07/yahoo-launches-pipes/.

Thatte S XLANG: Web Services for Business Process Design [Report]. - [s.l.] : Microsoft, 2001.

W3C WAI Site: Usability Testing Questions [Online] // Web Accessibility Initiative. - W3C, October 24,

2003. - March 11, 2007. - http://www.w3.org/WAI/EO/Drafts/UCD/questions.html.

W3Schools Web Statistics and Trends [Online] // W3Schools.com. - January 2007. - March 11, 2007. -

http://www.w3schools.com/browsers/browsers_stats.asp.

Walker S.M A Flexible, Policy-Aware Middleware System [Report]. - [s.l.] : University of St Andrews,

2005.

Web Services Graphical User Interface (WSGUI) [Online]. - October 26, 2006. -

http://wsgui.berlios.de/.

Wells D [Online] // Extreme Programming: A Gentle Introduction. - February 17, 2006. -

http://extremeprogramming.org/.

Wenjun Y and Juanzi L Interactive Service Composition in SEWSIP [Conference] // Proceedings of the

2005 IEEE International Workshop on Service-Oriented System Engineering. - 2005.

Yahoo! Yahoo Pipes [Online] // Yahoo. - February 2007. - http://pipe.yahoo.com.

Zirintsis E. [et al.] Hyper-Programming in Java [Journal]. - [s.l.] : Morgan Kaufmann, 1994.




Page | 78

Appendices




Page | 79

Appendix A: Maintenance Documentation




Page | 80

Maintenance Documentation

Starting YaWSA

An HTML guide to starting YaWSA can be found in the submitted documentation, and in the yawsa-

tomcat folder. It is named ‘installation’.

YaWSA Structure

The system is broadly split up into two areas: the tomcat servlet and the back-end server. This

document discusses each in turn.

YaWSA Tomcat Servlet

This servlet is structured according to well-defined standards and conventions. Of note are the

following:

‘WEB-INF’ folder: contains the web.xml file defining the interfaces in the servlet, and a file

called dwr.xml that defines the operations that are available for asynchronous

communication.

‘WEB-INF/lib’ folder: contains all the JAR files required by the servlet. These are the dwr.jar

file that facilitates asynchronous communication, and local-dependencies.jar which contains

the NDS module for debugging.

‘WEB-INF/src’ folder: contains all the Java classes used within this servlet. Specifically

ITomcatInterface which defines the operations that will be available for asynchronous

communication with the client. This interface extends java.rmi.Remote as these methods

simply call corresponding classes on the backend server.

index.jsp: The YaWSA homepage. This page is used through the creation of compositions (as

communication is asynchronous). It contains a lot of dynamic code that can be used to

restore a user’s session if they refresh the page or go back. This functionality is not currently

active in the system.

‘js’ folder: Contains all of the JavaScript files used in the system. These files are:

o fat.js: A library function used to ‘flash’ HTML elements; to highlight them in yellow

briefly. This is used to signify that an element has been updated.

o YawsaDHTML.js: Contains elements written for this project, including:

ShowHideToggle – used to show/hide elements on a page.

writeToIFRAME – used to write the user’s ID to a hidden IFRAME. This

works across all browsers.

getIFRAMEDocument – used to retrieve the users session ID.

o YawsaUtilities.js: Contains elements written for this project, including:




Page | 81

var reply0 = function(data) – a function that parses the information

received from the server. This expects to receive an array of arrays. The

inner arrays contain two elements: the first is the ID of an HTML element,

and the second is the data to be placed in that element. This method

places the data into the given element.

getFormDataJS – Used to submit form data to the system. Recursively

traverses the DOM tree from the given element and returns all information

from textboxes and selection boxes along with a corresponding ID.

Help folder: This folder contains JSP pages relating to the systems help functionality,

including use cases, FAQ’s and an introduction to the system.

Back-End Server

The backend server contains the majority of the systems functionality. The remote interface with theservlet is contained within the tomcat package – TomcatInterface.java . The tests package contains

unit tests for the system. The server package contains the following packages:

exception: Contains classes created for YaWSA that extend java.lang.Exception.

htmlgeneration: Contains classes that are used to generate HTML code for the system. For

example, the OperationList class contains methods that create HTML presenting the user

with a list of available options for a service.

invocation: contains classes used in the generation and invocation of proxies. Apache Axis

and the dynamic compiler are not used outwith this package.

sessions: contains classes used to store users’ session details.

store: contains classes relating to the object and composition stores.

tree: contains all the classes used to represent and access composition trees. Most of these

classes extend the Node class which contains basic tree functionality.

util: contains various utility functions used throughout the system. For example, a method

that returns the contents of an object in HTML form, and a method that escapes special

HTML characters.

Other classes:

o CommandLineStartup – starts up the system in command-line mode. This allows

invocation of a Web Service from the command line.

o SystemStartup – starts up the system including an RMI registry. This allows the

Tomcat servlet to connect to it. If no arguments are provided RMI will run on the

default port (1099).

o SystemShutdown – used to shutdown the system (specifically unbind from the RMI

registry).




Page | 82

Appendix B: Project Specification and Plan




Page | 83

Project Description

Introduction

This project involves the creation of a website facilitating the invocation and composition of web

services.

Specifically, it will permit web services that have been deployed, described (in WSDL), and are

compliant with SOAP 1.1 to be invoked and composed from a standard Web Browser. Using a Web

browser, service calls may be made and parameters passed to service instances.

This requires the construction of dynamic web pages and service adapters to link from the HTTP

domain to the service provision domain. Systems similar to this exist, for example, to control

provisioning in the JBOSS (JBoss Inc., 2005) system, or invoke web services through ASMX files.

However these are limited to scalar values. In this project we propose the incorporation of hyper-

programming technology permitting arbitrary objects from multiple address spaces to be passed to

the services. This will allow existing services to be chained, producing new composite Web Services.

Use Case

This section gives a motivating example for the proposed system.

A company provides two web services; AddWS, which adds two numbers (given as parameters) then

returns the result, and DivideWS that divides one parameter from another then returns the result. An

employee wishing to find the average of two numbers has to invoke AddWS and DivideWS in

sequence, creating an individual web services client for each task.

The proposed system helps this employee in two ways. Firstly, to invoke these services the user

doesn’t have to create a web services client – they simply give the system a link to the services

description file. Having done this the employee can now chain the services by piping the output from

AddWS into DivideWS as a parameter, removing the need for the results to be copied manually.

If this is a task that has to be performed frequently the employee can save the newly created

composite Web Service and return to use it when required.

Objectives

The following objectives have been divided into sections to prioritise core aims and aid the design.

Primary

Provide access to HTTP invocable services by allowing invocation through an interface to the service

provision domain.

Invocation should be possible for scalar types (e.g. integers), and arbitrary data types defined in the

service description (WSDL file).




Page | 84

Secondary

The interface should provide flexibility of input, potentially extending to further textual

representations, URLs, and XML representations.

It should be possible, through the interface, to ‘chain’ web services. This involves passing the result of

one web service as a parameter to another.

The system should incorporate hyper-programming technology enabling services to be composed out

of existing services.

Tertiary

Users should be able to describe their compositions (see point 0, allowing them to be saved and run

again at a later date.

The system should be able to cope with the failure of services by providing meaningful, relevantmessages to the end user

Context Survey

This section provides an introduction to some of the fundamental areas covered in this project.

Introduction

Web Services




through open standards, meaning developers aren’t forced to use proprie tary applications.

The Web Services architecture consists of a set of protocols, each used for a distinct purpose. Figure

41 gives examples of these protocols and the functions that they perform.



NETWORK LAYER

WSDL

SOAP

HTTP, FTP, SMTP,

etc.

PUBLICATION &


Figure 35: Web Services programming stack

The bottom three layers of this stack are required in order to have interoperable web services, with

the remaining two providing desirable but optional functionality. The following sections describe the

protocols that have become standards for the service description layer and messaging layer.




Page | 85



stack, allowing descriptions of the methods provided by particular Web Services. These services are

defined by abstract method definitions, transport protocols employed for communication with the

service, and the location of the service in the form of a URL. While WSDL is in some ways limited (e.g.

it isn't able to describe transactions), it has become the de facto standard for the service description

layer, with higher layers in the stack utilizing it.

SOAP






SOAPs most widely used challenger. Not a specification, but an architectural style, REST is often used

without anyone knowing or understanding it (Burnham, 2004). Examples of REST web services include

Google's Ad-sense network and Amazon's Affiliate network that only require a few lines of HTML to

call.

Hyper-programming

A hyper-program is a source program containing both text and links to objects, unlike traditional

programs that are limited to referring to purely textual data (Kirby, et al., 1992). A major motivation

for

providing such a system is to allow the application programmer to compose programs

interactively, selecting items to be incorporated in to their programs (Kirby, et al., 1992) without

writing complex access specifications.

Hyper-programs contain denotations to for data that will be resolved to the actual data prior to


(Kirby, 1992):

Data Item: The value to be resolved. In a Web Services Architecture this corresponds to the service

itself.

Access Path: A description of the position of a data item. The access path of a Web Service is its URI.

Access Specification: Contains the access path of an item along with a description of its expected

type. The Service Description layer of the Web Services Architecture performs this function with

WSDL.


write complex process specifications, by allowing services to be composed interactively.




Page | 86


XMLHttpRequest is an API available in many scripting languages (such as JavaScript and VBScript) that

allows XML data to be sent to and from a web server using HTTP. Despite being available since 2002 it

was not until Google released Google Maps in 2005 that the technology reached mainstream web

development. At about the same time this technology was given a name – AJAX (Garrett, 2005).

Before AJAX, the classic web model involved synchronous HTTP requests and responses. With

XMLHttpRequest asynchronous communication with the server is possible, meaning entire pages

don't have to be reloaded if only a small amount of data has changed. Combined with well established

JavaScript functionality and DOM manipulation, this has allowed developers to increase page

interactivity, speed and usability. The result is that many sites have created applications previously

limited to desktop computing, such as word processors (e.g. Google Docs) and desktops [e.g.

Protopage (Protopage, 2005)].

Current Research




application integration, by automating the integration of components.



does, and functional annotation which describes how a service behaves.


Functional annotations are expressed within flow specifications that define the order in which

messages are exchanged between services.




IBM and Microsoft, BPEL4WS superseded both corporations’ previous attempts at a flow language;

WSFL (Laymann, 2001) and XLANG (Thatte, 2001) respectively. The result of combining features from



For the purposes of this project functional annotation languages are relevant to the tertiary goal of

describing web service compositions.




Page | 87



ontologies. While this technique hasn’t found the kind of commercial support that functional


(Berners-Lee, et al., 2001) and in academia.



al., 2001) to provide an ontology expressive enough to represent the properties of web services.

Comparison


operators, as protocols specify what a service does, and can are machine-readable. In this sense

functional annotation protocols are limited, as they can only describe how a service will behave,

leaving more work to create compositions.

Despite this, semantic annotation protocols are largely unproven, while functional annotation

protocols are being used in industry today.

Web Service Modeling


web services; most focusing on description through UML (Baresi, et al., 2001)(Johnston, 2005).

Numerous other attempts at visualizing web services are either defunct ( WSUI) or early in

development [KWSDL + Kung, WSGUI (Web061)].



preference.

Existing Applications

Of all the current web based Web Service tools Mindreef SOAPscope (Min06) is the most complete.

Users can invoke any web service provided they can provide the corresponding WSDL file, even when

parameters are non-scalar values. The site allows users to customize HTTP headers and SOAP sent to

the service, and provides comparison and analysis tools for WSDL files.

Conclusion

There are a number of systems (such as SOAPscope) which fulfill the basic criteria of this project.

However none of these systems allow for the interactive composition of Web Services, or consider

the possibility of an intermediate data store, as set out in this project.




Page | 88

The primary motivation for doing the required work on the prototype is to get the system to the level

of these existing systems. This system will allow the testing of Web Services not associated with .NET,

such as those exposed by the RAFDA RunTime (Walker, 2005).

Beyond the functionality provided by the prototype the proposed system would allow interactive

composition of services. At present there is no other software in the public domain that achieves this,

with business processes written either by hand, or with less interactive toolsets. No other system

considers the temporary storage of data for use among Web Service invocations. This is, in part, a

result of the desire for automation of processes, making such a system undesirable. However a

system providing a data store provides advantages in testing – where services are being configured

and linked – and provides a useful tool where no pre-set composition will suffice. Such a system

would make the process of creating compositions easier.




Page | 89

Requirements

Functional Requirements

Web Service Interpretation

The system will be able to parse Web Service Description (Version 1.1) files, to extract the

information specified within each file. This information should be sufficient to create proxy

classes for the web service being described.


The user will be able to invoke web services through a webpage, provided that a description

file has been correctly interpreted (see 0).

The system shall allow users to invoke service with custom defined data types.


The user will be able to compose linear sequences of web service interactions through a

webpage.

Having specified a series of interactions (see 0) the user will be able to invoke the specified

composition.

It should be possible to store the results of Web Service invocations on the system, for use at

a later date.

Non-Functional Requirements

Efficiency

User event response time will be less than 5 seconds, assuming normal load conditions on

the host server. Rationale: A good interface gives users feedback when they interact with the

system. This should happen, even if it is simply a ‘loading: please wait’ dialog.

Scalability

The system should be able to support more than one person using the system at a given

point in time. Rationale: A well-implemented system of this type should be multi-threaded

and allow for more than one user at any point in time.

Usability

A user new to the system will be able to invoke a web service with reference to the

immediate onscreen documentation provided. Rationale: The system should be designed to

be as intuitive as possible – this requirement shall be used as a metric to measure this.




Page | 90

A user new to the system will be able to use the remaining functionality of the system with

the documentation provided. Rationale: As with the previous requirement, this shall be used

as a metric to measure usability.

Documentation

Users should be provided with documentation on the webpage including, but not limited to:

o Description of how to invoke services and use case supporting this.

o Description of how to chain services and use case supporting this.

Rationale: Documentation is essential to any webpage of this type, as users have no other

means to grasp the system.

Documentation should assume nothing about the users’ knowledge of Web Services.

Rationale: The system could be used as an introduction to Web Services, and is not

necessarily targeted at an expert audience.

Standards

The system should be able to invoke all web services provided they:

o Are described by a WSDL V1.1 compatible file

o Send and receive messages in valid SOAP V1.1

o Are publicly available, thus accessible from the systems server.

Rationale: Web Services that don’t conform to the following standards are outwith the scope

of this project.

Portability

Users should be able to view the webpage and use its full functionality on Firefox (version

2.0) and Internet Explorer (version 7), with JavaScript enabled. Rationale: The system should

run on the two most popular web browsers on the internet. Version numbers are included to

avoid any unforeseen problems with new versions during implementation.

Organization

The webpage will be written in HTML and JavaScript.

The backend to the system will be written in Java 1.5, and may make use of third-party

libraries and applications (such as Apache Tomcat).

Delivery

The final solution must be handed in on the 27th

March 2007.




Page | 91

Project Plan

Document Overview

This document gives a high-level overview of the proposed system, and the methodologies that will

be applied to the development.

Development Model

Development models are integral to the software engineering process, in helping to guide

development, and compensate for risks. Accordingly, the choice of development model is important

and will have an effect on the rest of development.

One of the most commonly used methodologies, the Waterfall model, fits well with deadlines for

written deliverables; however it has no provisioning for prototyping. Iterative or agile developmentprocesses allow for such prototypes, aiming to reduce risk in the process. While such development

models are less suited to systems with high criticality, and safety requirements, the focus of

development on this project is on meeting several key deadlines.

As a consequence of this analysis Extreme Programming (Wells, 2006) will be used for this project. In

recent years it has become one of the most prominent agile development methodologies, by extolling

simplicity and feedback through test-based development. The project monitoring section is based on

this approach, and plans for numerous prototypes for various components within the system.

Figure 36: Extreme Programming Practices

Figure 36 illustrates extreme programming values. While a number of these, such as pair

programming, are not relevant to this project, the worth of test-driven development cannot be

underestimated.




Page | 92

System Plan

This section looks at the proposed structure of the system, expressing the purpose of each

component, as seen in Figure 37 below.

Web Front End

AJAX/JS

Initial page

Incoming

Messages

Outgoing

Messages

WSDL4J

WS Proxy Generator

Service

Composition

Service Invocation

To Service Endpoints

Service description

Internet

Server

Service invocation / composition

Store proxy

Invoke service(s)

Figure 37: Top level design

This diagram highlights the main components required for the proposed final system. The first

prototype of the system will not feature service composition or asynchronous communication with

the front-end.

Service Description

Before the user can invoke one of these services they must provide the system with a WSDL file

describing the service. Using the WSDL4J library to parse the WSDL file, the system will create a typed

proxy for the web service. This proxy will be stored in a suitable data structure until the user invokes

the service (having entered values for the required parameters). Once the proxy has been created the

program also creates a form, to be displayed to the user, which allows the user to enter values for the

parameters taken by the Web Service. Figure 38 illustrates this process.

WSDL Proxy Generated form for user

Service Storage

Web Front-End

p r o x y

Figure 38: Service Invocation

The proxies created from this process are fully typed, making checking for invalid arguments easier.

Service Invocation

To invoke a service, the user must complete a form containing fields for all the parameters of a

particular Web Service. Once submitted, the system applies the users input as parameter(s) to the

services proxy object (previously created – see 0), which in turn calls the actual Web Service with the

request.




Page | 93

Service Composition

Put simply, service composition requires multiple in-order invocations at a system level. To make this

possible the system must store the proxies created in 0, such that they can be linked together. This is

done by wrapping the service proxies in ‘boxes’, and making it possible for these boxes to be linked to

form service compositions. This is illustrated in Figure 39 below.

Box

DivWS

Box

AddWS

Figure 39: Storage of Proxies

Here proxies for both web services are wrapped in Box objects; parameters and return values are

indirectly linked through these. Here Inversion of Control is applied to reduce the coupling between

proxies.

Invocation of Compositions

Once a composition has been created, and a group of proxies stored (as in Figure 39), a compositor

program must be dynamically created to execute the invocation. This program will take so-called

boxes (containing proxies) as arguments, before a run method is called to execute the operation.

Limits on Client-Side Computation

Due to security restrictions imposed on the XMLHttpRequest object, it is only possible to send

messages to the same domain as the website. As a result invocations of Web Services must take place

via a server-side program.

Testing

Software testing is an essential part of the software development process, helping to reveal pitfalls in

design and errors made during implementation. It will be particularly important for this project as the

Extreme Programming methodology being used places considerable emphasis on test driven

development. In practice this means that testing will be performed progressively through the

implementation to identify problems as soon as possible.

Testing strategies

Unit Testing

Unit testing is a cornerstone of Extreme Programming, and will be performed on all modules within

the system, where possible. JUnit 4.1 will be used for system components implemented in Java.




Page | 94

Service Composition Testing

The final system will allow users to compose web services through a web front-end; however the

server-side composition engine should be tested prior to connection with the interface. This will be

performed in a number of stages;

Create proxy objects, and link them manually. Rationale: Proof of concept implementation of

composition.

Having linked proxy objects, manually create a compositor program to run the composition.

Rationale: Further proof of concept showing composite services being invoked.

Automatically create wrapper objects for proxies, which can be linked. Rationale: Progression from

previously implementations. This will allow the system to be built in increments.

Automatically create compositor program that successfully invokes compositions. Rationale: The final

stage in implementing a server-side composition engine.

This plan allows for comprehensive testing of the system before integration with the user interface.

Acceptance Tests

Extreme programming advocates the use of acceptance tests as a means of checking system

functionality against requirements. Acceptance testing will be performed in this project based on the

requirements outlined in the Project Specification.




Page | 95

Documentation

As with any system of this type, documentation must be produced for both the end-user and the

application programmer. The style and content of this documentation is described here.

User Level

Documentation for end-users should be available in document format and as a smaller guide for users on

the web front-end.

Both sets of documentation should provide a brief overview of Web Services before explaining the precise

operation of the system. A description of the systems functionality should be provided through a series of

worked examples, making it possible for a user to the system with reference only to documentation

provided.

Programmer level

As with any system it is possible that another programmer may at some point become involved in the

project and update or extend the programs functionality. Documentation should aim to make this task as

easy as possible for the incoming programmer.

Firstly, a maintenance document should be written detailing important aspects of the implementation,

and describing the structure of the system.

While self-documenting code is a laudable aim it is rarely possible in practice. As a result all Java classes

created for the system should be annotated with JavaDoc, and other code should be documented in a

similar fashion.

Project Monitoring

Project Milestones

27/10/2006 27/03/2007

01/11/2006 01/12/2006 01/01/2007 01/02/2007 01/03/2007

13/11/2006

Lit. Review and Prototype Design

08/12/2006

Prototype Demonstration

15/12/2006

Interim Presentation

09/02/2007

Final Spec. & Plan

16/03/2007

Draft Report

27/03/2007

Final Hand-in

27/10/2006

Initial Spec. & Plan

Figure 40: Project Milestones




Page | 96

While these deadlines represent a substantial body of work, they take no account of the implementation

of the system. The following Gantt chart includes both sets of goals and specifies when work on each task

should begin.

Risk Identification

Risk Probability Effects Action

Personal Illness Low Medium Loss of functionality

Dramatic increase in scope High Low Identify main goals and attempt to achieve

them; prioritize goals and allow more time

for deadline.

External factors Low Major Attempt best case solution extend

deadlines is possible

Implementation of AJAX

page takes too long.

Low Medium Revert to a pure HTML design.

Allowing Custom Data Types

proves impossible

Low Medium Limit depth of data types to an arbitrary

value.




Page | 97

Gantt chart

The chart below displays project deliverables as milestones (diamonds, tasks 1-9), and other personal implementation goals as rectangles (rectangles,

tasks 10-15).

December is left deliberately clear of implementation goals, allowing time to catch up should development fall behind. In addition, the first half of

January is left clear due to examinations.



Appendix C: Literature Review and Design




Page | 99

Literature Review

This literature review builds on the Context Survey in an earlier deliverable (Macdonald, 2006), with

additional analysis of relevant background literature and prior art.

Web Services Introduction




through open standards, meaning developers aren’t forced to use proprietary applications.

The Web Services architecture consists of a set of protocols, each used for a distinct purpose. Figure

41 gives examples of these protocols alongside the functions that they fulfill.

Figure 41: Web Services programming stack

The bottom three layers of this stack are required for the creation of interoperable Web Services,

with the remaining two providing desirable but optional functionality. The following sections describe

the protocols that have become standards for the service description layer and messaging layer.



stack, allowing descriptions of the functions provided by particular Web Services. These services are

defined by abstract method definitions, the transport protocol employed for communication with the

service, and the location of the service in the form of a URL. While WSDL is seen by some as being too

restrictive (for example, it isn't able to describe transactions), it has nevertheless become the de facto

standard for the service description layer, with higher layers in the stack utilizing it.

SOAP






NETWORK LAYER

WSDL

SOAP

HTTP, FTP, SMTP,

etc.

PUBLICATION &





Page | 100



a commonly used approach with a similar purpose. Not a specification, but an architectural style,

REST is often used without anyone knowing or understanding it (Burnham, 2004). Examples of REST

web services include Google's Ad-sense network and Amazon's Affiliate network that only require a

few lines of HTML to call. Despite this, SOAP is the dominant message format for Web Services and

will be used to send and receive messages in this project.

Hyper-Programming

Introduction

Hyper-programming is a paradigm for system construction, where a source program (a hyper-

program) contains both text and links to objects. Contrast this with traditional programs that are

limited to referring to purely textual data (Kirby, et al., 1992).

Hyper-programs contain denotations to for data that will be resolved to the actual data prior to


(Kirby, 1992):

Data Item: The value to be resolved. With Web Services composition this corresponds to the data

returned by a service.

Access Path: This is a description of the position of a data item. The access path of a Web Service is its

URI.

Access Specification: Contains the access path of an item along with a description of its expected

type. The Service Description layer of the Web Services Architecture performs this function with

WSDL.

The first implementation of a hyper-programming system was created in the Napier88 persistent

programming environment (Morrison, et al., 1989), with a Java implementation created later

(Zirintsis, et al., 1994).

A major motivation for

providing such a system is to allow the application programmer to compose

programs interactively, selecting items to be incorporated into their programs (Farkas, et al.,

1992)(Kirby, et al., 1992). Users should be able to navigate the value space, selecting data items for

inclusion to their source. In doing this the complexity is reduced, as access specifications don’t need

to be written for data items used by the program. This enables type checking to be performed earlier

at compile-time, ensuring that all items can be accessed at run-time (the access specification can

change).


write complex process specifications, by allowing services to be composed interactively. This project

aims to make this possible through a web based interface.




Page | 101

Hyper-Programming on the Internet

Hyper-Programming requires the presence of an external value space where bindings can be

constructed during program composition. While this is typically provided by a persistent store, a file

system or other mechanism such as the World Wide Web is equally valid (Morrison, et al., 1999).

A proposal for hyper-programming on the internet was first discussed in (Morrison, et al., 1999);

however the technology required to extend the paradigm was inadequate at the time and left several

significant technical difficulties. These included how to integrate data from external web sources in a

typed computation, and how to integrate typed data with the HTTP protocol. Since then the

standardisation of XML and the creation of Web Services standards such as WSDL have helped to

alleviate these problems, though no standard solution exists for making the potential failure of

references tolerable. A hyper-programming implementation for the internet, HyperWeb (Fox, et al.,

2004), has been developed and attempts to solve a number of these problems through a model of

web application program safety that aims to ensure referential integrity.

Other research outwith hyper-programming has focused on adapting existing internet fault tolerance

techniques, such as load balancing and data replication (Anderson, 1996)(Aghdaie, et al.,

2001)(Aghdaie, et al., 2002), to Web Services. A client-transparent implementation of such a system

by Aghdaie & Tamir works on a three-tier architecture, where server failure is detected by a front-end

server and requests are routed to a backup server. The scheme ensures that requests being processed

at the time of a crash are completed through use of TCP’s error control protocols.




application integration, by automating the integration of components.



does, while functional annotation describes how a service behaves (Srivastava, et al., 2003).


Functional annotation is used in Web Service composition to express how a service behaves. Services

using this approach are expressed within flow specifications that define the order in which messages

are exchanged between services.




IBM and Microsoft, BPEL4WS superseded both corporations’ previous attempts at a flow language;WSFL (Laymann, 2001) and XLANG (Thatte, 2001) respectively. The result of combining features from




Page | 102





ontology’s. While this technique hasn’t found the kind of commercial support that functional


(Berners-Lee, et al., 2001) and in academia.



al., 2001) to provide an ontology expressive enough to represent the properties of web services.

Comparison


operators, as protocols specify what a service does, and can are machine-readable. In this sense

functional annotation protocols are limited, as they can only describe how a service will behave,

leaving more work to create compositions.

Despite this, semantic annotation protocols are largely unproven, while functional annotation

protocols are being used in industry today. For the purposes of this project functional annotation

languages are relevant to the tertiary goal of describing web service compositions.

Interactive Composition

Several efforts are underway to create a method of interactively composing semantic Web Services.

These raise a number of issues relevant to both semantic and functional compositions. Kim and Gil

(Kim, et al., 2004) found that, even for a small number of services, users would benefit from the

assistance of tools that allowed them to specify complete and correct pathways in compositions. This

underlines the importance of guiding users – first by showing available compositions, and then

preventing invalid invocations.

Wenjun et al. (2005) break web service composition into three stages: designing process, binding

activities with concrete Web Services, and assigning data flow in the process. In assigning data flow

we must assume that all services in a flow use coincident message types, so that the output of one

service is of the same type as the input of another. It is however common that two messages are

subtly heterogeneous, despite both representing similar semantics (Wenjun, et al., 2005). Many

composition frameworks simply rule out communication between services with heterogeneous but

similar types. Others such as SEWSIP (Semantic Based Web Service Integration Platform) include a

message transforming service that converts the output from one service to be compatible with the

input of another service.




Page | 103

Extending this concept to allow other intermediate state would create an additional layer to Web

Service composition. This has not been covered in any existing Web Services research.

Web Service Modelling


web services; most focusing on description through UML (Johnston, 2005)(Skogan, et al.,

2004)(Baresi, et al., 2001)(Conallen, et al., 1999). Numerous other attempts at visualizing web

services are either defunct (WSUI) or early in development [KWSDL + Kung, WSGUI (Web061)].



preference. Providing a graphical representation of services would allow the creation of web service

compositions through direct manipulation, rather than more restrictive form fill-in methods.

Web Service Invocation Tools

Libraries

A number of libraries are available that assist in the creation of Web Services and Web Services

Clients. This section looks at two such programs.

Apache Axis

A part of the Web Services project at the Apache Software Foundation, Axis (Apache, 2006) is an

implementation of the SOAP submission to W3C. It was originally based on IBM’s SOAP4J library but

has since been redesigned, and versions now exist for Java and C++. Axis is the most complete Java

implementation of SOAP, allowing programmers to create Web Services and client proxies for Web

Services that handle the generation and transport of SOAP messages.

.NET Framework

Microsoft provide support for sending SOAP via HTTP(S) in the .NET framework (Microsoft, 2006), and

give IDE support through Visual Studio .NET. These tools provide similar functionality to Apache Axis;

however, as no Java implementation exists it is of limited use for this project.

Programs

Various programs exist that perform a similar function to the proposed prototype system. This section

looks at some notable applications.

Microsoft ASMX

ASMX files provide an interface for a specific Web Service, allowing users to invoke functions with

primitive parameters. They are Microsoft ASP files automatically produced for running .NET Web

Services (Tabor, 2002) when run on an IIS server, or through Visual Studio .NET. Pages describe




Page | 104

available functions, showing the SOAP message format for a request, and the expected return type.

Users can invoke services through a form, but are limited to methods with primitive parameters;

complex data types are not supported.

The prototype system aims to provide a similar system with the ability to invoke services with

primitive types and complex data types. The system will also differ in providing a generic framework

for invocation of any specified Web Service, rather than being used to invoke a specific Web Service

(as with ASMX).

Mindreef SOAPscope

SOAPscope (Min06) is a more complete solution than MS ASMX as invocation of complex data types is

possible. In addition, the website can be used to invoke any Web Service provided a WSDL file is

available. SOAPscope also allows customisation of SOAP being sent, and comparison between WSDL

files; functionality that goes beyond ASMX.

The initial prototype will mirror SOAPscope in its ability to invoke complex data types, but will not

allow SOAP to be customised on the client-side. The final implementation can learn from SOAPscope’s

WSDL tool, which allows for various representations of WSDL including a graphical UML-style view.

This is relevant to interactive Web Service composition, as it has the potential to form the basis of a

direct manipulation interface.


Introduction

XMLHttpRequest is an API available in many scripting languages (such as JavaScript and VBScript) that

allows XML data to be sent asynchronously to and from a web server using HTTP. Despite being

available since 2002 it was not until Google released Google Maps in 2005 that the technology

reached mainstream web development. At about the same time this technology was given a name –

AJAX (Garrett, 2005).

Before AJAX, the classic web model involved synchronous HTTP requests and responses. With

XMLHttpRequest asynchronous communication with the server is possible, meaning entire pages

don't have to be reloaded if only a small amount of data has changed. Combined with well established

JavaScript functionality and DOM manipulation, this has allowed developers to increase page

interactivity, speed and usability. The result is that many sites have created applications previously

limited to desktop computing, such as word processors (e.g. Google Docs) and desktops (e.g.

Protopage (Protopage, 2005)).

Despite these benefits a number of problems still trouble AJAX. As AJAX removes the need to navigate

away from a single page most applications break the expected behaviour of a browsers back button,

as the browser has not observed any state change. Some AJAX applications such as Gmail have

implemented work-around solutions to this problem. As most content is often dynamically generated




Page | 105

it is not possible for search engines to read most content, leading to a problem known as the invisible

web (Berkeley CS, 2005).

AJAX and JavaScript Libraries

The recent explosion in the number of AJAX web pages would not have been possible without the

AJAX and DOM libraries that have abstracted away from the intricacies of JavaScript. This section

looks at some of the most prominent libraries available, and analyses their relative strengths and

weaknesses.

These libraries can be broadly split into three categories: those that abstract over commonly used

JavaScript functionality; those that provide functions for developing widgets and visual effects in web

pages; those that make asynchronous communication with server languages (e.g. Java, PHP) easier by

wrapping the XMLHttpRequest object.

Prototype

Packaged as a 45kb JavaScript file, Prototype (Protopage, 2005) aims to ease the development of

dynamic web pages. It provides various programming shortcuts to commonly used functions such as

XMLHttpRequest, but requires users to program higher-level visual interfaces commonly associated

with AJAX applications. As a result a number of other frameworks have been built on top of

Prototype, providing programmers with more support for interface design.

script.aculo.us

script.aculo.us is one of a number of toolkits using Prototype. It offers support for various effects and

controls such as drag-and-drop lists, visual effects, and AJAX interaction. At the time of writing it is

one of the most popular AJAX libraries available (Gottipati, 2006), and is used by companies such as

NBC and Apple on their websites.

Google Web Toolkit

The Google Web Toolkit (GWT) differs from other libraries by allowing AJAX applications to be

developed in pure Java (Goo06). This code is converted into browser-compliant JavaScript and HTML

using the GWT compiler. In doing this, applications have stronger typing during development and

errors can be spotted earlier in development. It was used by Google to create applications such as

Google Maps and Gmail before being released to the general public in May 2006.

GWT guarantees compatibility with all major browsers§§§

, and removes many of the complexities

associated with developing AJAX applications. It also provides a number of widgets (such as those

used in Gmail) that provide similar functionality to those offered by script.aculo.us.

§§§ Compatible with IE, Firefox, Mozilla Firefox, Safari, and Opera.




Page | 106

In addition to GWT Google provide a number of related libraries for use in AJAX applications. AJAXSLT

(Goo061) is an implementation of XSLT in JavaScript. This can be used to transform XML messages

sent from the server on the client’s browser.

Other Technologies

This section describes a number of technologies relevant to the project.

Apache Tomcat

Tomcat (Apache, 2005) is a web container that implements the Servlet and JSP specification from Sun

Microsystems. It can function as a standalone Web Server or in combination another, such as an

Apache HTTP Server. Its suitability for integration with Java programs has made it a popular program

– so much so that it became a top-level Apache project in September 2005.

As the server-side section of the system will be written in Java, Tomcat provides useful functionality

for integration with a dynamic webpage. In addition to JSP support there are a number of third-party

frameworks that can be used with tomcat to create AJAX applications. The Google Web Toolkit -

described above - is an example of this.

Java Dynamic Compiler

The proposed system design requires that Java source files be dynamically compiled to create Web

Service proxy classes. The Dynamic Java Compiler (Kirby, et al., 1998) (Kirby, 2006) performs this task,

and will be suitable for use on the project.



Project Design

System Structure

The prototype system will allow users to invoke Web Services through a web based interface. This will

be connected to a Java based back-end system. The users’ conceptual model of the system is shown

in Figure 42.

Proxy Generator

Web Front-End

Server

Service

request

request

Mashalling

requestCompositor

response

Users Conceptual Model

Actual Communication

Figure 42: Conceptual System Overview

From the users viewpoint the front-end to the system is communicating with a service directly. In

actual fact the system uses a server that maintains a representation of the service (a proxy object),

and presents an interface to this on the user’s browser. When a service is invoked, a message is sent

from the front-end to the server, where the proxy is invoked (calling the service). To clarify this

process, consider a use case: a user wishes to invoke a Web Service called Course.enrol(), which takes

a Student object as a parameter. The service allows lecturers to enrol students in a course through a

Web Services interface. Figure 43 shows a basic model of the system, where the client (A)

communicates through the system (B, C) to invoke the enrol service (D).




Page | 108

System

B

C

Tomcat Servlet

Back-end Server

Java RMI

AJAX

D

A

SOAP

Course

enrol()

returnClass()

DBservice

lookup()

Client

Figure 43: Data Flow

To invoke the enrol() operation, the lecturer must first provide a link to the services WSDL file. They

enter the link, then submit the form in their browser (A, in Figure 43), sending the information to the

system (B). The system finds the WSDL file and passes it to Apache Axis in the back-end server (C),

which creates Java proxy files for the Web Service. These proxy files are stored in the back-end server,

and will later be used to invoke the service (at D).

Before the proxy files can be used, they must be dynamically compiled (they are initially plaintext java

files). This is done at the back-end server using the dynamic compiler. The class files created in this

process are stored for later use. In addition, a description of the parameters required to call the

service is passed back to the client’s browser.

The lecturer is presented with a form allowing them to enter details of the enrolling student (the

operation’s parameters). The user completes the form and presses the submit button. Once again this

information is sent from the users browser (at A), through to the back-end server (at C). Here, the

parameter values are passed to the Axis proxy object, and the proxy is invoked. The proxy is

responsible for the communication with the service (at D).

When the response is received, it is deserialized by the proxy and sent via Tomcat to the user

interface (A). This entire process requires substantial server-side computation, though the user is only

ever aware of a communication between the interface and the Web Service being invoked (as shown

in Figure 42; the conceptual model).

Implementation Specifics

Figure 43 introduced the general structure of the proposed prototype, without specifying the work

involved on the server. This section describes what will be required, and how it will be implemented.

In general, all server-side code will be written in Java, with AJAX being used for communication

between the client and server.




Page | 109

Storage of Proxies

The proxies created by Apache Axis are Java source files; dynamic compilation of these files is

required before the proxies are stored. Once created, these dynamically compiled class files will be

stored in a wrapper object.

The wrapper object will store details about available functions and parameters required for these

functions, and will be used by other programs to establish what operations are available on the

service. Linguistic reflection will be used on the generated proxy to obtain these details.

Invocation of Proxies

All calls to Web Services are made through the proxy objects stored on the back-end server (C, in

Figure 43). Two approaches to executing this were considered. These were:

Pass parameters as Java objects. Fully type all parameters (including custom data types) in Java,

meaning parameters exist on the server as Java objects, and are invoked through the Java service

proxy. This proxy serializes the objects into SOAP.

Pass parameters in strings, formatted as SOAP fragments. Parameters will be passed between

services, formatted in SOAP. This means that the parameters can be added to the SOAP forming a

request, and removes the need to enforce strong typing on the server. However, if this option were

chosen, the system would need to contain functionality to parse and create SOAP methods.

The prototype will attempt to follow the first approach, as this obviates the need for manual

construction of SOAP.

Once created, the proxies are stored in the wrapper object. This will provide a number of generic

methods to specify the method to be invoked, any parameters, and the types of these parameters.

This is shown in the wrapper API below.

public class Wrapper {

public List<Method> getOperation();

public Object invokeService(String function_name, Class[] parameter_types,

Object[] parameters);

public String getWSDL();

public URL getURL();

}

Figure 44: Wrapper API

This API may need to be expanded or modified as iterations of the system are developed, however it

shows the envisaged functionality of the wrapper object.




Page | 110

Client-Server Communication

The system will use the Apache Tomcat servlet container to facilitate communication between the

Java back-end and browser front-end. A number of AJAX frameworks have been created for Tomcat,

helping to ease development in this regard.

The servlet has been separated from the back-end server as a result of difficulties encountered when

implementing the prototype system. When trying to instantiate an Axis proxy class (within a Servlet

environment), errors are thrown within the Axis JAR file. This is a fault within Axis, and not the project

implementation.

Due to the time constraints imposed on the project, it was decided that a work-around to the

problem was the best option.

Four-Tiered Architecture

The system forms the middle two tiers of a four-tier architecture, as shown in Figure 45. The Tomcat

Servlet will, for the most part, pass messages onto either the client or back-end server. It will also

perform error checking, preventing unnecessary communication with the back-end server. Java RMI

will be used for communication between the servlet and back-end server.

System

Web Service

D

Back-End Server

C

Tomcat Servlet

B

Client

A

Figure 45: System Architecture

To invoke a service, messages must be encoded and sent between these four, distinct, parts of the

system. They are:

The clients’ web browser

The server-side tomcat servlet

The server-side back-end

The Web Service being invoked

The following section discusses how data will be encoded as it is passed between these parts.

Data Encoding

This section describes how data will be encoded as it is passed between system components. An

example is used to clarify this description.

Consider the system, illustrated in Figure 43, which shows two Web Services: Course and DBservice.

As before, Course provides a number of operations to enrol students in a course, and find out who is




Page | 111

enrolled. DBservice provides an operation, lookup(), for getting student and lecturer information from

the university directory. Each student has a name and a supervisor - the latter is a custom data type

containing further information (such as name, age).

Use Cases

There are three distinct use cases for this system, described below.

UC1: User Invokes Single Web Service

At the most basic level it should be possible for a user to query an individual Web Service and to

receive the return value. After invoking this service the user makes no further use of the returned

data (within the system). Example: A lecturer enrols a student in a course, and then leaves the system.

UC2: User Invokes Web Service using result from past invocation

A user wishes to query the lookup service to retrieve a Student object, and then enrol this student in a

course. They enter parameters for, and invoke, the lookup operation first, with the result being stored

on the server. Now, when they wish to enrol the student, they provide a link to this stored student

data, and the service is invoked.

UC3: User Chains Web Services

This is effectively a mutation of UC2, with the intermediate step hidden from the user. Instead of

explicitly storing the return value of DBService.lookup on the server, the user specifies that they want

to pipe the output into Course.enrol(), before invoking either service. In UC2 the user invoked each

service separately.

Example

The system must be able to support these three use cases, and is designed accordingly. This section

goes through an example of UC2, describing the design issues involved. In our example a lecturer will

attempt to enrol a student in their course. The student, named Angus, has a supervisor, Al, whose

details are already held in the system. Enrollment requires that a student’s details contain their name,

and the details of their supervisor.




Page | 112

System

B

C

Tomcat Servlet

Back-end Server

Java RMI

AJAX

D

A

SOAP

<soapenv>

<enrol>

<person>

...

</person>

</enrol>

</soapenv>

Course

enrol()returnClass()

DBservice

lookup()

AngusName:

Lecturer:

Invoke

Student:

Al-DSRef:

Supervisor

Client

Figure 46: Data Flow required for an enrolment

Figure 46 illustrates the flow of data through the system when the invocation is made. The client, at

A, will enter the required parameters for enrollment, and send this information to the tomcat servlet

(B) and into the system. After some processing of the data it will be serialized and sent as part of a

request to the Web Service at D. The following sections explain the process involved in this

invocation, and give details of the planned implementation. The process begins at A, with the user.

A: Parameter Entry

Before the system invokes a service, the user must enter the required parameters. In this example

they are presented with a form allowing them to enter a student’s name, and the details of their

supervisor. At this stage the user has three choices, as identified by the three use cases. They can:

enter the details of their supervisor (create a lecturer object, entering name and age for it); provide a

link to an existing lecturer object on the system; provide a link to a Web Service that returns a lecturer

object. The system must be able to describe this information in some format. The following types are

supported:

Primitive Values – Values that can be entered by the user into a textbox (e.g. Name).

Link to Web Service – A link to the output of a Web Service operation.

Link to Data Store – A link to a lecturer object already stored in memory.

In our example, the user submits a form with the following contents:

AngusName:

Lecturer:

Invoke

Student

Al-DSRef:Supervisor:

Figure 47: Submitted Form




Page | 113

Figure 47 shows that the user provides a reference to the lecturers’ details, rather than providing

them in the form. They have chosen to do this over entering the details manually, or piping the

output from another Web Service. The system will give users these options by listing them as part of

the form. The user will be able to: enter the parameters required for the object, choose from a list of

applicable stored objects (as in this case), or provide a link to another Web Service. Again, each of

these options corresponds to a specific use case identified above.

A to B: Encoding Parameters

When the form is submitted, the system encodes the information and sends it to the tomcat servlet

(B) using AJAX. It is important that no information is lost during the encoding process – notably, the

structure of the data being submitted.

In a client’s browser the form is displayed in a hierarchical structure - the Lecturer object representing

‘supervisor is a child of the root Student object. This information must be maintained when it is

flattened and sent to B (the servlet), and can be guaranteed by giving each node (in the form) an ID

number. This can be used to restore the tree structure server-side.

Encoding the Data

Data will be encoded using the following technique, thus ensuring it can be restored server-side.

Webpage Structure

A [id=1]

B [1] C [2]

D [1] E [2]

[A, 1], [B,11], [C,12],

[D,111], [E,112]

Encoded Format

Reformed Structure

A [id=1]

B [1] C [2]

D [1] E [2]

Figure 48: Flattening/Restoration of Tree Structure

The root letter, A, represents a parameter of the Web Service. A’s children are the parameters

required to instantiate A, and so on. When the form is submitted an ID is generated for each node in

the tree based on its position. For example, C is the second child of A, meaning it is given the ID ‘12’,

where ‘1’ is the ID of A. This process continues for every element, until the entire form is encoded. It

is then sent across the network where it can be reformed by reversing the process.

Data will be sent in an array, as shown in Figure 49. Each element in the web form is represented here

with an ID tag in the format described above. The type field describes the contents of this element – a

primitive value, a link to item in the store, or a link to another Web Service. Finally, the value field

contains the user’s input.




Page | 114

Figure 49: Form Data sent from Client

B to C: Forwarding the Message

Upon receipt of the data, the tomcat servlet does some minor error checking, before passing the

message onto the back-end server. It will check that the message is correctly formed and that the

user has provided a valid session UUID.

The Java RMI interface between the servlet (B) and the back-end server (C) effectively mirrors the

interface between the client (A) and servlet (B); Tomcat does not alter the format of the data, beyond

its conversion to Java types.

C: Processing the Request

Having received the request, the back-end server is responsible for parsing it, then invoking the Web

Service using Apache Axis. First, a Java-based tree will be constructed from the received data. Its

reconstructed form is shown below in Figure 50. This allows the system to instantiate objects, as the

system can easily find the parameters required to construct them.

Student

ID: 1

Lecturer

ID: 1ID: 2

String

Resolved ID: 12

Figure 50: Reconstructed Tree

This is a simplified illustration of the tree’s server-side representation. In the concrete

implementation the user’s parameters will form part of a larger invocation tree, containing meta-data

on the Web Service(s) being invoked, and facilitating the composition of services.

In our example - which is analogous to UC1 - the user is invoking a Web Service without chaining. The

following digression looks at a case where services are being chained.

ID

Type

Value

1

<Complex>

12

<Store>

#ref

11

<Primitive>

“Angus”




Page | 115

Chaining Services: Server-Side Structure

In our example the user is making reference to an item stored on the server. Another use case - UC3 -

would have the user creating a composition that gets a Student object from DBService.lookup() and

uses this as a parameter to enrol() – effectively piping the output of lookup() into the enrol()

operation.

The server must be able to represent such a composition server-side, before any invocation can take

place. This will be achieved by structuring invocations chains into a Java tree construct, as shown in

Figure 51 below. This invocation tree adds another layer of indirection, enabling parameters to point

to objects directly, or to other Web Services. Figure 51 shows the enrol () method of Course is being

invoked with the value returned by lookup().

INVOKE

Course

Wrapper enrol

returnStudents

“enrol”

INVOKE

Method to be called


“lookup”

“John Smith”

Parameter(s)

String DBservice

Wrapper lookup

Service in Wrapper

Figure 51: Invocation Tree

This composition is made possible by a function wrapper; the object shown in Figure 52. It allows the

program to specify a Web Service, the name of an operation in that service, and any parameters to be

used in a call to that operation. In our example the enrol() operation is available in the Course Web

Service, and takes a single parameter, Student .




Page | 116

Web ServiceFunction

Name Parameters

Figure 52: Function Wrapper

To compose a service chain, a function wrapper is provided as a parameter to a function call, rather

than the expected type. So, for example, if enrol() was to be called without composition, a pointer to

a Student object would be provided as a parameter. If this service was to be chained with the lookup()

function, a pointer to another function wrapper would be given in place of the Student object (as

shown in Figure 51). This wrapper, in its call to lookup(), must return a Student object for the

composition to run.

Resolving References

Before invoking the service, links to items in the store must be resolved. This will be done through a

pre-order traversal of the tree – when a link to the store is found it will be replaced with the actual

object. In our example the user has used a link to a Lecturer object (as shown in Figure 47) in the

object store. When this reference is encountered during the tree-traversal, the object will be

retrieved from the store, and the reference replaced.

Object Store

References can point to Web Services or items in the object store. This server-side data structure

stores the objects returned from previous Web Service invocations, allowing them to be used as input

for later operations.

The system could either automatically store returned values in the store, or ask users if they want it

to be stored. The latter is preferable as it would allow users to tag the item with identifying

information, making later use simpler.

C to D: Invoking the Service

When invoking the composition, a post-order traversal of the tree is required. This will ensure that

references to Web Services are evaluated in the correct order (so that the output of one can be used

as the input to another). During this traversal the following operations will occur (when necessary):

Objects will be instantiated

Links to Web Services will be resolved (these services will be invoked)

When the system reaches the root node (effectively a link to a Web Service) it will make a call to the

Apache Axis proxy with the parameters given. Axis serializes the parameters (into SOAP) and makes a

remote call to the Web Service in question. The services response is deserialized by Axis and returned




Page | 117

to the server as a Java object of the type specified by the service description. The server will then

return a string of HTML to the user displaying the result of the invocation.

Summary of Example

This example shows how the system has been designed to cope with the three identified use cases.

The sequence of events described above are summarised in the following state sequence diagram

(Figure 53), beginning with the server providing the user with a form.

Backend Server Intermediate Server Client

Form (String - HTML)

New Student Object + UUID

New Student Object

Update to Section of the Form (HTML)

Submit Form Contents (Array) + UUID

Submit Form Contents (Array)

Web Service

Invoke Service (SOAP)

Response (SOAP)

Response (HTML)

Response (HTML)

Figure 53: State Sequence - Four Tier Model

As the diagram shows, a number of calls are made to the backend server before a service is invoked,

however only one call is made to the service itself. Also visible is the intermediate tomcat servers in

forwarding messages from the client to the back-end server. It is used for little else, but for some

simple error checking.

Once information reaches the client, it is important it is displayed clearly, containing all relevant

information. The following section shows how the design attempts to achieve this objective.




Page | 118

Interface Design

This section provides screenshots of the prototype interface. These screenshots illustrate some of the

work carried out on the prototype, and are indicative of the final solution.

Initial Page

Before users can invoke a service they must provide a link to the WSDL file describing it. The initial

page fulfils this requirement by including a form with a link to the WSDL file. The system also allows

users to select recently used Web Services. Figure 54 shows a screen mock-up of this page.

Figure 54: User Interface - Initial Page Mock-up

Operation Page

Having provided a link to a WSDL file, the webpage allows asks users to select the function that they

wish to use, as shown in Figure 55.

Figure 55: User Interface - Operation Page Mock-up

The page shows a history of the user’s past actions, allowing them to quickly reverse any decisions in

the event of a mistake. In Figure 55 the users only previous action – entering the WSDL files address –

is shown at the bottom of the screen, and they are given the opportunity to alter it if they wish. As

the user goes further into the system this list of past actions will stack up at the bottom of the screen.

Invocation Page

This page allows users to enter parameters for the service and operation they wish to invoke. It is

currently not functional in the prototype, so Figure 56 shows a hard-coded example. It shows a form




Page | 119

for an operation requiring three parameters: a string, and two Person objects. These Person objects

must first be instantiated, so the system provides the user with a choice of constructer to use. Having

chosen a constructor, they will be able to add the values required for this constructor, such as a name

and age.

Figure 56: User Interface - Parameter Entry

The final system will allow for the dynamic composition of Web Services. This will initially involve the

inclusion of another text-based option for linking to other Web Services, but could be expanded to

allow graphical composition (drag-and-drop) of Web Services. At this stage this is only a secondary

goal.

Design Considerations

The design of the interface has been influenced by the cognitive dimensions - a set of design

principles for analyzing systems with a view to summative and formative evaluation. The framework

defines a number of dimensions that can be used to analyze systems. These include:

Hidden dependencies: These exist where important links between entities exist but aren’t visible. A

good system should make it obvious where hidden dependencies exist, and explain the consequences

of changing one of the entities. Relevance to Project: As shown in Figure 42 , the users’ model of the




Page | 120

system is markedly different from the system model. The user must be aware of the effect of their

actions on data, where their actions could cause unexpected effects.

Secondary Notation: Used to describe extra information not part of the formal syntax. Secondary

notation can be used to clarify pieces of functionality, by extending the semantics given by the

primary notation. Relevance to Project: The system is being defined with usability in mind, and correct

use of secondary notation helps towards this goal.

Visibility: Refers to the ability to see components clearly. In systems it is important that particular

aspects of functionality are visible when they are required, and not hidden away. Relevance to

Project: Available actions and operation are always displayed, as shown by the list of past operations

in Figure 55.

The system will be analysed with other dimension, not described here. It is hoped that by using these

criteria the effectiveness of the systems interface will benefit, helping to achieve the projects usability

goals.

Current Progress

Part of this design has already been implemented in an early prototype. It is currently possible to

invoke any Web Service from a temporary command line interface, which is directly connected to the

back-end server. The system can cope with Web Services that have the following types of parameters:

Primitive Types

Arrays

Enumerated Types

Complex objects to an arbitrary depth

The system is capable of supporting complex types (defined in a service description), that contain

further complex types, arrays and enumerated types within them. Input for these functions is

obtained recursively, reducing the amount of repetition in the code-base.

An initial prototype of the web-based interface has been created, and can communicate with the

server over AJAX. However it is not possible, as yet, to invoke services from the Web-based interface.




Page | 121

Appendix D: Status Report Equation 1




Page | 122

Status Report

This appendix summarises the status of the delivered software.

Overview

YaWSA is functionally complete with respect to the original project objectives. It allows users to:

Interactively compose and invoke services irrespective of the required parameters.

Store the results of services

Store the structure of services

Re-use stored results and compositions.

YaWSA also provides:

Comprehensive help documentation in a separate help section

An introduction to middleware, Web Services, and the YaWSA system

A set of three use cases that can be browsed in an individual page, and during invocations in a

special help box.

All of these features and functionality has been tested and proven to work.

Software

The system makes use of the Java Dynamic Compiler to compile proxy files at runtime. Dr Graham

Kirby helped to fix problems with this component if and when they impeded development.

User Manual

The system has an extensive help section on the YaWSA web-site. It has not been reprinted in this

document.

Web-page

The system meets the requirement of providing a project website with details on the project. As it is

itself web-based this information is included in the help section of the YaWSA servlet.




Page | 123

Appendix E: Testing Summary Equation 2




Page | 125

testGetAvailableServices

Tests that the system is able to perform reflection to find a service’s operations.

testSetFunctionToCall

Tests that the system is able to set the function to be called, checking that it exists.

testSetParameters

Tests that the system is able to set the parameters to be used in a call.

testInvokeService

Tests that a service can be invoked given correct parameters.

testGetServiceName

Tests that the system can perform reflection on the proxy classes.

testRequiredParameters

Tests that the parameters the system requires are correct for the given service.

testIsProxyGenerated

Tests that the system correctly checks whether a proxy has been generated.

ProxyGenerator class

The ProxyGenerator class is responsible the generation and compilation of proxy classes on the

system.

testGenerateProxy1

Test generating a proxy for a given service.

testGenerateProxy2

Test generating a proxy for a non-existent service. Should throw an exception.

testDisplayProxyInformation

Tests the system’s ability to output information about a give proxy. Should pass.

testFindServiceMethods

Tests the system’s ability to find services in the proxy.

testGetEmitter

Test the ability to get the emitter object, responsible for generating these proxies.




Page | 126

Interaction class

This class is responsible for handling sessions with respect to service wrappers.

constructInteractionWrapperNull

Checks that the system throws an exception if instantiated with a null wrapper object.

testGetServiceID

Checks that it’s possible, via an interaction object, to get the ID of a service.

testSetChosenOperationValidOp

Tests that it’s possible to set the operation to be called if the operation is valid.

testSetChosenOperationInvalidOp

Tests that it’s possible to set the operation to be called if the operation is invalid.

testRestoreSession

Tries to restore a browser session. This should pass, not throw an exception.

CurrentUsers class

Tests the system’s sessions handling for users.

testAddUser

Attempts to add a user to the session. Should be successful.

testCurrentUsers

Attempts to get a list of current users and checks for a user who should be there.

PrintDetails class

Tests the system’s ability to reflect on classes to get their contents. These methods test the class on

the types they are named after:

primitiveInput

arrayInput

webServiceEnumInput

ComplexInput

typeDescriptor

Store class

The store class is responsible for storing objects. These methods test its ability to add then retrieve an

item respectively.

testAdd




Page | 127

testGetForID




Page | 128

Evaluation Sheets

These sheets contain the results of a user survey carried out prior to completion of the project. Many

of the comments obtained from this survey were used to improve the YaWSA system.




Page | 129




Page | 130




Page | 131




Page | 132

YaWSA: Final Project Report

Documents

Transcript of YaWSA: Final Project Report