Based on service-oriented architecture described previously, we have developed a framework that permits automatic service composition and verification through testing. The functions of the framework include browsing and downloading existing components, and combining components to form a desired application. In addition, it supports automatic testing by automatically synthesizing test plans based on user-provided test cases. Figure 5 below shows the screen shot of our framework:
Figure 5. Screen shot of our framework
To illustrate various functionality of our framework we will use a motivating example below. Consider an audioplayer application domain that is similar to the e-book application domain described in previous chapters.
First, to establish the audioplayer application domain, one need to determine what kinds of artifacts should actually be deployed. In this example, it is assumed that software artifacts are Java classes; hence they assume the existence of a JVM and some core libraries such as Swing library on the user’s machine. Unlike other deployment standards such as OSGi, our
framework does not limit the types of artifacts to be deployed. For example, it is possible to design different application domains which include Web pages or other multimedia resources.
To distinguish different classes of artifacts recognized and managed by our framework, the domain initiator need to indicate which Space the domain artifacts belong to. A space in our framework is basically an artifact manager that recognizes a special class of artifacts and manages them accordingly. Figure 6 below shows a list of spaces that our framework recognizes.
Figure 6. Space manager
For our audio player example, we assume a simple Java space where classes and other relevant resources such as audio files, icons, and so on are recognized. Figure 7 depicts a specific audio player instance consisting of three major entities: Database, Player and Browser. Database stores the music resources; Player plays the audio resources stored in Database; Browser is the main user interface providing usual audio player operations.
Figure 7. An audioplayer application example
Figure 8 illustrates a component composition by an average user using a template.
According to the template that may be provided by some organizations or service providers, the user can simply choose the components whose types are constrained by the template. As Figure 8 shows, there is an Aduio.org organization, and it defines three public interfaces for implementation. There are three companies: Company A provides an AudioJavaBrowser component implementing the interface IAudioBrowser, and BuddhaDB implementing the interface IAudioDB. Similarly, Company B provides AudioXDBrowser implementing the interface IAudioBrowser, as well as LabDB implementing the interface IAudioDB. Finally, Company C just provides an AudioPlayer component that implements the interface IAudioPlayer.
Music Database
Audio Player
Browser Database
Player
Figure 8. An audioplayer template for average user
The actual metaphors that describe the inter-relations among these different types of artifacts are explained below. First, we show the metaphors that represent the public interfaces below:
In the metaphors above, the m:uri attributes indicate the global URIs of the public interfaces, respectively. What these interfaces imply are outside the scope of metaphors. In this case, their semantics should be consulted based on their corresponding documents indicated in the doc elements, respectively.
Com B
With these public interfaces, templates for specific audio players can be created.
Consider the template below:
<AudioPlayerTmpl>
<m:rel name=”player” m:uri=”//Audio.org/IAudioPlayer”/>
<m:rel name=”browser” m:uri=”//Audio.org/IAudioBrowser”/>
<m:rel name=”db” m:uri=”//Audio.org/IAudioDB”/>
<main class="code.audioplayer.AudioPlayerFrame"/>
</AudioPlayerTmpl>
The template suggests that we can simply choose suitable implementations and plug them together to make up an audio player. The “class” attribute of the main element in the template indicates that there exists a Java class implementation (that is, code.audioplayer.AudioPlayerFrame) in the user’s environment such that for a given instantiation of the template, a corresponding Java object can be instantiated, which will then contact other component services supplied in the template instance. For example, the template instance below shows that a service (instantiated based on) AudioXPBrowser from Com B, BuddhaDB from Com A, and AudioPlayer from Com C are used to fulfill the required parameters of the template: IAduioBrowser, IAudioDB and IAudioPlaye.
<myAudioPlayerFrame>
<m:is m:uri=”./AudioPlayerTmpl”/>
<player m:uri=”./myAudioPlayer”/>
<browser m:uri=”./myAudioXPBrowser”/>
<db m:uri=”./buddhaAudioDB”/>
</myAudioPlayerFrame>
<m:is m:uri="//Audio.org/IAudioBrowser"/>
<main class="code.audioplayer.ui.AudioXPBrowser"/>
Consider another case where the user is skilled enough to develop their own components in Java, and just uses one or more external components from other companies. For example, as shown in Figure 9, the user develops MyBrowser and MyPlayer, and chooses BuddhaDB from Company A that implements the IAudioDB interface.
Figure 9. An audioplayer diagram for skilled user
After composing components, we have to test the composition. As mentioned previously, automatic testing can also be supported when creating a particular application domain so that it becomes possible to verify the correctness and conformance of individual components as well as their composition. Below we use the same audio player application domain to illustrate our testing framework implementation.
Consider the testing related concepts depicted in Figure 10 that are part of the audio player domain.
Figure 10. An audioplayer testing diagram
In the figure, there is an organization Test.org which defines the standard concepts TestPlan and TestCase related to testing. There are also two companies Audio A and Audio B who participate in the domain and provide test cases TestPlayer and TestDB, respectively, that implement the interface TestCase from Test.org. Furthermore, suppose by implementing the TestCase interface it means that the test case can be used to test individual or some combination of components whose types are indicated in the “SUT” (System Under Test) attributes of its “needs” elements. For example, the TestPlayer test case from Audio A shown below indicates that it can be used to test components of IAudioPlayer type:
<TestPlayer m:uri=”//AudioA/TestPlayer”>
<m:is m:uri="//Test.org/TestCase"/>
<java class="AudioA.test.TestPlayer"/>
<needs SUT="//Audio.org/IAudioPlayer" as=”player”/>
...
</TestPlayer>
It is not difficult to see that the corresponding metaphor denoting TestCase looks like:
<TestCase m:uri=”//Test.org/TestCase”>
<m:elem tag=”java”>
<m:attr name=”class” type=”String”/>
</m:elem>
<m:elem tag=”needs” card=”*”>
<m:attr name=”SUT” type=”URI”/>
</TestCase>
Note that unlike the previous examples where the requirement of Java implementation are not implied, here to automate testing, TestCase also imposes the requirement that any test case should be implemented as a Java class, so that related test cases designed for specific SUTs can be gathered automatically by the framework and corresponding test plans can be synthesized and executed automatically. Below shows a simplified test case implementation in Java that helps illustrate our approach.
public class TestPlayer extends TestCase { public void runTest() {
testAuthor();
}
public void testAuthor() {
IAudioPlayer player = getPlayer();
assertNotNull(player.getName());
}
private IAudioPlayer getPlayer() {
return (IAudioPlayer)getContext("player");
} }
The Java implementation above also indicates that when a test case is executed, it will obtain the SUT it runs against from its execution context, by supplying a pre-defined name (i.e. “player”) that is also specified in the TestPlayer metaphor.
To perform testing, test plans need to be created first. A test plan is essentially a file describing the set of components and different but feasible combinations among them for testing. Because the number of combinations can be quite large, our framework can assist user to create test plans based on the components he/she is working on. Below shows an example test plan using the audio player example above:
Figure 11 TestPlan diagram
In this example, there are three test cases: TestPlayer, TestDB and TestDBPlayer, and four SUTs: AudioPlayer with ID 0, OlderPlayer with ID 1, LabDB with ID 2 and BuddhaDB with ID 3. TestPlayer just needs an IAudioPlayer type SUT, and it will test the players with ID 0 and 1. The setup is similar for TestDB. However, TestDBPlayer needs two kinds of SUTs, i.e. IAdudioPlayer and IAudioDB, so it needs to consider all combinations among available SUTs. A possible test plan is shown below, which depicts the four SUTs with their corresponding IDs: AudioPlayer, OlderPlayer, BuddhaDB and LabDB.
<testplan>
<suts>
<sut id="0" m:uri="/local/java/AudioPlayer"/>
<sut id="1" m:uri="/local/java/OlderPlayer"/>
<sut id="2" m:uri="/local/java/BuddhaDB/"/>
<sut id="3" m:uri="/local/java/LabDB/"/>
</suts>
...
</testplan>
The produced test plan is shown below:
Figure 12 An example test plan
As an example, the test plan above indicates that the testcase TestDBPlayer has to run four times. For example, the run1 in TestDBPlayer will use the player with ID 0 and the database with ID 2. The output after executing the test plan is given below:
Figure 13. Results of a test plan execution
Chapter 6. Discussion and Related Work
We have implemented the SOA and the testing framework based on the popular Eclipse platform [4]. Here we summarize some of the important features of our implementation without going further into details:
z All resources, including metaphors, are managed as files and organized as Eclipse-managed projects. It is possible that some metaphors may be invalid at a given point it time, although the user can perform various consistency checks periodically.
z Deployment is achieved through Eclipse’s built-in version control system (i.e. CVS).
Because public resource registries and repositories are also projects downloaded into user’s workspace, our SOA does not require additional communication protocols for service discovery and deployment.
z Except the metaphor mechanism and file-based storage for resources, the SOA is generic with respect to allowable resource types. For example, Java-based and C-based software artifacts can co-exist within the same SOA, so are two different testing frameworks for the same types of Java-based artifacts.
z Our testing framework implements both Java-based and scenario-based test scripts.
Java-based test scripts are implemented as JUnit test cases plus the associated metaphors describing their required service types to facilitate automatic testing. As discussed in the previous chapter, some test scripts can be generic and considered part of the public contract that service implementation should conform to, or vendor-specific and may be bundled with particular implementations.
Scenario-based test scripts are conceptually similar, except that they express the expected input/output or message exchanges using XML, thereby providing a more technology-neutral framework.
The vision of UVW is inspired by the concept of “intercreativity” envisioned by Tim Berners-Lee [5] when architecting WWW [6], where people collaborate by creating and posting Web contents for others to see. This together with the emerging service-oriented computing trend have led us to the conclusion that Internet is transforming into a common
medium for people to participate in, rather than just a consumer-producer platform where most people are restricted to access information and services provided by software developers.
An important reason we believe WWW will be a good model for extension is not just because of its ubiquity, but also because of its architectural simplicity that helped propelled the Web. This is reflected by the service space underpinning our SOA that differentiates our approach from existing ones. One advantage is that our SOA can support diverse application domains and distributed computing technologies on a community basis, which is a fundamental requirement for UVW. As the e-book example suggests, for example, resources available for composition are not limit to Web services, and can also include downloadable Java classes that run locally and interact with end users via GUIs. From this perspective, our SOA combines the concepts from “server-side” distributed computing technologies and the
“client-side” deployment frameworks that are common in modern Web browsers or operating systems. Similarly, our SOA can also support “light-weight” application domains such as P2P file sharing that may not require too much infrastructure overhead. Unlike WWW, however, our SOA is more of a distributed computing platform holding software artifacts and services, and permit service composition.
Virtualization has been one of the fundamental principles underpinning computer science and information technology, as seen in many research areas including programming languages, operating systems, etc. Virtualization of distributed, heterogeneous resources is recently re-signified by the grid computing [7, 8, 9] research and closely related peer-to-peer computing. One major goal is to utilize otherwise idle, disparate computing resources by joining them into workhorses that approximate super computers. Furthermore, the concept of virtual organization also stresses that the primary emphasis is on effective utilization of distributed resources across organizational boundaries while respecting the authority and policies of individual organizations. This is what differentiates grid computing from distributed operating systems research.
myGrid [10] is one of the famous open source Grid applications that aim to provide a high-level service-oriented middleware to support in-silico biological experiments.
Interestingly, myGrid includes the Taverna workbench as one of its core component, which allows biologists, rather than developers, to create workflows connecting third-party Web services via more intuitive, graph-based user interfaces. The workbench supports individual
scientists by providing personalization facilities related to resource selection, data management and process enactment. Figure 14 illustrates myGrid Taverna workbench. On the top-left, it shows available services for use. User can choose the desired services, add them to the workflow diagram, and set the process between services to compose a workflow with graph-based user interface.
Figure 14. myGrid Taverna workbench
The workflow can be saved as XML-based description, which is illustrated below:
<s:scufl xmlns:s="http://org.embl.ebi.escience/xscufl/0.1alpha"
version="0.2" log="0">
<s:workflowdescription
lsid="urn:lsid:net.sf.taverna:wfDefinition:544956f5-42dc-47e3-bbca-d4 ffcec13f0b"author="" title="example"/>
<s:processor name="OutputData1">
<s:arbitrarywsdl>
<s:wsdl>http://eutils.ncbi.nlm.nih.gov/entrez/eutils/soap/eutils.wsdl
</s:wsdl>
<s:operation>run_eSearch_MS</s:operation>
</s:arbitrarywsdl>
</s:processor>
<s:processor name="calculate">
<s:description>RENCI impl for blast service</s:description>
<s:biomobywsdl>
<s:link source="InputData:result" sink="calculate:input" />
<s:link source="OutputData1:parameters" sink="Result1:first_url" />
<s:link source="OutputData2:parameters" sink="Result2:sbegin" />
<s:link source="calculate:output" sink="OutputData1:parameters" />
Recently, this trend in user-centric, collaborative computing has gained some momentum.
Consider the widespread use of Web applications such as blogs and Wikipedia [11]. These applications provide easy-to-use interfaces that allow people to create contents such as opinions and photos for others to see. Equally importantly, they provide storage and content management facilities under the hood. Although the user interfaces are often limited (for ease of use), these applications already provide sufficient functionality people want. As a result, the simplicity helps these applications gain huge user base in a short period of time, which is often attributed by Web 2.0 [12] promoters as network effect.
Web 2.0’s emphasis on sharing and collaboration among end users, not developers, coincides with our view. On the other hand, the tendency of Web 2.0 application developers to centralize their proprietary implementation behind (high-performance) servers – a key characteristic for Web 2.0 companies to stay ahead – is in contrast to our UVW goal. As a result, Web 2.0 does not consider too much about a common computing infrastructure, or about the assembly of third-party modules, and the issue of software deployment and maintenance are considered irrelevant.
Our approach to describing and interpreting resources via metaphors provides a composition framework that promotes domain-specific, language-based component reuse, in the sense that new types of resources are conceived with corresponding languages defined and interpreters developed. Specifically, in the resource space, new resources can be created for a given domain (generic or domain specific); in this case, custom language syntax can be defined for the customization of a certain class of resource. In the service space, new communities or domains can be created by equipping containers with differentiating interpreters. The access interface to the container, the composition mechanisms, and the corresponding assembly languages are all extensible.
In short, our approach to composition is syntax-based in nature. This is in contrast to most AI-based composition approaches, e.g. the Semantic Web [13, 14] movement and related models such as OWL-S [15], where the main focus is on the development of languages for describing the properties and capabilities of Web services in unambiguous, computer-interpretable form, in order to facilitate automatic reasoning, negotiation, and dynamic integration of Web services.
Our approach also differs from another popular trend, i.e. workflow-based service composition (e.g. WS-BPEL and W3C CDL), which emphasizes on support for cross-organization business processes that are crucial in the coming e-commerce era.
Nevertheless, most workflow-based approaches are “server-side” technologies targeting developers and service providers. In contrast, the UVW unifies the server side and the client side, where end users and developers are among the many groups of people in the potentially complex ecosystem. In other words, the UVW can be characterized as a global, integrated development environment supporting “programmers” of various skills and needs.
This software engineering perspective also highlights many important factors that are missing in current AI-based or workflow-based composition approaches. For example, evaluating whether a service performs its duty as it claims to, or managing the versions of component services in a composite service are often beyond the scope of these composition approaches, but are still within our scope.
As another example, one important issue related to service instantiation and management is deployment. Deployment mechanisms are also an important area that receives many research and development efforts recently. Popular Web browsers, for example, often provide
plug-in mechanisms that download executable resources such as Java Applets or Flesh applications and manage them behind the scene for the user. Other deployment mechanisms outside the Web arena are also common; examples include the plug-in architecture of the popular Eclipse IDE, or the Java-based middleware OSGi [16] for component integration, or the Maven project that streamlines software building process by acquiring required libraries across network based on project profiles.
The OSGi Service Platform provides a general-purpose Java framework that supports the deployment of applications (called bundles) and provides the functions to change the composition dynamically without restarting. A bundle comprise of Java classes and other resources such as manifest file describing the information about the bundle to provide functions (services) and to be exported as Java ARchive (JAR) files are the only entities for deploying Java-based applications. A bundle can contain zero or more services and be downloaded, installed, updated and removed in an OSGi environment. A service published in a bundle can be searched and installed in OSGi environment by other bundles for exploiting.
Take the Knopflerfish project for example. Knopflerfish is a non-profit organization and aims
Take the Knopflerfish project for example. Knopflerfish is a non-profit organization and aims