An Abstract Service-Oriented Architecture

We propose a service-oriented architecture aiming at fulfilling the VW requirements described in the previous chapter. As shown in Figure 1, the architecture rests on a resource space in which resources are arbitrary artifacts identified with globally unique URIs.

Different types of resources may contain information in binary or text forms. Because some resources such as Web pages may embed references to other resources, the resource space hence forms a global, interconnected resource network, much like the hyperlinked WWW.

For the purpose of this thesis, it is sufficient to regard each resource as a file hosted inside a network addressable machine.

Figure 1. A service-oriented architecture

On top of the “persistent” resource space is the dynamic service space comprise of mutually interacting run-time objects, called services, which perform tasks upon requests.

More importantly, each service is associated with exactly one resource, although the reverse is not necessarily true. Resources are partitioned into disjoint sets with respect to the authority component of their URIs, and a partition may be associated with a manager service, called container, which governs the definition, instantiation, customization, composition, and other lifecycle activities for the services within the partition. Note that although a container itself is also a service and hence is associated with a resource, how the container is instantiated is considered system-dependent.

Within the service space, it is possible that a service can access another service directly if both are in the same memory space; otherwise some kinds of communication channels should be established between them. In either case, the container is responsible of establishing suitable links among the services in question, rather than allowing the managed services to

establish links on their own.

Containers can be implemented differently, and they join and leave the service space continuously. Containers can be long running at server side accepting requests, or transient at client side interacting with users. A container may offer different levels of management capabilities to different classes of users – although there are basic operations all containers need to support.

To complete the architecture, we refer to clients that serve as intermediaries between end users and the services as agents, which are not managed by containers. Note that some agents and services may be equipped with GUIs interacting with users directly.

Chapter 4. Metaphors for resource modeling and composition

4.1. Metaphor Format

In the service-oriented architecture outlined previously, it is required that services are instantiated based on the resource contents. Containers are responsible of interpreting the resource contents and determining what services to create and how they are customized.

When references to other resources are embedded inside a resource, the container may establish required connections among the respective services, according to the implied semantics implied by the resources (see below)..

Although resource interpretation and composition are container-specific or even proprietary, to increase the overall reusability and interoperability and to minimize unnecessary fragmentation, it is required that there exists a canonical resource description format to define new resources or annotate existing ones. These resource descriptors, called metaphors, are syntactical objects with structures derived from the contents of the resources they describe, respectively. A further requirement is that it should be possible to

“syntactically” check a particular resource composition in a semantics-neutral manner, before actual run-time composition takes place.

Naturally, we choose a subset of well-formed XML documents as the canonical metaphor representation . In general, a metaphor can contain arbitrary structure without restrictions.

However, we allocate a special namespace with some reserved elements and attributes. These meta-level constructs can be embedded inside metaphors and are used to constrain their structures without semantic implications. For simplicity, in what follows the prefix “m” is assumed to be bound to the meta constructs namespace. The reserved keywords are summarized below:

m:uri is an attribute whose value is a relative or absolute URI. When the root element of a metaphor has such an attribute, the value reflects the (intended) identity of the metaphor.

When such an attribute is absent in the root element, the identity of the metaphor should be inferred from the context. More importantly, in case the attribute occurs elsewhere, it always serves as a reference to another existing resource.

m:is is an element that occur only at the top level, and its “m:uri” attribute should link to

another metaphor - which we refer to as the type of the metaphor - that may contain additional contents and further constraints. When a metaphor includes a type this way, it not only inherits all contents from the type, but also should conform to the constraints imposed by the type. When the type contains other types, the contents and constraints are collected recursively. In addition, when a metaphor contains multiple types, it should conform to all the constraints implied. As constraints may conflict with each other, we only consider valid types such that their inferred constraints do not conflict. In addition, metaphors trying to conform to conflicting types are considered invalid.

m:rel is also an element that occur only at the top level and is used to constrain the allowed links among metaphors. Syntactically, it states that the enclosing metaphor can have a certain number of child elements of a particular tag in its top level. The tag name and the multiplicity are prescribed by the “tag” and “card” attributes, respectively. Furthermore, the

“m:uri” attribute also constrains the type of the metaphor can be linked to.

The m:elem element constrains the contents of metaphors. It states that a conforming metaphor can have child elements with element name specified by the “tag” attribute and their number of occurrences specified by the “card” attribute. The m:attr child elements, if any, also indicate the allowed attributes and their value types. In addition, m:elem can be declared recursively.

In other words, metaphors together form an ontology, or more precisely, multiple but possibly overlapping ontologies within the VW. Depending on the situations, precise semantics for a given ontology can also be defined in a foreign way. Metaphors can be created to annotate other actual resources, or they can be the resources themselves. In fact, is common to create metaphors to capture high-level concepts without explicitly describing their semantics, and use them immediately to annotate other existing resources. Unlike schema languages such as DTD and XML Schemas, metaphors mix meta-descriptors, links, and data contents together. Our goal is to confine ourselves to a subset of well-formed XML elements that are simple, sufficiently expressive, extensible, yet easy to check for consistency and validity. Therefore, we do not follow existing ontology languages such as RDF and OWL.

