Algebraic foundation of a data model for an extensible space-based ...

Algebraic Foundation of a Data Model for an Extensible Space-Based Collaboration Protocol Stefan Craß, Eva Kühn, Gernot Salzer Vienna University of Technology, Institute of Computer Languages

{stefan.crass, eva.kuehn, gernot.salzer}@tuwien.ac.at

ABSTRACT

and leave dynamically increases complexity. Such processes must be considered autonomous peers and coordination must therefore be distributed. We have learned from agent technologies [12] that in scenarios with high dynamics and where unforeseeable situations may occur, a blackboard based communication style is advantageous over message queues and publish/subscribe systems. In terms of a coordination platform this means that a medium is required, where processes can put and pick up information, and are automatically informed about events. Databases support data storage and access, but they have not been built to coordinate parallel and distributed processes. Coordination involves less complex data with the sole purpose to coordinate the interplay of processes; such data are on the move and short-lived. Especially, near-time notification about data changes and a blocking waiting for future changes is not possible without polling. Space-based computing middleware1 offers a data driven style for the coordination of processes. The value of shared data spaces is particularly founded in scenarios where autonomous processes need to collaborate in an ad-hoc manner, or where unforeseeable situations may occur [14]. A high degree of decoupling can be achieved using the spacebased architectural style where processes do not communicate by “commanding” each other via a method or service invocation, rather they use a shared data space as an intermediate where they put and get information and can be notified about changes. Or in other words, they have access to shared, synchronized, distributed data structures. At a first glance, a space resembles a database. Both have in common that they manage structured data and employ transactions. But the mission of a database is to administrate large amounts of persistent data and to offer complex querying capabilities on them, whereas a space is a middleware that serves to coordinate processes. The most widely known model of space-based computing is the Linda tuple space [8]. A widely used representative based on this coordination model is JavaSpaces [7]. We want to point out three problems with these technologies: (a) the tuple based data model is quite low level and the coordination law [5] is limited to template matching; (b) data model and access have not been formalized in a standardized way; and (c) interoperability between platforms is not supported. Coordination capabilities. In the Linda model, the basic data structure is a tuple being a sequence of typed fields. A space is a collection of tuples, comparable to records contained in a database table, but without any constraints on

Space-based computing middleware offers a data driven style for the coordination of processes. The interaction requirements between these processes can be complex, and the template matching coordination law of the Linda and JavaSpaces model is not sufficient. Moreover, the usage should not be limited to a single platform. Several authors have proposed coordination extensions, but besides the suggestion to use XML or RDF based query facilities, a formalization of a general and extensible space-based coordination model has not yet been realized. In this paper we present the algebraic data structures and the coordination model based on a navigational query language for the extensible virtual shared memory architecture, and show how they can be adapted to support arbitrary coordination laws by the introduction of user-definable matchmaker and selector functions. The platform independence is achieved through a language independent communication protocol. The formal specification of the data model is the necessary basis for this protocol.

Categories and Subject Descriptors C.2.4 [Computer-Communication Networks]: Distributed Systems; D.3.1 [Programming Languages]: Formal Definitions and Theory

General Terms Space-based computing

Keywords extensible virtual shared memory, data model, coordination, query language, tuple spaces, language independent protocol

1.

INTRODUCTION

The internet makes it possible to build applications consisting of many processes located at different computer sites and enterprises. The coordinated interplay of these processes is a complex task. The fact that processes may join Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IDEAS 2009, September 16-18, Cetraro, Calabria [Italy] Editor: Bipin C. DESAI c 2009 ACM 978-1-60558-402-7/09/09 $5.00 Copyright

1

301

http://www.spacebasedcomputing.org