resources. Consider a scenario in which a developer wishes to document the design patterns used in his/her design, which may be embedded implicitly in the implementation source code.

Suitable schemas can be created for various design patterns, respectively. The example below shows a possible schema definition that characterizes the Abstract Factory pattern [8].

<m:rel tag="factory" type="/java/AbstractClass"/>

<m:rel tag="product" card="1..*" type="/java/Interface"/>

<m:rel tag="concreteFactory" type="/java/AbstractClass"

<m:rel tag="concreteProduct" card="*" type="/java/Class"/>

</AbstractFactory>

The example below shows an application of the Abstract Factory pattern that conforms to the schema defined previously:

The example above is simple-minded because inconsistency can occur. However, for documentation purpose it suffices and the user is responsible of ensuring the consistency. On the other hand, more sophisticated schemas can be designed to fix potential conflicts, by introducing additional schemas. Also, more sophisticated GUIs to help developers create and maintain schemas and annotations can be supported.

As mentioned previously, there are some common protocols containers need to support.

Here, specifically, all containers need to reply the metaphors of the resources they manage.

Accordingly, it is straightforward for people to publish their own ontologies for the problem domains that concern them. On the other hand, public ontologies can also be created and maintained on a community basis so that containers or service developers joining the same community can interoperate and communicate.

4.2. A Component Model for Resource Composition

Because service composition is done through metaphor composition, our architecture serves not only as a distributed computing platform but also as a global software development environment. Because metaphor syntax and semantics are domain- and container-specific, there is no restriction about how services should be instantiated, assembled, or managed, except that the containers perform these tasks based on the semantics intended by the metaphor designers. This feature is essential to fulfill the requirement that the platform can

support users of varying degree of skills. However, reusability and interoperability can be compromised when, for example, multiple, overlapping but incompatible languages are created.

What we want is a virtual component assembly platform that promotes component reuse.

We adopt a component model that “encourages” manager-worker separation by ensuring that components are workers who concentrate only on the work they are designed for without worrying about how their supporting “colleagues” are created and accessed – all these tasks are the responsibility of the manager, thus making components more focused and reusable. As shown in Figure 2, a component is encapsulated inside its interface through which clients can interact with. The interface can further be divided, at least conceptually, into primary and customization interfaces. The former represents primary function the component provides, while the while the latter is used for configuration purpose before or when the component becomes functioning.

Note that the notion of component is abstract and is applicable not only to individual services, but also to groups of services. A composite component can be modeled as a set of collaborating services. Accordingly, the internal of a component is also divided into two parts – the subcomponents being used, and the connecting substance among these components.

Naturally, we refer workers to the former while managers to the latter. Workers are well encapsulated and unaware of the actual functionality of the containing component.

manage Customization

workers

Interface

consists of basic components FileSystem, FileTreeView, and FileView. Related templates are

<m:rel tag="root" m:uri="/java/File"/>

</FileSystem.tmpl>

<m:rel tag="filesys" m:uri="/fs/FileSystem"/>

</FileTree.tmpl>

<m:rel tag="fileSys" m:uri="/fs/FileSystem"/>

</FileView.tmpl>

<m:attr name="style" type="String"/>

</m:elem>

</Layout.tmpl>

Templates can be defined by developers or experienced users, even during run time.

Once accepted by the container, instances of templates can be created. To compose a file browser at run time, for example, the following metaphors need to be created in proper places and conform to the templates stated above:

<m:is m:uri="/gui/Layout.tmpl"/>

</layout>

The composition example above only instantiates components and arrange the layout of the GUI ones. There is no connection among components. In this example, what is needed is that selection of a tree node in the FileTreeView component should cause the included FileView component to read data from FileSystem and display it. To achieve the goal, some rule-based composition logics can be supplied. For example, the instantiation of FileTree above is augmented with such rules, which essentially say that whenever FileTree responds to

change of selection from the user, it will issue a metaphor event (of some type published elsewhere), and the rule-based composition simply pattern matches the event and issue commands to other components.

Without going further into the details about the syntax and semantics of the composition format, which is application- and domain-specific, Figure 3 shows the result of such composition.

Chapter 5. Case Study: An e-Science Workbench

We have been developing an e-Science workbench as a proof of concept for the VW goal.

The system is part of our efforts to develop a service-oriented infrastructure uniting heterogeneous, disparate computing resources across the Internet. The initial goal of the e-Science workbench is to develop a service-oriented version of an existing Matlab-based data analysis toolkit used by the Brain Research Center of NCTU. In the beginning, a single-machine version is developed. The required computing resources include Matlab [9]