them. Duplicate tuples are allowed. Collaboration means to insert data into the shared space, and to read, or to read and remove (consuming read) them from the space. The principle that determines which tuple shall be read is called template matching. A tuple must be given as template and is matched against the available tuples in the space. All information provided in the template – types and optionally also values of data fields – must match exactly, whereas undefined fields are interpreted as wildcards. The operation out adds one tuple to the space. With rd (or in, the consuming form of read) exactly one tuple can be retrieved from the space using a given template. Non-deterministically one is selected, which means that for rd there is no guarantee that a next read will deliver another tuple. In JavaSpaces the operations out, rd, and in relate to write, read, and take respectively. JavaSpaces defines a language binding and makes use of the Java serialization mechanism to write data into the space and to read them back into Java objects. A notify operation has been introduced which is a permanent subscription to the space, using the template matching mechanism. Template matching is not sufficient for the many demands on coordination. Alone, if a first-in-first-out ordering of the tuples in the space is required, it has to be implemented explicitly by adding sequence numbers to the data fields of the tuples. Therefore, many research works deal with extensions to the classical Linda model: LighTS [18] allows the user to implement the tuple class and the matching logic completely by him/herself, but still uses tuples as data model. XMLspaces [20] and Triple Spaces ([6, 17]) use XML respectively RDF data models, but still rely on the principle of template matching. Formalization. Many articles have been published on formalizing the operational semantics of coordination primitives in tuple spaces, using process algebras and process calculi: Klaim [16] is based on the π-calculus [15] and defines extensions for code and process mobility in Linda. In [4], notification, timeouts, and leasing concepts are specified. [2] and [3] prove that the expressiveness can be extended with tags for probabilities and priorities. Active XML [1], which is a framework for distributed data management based on XML and web services, has a formal model for its data structure and query language but it does not follow the space-based computing paradigm and thus lacks the flexibility of tuple spaces. A formalization of the data model and access semantics for extensible spaces is still missing which we consider an essential pre-requisite for a middleware to be accepted by industry. Platform interoperability. Both, Linda and JavaSpaces are defined as language bindings. GigaSpaces2 offers Java, C++ and .NET language bindings, but we do not consider this as platform interoperability as long as there is no specification of an open encoding and communication protocol. Only such a protocol will allow anyone to exchange the space server and to build adapters to arbitrary platforms. The contribution of this paper is an algebra and coordination model for a distributed shared memory system [11] called extensible virtual shared memory (XVSM) [13], extending the original tuple space model. Arbitrary coordination laws can be built on this general framework with minimal effort using a simple query language to match the 2

individual coordination needs; also template matching can be provided [10]. A further contribution is the definition of a layered architecture and an XML based protocol that defines all operations in a platform neutral way and should help XVSM to become an industry standard in the future. The runtime machine that processes the protocol requests is using the space operations itself for internal coordination, thus it is bootstrapped with own mechanisms. Section 2 gives a short overview of XVSM. Section 3 explains basic and XVSM specific algebraic data structures. Section 4 introduces the Core API and the language independent protocol. Section 5 presents the coordination model and its navigational query language. Section 6 shows a simple auction system as coordination use case. Section 7 summarizes the results and gives an outlook on future work.

2.

EXTENSIBLE VSM

XVSM [14] defines a generic approach to extend the coordination law, where the semantics are not arbitrarily left to the programmer. In addition, a structuring of the space into containers is introduced, because tuple spaces should be usable for larger programs that require a high level of abstraction; [9] defines a hierarchy of sub-spaces, whereas XVSM introduces internet addressable containers. A space holds shared data of collaborating applications, used to exchange information and to synchronize themselves. It can be embedded into the peer application, or run as a standalone server. A space consists of several structured containers that maintain data in the form of entries. A container is referenced by a unique URL which makes it accessible from applications running on local and remote computers. Similar to JavaSpaces, the elementary operations on containers include write, read, and take of entries. Containers can be bounded to a limited amount of entries. Thus, not only read and take, but also write may block, waiting until there is space in the container for the additional entries. In contrast to the Linda model which only provides template matching as coordination mechanism, XVSM introduces user-definable coordinators. They specify how new entries are maintained by the container and determine the entries to be returned by a read or take operation. They consist of query functions called matchmakers or selectors with optional parameters. A matchmaker is applied to one single entry of the container and returns true or false, meaning that the entry fulfills the matchmaker function or not. A selector is applied to an entire container. It returns a possibly empty, and possibly sorted (sub) collection of entries of the container that satisfy the selector’s criteria. Each container possesses individual coordination laws, determined by its coordinators. Thus, coordination via structured containers is flexible and extensible. In contrast to JavaSpaces, which are defined by means of a language binding, the “instruction set” of the XVSM core is provided as a protocol (XVSMP) with the advantage of language and platform interoperability. The XVSMP is completely asynchronous. On top of it any synchronous and/or asynchronous language binding can be implemented. A stable and useable open source Java implementation of XVSM has been built, proving feasibility and efficiency of the model. For more information on XVSM we refer to the open source (Java reference implementation) site3 . 3

http://www.gigaspaces.com

302

http://www.xvsm.org

3.

XVSM ALGEBRA

elements. The expression x.a may have two different values, either true or 42, of which one is chosen indeterministically.

This section presents the basic data structures of XVSM in a formal manner. The motivation for choosing this more rigorous approach is manifold. First, the formalization process itself helped in the design phase to detect under- or over-specified elements, forced design decisions, and led to simpler structures. Second, the formal definition serves as an unambiguous reference. Third, the formal model is a foundation and limitation, in the same way as tables and records are for databases. All data, including meta-data, has to be represented by the basic structures. Fourth, the abstract data model is a clear separation between high-level concepts like spaces and containers on the one hand and implementation issues on the other hand.

3.1

3.3

Collections of data

Algebra offers three elementary structures for aggregating data: sets, multisets (also called bags), and lists (also called sequences). From the computational point of view, multisets are the simplest structure of the three: data items may be stored and retrieved in an arbitrary manner, leaving room for optimizations like parallel access or indexing. Sets, on the other hand, place considerable burden on an implementation, since adding an element or computing the union of sets requires the removal of identical elements. In contrast, lists can be efficiently implemented by using linearly ordered memory or a linked list. Storing and retrieving data can be done in constant time. Baring in mind implementation costs and practical relevance – sets are frequently used in mathematics but are largely irrelevant in practice – we decided to incorporate lists and multisets into our basic data structure. To access and manipulate these structures we use the usual operations on lists and multisets, like union (x t y), set difference (x − y), cardinality (|x|), access to the head element of a list (first(x)) and the remaining elements (rest(x)), etc. To represent complex data it is necessary to nest lists and multisets, which requires some way to access the subparts of a data structure. Therefore we label data items by strings and use the labels for addressing the items. Formally, the elements of lists and multisets will have the form l:x, where l is the label and x is some data item. Empty labels can be used for anonymous properties that do not need an explicit label. As a matter of convenience, l:true may be abbreviated as l. Similarly, if x cannot be mistaken for a label, :x may be written as x.

3.2

XVSM Algebraic Types

This section introduces the types of xtrees that play a distinguished role in XVSM. Properties correspond to the attributes of an object. Each property consists of a name (label) and a value. Formally, properties are labeled xtrees. Entries are collections of properties. Basically an entry can have several properties with the same name and the same or different values. Formally, an entry is a multiset or sequence of properties, and hence an xtree. An entry may represent a real-life object (only data, no methods), a message, or a command. If an entry represents a message, its head could be modeled by several properties, as e.g. specified in the Java Messaging System (JMS) 4 , and its body could be modeled using the reserved property name payload. If the entry is a command, then further reserved properties could serve to model the command and its quality parameters. Containers store labeled entries, comparable to a database table. However, the entries may be linearly ordered, the fields may contain complex data, and the entries need not be of the same type. Formally, a container is a list or multiset of labeled entries. Spaces are multisets of labeled containers. A space consists of all containers located at a peer during runtime. Universes are multisets of labeled spaces. There is essentially only one universe U that contains all existing spaces. Meta data can be stored in meta properties of entry, container or space xtrees. These properties have labels with special prefix to distinguish them from regular data. Meta data can be used for internal coordination within the XVSM runtime.

4.

CORE API AND PROTOCOL

The data access is provided by so-called CAPIs (Core APIs) and modeled as several layers, starting with the algebraic access to the data structures up to the level of the XVSMP.

4.1

CAPI-1: Basic Operations

CAPI-1, the basic operation set of the XVSM core, is defined as the set of synchronous operations on the XVSM algebraic data structures (see Sect. 3) which either succeed or fail immediately. All operations are considered to run as atomic actions to avoid race conditions. This CAPI directly uses the data structures as arguments and changes them accordingly. The operations return an xtree with the properties result which stores the actual outcome if applicable, statuscode which can have any of the values OK, NOTOK or DELAYABLE, and optionally info for detailed error messages that specify the reason why the task failed. An OK status code means that the CAPI-1 operation succeeded whereas NOTOK indicates that it is not satisfiable at all. If an operation is not able to execute at the moment, but might be satisfiable in future invocations, a DELAYABLE status is set. The operations are write1, writeL1, read1 and take1. The first argument of each method specifies the xtree that needs to be changed or queried. The writeL1 operation writes an entry with a given label to the specified xtree,