for its basic computational support as well as the toolbox EEGLAB [10] developed by UCSD.

To wrap the Matlab computing power, as our implementation is Java-based, we use the open-source library, JMatLink [11], to work between the container and the Matlab engine.

5.1. The Workbench Architecture

The architecture of the e-Science workbench is depicted in Figure 4. As shown in the figure, one important objective of the system is to support multiple types of user interfaces for users to access the same set of resources and to perform flexible, dynamic service access, customization and composition.

Rich Client

Thin Client

VOS Core

VOS Core UI Service

Figure 4. An e-Science workbench overview

Behind the user interfaces are a set of collaborating containers hosting various types of computational and storage resources. Although the containers form a P2P network, each

container may provide different set of resources. That is, each container may allow its user to define and create new resources in a way depending on the available administration interfaces provided by the container.

More complex analysis flow can be grouped into workflows in the e-Science workbench, and the processing logic can be performed by some workflow engine services. Workflows are in fact an important form of composition (i.e. process-oriented composition), especially in business context.

A workflow consists of multiple tasks that are interrelated with each other via control flow and data flow, in a form similar to common programming languages. In our case, workflows are expressed as XML documents with corresponding run-time workflow services.

The enactment of a workflow is encapsulated in a process that contains the workflow instance and a scheduler, in which the process is responsible of maintaining the progress of the workflow while the scheduler decides which task processor a task is assigned to whenever the task is ready for processing. All these elements, that is, workflows, workflow instances, processes, schedulers and task processors are resources with corresponding metaphors in our system. A simple echo process is illustrated as follows:

<echo.proc>

<m:is m:uri="//meta/java/JavaObject"/>

<m:is m:uri="//meta/service/Process"/>

<scheduler

m:uri="/bci/test.ps/go/grid/scheduler/simple.scheduler"/>

<m:child name="echo">

<echo.fi>

<m:is m:uri="/task/FlowInstance"/>

Note that what the metaphor states is that when the container interprets the resource and recognizes that it is a type identified with URI “//meta/java/JavaObject”, it can instantiate a Java object – the service associated with the resource – using the class named

“cclab.grid.core.GridProcess” obtained from the metaphor content. The metaphor identified

When the service associated with the echo process resource is created, it needs two component services; namely, the flow instance and the scheduler, which are indicated below.

The flow instance in turn requires a workflow. All the references are represented as related URIs.

<simple.scheduler>

<m:is m:uri="//meta/service/Scheduler"/>

<m:is m:uri="//meta/java/JavaObject"/>

</simple.scheduler>

<echo.fi>

<m:is m:uri="/task/FlowInstance"/>

</echo.fi>

<echo.flow>

<m:is m:uri="/task/Flow"/>

<flow>

</task>

</task>

</flow>

</echo.flow>

As also being indicated above, a workflow may contain several tasks that are mutually related. Each task in the echo workflow above is associated with a task type that contains a set of parameters bound to the workflow’s variable, and each of these parameters can be an input parameter, output parameter, or in-out parameter. You can assign a task processor for each task in the workflow, or a scheduler will assign one automatically according to its internal scheduling policies and algorithms.

Figure 5 shows the class diagram describing our implementation of the task type. In short, new task types can be created as Java classes that implement the ITaskType interface.

Metaphors denoting these task types can be created afterwards and referenced in flows.

Whenever a task is ready to proceed, the task type (service) will take all the input (XML) parameters passed from the process, process the inputs, and return (XML) outputs back to the process. The bindings of flow variables with the input/output parameters are indicated in the flow and handled by the process.

ITask

Figure 5. Tasks and task types.

5.2. Console User Interface

The text-based console interface is in fact the required interface because it permits many advanced and privileged management tasks, such as the creation of metaphors. To illustrate the use of the console, we consider an experiment that uses single-trial event-related potential (ERP) to recognize different brain potentials with five degrees of drowsiness. We will show how to design a resource relative to a function in the experiment with metaphor and its interpreter and then use workflow to composite the resource to perform the entire experiment.

With the support of JMatLink we can already perform the function of the experiment mentioned above, if we know the exactly correct command format for the function. But this will not be an acceptable and user-friendly user interface. With the workbench, we need to design metaphors for this basic function to increase reusability and user friendliness. Consider a basic function, called “loadset”, that is provided by EGLAB. Through JMatLink, the function can be invoked in Java as shown below:

JMatLink engine = new JMatLink();

engine.engOpen();

engine.engEvalString(“EEG = loadset(...);”);

To incorporate EEGLAB’s “loadset” function into our system, for example, we would like to have a service that handles requests in terms of XML (i.e. using XML as the standard message format) and translates them in the form recognized by JMatLink. A simple metaphor can be defined for the purpose:

在文檔中資源導向計算及虛擬工作環境的設計與實作 (頁 14-0)