Xtrees

Based on the discussion above we now define xtrees, the basic data structure of XVSM. They are inductively defined by: (i) unstructured values like the integers, reals, and strings are xtrees, (ii) multisets (denoted by square brackets) of labeled xtrees are xtrees, and (iii) sequences (denoted by angle brackets) of labeled xtrees are xtrees. A path is a finite sequence of labels and numbers separated by slashes. E.g., the xtree x = [a, a:42, b:hpi:3.14, e:2.17i, [c:0]] is a multiset containing four labeled data items: a:true and a:42 carry the same label a, the nested list is labeled by b, and the nested multiset is implicitly tagged with the empty label. To access substructures we use labels and numbers separated by slashes. In our example we have x.b = hpi:3.14, e:2.17i, x.(b/pi) = x.(b/1) = 3.14 and x.(b/e) = x.(b/2) = 2.17; note the use of the position numbers 1 and 2 to access list

4

303

http://java.sun.com/products/jms

4.3

whereas write1 uses automatically generated unique labels. When using read1 or take1, all contained xtrees that fulfill the specified query are returned and, in the latter case, also removed from the space. These simple methods, together with the powerful query facilities described in Sect. 5.1, can be used to write and query user entries within containers, but also to write and destroy containers themselves or to change meta properties, so every higher level operation can be bootstrapped from this basic operation set. The functions are based on basic algebraic operations as shown in the following examples for multiset containers.

For CAPI-4 there exists an XML based protocol called XVSMP that is available to implement adapters to different platforms. This protocol is used between the XVSM peers and translated into CAPI-4 within the target space runtime. The endpoints in the protocol are on the one side a request container and on the other side an answer container. XVSMP uses all CAPI-4 operations with the difference that no return value is used. Instead, an answer container must be specified where the result and the status information of the operation is written to. This answer container is usually a virtual one that does not really store entries but directly interacts with the adapter, but it can also be materialized which is useful for mobile devices that are not permanently online. An adapter can exhibit both synchronous and asynchronous operations via a callback function.

writeL1(xt, lbl, entry) xt := xt t [lbl:entry] return [statuscode:OK] take1(xt, query) (entries, errXT) = applyQuery(xt, query) if (errXT == []) xt := xt − entries return [result:entries, statuscode:OK] else (isValid, reasonXT) = satisfiable(xt, query) if (isValid) return [statuscode:DELAYABLE, info:errXT] else return [statuscode:NOTOK, info:reasonXT]

5.

XVSM COORDINATION

Containers in XVSM are customizable via coordinators that are specified at container creation time. These coordinators can either be built-in or user-defined. The coordinator implementation must specify two methods that are used by the CAPI. Firstly, an accountant function is called whenever an entry is accessed by a write, take or read operation to enable the coordinator to administrate necessary coordination data like indexes etc. It also checks if the coordinator allows the operation or if some internal constraint is violated. Secondly, one or more query functions can be specified which are used for read and take queries. These coordinator functions can be implemented via basic algebraic operations (see Sect. 3) together with simple control structures like conditional statements, loops and recursion. The accountant function may also store its internal data in separate meta properties within the container or entry xtrees. It must not, however, change the data properties of entries or the meta properties of other coordinators. Query functions can also consist of a composition of already defined matchmakers or selectors. Assuming a key coordinator, the accountant function might update internal indexes for faster access and reject entries with duplicate keys whereas the matchmaker query function checks for every entry if the value of the key property is equal to the specified value. The coordinator concept makes sure that XVSM is flexible and extensible with regard to queries because it is possible to specify arbitrary coordinators and use them for read and take operations. We use the Linda coordinator as an example of how to specify a coordinator. Linda tuple matching needs a template entry and returns all entries that match this reference. An accountant function must check if the format of the entries is compatible with the coordinator, which expects entries like: E = hl1:[type:int, val:5], l1:[type:string, val:“abc”], . . . i . Templates have the same structure, except that wildcards (“*”) are allowed as values. The query function is specified as a matchmaker which takes the template and the examined entry as arguments. It is defined recursively as follows:

The function applyQuery returns the result of the query evaluation on the specified xtree as a list of child xtrees that fulfill the query and a status xtree with possible error messages. If the query cannot be fulfilled at the moment, it is checked if it is theoretically satisfiable by the satisfiable function which can also return an xtree indicating the reason for non-satisfiability.

4.2

XVSMP and Language Bindings

CAPI Layering

The XVSM Core API consists of several layers that are built upon each other, and only use operations of the CAPI directly below them and the algebraic foundation described in Sect. 3. The core features of XVSM are bootstrapped from the basic operation set of CAPI-1. CAPI-2 introduces transactions which aggregate several atomic CAPI-1 operations to bigger atomic actions and CAPI-3 enables coordinators (see Sect. 5). CAPI-4 includes operation timeouts and aspects, which can be dynamically plugged into any operation to add services like security, replication and logging. It forms the base for the XVSMP protocol that is used by application programmer APIs whereas lower CAPIs remain hidden from the developer. CAPI-2 and 3 are nonblocking extensions to CAPI-1 whereas CAPI-4 is realized by a runtime machine that schedules and evaluates incoming requests. Internally, it consists of several system containers and processor tasks which use a special blocking variant of CAPI-1 called CAPI-B to bootstrap themselves with own mechanisms. This blocking CAPI layer introduces a flag to each operation that determines whether an operation should be repeated until a result is obtained, comparable to the repeated execution of transactions in software transactional memory [19]. A core processor handles requests on user containers by invoking the appropriate CAPI operation. When an invoked CAPI operation returns a DELAYABLE status, the request is retried by the runtime machine until the operation completes successfully, an error occurs as indicated by a NOTOK status, or the runtime encounters a timeout.

linda-query-func(tmpl, E) := |tmpl|=|E| ∧ (|tmpl| = 0 ∨ (((first(tmpl).type=’*’) ∨ (first(tmpl).type=first(E).type)) ∧ ((first(tmpl).val=’*’) ∨ (first(tmpl).val=first(E).val)) ∧

304

entries within containers. Inside the XVSM runtime specification, it is also used to select containers of a space or meta properties of containers and entries.

linda-query-func(rest(tmpl), rest(E))))

5.1

XVSM Query Language

The XVSM Query Language is used to select entries from a container. It can consist of several predicates that are chained via the pipe operator “|”. An XVSM query (XQ) has the form: SXQ1 |SXQ2 | . . . |SXQn where SXQi is a simple XVSM query. A SXQi can be either a matchmaker or a selector. The first simple XVSM query is evaluated on all entries of the container and yields a multiset or sequence of entries that fulfill the predicate. This result of the first chain element is then passed on as input to the second filter of the chain and so forth. This concept, originally introduced in [13], has been enhanced and generalized to enable extensible coordination models with self-defined selectors and matchmakers that can be chained together to create complex queries. Now, any SXQ of the form queryName(args...) can be used in the query language, whereas the query name must be unique for the entire system. Internally, this SXQ is mapped to the corresponding query function of the coordinator. An XVSM query is applied to a container by the so-called query executor which optimizes the query to gain maximal benefit from pipelining and parallelization. When encountering a matchmaker function, this method is applied to every entry and all matching tuples are sent immediately to the next element of the filter chain. If this is a selector, the query executor needs to wait until the result of the previous stage is complete. The result set of the entire query is used by the CAPI to notify coordinator accountant functions about the event and remove the entries in case of a take operation, before it is finally returned to the user. The following list shows the predefined SXQ functions:

6.

EXAMPLE

As a use case scenario for collaboration the ad-hoc, neartime interaction of multiple parties that do not know each other in advance has been selected. A person decides to sell some goods via the internet to the best price that can be achieved. This is a spontaneous action that shall be carried out quickly, and the implementation effort shall be low. Let us assume that the articles to be sold are books. A seller starts announcing the goods with an initial price quote. A buyer can place bids, and withdraw them. Each seller applies certain policies under which conditions the acceptance of a bid shall take place. We assume the following policy: The seller waits for k bids from different bidders and then takes the best one. The auction is mapped to one single container C which holds entries of the following types: offerings with initial price quotes (IPQ), bids (BID) and acceptance messages (ACPT). The corresponding entries have the following properties where “id” stands for unique article id, and “ipq” means initial price quote: initial price quote bid acceptances of bid

IPQ, ipq, id, author, title, . . . BID, id, price, buyer ACPT, id, price, buyer

The container is modeled as a multi-set with a special coordinator called AuctionCoordinator, whose accountant function guarantees (i) that for each article at most one entry for IPQ and ACPT respectively may exist, and (ii) that a bid entry must have a price greater than the initial price quote. The coordinator might include one or more query functions that represent default auction policies. However, we use user-defined policies defined as stored queries instead that can be changed dynamically but are not able to access the internal optimization data of the AuctionCoordinator. The seller starts an auction by writing an IPQ entry with unique value for Id into C. The auction is parameterized with the number of required bids k. The seller calls an asynchronous read operation that invokes a callback function as soon as its query returns a result. In our example, this query would be */BID | */id=Id | sortdown(price) | distinct(buyer) | cnt(k) | cnt(1). The callback function then writes an ACPT entry to the space to notify the buyers. The buyer’s functionality comprises (1) searching for an interesting article to buy (via template matching on IPQ entries), (2) placing a bid by writing a BID entry into C, (3) removing a bid by taking it from C, and (4) being notified about higher bids and the end of the auction. Task (4) is realized via two asynchronous read operations with the queries */BID | */id=Id | */price > myBid | cnt(1) and */ACPT | */id=Id | cnt(1), respectively. A database solution would use polling to wait for bids and is thus less reactive. Also an ad-hoc deployment is not so easy because an administrator needs to install the required tables. In JavaSpaces, there is no means to wait until a certain number of tuples is in the space. A check for a higher price is also not possible as only equality checks are allowed, so the application must take care of the coordination.

• sortup(l), sortdown(l): Sort entries depending on the value of their property l. • cnt(n): Return the first (for sequences) or any (for multisets) n entries of the input. If there are not enough entries available, the query fails. • distinct(l): Create an entry list with unique values for the property l. If more than one entry has the same value for l, the first one is taken (for sequences). • x ∈ range, x ∈ / range: It is checked for every entry if a certain value lies within a set of allowed or forbidden values specified by range. The query path specified in x denotes which (sub) xtree of the given entry is actually compared to the range. It may contain wildcards and can be arbitrarily nested. For convenience, it is also possible to use x = v and x 6= v for single values as well as x ≤ v, x < v, x ≥ v and x > v. If any value is allowed, the xtree path (x) is sufficient as a predicate. So, the query “e1” will yield true for any entry with the (automatically generated) label e1, while the execution of “*/l1 < 10” will return all entries (with any label) that contain a property with label l1 and a value less than 10. Furthermore, all matchmakers can be combined with logical conjunction, disjunction and negation. Note that in some cases these queries can be non-deterministic, e.g. if the entry has several properties with the same label. As already mentioned in Sect. 4.1, this query language is not limited to

305

7.

CONCLUSION

Longman Ltd., Essex, UK, 1999. [8] D. Gelernter. Generative communication in Linda. ACM Trans. Program. Lang. Syst., 7(1):80–112, 1985. [9] D. Gelernter. Multiple tuple spaces in linda. In PARLE ’89: Proceedings of the Parallel Architectures and Languages Europe, Volume II: Parallel Languages, pages 20–27, London, UK, 1989. Springer-Verlag. [10] L. Keszthelyi. Design and implementation of the JavaSpaces API standard for XVSM. Master’s thesis, TU Vienna, Inst. of Computer Languages, 2008. [11] E. K¨ uhn. Virtual Shared Memory for Distributed Architecture. Nova Science Publishers, 2001. [12] E. K¨ uhn, R. Mordinyi, L. Keszthelyi, and C. Schreiber. Introducing the concept of customizable structured spaces for agent coordination in the production automation domain. In The 8th Int. Conference on Autonomous Agents and Multiagent Systems (AAMAS), May 10-15 2009. [13] E. K¨ uhn, R. Mordinyi, and C. Schreiber. An extensible space-based coordination approach for modeling complex patterns in large systems. 3rd Int. Symposium on Leveraging Applications of Formal Methods, Verification and Validation, Special Track on Formal Methods for Analysing and Verifying Very Large Systems, 2008. [14] E. K¨ uhn, J. Riemer, R. Mordinyi, and L. Lechner. Integration of XVSM spaces with the web to meet the challenging interaction demands in pervasive scenarios. Ubiquitous Computing And Communication Journal (UbiCC), special issue on ”Coordination in Pervasive Environments”, 3, 2008. [15] R. Milner. The polyadic pi-calculus: a tutorial. Technical report, Logic and Algebra of Specification, 1991. [16] R. De Nicola, G. L. Ferrari, and R. Pugliese. Klaim: a kernel language for agents interaction and mobility. IEEE Trans. on Software Eng., 24(5):315–330, 1998. [17] L. Nixon, O. Antonechko, and R. Tolksdorf. Towards semantic tuplespace computing: the semantic web spaces system. In SAC ’07: Proc. of the 2007 ACM symposium on Applied computing, pages 360–365, New York, NY, USA, 2007. ACM. [18] G. P. Picco, D. Balzarotti, and P. Costa. Lights: a lightweight, customizable tuple space supporting context-aware applications. In SAC ’05: Proceedings of the 2005 ACM symposium on Applied computing, pages 413–419, New York, NY, USA, 2005. ACM. [19] N. Shavit and D. Touitou. Software transactional memory. In Proc. of the 14th ACM Symp. on Principles of Distributed Computing (PODC), pages 204–213, 1995. [20] R. Tolksdorf, F. Liebsch, and D. M. Nguyen. XMLSpaces.NET: An extensible tuplespace as XML middleware. In Proc. 2nd Int. Workshop on .NET Technologies, 2004.

The template matching introduced by the Linda model and subsequently used by JavaSpaces is not sufficient for complex collaboration scenarios. Even a simple first-in-firstout order, which is also supported by messaging systems, requires extra programming effort. One important weakness of space-based computing is the lack of a powerful query facility because often complex queries are necessary that are not easily mapped to template matching which only supports simple equality checks. In this paper we have introduced an extensible coordination concept based on a powerful query language and algebra for data structures of the space, which allows nearly any kind of coordinator to be defined. Our space-based computing middleware, XVSM, supports user-definable coordinators that allow arbitrary queries, which enables the user to react quickly to complex coordination requirements. A main contribution of XVSM is its layered architecture that allows us to bootstrap higher layers with own mechanisms that were defined on lower layers. The paper has shown the formal specification of the lower layers as a necessary foundation and the hooks for extensibility and flexibility. A language independent protocol is used to allow collaboration between different systems. We have shown the feasibility of our model by outlining a simple auction system. Our formal definition approach will be the base for further research on the XVSM coordination model. The next steps will be the specification of the operational semantics of the runtime model and the modeling of further CAPI levels, accompanied by the implementation of an executable specification in the functional programming language Haskell.

8.

ACKNOWLEDGEMENTS

We would like to thank Laszlo Keszthelyi and Richard Mordinyi for their valuable comments on this text.

9.

REFERENCES

[1] S. Abiteboul, O. Benjelloun, and T. Milo. The active xml project: an overview. The VLDB Journal, 17(5):1019–1040, 2008. [2] M. Bravetti, R. Gorrieri, R. Lucchi, and G. Zavattaro. On the expressiveness of probabilistic and prioritized data-retrieval in Linda. Electr. Notes Theor. Comput. Sci., 128(5):39–53, 2005. [3] M. Bravetti, R. Gorrieri, R. Lucchi, and G. Zavattaro. Quantitative information in the tuple space coordination model. Theor. Comput. Sci., 346(1):28–57, 2005. [4] N. Busi, R. Gorrieri, and G. Zavattaro. Process calculi for coordination: From Linda to JavaSpaces. In Proc. of the 8th Int. Conf. on Algebraic Methodology and Software Technology (AMAST), pages 198–212, London, UK, 2000. Springer-Verlag. [5] P. Ciancarini. Coordination models and languages as software integrators. ACM Comput. Surv., 28(2):300–302, 1996. [6] D. Fensel, R. Krummenacher, O. Shafiq, E. K¨ uhn, J. Riemer, Y. Ding, and B. Draxler. Tsc triple space computing. Springer, Elektrotechnik & Informationstechnik, pages 31–38, 2007. [7] E. Freeman, K. Arnold, and S. Hupfer. JavaSpaces Principles, Patterns, and Practice. Addison-Wesley

306