Java程序辅导

  
Enterprise-enabled Ubiquitous 
 Workspace Infrastructure 
 
 
Terence Blackburn 1 
 
Honours Thesis 2002 
 
 
 
 
Supervisors: 
Assoc Prof Rudi Vernik 1, 2 
Dr Damien Bright 1 
 
 
1 School of Computer and Information Science 
University of South Australia 
Mawson Lakes Blvd 
Mawson Lakes South Australia 5095 
 
2 Defence Science and Technology 
P O Box 1500 
Edinburgh South Australia 5111 
 
 
November 2002 
Terence Blackburn 1 Enterprise-enabled Ubiquitous WorkSpaces 
Abstract 
Current research in the area of ubiquitous computing environments is shifting the focus of 
human computer interaction away from traditional interfaces such as keyboards and mice and 
towards more natural modes of interaction such as speech and gestures. An important 
environment that can benefit from this trend is the enterprise-enabled workspace but this 
domain has not been investigated in any great detail in current literature. Enterprise work 
environments require support across a range of activities that include meetings, strategic 
planning, remote coordination (command and control) and collaborative work activities such 
as software development. This project investigates the use of architectural frameworks as the 
infrastructure for next generation, enterprise-enabled, ubiquitous workspaces. 
 
“LiveSpaces”, in the UNISA e-World laboratory, is an example of a research initiative to build 
an experimental, adaptive, context aware environment and is used as a basis to explore 
some of the issues involved in building future, collaborative work spaces. A meeting room 
scenario is employed to identify some of the attributes involved in underpinning these future 
workspaces. An experimental, hybrid software framework is built which involves integrating 
MIT’s MetaGlue, a multi-agent, ubiquitous computing infrastructure, with DSTC’s Open 
Distributed Services Infrastructure (ODSI), an enterprise enabled architecture that has a 
messaging based enterprise bus and a workflow focus. 
 
In addition to building the experimental infrastructure, the other major component in this thesis 
devotes itself to exploring the characteristics of enterprise-enabled workspaces and 
highlighting how MetaGlue and ODSI have supported these characteristics. Time was taken 
to examine the areas where the infrastructure components complement each other, in terms 
of workspace attributes, and the areas where neither of the architectures adequately 
addresses the needs of future workspaces. The discussion section evaluates these strengths 
and weaknesses and both infrastructures are considered against a set of desirable 
workspace attributes identified in Section 2.6. These attributes include context awareness, 
adaptability, process orchestration and collaboration but the most important characteristics 
that underpinned all of these attributes were security and state management. Neither 
framework had incorporated any level of security and this is an area that needs to be 
addressed prior to any attempts at commercialisation. State management involves capturing, 
persisting and recreating state on demand and this supports all higher order workspace 
characteristics. 
 
The environment built for the experiment provides a basis for further work to examine how 
such software frameworks can be extended to address many higher order workspace 
requirements such as rapid instrumentation, workspace replication, collaboration across 
multiple workspaces and interleaving different levels of security simultaneously. 
Terence Blackburn 2 Enterprise-enabled Ubiquitous WorkSpaces 
Declaration of Originality  
 
All of the material in this thesis is my original work and I believe that this thesis does not 
contain any material previously written or published by another person except where I have 
acknowledged the authors in the body of the document or in the acknowledgements section 
on the next page. 
 
 
 
 
 
 
 
Terence Blackburn 
24th November 2002 
Terence Blackburn 3 Enterprise-enabled Ubiquitous WorkSpaces 
Acknowledgements 
 
The quality and quantity of academic work during an Honours project moves up to a new 
realm compared to the mass production years of an undergraduate degree. It is far more 
demanding on students who take this path. There is no time for party powders, adult 
beverages or basking on the beach. There is no time for anything except work. 
 
My supervisors made it sound easy. “Just change that. Just add this. You can cut and paste 
from your paper and most of it is done.” This is not the case! Don’t let anyone have you 
believe that learning how to undertake research, writing the odd paper or two, creating a 
practical thesis component and cramming in regular course work is easy because it is not. 
 
In addition to lots of other things, Rudi and Damien, thank you for encouraging and 
challenging me. I’ve stretched myself in new directions this year, ones related to the cerebrum 
rather than the tum and bum and it’s where I want to head. You’ve provided excellent tag 
team support through the last twelve months and I appreciate your agreeing to run with me 
through my PhD years. 
 
I appreciate the time that Robyn Whibley and Mathew Phillips from DSTO spent with me 
sharing their perspective on some of the components in LiveSpaces and Brett Wilkinson from 
Flinders University for his thoughts and perception regarding some of the concepts in the 
project. 
 
Most of the acknowledgements relating to material in the document are contained in the 
references section but some explicit recognition is warranted. DSTC have allowed me to use 
some of their material in this thesis and this included the Wfclient java code for the connection 
from MetaGlue to ODSI. Thank you Andy Bond and Michael Lawley for your support and 
advice. The e-World lab supplied the Python code for the workflow stub and DSTO provided 
assistance creating the MetaGlue agents. 
 
My thanks go to the researchers at Stanford, MIT and DSTC for (unwittingly) providing the 
inspiration for this work and second last (but not second least), I would like to express my 
gratitude to DSTO for underpinning my project. Without their generous and ongoing support, 
the e-World laboratory and the exciting research we are undertaking would probably not exist. 
 
When eating dessert, we always save the best till last. Thanks to my partner, Jan, who 
tolerated for a year a person who was not very tolerable at times and who still gives me a 
loving smile when I least expect it. 
 
Terence Blackburn 4 Enterprise-enabled Ubiquitous WorkSpaces 
Acknowledgements (Cont) 
Figure 3.1 Copyright DSTC 
Figure 3.2 Copyright DSTO 
Figure 3.3 Copyright DSTO 
Figure 3.4 Copyright GMD-IPSI 
Figure 3.5 Copyright GMD-IPSI 
Figure 3.6 Copyright GMD-IPSI 
Figure 3.7 Copyright University of Aarhus 
Figure 4.2 Copyright University of South Australia 
Figure 4.4 Copyright DSTC 
Figure 4.5 Copyright DSTC 
Figure 4.6 Copyright Stryon 
Terence Blackburn 5 Enterprise-enabled Ubiquitous WorkSpaces 
Contents 
 
Abstract .................................................................................................................................. 1 
Declaration of Originality ........................................................................................................ 3 
Acknowledgements ................................................................................................................ 4 
Contents ................................................................................................................................. 6 
Glossary ................................................................................................................................. 8 
1. Introduction......................................................................................................................... 9 
2. Future WorkSpace Environments .................................................................................... 12 
2.1 Overview..................................................................................................................... 12 
2.2 Research Initiatives .................................................................................................... 12 
2.3 Architectural Focus ..................................................................................................... 12 
2.4 WorkSpace Activities .................................................................................................. 13 
2.5 Infrastructure Characteristics...................................................................................... 13 
2.6 Characteristic Descriptions......................................................................................... 13 
2.7 LiveSpaces ................................................................................................................. 15 
3. Architectures, Infrastructures and Components............................................................... 20 
3.1 MetaGlue .................................................................................................................... 21 
3.2 ODSI ........................................................................................................................... 24 
3.3 iROS ........................................................................................................................... 28 
3.4 Roomware................................................................................................................... 32 
3.5 TOPOS ....................................................................................................................... 36 
3.5 Topos (Cont.) .............................................................................................................. 40 
4. Case Study ....................................................................................................................... 41 
4.1 LiveSpaces Configuration........................................................................................... 41 
4.2 Scenario...................................................................................................................... 44 
4.3 Case Study Analysis................................................................................................... 45 
4.4 Process Execution ...................................................................................................... 52 
4.5 Results of Experiment................................................................................................. 60 
5. Discussion ........................................................................................................................ 63 
5.1 Implementation issues ................................................................................................ 64 
5.2 Service Provision ........................................................................................................ 65 
5.3 Architectural Design.................................................................................................... 69 
5.4 Inter-infrastructure ...................................................................................................... 71 
5.5 Security ....................................................................................................................... 72 
5.6 Scalability.................................................................................................................... 76 
Terence Blackburn 6 Enterprise-enabled Ubiquitous WorkSpaces 
5.7 Orchestration and Synchronisation ............................................................................ 77 
5.8 Adaptability ................................................................................................................. 77 
5.9 Persistence and State Management .......................................................................... 78 
5.10 Context Awareness................................................................................................... 79 
5.11 Collaboration............................................................................................................. 80 
5.12 Distribution................................................................................................................ 80 
5.13 Summary................................................................................................................... 81 
5.14 Future Work .............................................................................................................. 84 
6. Conclusions ...................................................................................................................... 88 
References............................................................................................................................... 91 
Appendix A............................................................................................................................... 96 
MetaGlue Agent Source Code................................................................................................. 96 
Speech agent ....................................................................................................................... 96 
SendAgent............................................................................................................................ 96 
ReceiveAgent ....................................................................................................................... 97 
ExplorerTestAgent................................................................................................................ 97 
ExplorerAgentWrapper......................................................................................................... 98 
Processx10Agent ................................................................................................................. 99 
x10Devices ........................................................................................................................... 99 
StartWfClient ...................................................................................................................... 100 
WfClient .............................................................................................................................. 100 
ODSI Source Code ................................................................................................................ 102 
test_client ........................................................................................................................... 102 
running_test........................................................................................................................ 103 
 
 
 
Terence Blackburn 7 Enterprise-enabled Ubiquitous WorkSpaces 
Glossary 
AR (WorkSPACE) Augmented Reality, where virtual and physical 
environments intersect 
BEACH (AMBIENTE) Basic Environment for Active Collaboration with 
Hypermedia, a software environment. 
Catalog (Intelligent Room) This MetaGlue agent keeps track of the agents 
that are active. 
DataHeap (Interactive Room) This mechanism allows movement of large 
chunks of data across applications in a workspace 
Event Heap (Interactive Room) This shared memory model facilitates device 
communications and is based on a tuplespace, which is a shared 
blackboard for posting and receiving events. 
iCrafter (Interactive Room) This facilitates writing "services", applications 
that provide utilities and functions for other applications. It is useful 
for writing various types of device controllers. 
iROS (Interactive Room) This is a middleware layer/meta-operating 
system for technology-rich "interactive rooms". It is written in Java 
and uses a client server paradigm. 
Lore (Interactive Room) Lore is a semi-structured database that stores 
XML structures containing context information, groups of related 
objects eg personal data, and active objects in the workspace. It 
acts like a catalog for keeping track of resources rather than storing 
all objects. 
Notifier (Intelligent Room) a publish-subscribe communications mechanism 
for MetaGlue agents. 
Topos (WorkSPACE) a software client that presents a 3D spatial 
hypermedia interface to document and material organisation 
Transient state API (Interactive Room) this allows applications to "discover" which other 
applications are running in the workspace and query their state 
Terence Blackburn 8 Enterprise-enabled Ubiquitous WorkSpaces 
1. Introduction 
This thesis examines ubiquitous computing infrastructure from the perspective of enterprise-
enabled, future work environments1. 
 
The term “enterprise-enabled ubiquitous workspace” is defined here as a 
technology-rich physical environment that supports business processes 
and links together enterprise assets, services and data repositories with 
new input/output mechanisms coupled to new computing devices. 
 
In such an environment, various aspects of the enterprise are represented using some form of 
enterprise model which keeps track of roles and policies and which can be utilised in process 
orchestration and collaboration. This model is constructed using a top down approach and is 
based on enterprise goals and activities, which are expressed as business processes in the 
form of workflows. Process orchestration tools such as workflow engines are important in this 
type of environment to coordinate business processes that can facilitate productive interaction 
between decoupled components and devices. 
 
Enterprise work environments require support for a range of activities such as meetings, 
strategic planning, remote coordination (command and control) and collaborative work such 
as software development. The software infrastructure required to support enterprise-enabled 
work environments is complex and research to date in ubiquitous/pervasive computing has 
focused more on augmenting physical spaces with new interface technologies at the expense 
of enterprise needs. One of the driving factors behind the current trend to pervasiveness is 
the desire to abandon traditional computing interfaces and embrace more natural ways of 
utilising technology infrastructures [53]. In future, collaborative environments, keyboards and 
mice will be replaced and more human-centric, natural interaction mechanisms such as voice 
and gestures will be coupled with new interactive display devices. This will enable people to 
move from being “cabled and connected” to environments where “wireless and wandering” 
will be the norm and this is where a substantial amount of research has been focused. These 
trends will allow humans to be physically decoupled from computers but this will raise many 
issues [21]. 
 
Future workspaces will employ a range of display technologies, interaction devices, and 
contextual sensors to augment physical spaces such as meeting rooms and collaborative 
work areas. In these settings, technology will become ubiquitous and, in a sense, will 
disappear from view. It will become interwoven with the physical backgrounds of 
collaborative, interactive environments [49]. New software infrastructures will provide the 
                                                     
1 A summary paper can be found at http://eworld.unisa.edu.au/publications/entworkspace.pdf 
Terence Blackburn 9 Enterprise-enabled Ubiquitous WorkSpaces 
basis for integrating, controlling and coordinating activities and technologies within these 
future workspace settings. Additional enterprise-level infrastructure will be required to provide 
for the integration and synchronisation of multiple, collaborative workspaces. 
 
This thesis focuses on the challenge of providing the underlying architectures and software 
infrastructure to accommodate these future environments and associated workspace 
applications. As with individual workstations, which require an operating system to coordinate 
and run applications, ubiquitous computing applications will require an underlying operating 
environment. Research is well underway in various laboratories, e.g. [5, 29, 35, 45], to more 
fully understand what this underlying infrastructure should be and a substantial part of this 
work has focused on infrastructure to support interactions between people and devices. 
 
In this thesis, we begin to explore how the infrastructure 
for these interactive environments might be extended 
and integrated into broader enterprise-level solutions.  
 
Some of the characteristics that need to be considered in this respect include the use of 
workflow processes for orchestrating and coordinating work activities, various layers of 
distribution, enterprise information management and integration with various enterprise 
services such as ontology servers, data repositories, and web services. 
 
Sections two and three discuss the results of an extensive literature review undertaken to 
identify related research initiatives. Section two also sets the context for the thesis by 
discussing the desired characteristics of future workspaces and by providing examples of the 
types of activities that will need to be supported in these settings. 
 
Section three reviews five separate, different approaches to creating collaborative and 
adaptive infrastructures. We discuss the architectural components that have been used to 
form the foundations for intelligent, interactive environments and emerging enterprise-
computing approaches. 
 
Section four starts by discussing the research environment that was used to conduct a case 
study. The case study involved establishing a LiveSpaces environment as an interactive 
meeting workspace. The infrastructure was comprised of two components: MetaGlue [29], a 
multi-agent, ubiquitous computing infrastructure, which forms the basis of the MIT Intelligent 
Room, and ODSI [2-4], an enterprise framework from DSTC. ODSI implements the concept of 
an enterprise bus that allows the integration and coordination of a range of enterprise 
services across an organisation. It uses an enterprise model, in the form of organisational 
structures, context and processes, to orchestrate and coordinate work activities and allow 
flexible employment of various enterprise applications and services. This section also 
Terence Blackburn 10 Enterprise-enabled Ubiquitous WorkSpaces 
describes the technology that was involved in the case study and spends some time 
describing the important software and hardware components that were employed. To 
highlight the merits of using an enterprise-enabled, interactive workspace, a simple meeting 
scenario was used as the setting for the experiment. 
 
Section five reports on the results of the case study. It discusses what we have learnt in the 
context of future workspace characteristics and summarises the discussion of key results. In 
addition, it raises some issues that invite further exploration such as the merits of lightweight 
messaging in an enterprise environment and the absence of security, which hinders the ready 
adoption of this type of enterprise-enabled workspace technology by business. 
 
Section six completes the thesis by highlighting the conclusions that we have reached and 
sharing the insights that we have experienced. 
Terence Blackburn 11 Enterprise-enabled Ubiquitous WorkSpaces 
2. Future WorkSpace Environments 
2.1 Overview 
Ubiquitous and pervasive computing initiatives are providing the components for augmenting 
physical workspaces with devices that will allow people to interact more effectively with each 
other and with technology [13]. Future workspaces will be extended with various interactive 
display devices, universal interactors like personal information appliances, human-centric 
input mechanisms and natural language interfaces. Approaches such as augmented reality, 
virtual presence and conversational agents will help transform the way in which people use 
information to support individual and collaborative workspace activities. This section 
examines the components of future workspaces and the attributes that will be required to 
support them. 
2.2 Research Initiatives 
Several research projects [5, 29, 35, 45] are currently underway that look at how these 
devices and technologies can be integrated and managed as part of a future workspace. For 
example, MIT’s Intelligent Room integrates the use of speech, gestures [27] and natural 
language interfaces to help users interact with workspace applications. Context plays an 
important part in enabling the room to tailor itself to the needs of workspace participants. 
Stanford’s Interactive WorkSpace [17] explores the management of information in multidisplay 
environments and supports user interaction between personal handheld devices and large 
interactive displays. The researchers at the Ambiente [35] project in Darmstadt, Germany, 
have adopted a parallel approach to the Stanford work with a focus on multi device, 
interactive workspaces. They have extended this model by reengineering pieces of furniture 
such as tables and chairs to act as parts of a collaborative workspaces. Each of these 
initiatives has as its core, an infrastructure component that addresses important requirements 
such as display management, interaction management and context awareness. 
2.3 Architectural Focus 
Related work has been undertaken to look at how these future workspaces might support 
collaborative work activities [15, 17]. For example, Stanford’s Interactive Room has been 
used to support architectural design activities while MIT’s Intelligent Room supports 
applications such as the Meeting Manager [28]. The Ambiente infrastructure allows users to 
join pieces of workspace furniture to form larger, interactive, virtual workspaces. However, a 
review of the literature suggests that relatively little work has focused on examining how these 
types of workspaces might be deployed as part of an overall enterprise environment. For 
example, there is interest in the area of command and intelligence environments where 
several such distributed workspaces might be used to collectively plan and execute a military 
mission. Similar situations arise in the planning and execution of large software development 
Terence Blackburn 12 Enterprise-enabled Ubiquitous WorkSpaces 
projects and perhaps in the coordination of security for large sporting events. In such 
situations, the work within individual workspaces needs to be orchestrated and synchronised 
with other workspaces so that overall enterprise goals can be realised. 
2.4 WorkSpace Activities 
The types of activities that need to be supported in individual workspaces include those 
associated with collaborative planning, analysis, briefing and execution. Each activity usually 
requires access to corporate data and often generates new information; hence, appropriate 
access to enterprise-wide data sources is critical. Workspaces also need to adapt readily to 
the type of activity being undertaken, the setting that is hosting the activity and the people 
involved with undertaking the activity. This adaptive characteristic can be described as 
context awareness or enterprise awareness [12]. Moreover, activities need to be orchestrated 
and managed within individual workspaces to ensure that goals are met within a required 
timeframe and this can also involve awareness of context in the larger scope of activities. 
2.5 Infrastructure Characteristics 
As discussed earlier in this section, research into intelligent and interactive rooms has 
identified a number of desirable characteristics that need to be supported through ubiquitous 
computing infrastructure. Some of these characteristics can be physically manifested through 
display management, interaction management, mobility, location sensitivity and support for 
disconnectedness. In taking an enterprise perspective on the use of these future workspaces, 
there are several additional characteristics that we believe need to be addressed. These 
include distribution management, orchestration and synchronisation of organisational 
processes, enterprise awareness, information management, and security. As discussed in 
Section 3, these aspects are being considered in various research projects that look at future 
enterprise computing architectures and infrastructure. 
 
Our challenge is to investigate infrastructure for future work 
environments that exhibit a combination of desirable characteristics 
from both ubiquitous computing and enterprise computing domains. 
 
This will be followed by an analysis of our findings, and this may lead us to some conclusions 
regarding the future directions for these infrastructure environments. 
2.6 Characteristic Descriptions 
Some of the attributes required by enterprise enabled future workspaces include: 
Terence Blackburn 13 Enterprise-enabled Ubiquitous WorkSpaces 
Context Awareness 
In terms of future workspace environments, context awareness refers to the ability of a 
system able to perceive the state or existence of some aspect of itself or its environment. 
The particular environment can be physical, simulated or virtual. This awareness may 
include conditions such as temperature, time, smell and lighting levels or the proximity of 
a person and what that person is doing. Environment awareness also includes 
information and data and examples could include network traffic levels, the 
communications activity in an agent messaging system or the firing of a database trigger. 
This context awareness can exist both within and between workspaces. 
Adaptiveness 
This key attribute is linked to the management of change, and it can have a number of 
different manifestations and drivers. In this research, workflows and business processes 
constitute two of the main drivers for adaptive behaviour and this behaviour will promote 
the dynamic composition of future workspaces. Other divers will include conditional 
branching within a process, changes of state, levels of activity and scaling factors. 
Process Orchestration 
This concept can be described as the arrangement or combination of a series of 
contiguous actions or processes for a desired effect within the enterprise. The processes 
can include: the arrangement of a series of workflows to create a higher order workflow, 
the dynamic composition or reconfiguration of an adaptive environment or the 
synchronisation of a set of enterprise activities. 
Collaboration 
In this context, collaboration means working together or cooperatively in an endeavor and 
the effort may or may not be goal oriented. In addition to individuals and groups, 
collaboration also applies to device, machine and process activities in local and remote 
workspaces. 
Distribution 
Distribution, in this thesis, encompasses the idea of dissemination or spreading of 
components in an enterprise. Layers of distribution will include people, workflows, 
processes, data, computer hardware and services. The enterprise, which can be situated 
locally, remotely or virtually, is often a distributed entity by default. 
State Management 
The observable or unobservable condition of an object is called state and, to enable 
management of state, information relating to the condition is usually stored as a data 
type. 
Terence Blackburn 14 Enterprise-enabled Ubiquitous WorkSpaces 
Security 
Software infrastructures are not introduced into production environments without 
safeguards to isolate and protect whatever organisational assets are potentially exposed. 
Existing security models are constantly challenged to address weaknesses and new 
forms of attack from malicious intruders. Future enterprise security models will be 
stretched even further with a range of new issues as workspace components are 
invented or reengineered. 
Persistence 
The ability of an object or a piece of data to remain in existence after the end of a process 
is called persistence. This can also be described as continuance or prolongation of the life 
of the object. 
 
A combination of some of these characteristics will be evident in future workspaces and one 
of the cornerstones of this research is to determine the most advantageous approach to 
creating the infrastructure to support these enterprise-related attributes. 
 
2.7 LiveSpaces 
2.7.1 Overview 
The LiveSpaces environment is a joint undertaking between the Australian Defence Science 
and Technology Organisation (DSTO) and the University of South Australia’s Advanced 
Computing Research Center (UniSA/ACRC). It incorporates components from their separate 
research programs along with research components from DSTC. LiveSpaces is an 
experimental test bed for examining workspace infrastructures and it is being used to explore 
a range of issues related to future workspace development. 
 
2.7.2 LiveSpaces Goals 
The LiveSpaces experimental environment project has been established with specific goals 
that focus on exploring a range of issues related to collaborative work in future Defence 
settings, in support of large software projects and in health domains. These goals will be 
pursued by extending DSTC’s Open Distributed Services Infrastructure (ODSI) research 
platform through technology integration and experimentation. Specific areas of research 
include enterprise and inter-enterprise system architectures, enterprise security, rapid 
configuration, advanced visualisation and multimodal interfacing, context management, 
business process realisation and enterprise synchronisation. Technologies that support these 
initiatives include adaptive workflow engines, interactive displays embedded in room furniture 
Terence Blackburn 15 Enterprise-enabled Ubiquitous WorkSpaces 
such as tables and walls, real time avatar interaction, advanced teleconferencing, mixed 
reality, mobile and wireless computing paradigms and knowledge processing/management. 
 
This project experiments with a subset of these technologies and goals and includes a focus 
on context awareness, workflow processing, advanced display technologies, speech 
interfaces, enterprise data access and collaboration. 
2.7 3 Architectural features 
Several of the major components of LiveSpaces (see Figure 2.1) are based on ODSI 
architectural principles [2, 3]. ODSI has been selected as a foundation for ODSI for a number 
of reasons. The framework has been designed with flexibility and adaptability as architectural 
cornerstones. ODSI’s abstract definition of service provision allows it to rapidly integrate new 
technologies and components without the need for reengineering. It is driven from a high-level 
enterprise perspective where business processes and enterprise needs dictate what should 
be done but do not dictate how it should be done. The implementation of these requirements 
is left to lower level integration technologies. 
 
The implementation independence of ODSI and LiveSpaces acts as a base for the rapid 
composition of experimental superstructures. The peer to peer infrastructure is written in 
Python, an object oriented scripting language, which is powerful yet concise. Many cross 
platform technologies are deployed in the Java programming language and Python has a 
natural interface to Java in the Jython language. This allows Python code to be implemented 
and executed from within the Java Virtual Machine. This allows the choice of either tight or 
loose coupling between software components depending on the application’s design. 
Terence Blackburn 16 Enterprise-enabled Ubiquitous WorkSpaces 
 
Figure 2.1 LiveSpaces Architectural Components 
 
The workflow engine is the heart muscle of the LiveSpaces enterprise framework and the 
Breeze suite of workflow products [43] has been selected for this implementation. This 
includes the Breeze workflow engine, the GUI based Bred workflow editor and Brzmon, which 
is a monitoring program that displays a workflow’s status throughout the course of its 
execution. 
 
Elvin [33] is the messaging mechanism that facilitates communication within the LiveSpaces 
framework. It is lightweight, fast and easy to deploy and use. (Available client 
implementations cover most of the major programming languages and code examples are 
available from the Elvin [41] web site.) The messaging model is content based and 
asynchronous so that publishers and subscribers remain anonymous and no message 
acknowledgements are required. 
2.7.4 Enterprise Model 
The focal point of the LiveSpaces infrastructure is the Enterprise Model. This is manifested in 
support for enterprise roles and policies, which are stored and accessed from data 
repositories, and business processes, which are expressed as workflows. 
 
Context information is gathered from a number of levels. These include: software applications 
such as calendars, environmental sensors and enterprise models such as organisational 
Terence Blackburn 17 Enterprise-enabled Ubiquitous WorkSpaces 
hierarchies. This data is aggregated and used in the contextual environment for planned 
activities. 
 
Collaboration is fostered in a number of ways: 
o through the peer software model, which promotes peer interaction for the fulfillment 
of service requests 
o through the meeting coordinator agent, which supports interaction between 
participants to achieve desired goals 
o via the workflow engine, which can direct and control activities described by business 
processes and, hence, provide process orchestration. 
 
Security is not a feature of the abstract LiveSpaces model but would probably constitute an 
important component of the infrastructure if it was implemented within an organisation. 
 
Persistence is supported in the enterprise model in a number of formats. Business processes, 
in the form of workflow stubs, are stored in a database and accessed by the workflow engine. 
Legacy data, which may be stored in proprietary formats, can be used in the model if the 
appropriate interfaces are available. 
 
Figure 2.2 LiveSpaces Populated with Research Components 
 
Terence Blackburn 18 Enterprise-enabled Ubiquitous WorkSpaces 
Other components, such as the augmented reality interface and the simulation services, are 
abstractions without implementation layers in the version of LiveSpaces used in this case 
study. 
 
The LiveSpaces model has no security layer although Elvin version 4 has a number of 
security components that offer different levels of secure messaging. This, by itself, however, 
does not constitute a holistic approach to enterprise security. If Elvin version 4 is utilised as 
the enterprise bus, rather then a previous version, it may support point-to-point message 
security but it does not protect databases, it does not isolate a network from denial of service 
attacks, nor dos it quarantine enterprise servers. 
 
The flexibility of the architectural model is exemplified by the selection of technologies that 
has been plugged into the LiveSpaces framework as depicted in Figure 2.2. This 
configuration has been created for research into future command environments and has been 
supplied courtesy of DSTO. Many of these technologies exist only in research laboratories but 
LiveSpaces is actively being used as a dynamic environment for conducting experiments. 
Terence Blackburn 19 Enterprise-enabled Ubiquitous WorkSpaces 
3. Architectures, Infrastructures and Components 
Several architectures and software infrastructures have been identified that provide some of 
the desirable characteristics for the type of enterprise-enabled workspaces outlined in Section 
1. In this section we draw from five examples to highlight how some of these characteristics 
have been supported and implemented. 
 
MetaGlue [30] is a mobile, multi-agent system that supports an experimental, intelligent room. 
Most of the infrastructure consists of various agents that have one specific function. Most of 
these agent functions are concerned with device control activities and interfacing to 
applications. The remaining agents that are not involved with these activities are concerned 
with the administration and management of the agent system. 
 
ODSI [2] is an enterprise-focused framework that allows business managers to create and 
describe abstract business processes. The supporting peer to peer infrastructure assumes 
responsibility for instantiating and executing these business processes and it relies on a set of 
plug in components to achieve its goals. 
 
IROS [18] is an architecture that was designed to support large display devices. It has been 
extended to encompass human interactivity and to integrate small hand held devices. Other 
components have been built over this infrastructure and one of them, the Event Heap, is of 
particular interest for its enterprise support. 
 
Roomware [35] is one of the two European projects that have been included in this section. 
Its area of focus is the integration of computer-augmented components into items of furniture 
such as tables and chairs. By using this approach, the researchers have created new modes 
of work orchestration and group collaboration between digital objects and humans. 
 
The final infrastructure that will be reviewed is TOPOS [29], which has a 3D focus. This 
research has goals to enhance distributed collaboration in various spaces. These spaces 
include local, remote and digital spaces and all of this work is enveloped by a central spatial, 
3D theme. 
 
The section concludes with a table that summarises these five approaches and highlights 
their key attributes and components. 
Terence Blackburn 20 Enterprise-enabled Ubiquitous WorkSpaces 
3.1 MetaGlue 
Overview 
The Intelligent Room is a part of the Oxygen [5] project at the Massachusetts Institute of 
Technology, Cambridge, MA. It integrates a wide range of devices such as: 
 
o cameras that monitor people and events 
o microphones that listen to verbal commands and oral conversations 
o speakers that play music and output synthesised voices 
o projectors that display graphical information 
o LED signs that display textual information 
o various consumer devices such as VCRs and DVD players [13]. 
 
The supporting software communication infrastructure in the room is MetaGlue, a mobile, 
multi-agent system. MetaGlue provides human-computer interfaces, support for persistent 
storage mechanisms and device customisation abilities. 
Architectural Components 
MetaGlue Version 0.5 [30] is a multi-agent based system that provides computational glue for 
large groups of collaborative software agents and device controllers, such as those used in 
the Intelligent Room [5]. It provides communication and discovery services and enables users 
to interact, subject to access control, with software and data services in the room. It also 
arbitrates among applications competing for resources [11]. MetaGlue separates software 
that acts on behalf of users from software that controls spaces. Societies, or groups of 
agents, can be attached to any entity in an intelligent room and can move with the entity eg 
camera and microphone agents that are associated with a person who walks across the 
room, would move from one set of device controllers to another positioned near the person’s 
new location. This introduces the concept of mobile agents. If a service is not available on a 
particular host, MetaGlue can spread to that host and this is a process called glue spreading. 
In this process, the required agent is started on the new host to provide the required service. 
 
MetaGlue is implemented in Java and replaces the Remote Method Invocation (RMI) 
mechanism with one that allows dynamic reconfiguration and reconnection so that agents can 
invisibly resume previously established but broken connections. MetaGlue provides the 
support for managing systems of interactive, distributed computations i.e. those in which 
different components run asynchronously on a heterogeneous collection of networked 
computers. It provides high-level support for writing groups of interacting software agents and 
automates the connection and distribution of these agents according to their service and 
computational requirements. 
 
Terence Blackburn 21 Enterprise-enabled Ubiquitous WorkSpaces 
The MetaGlue framework supports context awareness by capturing state information from the 
devices in the environment. It supports distribution by managing a set of device controllers 
and a level of persistence by retaining device state and agent attributes in a database. 
Persistence is also supported by way of the Catalog Agent, which stores agent stub 
information in a database. 
 
Currently, there are a number of projects building on the MetaGlue infrastructure that are 
designed to expand the functionality of the Intelligent Room. Some of these new projects 
incorporate and extend various desirable workspace characteristics including collaboration, 
process orchestration and security. The following bullets describe a selection of these 
projects. 
 
o A help system [7] allows a person to enter the room and receive interactive, 
multimodal assistance from the room itself via speech output, visual displays and 
keyboard/mice interfaces. The room's help system provides information about the 
room's abilities and how a person can use them. This has similar interface 
characteristics to ReBa, the reactive, behavioural system [13], which allows the room 
to respond to specific user actions and commands on a one to one basis. In a similar 
vein, the dynamic, context aware, speech recognition system aims to generate a 
single, robust, contextual grammar and create a true, free form speech interface to 
the room. The SAM project [13] aims to make the Intelligent Room responsive to user 
affect (curiosity, frustration, etc). It also aims to make it affective, emotion-enabled 
and expressive of its own state in emotional terms, which would be expressed 
through spoken inflection in Text To Speech (TTS) output. 
 
o Another set of projects [13] maintains a multi-user, multi-spatial focus with regard for 
available resources. Collaborative environments can experience situations where 
multiple users attempt to share the resources in an environment. This is best handled 
through a segmentation of agents based on their representatives, human or device, 
and a simple knowledge representation that encompasses the capabilities of the 
space and user roles. Rascal [13] is a Resource Manager that is able to obtain 
resources in terms of the services they provide and arbitrate among contending 
requests for resources that may become scarce as the number of applications in the 
room increases. The Meeting Manager [28] is a multi-user, multimodal collaboration 
tool for planning, facilitating, and browsing structured meetings. It stores the contents 
of the meetings, including video, in a database for reference at a later date. 
 
o A project that would need to consider environmental factors is the security and 
privacy project [40], which incorporates an access control scheme to ensure that only 
an authorised person will have access to the information in the Intelligent Room. 
Terence Blackburn 22 Enterprise-enabled Ubiquitous WorkSpaces 
Another project, which extends the Intelligent Room metaphor beyond the four walls 
of a room, is being undertaken by the mobile computing team. Its goals are to design 
new principles for intelligent agent-based systems to operate on numerous mobile 
platforms and to enhance MetaGlue to operate efficiently on small, mobile platforms 
 
o The sensor development group [13] is researching a variety of wired and wireless 
sensors (temperature, pressure and humidity sensors and motion detectors) to 
incorporate them into the existing system and program higher-level code to organize 
and interpret the data from the sensors to execute specified or implied tasks. The final 
project [13] deals with information retrieval, web access and personal information 
management. It seeks to make the process fast and efficient and provide 
mechanisms to access previously visited information sources. 
Analysis 
A software agent in this environment has been defined as any piece of software that exposes 
some of its functionality to other agents or software programs and can communicate 
independently within a network with these other agents [13]. In this future workspace, agents 
control hardware or software devices. It is important that agents can act autonomously and 
without a single point of failure, which would be embodied in a central agent controller. In this 
way scalability is supported as the system may evolve to hundreds or thousands of agents. 
However, there may be limits to this scalability and this is discussed in Section 5.5. Another 
desirable agent quality is the ability to stop, start, remove or dynamically introduce agents 
without interrupting the system. 
 
Agents in this environment become powerful when combined with other agents and are 
organized into communities or societies, in the case of MetaGlue [8, 13, 30]. These societies 
may be representative of logical workgroups, individuals or workspaces, which are all located 
behind a firewall. An individual in a room, for example, may have a camera agent and a 
microphone agent “attached” to them while they are in the room. The agents may move to 
different computer hosts to provide access to different cameras and microphones as the 
person moves across the room. However, there is currently no mechanism to extend the 
model beyond the room and the firewall although research is addressing this issue (see 
earlier in Section 3.1). Communication occurs when an agent produces or sends a message 
on a channel and any number of subscriber agents can receive the message. This 
publish/subscribe communication system succeeds in an agent community because it 
promotes non-blocking communication and loose coupling between agents. Both of these 
characteristics are desirable in workspaces. 
 
MetaGlue provides a flexible, functional and scalable infrastructure to allow research into 
future workspace requirements. The scalability attribute, however, must be qualified by the 
Terence Blackburn 23 Enterprise-enabled Ubiquitous WorkSpaces 
need to add a security blanket to control the activities of agent societies that need to exist 
outside of the corporate firewall. MetaGlue lacks an enterprise theme to support business 
processes rather than sensorally focused ad hoc activities. Debugging a set of heterogeneous 
agents can also present challenges, as there is no structure to support this activity. 
Fortunately, most agents are less than one page of source code and are not inherently 
complex.  
3.2 ODSI 
Overview 
The Open Distributed Services Infrastructure (ODSI), from Distributed Systems Technology 
Centre (DSTC) in Queensland, is a framework that supports the collaboration of enterprise 
resources, encapsulated as an enterprise model, to meet the challenge of an adapting 
enterprise [2, 3, 4]. 
 
The enterprise model can be described as a representation of the set of polices, data 
repositories and organisational roles that leverage enterprise assets to achieve enterprise 
goals. 
 
ODSI concentrates on providing collaborative services such as business process execution 
rather than data-driven applications and hence maintains an enterprise perspective rather 
than a software focus. 
 
It provides a service integration environment designed to combine enterprise-modeling 
techniques that incorporate shared enterprise information, such as policy, role and 
component descriptions, with lightweight workflow and dynamic service integration 
technology. It provides lifecycle management for distributed software services through a peer 
infrastructure and supports their collaboration to perform complex business processes [4]. 
Architectural Components 
This enterprise-focused infrastructure utilises an adaptive, enterprise bus called Elvin [33, 41], 
which is both a content-based routing engine and a lightweight notification service. Message 
producers detect events in their systems and send a notification to Elvin, which in turn passes 
the notification to any clients that have previously registered an interest in that event. (Events 
are changes in the state of an object.) Registration is affected by means of a flexible 
subscription expression, which is composed of name/value pairs. The difference between 
Elvin’s messaging model and most messaging systems is that Elvin’s message addressing 
method is motivated by the message content rather than a client address or channel name. 
Subscribers “require” any message that contains a specified word or phrase, for example, 
From == “Lucy” or To == “Tom”. The advantage of this approach is that it decouples 
Terence Blackburn 24 Enterprise-enabled Ubiquitous WorkSpaces 
producers and consumers and thus promotes system evolution, integration and client 
homogeneity [10]. 
 
ODSI work processes are driven by a workflow engine to enable resource coordination and 
process orchestration. Breeze, the workflow engine that was used in this experiment, is 
implemented in Java and can be used in a number of different modes:  
o as a standalone application 
o as a separate application but using Elvin as a communication mechanism 
o fully integrated into ODSI where Python scripts can used to invoke the engine and 
pass parameters seamlessly to the workflows. 
 
The third example, where Breeze is fully integrated into ODSI, was used in the case study 
although a Java client was used to start an instance of the workflow engine rather having it 
started by the ODSI management software. 
 
ODSI introduces an intermediate business logic layer that defines the coordination of 
enterprise services and resources independent of underlying technology [3] and this allows 
flexibility in the implementation of the infrastructure. Service components, which can be 
software applications, are dynamically assembled based on workflows and their execution is 
managed within the policies defined by the enterprise. By extracting this information from  
Figure 3.1 ODSI Architecture 
 
Terence Blackburn 25 Enterprise-enabled Ubiquitous WorkSpaces 
enterprise components, system behaviour can be changed without modifying service 
implementation. This is manifested through sub workflows and conditional branches in the 
main workflow. 
 
The Peer infrastructure manages the lifecycle of software services, which leverage enterprise 
resources (see Figure 3.1). It supports publication, discovery and management of these 
independent enterprise resources and there are three specific interfaces. 
 
o The peer to peer interface supports the discovery and allocation of service requests. 
Each peer understands its current service abilities and satisfies work requests when 
service requests are received through their particular service subscription. Remote 
Procedure Call (RPC) environments, by contrast, direct work requests towards a 
server thus making it the responsibility of clients to discover service provisions. 
o The client to peer interface is similar to the peer to peer interface as the client forms 
the equivalent of a dynamically allocated peer. It publishes a service request to any 
peer who will listen and waits for service fulfillment. This is registered as a return 
message of “failed”, “succeeded” or “still running”. If the peer is able to fulfill the 
request, the result is returned to the client. If not, the peer will forward the request on 
to any other peer that has subscribed to service descriptions that match the request. 
Peers maintain the service provision state of other peers by caching previously 
discovered service locations and similarly discard them when the services become 
unavailable. 
o The peer to service interface provides reflection, management and work allocation to 
services. A service wrapper translates between the enterprise service interface 
provided to the peer and the implementation of the service. The service 
implementation may exist within the wrapper itself or alternatively be accessed 
through application invocation, some middleware infrastructure (CORBA, Java, COM, 
etc.), or via a network protocol (HTTP, NNTP, SNMP, SMTP, etc.). 
 
At the heart of ODSI is a service management infrastructure that facilitates the coordination of 
software services to perform complex enterprise processes. Persistence is provided to the 
enterprise as the service and process definitions are stored in the Enterprise Model along with 
policies that effect the operation of the business. The storage mechanisms can range from a 
relational database to a flat text file. This execution of this persistence mechanism is 
expressed in the specific enterprise implementation. 
 
The ability to adapt to enterprise needs is expressed through the workflow engine. Breeze 
supports conditional workflows and sub workflows that can be created and loaded at runtime. 
In addition, workflows can be non-blocking, which allows a workflow to proceed without 
Terence Blackburn 26 Enterprise-enabled Ubiquitous WorkSpaces 
feedback from the existing process, or blocking, which means that it must wait for a response 
from the process before continuing with the workflow. 
 
Collaboration is an implicit feature of the ODSI framework and is expressed through the 
enterprise bus. Due to its message-based rather than service-based approach, all clients 
have equal and unrestricted access to the bus, up to the high throughput capabilities of the 
Elvin messaging server. 
 
Due to its lightweight design and implementation, state management and security were 
deliberately not included in this architectural paradigm but distribution is supported through 
the content-based messaging feature. 
Analysis 
A peer provides a container or habitat that is dynamically populated with services, which are 
made available to peers through enterprise interface specifications. These specifications, also 
called workflow stubs, provide reflection on their capabilities and are currently written in 
Python. Typically the interface describes mechanisms to start, allocate work, and terminate a 
service. Any required parameters are usually simple strings or integers. These enterprise 
interface descriptions are stored in the enterprise model, usually a database, and are linked to 
actual service implementations when a service is allocated to a peer. 
 
The peers communicate through an enterprise bus provided over the Elvin publish/subscribe 
notification service. By utilising content-based routing, they are able to ensure service 
availability and scalability and to dynamically form communication channels based upon 
service provision and requirements descriptions. The content-based approach does not tie 
the service requester to a particular peer, as it would with a service-based approach, but 
allows the peer to pass the service request to another peer if it cannot fulfill the request itself. 
Another feature of the content-based model is that there is no guarantee of message delivery. 
If a subscriber misses a message, it is not stored for later retrieval. 
 
ODSI has an abstract approach to providing enterprise services and applications, which 
allows organisational flexibility in implementation. The peer to peer approach to fulfilling work 
requests and undertaking workflow activities provides a sound basis for experimentation in 
future workspace design. However, it lacks the environmental sensors that are necessary to 
connect to human clients in a natural way. 
 
ODSI would be complemented by an infrastructure such as MIT’s 
MetaGlue or the Stanford Interactive Workspace environment, 
which would provide the eyes and ears to interact with the physical 
world. 
Terence Blackburn 27 Enterprise-enabled Ubiquitous WorkSpaces 
3.3 iROS 
Overview 
The Interactive Workspaces project at Stanford University [15, 16, 19, 37, 51] has developed 
a high level architecture, iROS [18], for organising multi-person, multi-modal interactions in an 
integrated space that combines multiple computer systems. The environment has an 
experimental hardware and software infrastructure that features large, high-resolution wall-
mounted displays, called Interactive Murals [16], two 18' by 4.5' rear-projection, touch-
sensitive SmartBoards (see Figure 3.2), collaborative, bottom projected tabletop displays 
called Interactive Tables (see Figure 3.3), as well as small, personal mobile computing 
devices such as laptops and PDAs connected through a wireless LAN. Specialized input and 
output devices such as LCD-tablets, laser pointer trackers, microphone arrays and pan-and-
tilt cameras are also present in the environment. 
Architectural Components 
The infrastructure supporting the intelligent room is based on the Intelligent Room Operating 
System (iROS). Events in the workspace are communicated from one device and process to 
another using a simple communication mechanism based on a tuplespace and the 
implementation in this environment is based on the TSpaces server from IBM [44]. Tuple 
spaces [15-9, 47, 50,] are based on Linda [22], a coordination language devised in the early 
1980s, which provides virtual, shared memory spaces for different processes and processors. 
They have been used for many years as a shared memory model for parallel and distributed 
computing architectures [22]. They decouple producers and consumers in time and space 
and provide interprocess communication and synchronisation, which is logically independent 
from the underlying network. 
 
Events in a system can be stored as tuples in a tuple-space [15]. (Tuples are simple data 
structures that have a name variable and zero or many variables.) This is analogous to a 
shared blackboard and publishing and subscribing to the tuplespace is sufficient to participate 
in the room infrastructure, which supports dynamic reconfiguration and allows components to 
remain very loosely coupled. 
 
Instead of a traditional event queue, the architecture utilises a heap abstraction, called the 
Event Heap [17], as the main communication mechanism between the software components. 
The event queue metaphor, which works well for a single user sitting in front of a single 
computer using a GUI, breaks down in an interactive workspace with multiple users sharing 
common hardware and software applications. The Event Heap is a mechanism by which 
multiple users, machines and applications can all simultaneously interact as consumers and 
generators of system events. An example of this feature is the ability of multiple users to 
operate mouse pointers simultaneously in the same display area. 
Terence Blackburn 28 Enterprise-enabled Ubiquitous WorkSpaces 
 Due to their lightweight nature, however, tuple space mechanisms only support small feature 
sets and do not provide a secure environment. There are also scalability problems where only 
one tuple space is implemented. Clients can post event notifications to the event heap, query 
the event heap for events matching a template, or subscribe for notification when another 
entity posts events matching a template. 
 
 
Figure 3.2 Large Displays at Stanford 
 
 
The room’s infrastructure has leveraged the benefits of standard off the shelf hardware and 
software by including a browser interface and mature development and authoring tools. 
 
One domain for PDA usage includes remote control and universal-interactor applications. To 
facilitate PDA interaction in the workspace, an application called the Usher [16] was created 
that behaves like an HTTP server. It converts well-formed PDA HTTP GET and POST 
requests that contain name/value pairs into operations against the event heap and tunnels 
event-heap remote procedure calls over HTTP. The usher is currently implemented as 
several Java servlets that plug into standard Java-supporting web servers. The opposite 
procedure is undertaken to query the event heap for events matching a template. A fat URL 
containing the encoded tuple is sent back to the browser enabled PDA. Using this 
Terence Blackburn 29 Enterprise-enabled Ubiquitous WorkSpaces 
mechanism, the usher can be invoked via almost any HTTP command and this again raises 
the lack of security issue. 
 
The Event Heap [15-9] is designed to be flexible, robust to the failure of individual nodes and 
lightweight. However, issues like lack of security limit its practical applications in an enterprise 
environment. A practice called snooping has been included in the design of the Event Heap 
that allows any consumer to browse any current tuple. This has obvious security ramifications 
in an enterprise environment where not all information is cleared for public release. 
 
Events auto-age and are garbage collected, so events can be posted without knowing 
whether or not they will be consumed and this has some similarity to the Elvin model. This 
feature, which supports disconnected or mobile environments, is a key requirement for future 
workspaces. It allows users with mobile computing devices, such as laptops and PDA’s, to 
seamlessly enter and leave the interactive workspace. While in the workspace, users can 
interact with an existing application and simultaneously control various hardware devices in 
the room. Depositing a tuple in a tuple space has the benefit of adding a persistent element to 
the model. 
 
Collaborative work has support through the ability for multiple users to interact using the same 
infrastructure. This allows data objects, for example, to be shared directly and interactively 
rather than having to save an object and copy/paste it to the other user’s space. This also 
involves an element of context awareness and adaptivity. 
 
Distribution is also directly supported theoretically if not practically. A user with web access 
from anywhere in the world can post a fat URL into the workspace and utilise any of the 
available facilities. In practice, however, few organisations would be comfortable allowing 
public exposure to the enterprise with an insecure connection. 
 
A number of projects [45] have been started that either extend the infrastructure in the room 
or build on the work in an unrelated domain by utilising the architecture in the room. Brief 
details of some of the projects are as follows. 
 
o A four-dimensional project management team [45] has been developing 2D and 3D 
visualisation tools to support the collaborative planning of large projects and facilities. 
The visualisations try to represent the metaphors and information contained in normal 
printed documents and are displayed on the large tiled sets of displays. In a similar 
way another team has applied advanced visualisation techniques to help debug large 
computer systems, log files and networks. 
 
Terence Blackburn 30 Enterprise-enabled Ubiquitous WorkSpaces 
o Medicine [45] has benefited from the facilities in the room through two projects. The 
first is creating computational technologies to support scientific collaboration and it 
focuses mainly on using the interactive mural in two way or N way meetings between 
individuals or groups. (The interactive nature of the room is also the cornerstone of an 
interactive learning experiment that seeks to investigate the requirements of distance 
learning with hands on and virtual experimentation.) The second project is driven by a 
3D Medical Imaging Laboratory and extends radiology into 3D space in an effort to 
explore the integration of high-density scan images with 3D volumetric rendering and 
analysis. 
 
o Another approach [45] has revisited the traditional meeting scenario and considered 
how the model can be extended to include remote collaboration, logging of activities 
and PDA/whiteboard interaction. 
 
 
Figure 3.3 Tabletop WorkSpace at Stanford 
 
Terence Blackburn 31 Enterprise-enabled Ubiquitous WorkSpaces 
Analysis 
Tuple spaces users can assume the roles of server or client and publisher or subscriber. The 
model also allows any client to access information or insert malicious information. This is a 
supported concept called snooping and has been mentioned previously. In this scenario, a 
user can take a tuple from the tuple space, alter it and replace it. This can be useful where a 
number of clients may wish to view an event but it can be dangerous when sensitive material 
is being processed. Tuple spaces suffer from a lack of security (as was mentioned with 
snooping), RMI can be a performance bottleneck and there is a high overhead associated 
with the repetitious serialising and deserialising of objects, which leaves a tuple space 
vulnerable to a denial of service attack. 
 
Multiple languages are supported for writing client interfaces and template matching rules for 
the tuple space are relaxed with regard to field size and field order. This adds a degree of 
flexibility that was not present in the original Linda model. 
 
The URL transport mechanism over HTTP can also support event notifications that may be 
triggered from within a web browser environment but the support for this feature is limited to 
static web pages rather than dynamic HTML, which is a security bonus. It dos not support 
client side or server side scripting features. 
 
The design of the Interactive Workspace superstructure and the iROS infrastructure creates 
an environment that lends itself to exploring enterprise workspace requirements. The tuple 
space mechanism and the HTTP server may support the level of scalability required in a 
distributed organisation. The Event Heap provides the flexibility to allow seamless client 
connectivity from legacy systems through to mobile handheld devices although research in 
the area of security will be a necessary precursor to widespread enterprise adoption. 
3.4 Roomware 
Overview 
The Ambiente [35, 54] project, which evolved from work started in the mid 1990s by GMD-
IPSI, Germany, has as its theme an office landscape for creative and innovative work, where 
computing devices are ubiquitously integrated into room elements. It is based on Roomware, 
which is a set of computer-augmented room elements such as walls, tables and chairs. These 
devices are supplemented by the Passage mechanism, which enables the physical 
transportation of digital information between different Roomware components. For example, 
digital objects can be passed between two chairs though the use of a neutral proxy object. 
Terence Blackburn 32 Enterprise-enabled Ubiquitous WorkSpaces 
Architectural Components 
Significant new electronic devices to emerge from this research include DynaWall [54], an 
electronic wall with a large interaction area, InteracTable, an interactive table for informal 
group work and mobile electronic chairs called CommChairs. Illustrations of these objects are 
included in this section. 
 
BEACH [35], which is synchronous groupware, provides the basic functionality necessary for 
cooperative work. Digital information structures are accessible via touch-sensitive interaction 
areas on the items of furniture and can be processed individually or in parallel in a group 
meeting. Accordingly, the user interface integrates the access to private and public 
workspaces. The "pen-centric" user interface enables the use of pens, fingers or similar 
objects to create and annotate documents as well as to trigger commands using gestures. 
Information objects can be “thrown” from one DynaWall to another, e.g., for structuring 
purposes. 
 
The InteracTable has a horizontal information display that has no predefined orientations 
such as top and bottom or North and South. Therefore, by rotating objects users can change 
the alignment of documents to the positions of the people standing around the table. Several 
views of the same document can be created and used simultaneously. 
 
Collaboration is one of the key themes of the Roomware components. For example, the 
chairs in the room are tracked electronically for position and location. This information is used 
to initiate a coupled session with shared displays between the CommChairs when they are 
moved together to form a collaborative unit. Users are able to remotely edit and annotate 
objects residing on other pieces of furniture. 
 
The project also supports state management, distribution and context awareness within the 
environment. This is exemplified in the a3 room where sensors are used to identify the people 
in the room. The room identifies the project that the group last worked and configures itself by 
restoring the state relating to the applications and documents involved in the project. 
 
Another example of state information management is highlighted with the Passage [35] 
mechanism. This is a process of connecting digital information objects to uniquely identifiable 
physical objects. The required information is selected and linked through software to the 
physical object on a special tray. This object can then be moved to another tray and all of the 
associated information sets can be retrieved, applications opened and appropriate network 
connections mounted. This also involves a substantial amount of persistent state information 
storage. 
Terence Blackburn 33 Enterprise-enabled Ubiquitous WorkSpaces 
Analysis 
While the Roomware products are examples of collaborative work environments, they do not 
necessarily follow the theme of pervasive computing where the computers are becoming less 
visible. Some of the interfaces, however, have obviated the need for keyboards and mice and 
have provided users with a high degree of flexibility. 
 
 
Figure 3.4 Discussions at the InteracTable. 
 
As discussed, the InteracTable (see Figure 3.4) has no notion of orientation and users can 
move objects around the able for easier viewing. Each user can their own version of the 
object, which is oriented to the position of the person. Are changes updated to all versions of 
the object and how is this interactively supported? Can data objects be shared in real time or 
do users have different instances of the object? 
 
Each CommChair is provided with an interface for a wireless network connection and an 
independent power supply. The chairs enable people to work privately and to connect to 
shared workspaces that may be displayed on the DynaWall or the InteracTable. Users can 
also edit and annotate objects on these Roomware components remotely. 
 
 
 
Figure 3.5 Two views of a CommChair 
 
 
Terence Blackburn 34 Enterprise-enabled Ubiquitous WorkSpaces 
The CommChairs (see Figure 3.5) combine the functionality of an office desktop computer 
with an armchair thus freeing the user from a conventional desk but is this small chair an ideal 
work environment and is putting two chairs together really a useful and efficient thing to do? 
 
The DynaWall (see Figure 3.6) is an "interactive electronic wall", which is manifested as a 
touch-sensitive information device. Its objective is to simulate a large, paper based surface 
 
Figure 3.6 Two users interact at the DynaWall 
 
 
whose interface enables a new set of intuitive, natural, human-computer interactions. It is 
possible that information objects can be taken from one position and placed somewhere else 
on the display or thrown from one side to the opposite side. What happens to the object when 
it lands? Gestures with hands and fingers empower the user with a more natural human work 
interface and this allows an expanded set of choices for editing and annotating large display 
areas. 
 
The Ambient workspace has a clear focus on collaboration and context awareness through 
the use of augmented room components, principally chairs, tables and wall displays. 
Workflow is supported but restricted at a low level to applications and individual projects. 
Even large projects are small components in an enterprise and there is no higher order glue 
for integrating the work components into an organisational context. 
Terence Blackburn 35 Enterprise-enabled Ubiquitous WorkSpaces 
3.5 TOPOS 
Overview 
As with AMBIENTE, (see Section 3.4), the WorkSPACE [29, 55] project from the University of 
Aarhus, Denmark, is a part of the European Union’s “Disappearing Computer” project. It 
focuses on moving from traditional screen and keyboard interfaces into pervasive computing 
where traditional user interfaces are replaced by a wide variety of new devices. The 
WorkSPACE project is based on an architecture called TOPOS, which is a re-write of the 
MANUFAKTUR [55] architecture. It is aimed at local and distributed work collaboration 
through the use of new software and hardware components integrated into various kinds of 
augmented reality workspaces, environments and fields. This is called a Spatial Computing 
Environment. The research has three focal points:  
o Spatial Computing in the Distributed Project Room 
o Object Centred Spatial Computing 
o Spatial Computing Artefacts in the Field. 
Architectural Components 
Human work activities often generate dynamic configurations of spaces, information, and 
people both within and outside of the office. These configurations include both digital and 
physical materials and a lot of work centres on making sense of one piece of information in 
relation to many others. Elements of spatial computing include embedded computing, 
augmented reality, distributed and co-located collaboration and enhanced user interfaces that 
include hearing, touching and tracking devices. 
 
Topos is the name of both the supporting software infrastructure as well as the client 
software, which presents a 3D interface to document and material organisation. The 
workspace in Topos is the primary means of grouping and organizing materials and 
documents in 3D space. 
 
Terence Blackburn 36 Enterprise-enabled Ubiquitous WorkSpaces 
 
Figure 3.7 View of a 3D Topos Client 
 
 
Figure 3.7 shows a screen shot of a Topos client and it depicts an open workspace containing 
a set of document objects. Double clicking any of the document objects will launch the screen 
document in its application and changes to it will be immediately reflected within Topos. The 
objects can be sized, moved and rotated, light effects may be applied and documents can be 
made semi-transparent or organized into groups. The screen shot also shows the use of a 
textured, light mapped and shadowed terrain, floating semi-transparent toolbars and a halo of 
manipulation tools around the selected objects. 
 
The Topos infrastructure consists of SQL databases to maintain persistent, collaborative 
workspace state, a real-time, interactive collaboration server and a location-based, service 
discovery framework to support configuration-less networked services. It is geared towards 
interactive walls and tables, mobile augmented reality, desktops and the Internet. It integrates 
with video tracking and GPS systems and can provide limited functionality inside a web 
server. 
 
The Tag-and-Track (TNT) Framework [29] services are written on top of the C++ framework 
developed within WorkSPACE. TNT is a location-based, service-discovery framework that is 
related to Universal Plug and Play and emphasises the provision of network services based 
on physical location. 
Terence Blackburn 37 Enterprise-enabled Ubiquitous WorkSpaces 
 In these 3D domains, work is characterised by a high level of cooperation. Groups of people 
can simultaneously work with the same information or material in different ways and at 
different locations. Attributes such as collaboration, context awareness, persistent storage 
and state management are important features in this environment and are critical for 
maintaining cohesive workflow. 
 
Adaptiveness, along with collaboration, is one of the key workspace descriptors. Without this 
element, the underlying technology would not be able to serve and maintain real-time 
environments to multiple users without reference to physical location. Updates to state or 
information made in one physical setting that is connected to a second environment, whether 
physical or virtual, need to be accommodated in real-time. 
 
Context awareness is a key component of the infrastructure and this is underpinned by 
Awareness Agents and a server to support off-line configurations. There is also a location-
based service discovery framework to support networked services. 
Terence Blackburn 38 Enterprise-enabled Ubiquitous WorkSpaces 
3.
6 
Su
m
m
ar
y 
of
 A
rc
hi
te
ct
ur
al
 F
ea
tu
re
s 
So
ur
ce
 
 
 
 
 
 
Pr
oj
ec
t
Fo
cu
s
In
fr
as
tr
uc
tu
re
K
ey
w
or
ds
C
om
po
ne
nt
s
M
IT
 
 
In
te
llig
en
t
ro
om
 
C
on
te
xt
 a
w
ar
e,
 d
ev
ic
e-
dr
iv
en
, c
ol
la
bo
ra
tio
n 
M
et
aG
lu
e 
(J
av
a)
 
M
ul
ti-
ag
en
ts
, m
ul
tim
od
al
, a
nt
hr
op
oc
en
tri
c,
 
in
te
ra
ct
iv
e,
 m
ul
ti-
de
vi
ce
 
M
et
aG
lu
e,
 s
oc
ie
tie
s,
 C
at
al
og
, 
N
ot
ifi
er
, h
ar
dw
ar
e 
an
d 
so
ftw
ar
e 
de
vi
ce
s,
 a
ge
nt
s 
 
St
an
fo
rd
 
 
In
te
ra
ct
iv
e
W
or
kS
pa
ce
 
La
rg
e 
di
sp
la
ys
, 
in
te
ra
ct
iv
e,
 s
m
al
l 
de
vi
ce
s,
 in
te
ra
ct
iv
ity
 
IR
O
S,
 E
ve
nt
 
H
ea
p 
(J
av
a)
 
Tu
pl
e 
sp
ac
es
, m
ul
ti-
de
vi
ce
, m
ul
ti-
m
od
al
, 
PD
As
, l
ar
ge
 d
is
pl
ay
 d
ev
ic
es
, f
lu
id
 
in
te
ra
ct
io
n,
 a
dv
an
ce
d 
vi
su
al
iz
at
io
n 
 
 
Ev
en
t H
ea
p,
 D
at
aH
ea
p,
 L
or
e,
 T
-
Sp
ac
es
, i
R
O
S,
 iC
ra
fte
r, 
Pr
ox
iW
eb
 
D
ST
C
 
 
 
O
D
SI
En
te
rp
ris
e 
m
od
el
s,
ab
st
ra
ct
 b
us
in
es
s 
pr
oc
es
se
s 
Pe
er
 to
 p
ee
r, 
en
te
rp
ris
e 
bu
s 
(P
yt
ho
n,
 C
) 
Pe
er
 to
 p
ee
r, 
co
nt
en
t-b
as
ed
 m
es
sa
gi
ng
, 
en
te
rp
ris
e 
ta
sk
s 
an
d 
ar
ch
ite
ct
ur
e,
 s
er
vi
ce
 
w
ra
pp
er
s,
 li
gh
t w
ei
gh
t, 
bu
si
ne
ss
 p
ro
ce
ss
es
 
 
El
vi
n,
 p
ee
rs
, e
nt
er
pr
is
e 
m
od
el
, 
bu
si
ne
ss
 p
ro
ce
ss
es
, w
or
kf
lo
w
 
en
gi
ne
 
G
M
D
 
 
 
Am
bi
en
te
Pr
oc
es
s 
or
ch
es
tra
tio
n,
co
lla
bo
ra
tio
n,
 
au
gm
en
te
d 
fu
rn
itu
re
 
R
oo
m
w
ar
e,
 
BE
AC
H
 
(S
m
al
lta
lk
) 
W
or
kf
lo
w
 m
an
ag
em
en
t, 
co
lla
bo
ra
tio
n,
 
vi
rtu
al
, d
ig
ita
l a
nd
 re
m
ot
e 
en
vi
ro
nm
en
ts
, 
m
od
el
es
s 
in
te
rfa
ce
, a
ug
m
en
te
d 
fu
rn
itu
re
 
 
C
om
m
C
ha
ir,
 In
te
ra
cT
ab
le
, 
D
yn
aW
al
l, 
C
on
ne
cT
ab
le
, 
R
oo
m
w
ar
e,
 P
as
sa
ge
 
Aa
rh
us
 
U
ni
ve
rs
ity
 
W
or
kS
PA
C
E 
3D
 d
is
pl
ay
s,
 s
pa
tia
l 
co
lla
bo
ra
tio
n 
To
po
s 
(C
++
) 
C
us
to
m
 c
om
po
ne
nt
s,
 a
ug
m
en
te
d 
en
vi
ro
nm
en
ts
, c
ol
la
bo
ra
tiv
e 
w
or
k,
 s
pa
tia
l 
co
m
pu
tin
g,
 in
no
va
tiv
e 
in
te
rfa
ce
s 
 
D
es
ig
ne
r’s
 W
or
kb
en
ch
, 3
D
 
W
hi
te
bo
ar
d,
 T
op
os
 
Te
re
nc
e 
B
la
ck
bu
rn
 
39
 
En
te
rp
ris
e-
en
ab
le
d 
U
bi
qu
ito
us
 W
or
kS
pa
ce
s 
3.5 Topos (Cont.) 
Analysis 
All collaboratively shared workspace state in Topos is kept in an SQL database. A 
collaboration server, which keeps track of connected clients, facilitates real-time collaboration  
and forwards update messages among the clients whether they are local or remote. The data 
to update the databases is not sent through the collaboration server, but stored directly in the 
database. Instead, an update message is sent to the collaboration server, notifying 
collaborating clients of the partial changes that have happened. An awareness agent watches 
changes made in workspaces and updates the state of closed workspace proxies to notify 
users who come on-line later, that changes have happened in those workspaces without 
users having to inspect the workspaces.  
 
This environment supports many of the attributes deemed desirable for future workspaces 
and this includes support for elements of group workflow. However, the workflow concepts in 
this research seem to be driven by ad hoc design projects rather than by a broader enterprise 
perspective. As such, the research is transferable to other generic design projects and similar 
work but may be difficult to translate to the higher-level business process orchestration that is 
important to enterprise continuity and workflow tasks. 
Terence Blackburn 40 Enterprise-enabled Ubiquitous WorkSpaces 
4. Case Study 
The case study uses a meeting as an example of a real world scenario that represents a 
common business activity. It has been used to explore the requirements of software 
infrastructures that are capable of supporting enterprise-enabled workspaces. A hybrid type of 
architecture approximates more closely to the key attributes identified in Section 2 so the 
integration issues are important but of a secondary nature. The hybridised framework also 
reduces development time as a number of key features need only be included rather than 
created. 
 
The case study experimented with the application and integration of two infrastructures, 
MetaGlue from MIT and ODSI from DSTC. MetaGlue was chosen for its strength in 
integrating and managing hardware and software devices in a workspace environment. ODSI 
was selected for providing an enterprise focus primarily, in this case, through the Breeze 
workflow engine and the Elvin-based enterprise bus. In the research, we hoped to achieve 
some understanding of the level of enterprise support that the integration exercise provides 
and to gain some insight into the extent of underpinning for future workspace characteristics. 
 
Section 4.1 revisits the LiveSpaces environment that was used in this case study and spends 
some time looking at its configuration. (This process is started in Section 4.1 and extended 
with some components in Section 4.3.) The LiveSpaces components are reviewed and their 
functionality and role in the experiment is described. The scenario for the case study is 
characterised in Section 4.2 and a small description of typical meeting activities is supplied. 
Section 4.3 reviews the experiment and spends some time looking at the component 
functions and, where necessary, extends the descriptions from Section 4.1. Section 4.4 
focuses on the programming aspects of the work and some of the source code details are 
discussed to illustrate the software features. (Full details of the source code are included in 
Appendix A.) This section concludes with a summary of what was achieved in the work and 
also what was not completed. This has been highlighted to convey a clear picture of what was 
achieved in the practical side of this project. 
4.1 LiveSpaces Configuration 
Operating Environment 
A future workspace environment called LiveSpaces has been configured with off the shelf 
technology to support research activities. It has been set up with computers that host a 
Microsoft Windows 2000 environment for supporting the web displays, MetaGlue, viaVoice 
and application software and a Solaris UNIX environment, which hosts the Elvin messaging 
server [8], the Breeze workflow engine and ODSI. 
Terence Blackburn 41 Enterprise-enabled Ubiquitous WorkSpaces 
Components 
The configuration for the LiveSpaces Environment, used in this case study, is depicted in 
Figure 4.1. LiveSpaces, due to its abstract nature, can simulate a plug and play framework. 
The component configuration used in this experiment can be juxtaposed with an alternative 
configuration as depicted in Figure 2.2 to illustrate the flexibility of the framework. 
 
A number of components from DSTC research have been incorporated into the framework 
and these include the Breeze workflow engine, which is a service offered by an ODSI peer, 
and the Bred graphical workflow editor, which is used to create workflow schemas for Breeze. 
The Elvin content-based messaging engine is used as the enterprise bus and the ODSI 
framework is used to enterprise-enable the architecture. 
 
The display and interaction layer hosts three different applications. The dialog interface 
utilises the viaVoice speech recognition engine from IBM and this is coupled to a headset 
 
Figure 4.1 LiveSpaces Architecture for Case Study 
 
microphone. A touch-sensitive, interactive SmartBoard is used as the main display device and 
results from the viaVoice-captured commands are output to this device. The framework has 
also been established to accommodate x10 device controllers. These are small hardware 
modules that regulate the state of simple devices such as lights, appliances and multimedia 
components. 
 
Terence Blackburn 42 Enterprise-enabled Ubiquitous WorkSpaces 
MetaGlue, the multi-agent system, provides the communications layer between the 
environmental interfaces and the enterprise bus. MetaGlue is responsible for channeling 
output from the viaVoice speech-to-text engine into the ODSI environment for processing by a 
workflow. 
 
A database is utilised by both ODSI and MetaGlue and, in this experiment, MySQL was used 
by both frameworks. MetaGlue uses the database to store information about agent 
occupations, agent attributes/values and agent societies. Breeze uses the database to store 
workflow schemas and templates and ODSI uses relational tables to store associated 
enterprise data. 
 
The workspace includes a 1.5 x 1.2 meter touch-sensitive Smart Board operated through a 
front mounted projector. IBM’s viaVoice speech recognition software processes the voice 
input and provides the speech-to-text functionality. R-JAX, a program from Stryon, processes 
event generated messages and passes them to MS Windows applications. These 
applications can be run collaboratively on the smart board displays or on personal notepad 
computers, which can communicate via an 802.11 wireless LAN. X10 device controllers are 
used to control various LiveSpaces devices such as lights and the coffee machine. 
 
The picture of the LiveSpaces environment in the e-World laboratory, as depicted in Figure 
4.2, shows three wireless notebook computers in the foreground, the interactive SmartBoard 
on the right of the picture and a coffee machine in the background connected to the x10 
device (not visible in the diagram) plugged into the wall. One of the users has a wireless 
keyboard and mouse while the other user is using a PDA. 
Terence Blackburn 43 Enterprise-enabled Ubiquitous WorkSpaces 
 
Figure 4.2 Technology in the LiveSpaces Environment 
 
 
4.2 Scenario 
An augmented, dedicated meeting space was selected as being a relevant scenario for the 
investigations. Activities normally conducted during meetings were considered as 
representative of the types of workspace activities that we might be interested in for future 
command and intelligence, planning and review environments. The aim of the experiment 
was to extend the meeting paradigm to incorporate workspace attributes such as context 
awareness, adaptability, collaboration and workflow process orchestration. This was to be 
supported by MetaGlue and ODSI. 
Meeting Activities 
This enterprise perspective in this project focuses on integrating the two architectures in an 
effort to extend the range of resources available to clients for future work activities, an 
example of which is a meeting. 
 
Typical activities that are undertaken during the course of a meeting to promote collaboration 
and workspace adaptivity include the following: 
 
o Data capture in the form of minutes and motions, analogous to state capture 
Terence Blackburn 44 Enterprise-enabled Ubiquitous WorkSpaces 
o Data interrogation by applications 
o Data display in either paper or electronic format 
o Collaborative, structured work such as discussion of agenda items  
o Unstructured, adaptive work such as discussions on general business 
o Steering activities, or process orchestration, usually from the chair 
 
The nature of the activities outlined in the above scenario match with the workspace attributes 
that the case study intends to explore. 
Meeting Workflow 
The chair starts the meeting with a command spoken into the microphone. viaVoice converts 
the words into text, which is passed in turn, to 
o a MetaGlue speech agent 
o the MetaGlue Notifier (the agent responsible for sending event notifications to 
subscribers) 
o the “Elvin client” agent 
o the Elvin messaging server. 
Elvin sends it to a subscriber, the ODSI peer that is hosting Breeze, the workflow engine. 
Breeze, acting as a service on the ODSI peer, processes the message and starts the 
appropriate workflow. The first task in the workflow turns on the coffee machine, loads a 
browser window and displays the agenda for the meeting. Breeze publishes these instructions 
to Elvin who passes them to a MetaGlue agent, which relays them to the MetaGlue Notifier, 
which, in turn, passes them to the appropriate service controller agents. The first of these 
messages is sent to an x10 device controller that turns on the coffee maker and an 
application controller, a wrapper agent for the web browser, processes the second message. 
This wrapper agent, which had subscribed to the second message starts the browser on the 
Smart Board and sends it a URL, which is a web page displaying the meeting agenda. 
4.3 Case Study Analysis 
The schematic in Figure 4.3 describes the integration of the MetaGlue and ODSI 
architectures along with the peripheral devices in the experiment. The colours delineate the 
two infrastructures and where they meet. This conjunction of ODSI and MetaGlue could have 
been created in a number of ways, all of which could be described either as some MetaGlue 
code working within ODSI the environment or some Python code executing inside a MetaGlue 
agent. The latter was tempting to use, as the Jython programming language would have 
Terence Blackburn 45 Enterprise-enabled Ubiquitous WorkSpaces 
 Figure 4.3 Schematic of ODSI Integrated with MetaGlue 
enabled an agent to invoke an ODSI workflow directly from the MetaGlue environment but we 
chose a similar solution. A Java program, called WfClient, which had already been written by 
DSTC, was designed to invoke the Breeze engine and start a workflow. Unfortunately some 
version mismatches slowed down our efforts to implement this code so it was not quite 
working at the end of our case study. 
 
Other sections of the diagram in Figure 4.3 detail where the devices are connected to the 
architecture and illustrate some of the available options for implementing workflow tasks. For 
example, the x10 devices can be controlled by any part of the infrastructure. MetaGlue has 
agents that can issue x10 instructions, Elvin could send simple on and off calls to appliances 
and the tuple space environment mentioned in the Stanford work, but not part of this 
experiment, also has support for x10 devices. 
Breeze Workflow Engine 
Breeze has been described as a lightweight, cross platform workflow engine. However, it 
does not schedule or run workflows in the accepted sense. It coordinates enterprise services 
to perform business processes or, in other words, workflow tasks are completed through 
service requests. The workflow tasks are issued as service requests to the local peer, which 
Terence Blackburn 46 Enterprise-enabled Ubiquitous WorkSpaces 
runs the Breeze engine. The peer then assumes responsibility for trying to implement the 
service identified in the workflow task. To paraphrase, the workflow engine asks for a service 
to be carried out but has no interest in how it is carried out or who carries it out. It only needs 
to know whether or not it has been carried out.  
 
The first action in the meeting used in our case study scenario can be used as a workflow 
example. A command is issued by the chair to open the meeting. The first workflow task is 
programmed to display a web page. Breeze asks a peer to undertake this service and only 
wants to know whether and when it is completed. Since it is implementation independent, 
Breeze can exist independently of service implementation and vice versa. 
 
Breeze provides a range of workflow features including sub-workflow execution, joins, data 
flow and control flow definition. It does not provide loops, as state management provides 
significant challenges but workflows may be built recursively by designing a sub workflow that 
calls itself. This simulates a loop but adds more user control through simpler state 
management. 
 
In the case study, the Breeze workflow was very simple. It consisted of subscribing to 
messages, processing them through the workflow engine and sending them to the Elvin 
server for a subscribing MetaGlue agent to receive. 
Bred 
Workflows are defined using Bred, a graphical workflow definition tool (see Figure 4.4 & 4.5). 
The workflow manager is able to select from a toolbox of logical business services and pre-
defined workflows to build new workflow definitions. The tool guides the user through service 
or sub-workflow selection as well as the mapping of data between the collaborating 
components. Workflows are generated by Bred and stored in two formats, in an XML format 
on the local file system and in an SQL database for later execution by the workflow engine.  
Brzmon 
The workflow manager, Brzmon (see Figure 4.6), is an asynchronous interface to the 
synchronous workflow engine. It manages a set of threads executing synchronous calls to the 
workflow engine. Brzmon keeps track of which workflows are being executed and their current 
state and, by querying Breeze, any sub-workflows that are active, can be monitored. Any 
workflow problems are propagated back to the workflow manager and a sub-workflow stack 
trace provided. Colours are used to indicate the status of the current workflow execution. Red 
indicates that a process has completed and green indicates that a task is active. The example 
in the Figure 4.5 is taken from the literature and does not represent the workflow in the 
meeting scenario, which is depicted in Figure 4.4. 
Terence Blackburn 47 Enterprise-enabled Ubiquitous WorkSpaces 
Peers 
A peer is an application server. It provides a container for services and has mechanisms for 
interacting with other peers for the lookup, discovery and management of services. To 
support this peer interaction, a communication model is required and ODSI uses Elvin. All 
peer services support a reflection interface that informs the peer of their capabilities. The host 
peer will then advertise this information to other peers. 
 
When a peer receives a request, it must decide how to process it. If the service request can 
be fulfilled locally, it will direct the request to the local peer. If the service is not available 
locally it will refer to its cached list of peers and their associated services to try and send the 
request to a peer with the capability to fulfill the request. If this is unsuccessful, the request 
will fail.  
 
Peers interact with their environment through three important interfaces: peer to client, peer to 
peer and the peer to service interface. The peer-to-client interface allows external parties to 
access services as well as provides service access for other services. 
 
Only one peer was used in the case study. It ran the enterprise database as a service, one 
copy of which must run to initialise and utilise ODSI services, and it also hosted the Breeze 
workflow engine as an enterprise service. For this experiment, the peer interacted with 
another party, the MetaGlue environment, on a peer-to-client basis and also on a peer-to-
service basis when using ODSI services and invoking a Breeze workflow. 
 
 
Figure 4.4 Meeting Workflow 
 
Terence Blackburn 48 Enterprise-enabled Ubiquitous WorkSpaces 
 Figure 4.5. Bred 
 
 
 
Figure 4.6. Brzmon 
 
 
Terence Blackburn 49 Enterprise-enabled Ubiquitous WorkSpaces 
Elvin 
Elvin is a notification/messaging service with a difference. Rather than messages being 
directed by applications from one component to another, Elvin messages are routed to one or 
more locations, based entirely on the content of each message. 
 
Elvin Version 3 [41-2] is an example of a content-based messaging service and provides the 
enterprise bus for ODSI. Elvin sends simple structured messages and allows clients to use a 
subscription language to select messages of interest. The messages are sent asynchronously 
and it is assumed that they arrive at their destination. There is no system of message 
acknowledgements or data resending in this model and there are no guarantees of message 
delivery. 
 
It uses a publish/subscribe mechanism and typically sends messages over event channels. 
Notifications are arbitrary sets of name value attributes and subscriptions are Boolean 
expressions, which are matched against the attributes of the notification. The Elvin server 
uses an algorithm to check the notification against any registered subscriptions and delivers 
the message to matching consumers. This makes the system decoupled, transitory, policy 
free, content based and dynamic. 
 
It is very simple to use Elvin, only three lines of Java are required to write a client and send a 
message. No sessions need to be set up, no logins are required and conversations are 
unidirectional. In addition to the normal primitives, the subscription language [42] supports an 
opaque data type, which allows serialised objects to be attached to a message.  
 
MetaGlue 
A number of MetaGlue agents were built for this experiment. (For more details see Section 
4.4) The important features that needed to be provided were: 
 
o Handling speech input and converting text to commands 
o Starting workflows from the ODSI environment 
o Starting applications on the display devices 
o Switching the state in devices from off to on etc 
o Communicating within the MetaGlue environment 
o Communicating within the ODSI environment 
o Communicating between the environments 
 
It is important for the LiveSpaces software infrastructure to be robust and dynamically 
reconfigurable to support new features in composable workgroup configurations. MetaGlue 
agents provide these desired attributes as agents can be automatically started, connected 
Terence Blackburn 50 Enterprise-enabled Ubiquitous WorkSpaces 
and distributed as required. All of the agents communicate through interfaces, as in the RMI 
model, and all agents must implement an agent interface. 
 
MetaGlue also includes a runtime environment, the MetaGlue Virtual Machine (MVM), which 
is a container environment for agents. There are special MetaGlue system agents that 
establish, distribute, and connect agents. These include the Catalog, which stores references 
to agent names and stubs, the Notifier, which is the agent communication channel and the 
Agent Manager, which must run in each MVM and is responsible for starting agents. 
 
R-JAX 
Stryon’s R-JAX [48] exposes the methods of Microsoft ActiveX, DLL and COM objects to any 
Java application running in a Java Virtual Machine. R-JAX enables any of the MetaGlue 
agents to invoke the methods and retrieve and modify the variables of the COM or ActiveX 
object, as if they were accessing native Java objects (see Figure 4.7). 
 
 
Figure 4.7 Superset of R-JAX Functionality 
 
A direct access interface is provided for Java technology and COM programs that reside on 
the same computer as the R-JAX server, which runs on the Windows server where the 
COM/DLLs reside. 
 
In our case study, a dedicated agent, the ExplorerWrapperAgent, acts as an interface 
between the MetaGlue environment and an application wrapper, which in this example, wraps 
Internet Explorer. The agent and wrapper are tied to the computer that hosts the R-JAX 
software and the Windows application. Internet Explorer is used to display the meeting items 
such as the agenda in the first workflow task. 
Terence Blackburn 51 Enterprise-enabled Ubiquitous WorkSpaces 
ViaVoice 
This program allows a user to navigate through applications and around the Internet using 
natural language voice commands. Dictation can be performed using Microsoft Word or e-
mail. Applications can be opened and closed and a subset of commands is available for a 
number of programs. While these features are available in viaVoice, they were not used. 
Instead, the open and close commands are created in a grammar file that is used by the IBM 
Java Speech application. This allows fine-grained control over applications and a closer fit 
with the methods available from within the application. 
 
In our meeting scenario, viaVoice was used to capture user commands from a microphone 
and convert the spoken commands into text. A downstream MetaGlue Speech agent then 
processed the text commands according to the relevant contextual business processes. 
SmartBoard 
The interactive SmartBoard turns a computer and projector into a tool for teaching, 
collaborating and presenting. With a computer image projected onto the board, a user can 
touch its large, touch-sensitive surface to access and control any application. Using a 
coloured electronic pen from the SMART Pen Tray, a user can work at the board to take 
notes or highlight important information or open and manipulate applications. In the case 
study the SmartBoard was used to display web pages with agenda items for the meeting. 
X10 devices 
X10 is a communications "language" that allows compatible products to talk to each other via 
the AC electrical wiring in a building. No rewiring is necessary in most cases, although in the 
e-World lab the existence of different power circuits limited the flexibility of the x10 devices. 
The installation of a coupling device at some point in the future to link the circuits will allow the 
x10 signals to communicate freely throughout the room. 
 
Activation messages can be sent either of two ways. Either a plug-in unit with an antenna 
catches the radio signal from the wireless transmitter and puts the X10 signal onto the line or 
a transmitter module is used to directly couple a computer to the power network through an 
RS232 serial connection. The latter was used in the LiveSpaces environment. 
4.4 MetaGlue Code 
This section displays and discusses the source code for some of the agents and applications 
that were required to build the LiveSpaces environment. A description of the correlation 
between the processes in the case study and the programming work is detailed in Figure 4.8 
The figure describes the three separate process streams that, in total, comprise the 
functionality of the LiveSpaces example. The two points displayed in red highlight the two 
areas that were incomplete at the time of submitting this thesis. The point under the 
Terence Blackburn 52 Enterprise-enabled Ubiquitous WorkSpaces 
x10Devices source code identifies a problem communicating with the serial port on the 
application computer that hosted the x10 devices. The second unfinished point relates to 
software version mismatches that were experienced with the Breeze workflow engine and the 
application used to instantiate a workflow from within the agent environment. 
 
In the source code examples, only the relevant methods are included. The full source code for 
the MetaGlue agents and the ODSI workflow examples is contained in Appendix A. 
 
SpeechAgent 
This agent loads a grammar file, which contains predefined phrases and checks the incoming 
text message from the IBMJS application against this set of commands. The grammar file in 
this experiment is the simplest possible with only one command to process. 
#JSGF V1.0; 
grammar myprojects.test.explorer; 
public =open explorer ; 
 
It is loaded in the following manner using the loadGrammar() method from the 
GrammarInspectorAgent class, which inherits from the agentland.resource.ManagedAgent 
class. 
loadGrammar("myprojects.test.explorer") ; 
 
It then uses the reliesOn( ) method to make sure there is an instance of the ExplorerWrapper 
active. If there is no active instance, MetaGlue will start one on the designated host, in this 
case the host identifier is “hostname”. 
explorer=(ExplorerWrapper)reliesOn("agentland.iroom.application.explorer.ExplorerWrapper", 
"hostname"); 
 
(The agent name “ExplorerWrapper” does not reflect the functionality of the agent.) 
Abstract Process Center 
This term has been employed to make the meaning of the workflow clearer. All of the 
perceived functionality in the Process Center is contained in other agent code. For example, 
to send a command to an application wrapper, the SendAgent code would be used. Rather 
than use the term SendAgent repeatedly to invoke different functions in the LiveSpaces room, 
the Process Center is used to receive requests and dispatch workflow processes to agents. 
Terence Blackburn 53 Enterprise-enabled Ubiquitous WorkSpaces 
SendAgent 
This code for SendAgent and ReceiveAgent is used for agent communication within the 
MetaGlue system. The reliesOn() method is used to ensure that there is a Processx10 agent 
available.  
x = (Processx10)reliesOn ("myprojects.test.Processx10") ; 
 
The next line ensures that the Notifier is listening for any messages that are being published. 
Not = (Notifier)reliesOn ("agentland.util.Notifier");  
 
A string, labeled s, is sent on the channel called ‘test’. (A secret is a message.) 
not.notify(new Secret(getAgentID( ), "test.channel", s)) ; 
ReceiveAgent 
In a similar manner to SendAgent, this code is also used extensively throughout MetaGlue. In 
this example, the ReceiveAgent sets up a connection to the notifier and then, on the next line, 
subscribes to a channel called “test” by using the addSpy( ) method. The agent will receive 
any messages sent on this channel. 
notifier = (Notifier)reliesOn("agentland.util.Notifier") ; 
notifier.addSpy(getAgentID(), "test.channel") ; 
 
The tell() method is used to receive the message, called a secret, and divulge its contents. 
Here, the method prints the channel name, the contents of the message and the name of the 
agent that sent it. 
System.out.println ("channel = "+ secret.name( )); 
System.out.println ("message = "+ secret.details( )); 
System.out.println ("agentID = "+ secret.getSource( ).toString( )); 
 
ExplorerTestAgent 
This (inappropriately named) agent is used to set up a connection with Elvin, the message 
router. It demonstrates how to create subscriber code, message producer code and then 
demonstrates the usage of the two features. 
 
First a message producer is set up. The next piece of code is used to create a message and 
then send it. The line notif.put adds a string to the message. This string includes the word 
‘demo’, which will be used in the subscription. 
 
Producer prod = new Producer(new ElvinURL("elvin://river")) ; 
Notification notif = new Notification() ; 
notif.put("demo","from terence ") ; 
Terence Blackburn 54 Enterprise-enabled Ubiquitous WorkSpaces 
prod.notify(notif); 
 
The next piece of code builds an Elvin consumer and a subscription. The subscription 
‘requires’ that any message containing the word ‘demo’ is passed back to the subscribing 
client. 
 
Subscription sub = new Subscription("require(demo)") ; 
sub.addNotificationListener (this) ; 
Consumer cons = new Consumer(new ElvinURL("elvin://river")) ; 
cons.addSubscription(sub) ; 
 
The final method is activated when the Elvin messaging engine sends a message that 
matches the subscription requirements, in this case if the message contains the word ‘demo’. 
In the method below, the message is printed to the screen. It can be processed in other ways. 
 
System.out.println(event + "terence's message..."); 
ExplorerWrapperAgent 
The code in this agent is used to start the application, Microsoft Internet Explorer. The 
commands from the speech capture agent are processed then passed in the form of a hash 
table. If the hash table contains the correct “rule”, which is “open” in this case, the 
corresponding methods are invoked. 
if(tags.get("rule").equals("open")) 
    explorer.startApplication( ); 
 
Once Internet Explorer is started, subsequent commands can be issued. In order, a URL is 
requested, the application is told to wait for 10 seconds and then the home page is retrieved. 
 explorer.gotoURL("www.unisa.edu.au"); 
 Thread.sleep(10000); 
 explorer.goHome( ); 
 
Processx10Agent 
The workflow engine may issue a command to turn on an appliance. The command is sent 
through Elvin to a Processx10Agent, which parses the message to extract the relevant data. 
The data will identify the device by a label and specify whether the device should be turned 
off or on. 
 
Each x10 device has an identifier that is composed of two parts. The first part is an alpha 
character between ‘a’ and ‘p’ inclusive and the second character is a number between 1 and 
Terence Blackburn 55 Enterprise-enabled Ubiquitous WorkSpaces 
16 inclusive. Devices may share the same identifier and, in this case, the devices will process 
the same command. Commands are usually sent to change the state of a device from off to 
on or vice versa. Lights, however may accept a command that changes the level of brightness 
or a dim command. 
 
The x10 devices cannot be queried to determine their state so it must be stored separately 
and this has not been implemented in this experiment. Neither is it possible to determine 
whether the appliance is plugged in or unavailable. Serial port problems can be addressed, 
however, through the normal Java exception handling methods 
 
The following line of code in the doX10( ) method of the Processx10Agent class creates an 
x10Devices object. 
 
x10 = new x10Devices ( ) ; 
 
The turnOn( ) method (and the turnoff() method) from the x10Devices class takes two 
parameters. These parameters identify an x10 device. In this example, the x10 interface to 
the coffee maker in the LiveSpaces room is designated E5. Each of the components in the 
label, ‘e’ and 5, is sent as a separate parameter. Both are converted to bytes in the 
x10Devices class. 
x10.turnOn ('e', 5) ; 
X10Devices 
This piece of code starts an x10 device such as a coffee maker or a light. The primitives that 
are sent to the serial port must be bytes so the input parameters, housecode = ‘e’ and module 
= 5, are converted at the start of the method.  
 
house = (byte)housecode;  
mod  = (byte)module ; 
x10  = new SerialX10 ( ) ; 
 
A SerialX10 object is created and the open( ), turnOn( ) and close( ) methods are invoked 
from the SerialX10 class. The balance of the code is used for catching exceptions. 
x10.open ("COM2") ; 
x10.turnOn(house, mod) ; 
x10.close() ; 
 
Terence Blackburn 56 Enterprise-enabled Ubiquitous WorkSpaces 
StartWfAgent  
This class invokes a Breeze workflow directly from a MetaGlue agent running within a Java 
Virtual Machine. It does this by creating a WfClient object and passing a string as a parameter 
to the first workflow task. A number of different command line parameters must be included to 
start the workflow. This agent requires a set of string parameters that are used to invoke the 
workflow engine and supply a command and, optionally, some name value pairs. The 
StringTokenizer is used to break the input string into a series of smaller strings, which are 
stored as tokens. These are passed to a string array and then to the run( ) method of the 
workflow client software, WfClient, which processes the array values accordingly. 
 
The first line saves the command line parameters from the input string s in a variable. 
tokens = new StringTokenizer(s) ; 
 
The next line creates a string array. 
cmds = new String[tokens.countTokens( )] ; 
 
The next two lines create the WfClient object and invoke its run( ) method with the array as an 
input parameter. 
wf = new WfClient () ; 
wf.run(cmds) ;  
 
WfClient 
This class contains the run( ) method that starts the Breeze workflow from the MetaGlue 
agent. It was supplied by DSTC and has been modified to fit the LiveSpaces environment. It 
takes an array of strings passed form the StartWfAgent code and processes it in order to 
configure the workflow engine. Towards the end of the code, the invoke( ) method, which is 
part of the Server class in ODSI, is used to start the workflow. This is where control passes to 
the ODSI environment. 
ODSI Code 
All communication within ODSI uses the Remote Procedure Call (RPC) method through Elvin 
to pass messages from one peer to another. A handle to the peer is created using the 
following call, which uses strings for its arguments. 
peer = misc.get_peer(‘peer_name’, ‘network_name’) 
 
The peer instance can then communicate with ODSI by calling the rpc( ) method with the 
following string arguments   [args=??].  
res = peer.rpc(‘wrapper method_example’, argument=1) 
 
Terence Blackburn 57 Enterprise-enabled Ubiquitous WorkSpaces 
Peers are only interested in whether or not a service has been performed and, consequently, 
all return values from a service invocation call are one of: succeeded, failed, aborted or 
running. If no return message has been received after a timeout value has elapsed, an abort 
value will be assumed. 
test_client 
This code, called test_client.py, is used to test the functionality of the workflow interface called 
running_test and it supplies the equivalent functionality of WfStartAgent and WfClient. The 
program starts Breeze, loads the running_test workflow and waits for a message. When one 
is received, it performs some string manipulation and returns a message to the workflow. 
When a message is received, it is manipulated by reversing its string order before being 
returned via Elvin. 
m = list(m) 
m.reverse() 
m = ''.join(m) 
send_reply(id, m, TIMEOUT) 
 
A connection to Elvin is created. 
client = elvin.client(elvin.ThreadedLoop) 
 
This line creates a subscription to Elvin messages with a particular message ID and sets the 
Boolean reply value. 
sub = conn.subscribe("require(MSG.ID)", 1, None) 
 
This method, defined at the start of the code, loads Breeze and the workflow. 
start_workflow() 
 
running_test 
All requests to peers are Elvin event notifications and are comprised of a sequence of 
attribute/value pairs. The peers use several of these attributes/value pairs for the message 
protocol. 
ODSI.From Name of the requesting peer.  
ODSI.To Name of target peer.  
ODSI.Interface Name of the service and function being requested.  
ODSI.Instance Unique identifier for this interaction. 
 
An example of the ODSI message format is detailed as follows. 
ODSI.From Terence 
ODSI.To Damien 
Terence Blackburn 58 Enterprise-enabled Ubiquitous WorkSpaces 
ODSI.Interface e-World turnOn_coffee 
ODSI.Instance 345km9gf8ifm4 
Name start_expresso 
 
This uses the turnOn_coffee wrapper in the e-World namespace. 
turnOn_coffee (name="start_expresso") 
 
running_test is a Breeze service wrapper which works in conjunction with the test_client code. 
It has two methods, which are advertised as being available, called send( ) and query( ) and 
the two methods are called separately. The send( ) method creates a message, publishes it to 
the enterprise bus and broadcasts a succeeded notification. A connection to Elvin is created. 
self.client = elvin.client(elvin.ThreadedLoop)   # plus other code 
 
A subscription is created and registered. 
sub = self.conn.subscribe('MSG.reply == "%s"' % id) 
sub.add_listener(self.__reply, self.conn) 
sub.register() 
 
The send( ) method is invoked, which sends a string as a message. 
n = {'MSG.ID': sha.sha(time.asctime()).hexdigest(), 'MSG.reply': 0, 'MSG.msg': msg} 
self.conn.notify(n) 
 
The workflow checks to see if there is a reply. (This is part of the constructor.) 
self.recieved = threading.Event() # check for reply 
 
The workflow waits until it receives a message and then query( ) method sends a reply. 
n = {'MSG.ID': id, 'MSG.reply': 1, 'MSG.msg': msg} 
self.conn.notify(n) 
 
The query( ) method creates a message in the ODSI format as detailed above, then a 
message is created. 
id = sha.sha(time.asctime()).hexdigest() 
sub = self.conn.subscribe('MSG.reply == "%s"' % id) 
sub.add_listener(self.__reply, self.conn) 
sub.register() 
 
The method is published to the ODSI network. 
n = {'MSG.ID': id, 'MSG.reply': 1, 'MSG.msg': msg} 
self.conn.notify(n) 
 
Terence Blackburn 59 Enterprise-enabled Ubiquitous WorkSpaces 
The method then sends ODSI a message to say that it is running and waiting for a response 
to be returned. 
self.Running() 
4.5 Results of Experiment 
The Merriam-Webster’s dictionary defines research as “investigation or experimentation 
aimed at the discovery and interpretation of facts”. This description embodies the work that 
was undertaken in this experiment. We had Beta versions of software to work with, for 
example, MetaGlue 0.5 and Breeze 0.5, we had new interfaces to explore, such as the x10 
serial devices and we had integration issues to contend with for an environment that has 
never been built. This is what makes research vibrant. 
 
We did not quite finish all that we started out to achieve but at the time of completing this 
thesis we have come close. The work that we have started will continue and it will be 
extended in different directions over the next few years as part of other projects. We have 
created the foundation for some interesting and useful research into future workspaces and 
related areas. 
 
To put the work that we completed in context, the meeting scenario must be revisited. A 
normal meeting will proceed along the following lines in the LiveSpaces environment. The 
following is an overview, as some of the minor details have been omitted for clarity: 
 
Figure 4.8 Workflow Execution for a Meeting. 
Terence Blackburn 60 Enterprise-enabled Ubiquitous WorkSpaces 
 1. Capture Voice Command: the chair starts the meeting with a command spoken into 
the microphone. 
2. Convert voice to text: viaVoice converts the speech into text 
3. Compare text to commands: the text is passed in turn to a MetaGlue speech agent, 
which uses the “explorer” grammar to identify the commands issued 
4. Send command to Notifier: the command is sent to the MetaGlue Notifier (the agent 
responsible for MetaGlue communications) 
5. Receive command from Notifier: The command can be parsed and processed 
6. Send command to x10 device: these commands can optionally be executed directly 
rather than by the workflow engine 
7. Send command to start application: applications can optionally be invoked directly 
rather than by the workflow engine 
8. Produce Elvin message: the “Elvin client” agent and the Elvin messaging server, 
which sends it on to an ODSI peer subscriber. 
9. Start a workflow: the correct parameters, if any, are included 
10. Start Breeze and invoke a workflow stub: The Breeze workflow engine is started and 
it then loads the required workflow script from the enterprise database 
11. Send ODSI message to Elvin: the Breeze workflow task instructions are sent through 
Elvin  
12. Receive Elvin message: this returns execution to the Abstract Process Center 
13. Process Elvin message: the message is parsed and processed and any commands 
are relayed via the MetaGlue Notifier to any device agents or application controller 
agents that can handle the request. A specific host can be specified, if required 
14. The first workflow task turns on the coffee machine 
15. A wrapper agent for the web browser processes the other part of the message and 
passes it through the R-JAX server, which starts the browser on the Smart Board and 
sends a URL to the browser. 
 
Figure 4.8 also highlights the two code points that need to be completed in this scenario. A 
detailed summary of the source code is highlighted in Section 5.12 and the two sections that 
need further work are also detailed. 
 
The actions in the meeting scenario above would encompass the greater part of a standard 
meeting. Commands to browse backwards and forwards through the agenda items required 
the use of the ‘back’ and ‘next’ commands in the browser. These instructions would not 
logically be a part of the Breeze workflow but could be processed directly by a MetaGlue 
agent. The workflow would cycle through the agenda items and display different web pages. It 
may have a conditional branch that starts a PowerPoint presentation and it may have sub 
workflows that would process a set of instructions for a particular agenda item. All of these 
Terence Blackburn 61 Enterprise-enabled Ubiquitous WorkSpaces 
actions can be described by the activities in the scenario described in Figure 4.8. All of the 
code to implement these actions has been created in the case study. 
 
The code does not have the capability to handle errors. Some Java processing errors will be 
caught but problems with the workflow may halt execution of the meeting flow. Breeze does 
not store state and will consequently be unaware of the status of the workflow. The agent 
system is unable to interrogate devices to determine their status and will be unable to 
accommodate requests to restore a required state. This is a serious pitfall in the workflow 
model and one of the ramifications of trying to integrate the two dissimilar architectures. 
 
Some of the benefits that arise from the research include the ability to leverage COM objects 
from within the Java environment, the ability to access enterprise resources from the multi-
agent system and the benefit of being able to incorporate new interface devices such as voice 
activation. 
 
Some of the weaknesses that become apparent include the inability to handle errors and 
failures (as discussed above), simplistic workflow task execution results such as failed, 
running or succeeded and the high level of vocal training that is required by viaVoice. 
 
Data sources are a vital component in any enterprise but they have had little mention in this 
thesis. Even in a meeting scenario, data items will need to be retrieved and reviewed and new 
information will be processed and stored in a database of some type. We have taken the 
approach that, while information manipulation is a critical exercise in any enterprise, it is 
already a mature activity and including it in our work would add little to the research. 
 
Terence Blackburn 62 Enterprise-enabled Ubiquitous WorkSpaces 
5. Discussion 
Agent based systems, messaging systems and tuple spaces represent three approaches that 
were discussed in the literature review in Section 3. They exhibit many desirable future 
workspace characteristics but no one architecture provides all of the characteristics and this 
has been one of the main motivations into exploring this aspect of ubiquitous enterprise 
computing. In this section, MetaGlue and ODSI, the infrastructures used in the case study, 
are discussed within the context of LiveSpaces characteristics and the strengths and 
shortcomings of these architectures are considered. 
 
Preliminary results indicate that it is possible to aggregate and blend the strengths and 
benefits of the individual software infrastructures to extend the LiveSpaces environment with 
enterprise-enabled characteristics. ODSI has a strong process orchestration focus and was 
able to leverage the adaptive, device management features of MetaGlue while MetaGlue has 
strong context awareness and collaborative features that were enhanced by integrating the 
ODSI enterprise workflow concepts. It is analogous to giving eyes and ears to a structured, 
work focused person who cannot see or hear. 
 
A number of aspects relating to the case study will be discussed in this section and the first 
issue examines the implementation experience. There were a number of choices that needed 
to be made on how to approach the integration questions and some time will be examined. 
The topic of enterprise service provision is discussed at length and this is followed by an 
examination of some of the architectural approaches taken by MetaGlue and ODSI. This 
leads the discussion into interoperability and how bridging into MS Windows applications fits 
into the LiveSpaces infrastructure. 
 
The balance of this section examines the role of the enterprise attributes, which were 
examined in Section 2, within the LiveSpaces setting. Separate paragraphs cover each of the 
characteristics of: security, scalability, orchestration and synchronisation, adaptiveness, 
persistence and state, context awareness, collaboration and distribution. The descriptions in 
Section 2 are expanded within the context of the experiment and some conclusions become 
apparent. This is followed by a summary. 
 
This Discussion section finishes with an outline of several areas that represent future 
research directions and this also introduces the attributes of tuple spaces, which feature in the 
Stanford research but have not been mentioned here at any length. Tuple spaces were not 
included in our experiment but appear to offer a range of benefits for enterprise-enabled 
workspaces. 
Terence Blackburn 63 Enterprise-enabled Ubiquitous WorkSpaces 
5.1 Implementation issues 
MetaGlue can be downloaded from the MIT Intelligent Room website along with 
documentation and startup instructions. Installing the software was straightforward and the 
accompanying test environment was utilised extensively to trial prototype agents. When it 
came to extending the set of agents that accompanied the code, problems were experienced 
with the x10 devices. While there was example code that opened and closed a set of curtains, 
the implementation appeared to be taken from a fully featured agent environment, which 
meant that it was necessary to create x10 agents with a full state management harness. This 
meant that deploying an x10 device controller became a complex exercise and, consequently, 
lack of time precluded using this feature. Fortunately, there was an example of an application 
wrapper agent available and this facilitated the presentation of web pages on the SmartBoard. 
 
ODSI seems to be an architecture that was designed and implemented in an early release by 
researchers at DSTC and there do not appear to be plans to develop the infrastructure 
further. It has a sensible philosophical approach to designing architectures with an enterprise 
focus and represents a sound experimental platform for enterprise research. The 
infrastructure lacks documented support but the researchers in the e-World laboratory 
enjoyed solid email and phone support when it was required from the developer organisation, 
DSTC. 
 
As a result of experimenting with ODSI, several interesting issues arose. The first was that 
once a service request is sent to ODSI, no further action was necessary. The peer to peer 
infrastructure assumes responsibility for fulfilling the request and finding a peer that can 
provide the service. For example, when a request is sent to ODSI, via Elvin, to start a 
workflow, a peer starts an instance of Breeze and passes in any values to the workflow. 
 
However, Breeze does not perform work in an intuitive manner. It was not designed with the 
capability to launch or monitor enterprise services but has an abstract approach to fulfilling 
work requests. It implements workflow requests by directing peers to start and manage 
enterprise services that are defined and reside elsewhere. This makes it a useful coordination 
engine and, given its features, such as sub workflow tasks, conditional branching and 
recursion, it can be effective in coordinating workflow requests. Breeze also has the capability 
of operating in a stand-alone mode, separate from ODSI, and using remote procedure calls or 
Java’s remote method invocation to call external services.  
 
Breeze allows blocking workflows that can accept new sub workflows at runtime and although 
this allows a workflow to be started without sub workflows being defined, a workflow cannot 
be changed dynamically. To change an active workflow, the engine must be stopped and the 
new workflow loaded. This describes support for process orchestration but a lack of support 
for adaptiveness and the rapid, dynamic composition of workspaces. 
Terence Blackburn 64 Enterprise-enabled Ubiquitous WorkSpaces 
5.2 Service Provision 
The MetaGlue and ODSI models share a similar approach for providing services to the 
enterprise. This is loosely based on a set of peers that can perform specific services when 
requested and it stands in contrast to a centralised model of service provision where all 
requests for fulfillment are channeled through a central authority. Certain core services are 
available in the peer architecture and these usually comprise the basic functions that are 
needed to boot the system (see Figure 5.1). 
 
We have not defined the term “peer to peer” in order to distance ourselves from any potential 
discussion on the subject but, instead, we have looked at some of the characteristics of the 
peer to peer model and placed ODSI and MetaGlue within this context. 
 
In a generic peer to peer model, all peers are equal. They advertise their state and the 
services they can provide and other peers store the information. Peers must also advertise 
any changes to their set of services so that other peers have a current picture of the system. 
Peers all use the same peer management software to perform their management duties. 
Peers can perform services themselves or pass the service request to another peer if it is 
more appropriate. For example, a particular light, rather than just any light, may need to be 
switched on and this will require service provision on the host for that light service. In this 
example, the peer passes the service request to the peer operating on the light’s host. 
 
ODSI needs to load the Enterprise Model on at least one and usually only one peer. (The 
Enterprise Model has been defined as support for enterprise roles and policies, which are 
stored and accessed from data repositories, and business processes which, are expressed as 
workflows (see Section 2.7.3)). It is unclear how the architecture would operate if the 
Enterprise Model was loaded onto more than one peer, but it is possible that some degree of 
confusion could appear. For example, if there are two versions of the enterprise model loaded 
and there is a request to load and start Breeze, can ODSI arbitrate between the different 
implementations and only load one? If two versions of Breeze are instantiated, they will both 
subscribe to the same Elvin-routed service requests. Will both versions of Breeze load an 
instance of the workflow interface and execute the workflow? If there are two versions of the 
same workflow stub to load, which gets loaded and which database is it saved to? There may 
be simple answers to these questions but it seems likely that only one enterprise model would 
exist in each ODSI domain. 
 
MetaGlue has an agent called the “Agent agent” from which all agents extend and inherit their 
primitives. This includes system agents such as the Catalog agent and the Configurator 
agent. Its main function is to start agents automatically in the system and this function is 
analogous to loading an ODSI peer on a host, except that ODSI peers must be loaded 
manually. 
Terence Blackburn 65 Enterprise-enabled Ubiquitous WorkSpaces 
 MetaGlue has an agent, which performs an ODSI “Enterprise” type role, called the Catalog. 
This Catalog Agent allocates unique names to agents and stores the agent name details in a 
database. Only one catalog can exist in an agent society. In addition, there are other helper 
agents that have similar administrative functions such as the Attribute Manager agent, the 
Configurator agent and the Notifier, which, like Elvin, facilitates communication in the 
architecture. 
 
The agent that shares a similar attribute set to an ODSI Peer is the Manager agent and its 
main role is to supervise a container environment called the MetaGlue Virtual Machine 
(MVM). All Manager agents use the same management software to search for agents in the 
MVM that they maintain and start them or stop them as requested. For example, if an agent 
requires a service to be fulfilled on a particular host, the Manager agent will either find the 
required agent in the MVM or, if one does not exist, start one up to provide the service. If 
there is no Manager agent or MVM on the target host, MetaGlue will invoke a daemon that 
will spread MetaGlue to the host, create an MVM and start a Manager agent, which will then 
start the required agent to provide the service. This functionality extends beyond that of an 
ODSI peer, which must always be loaded by hand when a system is booting. 
 
Some of the MetaGlue behaviour is similar to that of a peer to peer model but it probably 
exceeds the definition and is not a peer to peer structure. This is due to the heterogeneous 
nature of agents, the central administrative structure and the ability to move services (agents) 
from host to host as required. 
 
Figure 5.1 Generic Service Architecture 
 
The ODSI model, as depicted in Figure 5.2, relies more heavily on core services than 
MetaGlue. This is manifest in the enterprise approach to service integration and provision. 
Enterprise roles and policies are stored in a data repository and an example is the Breeze 
workflow engine. When Breeze loads a workflow, it interrogates an enterprise database for 
the workflow interface or sub workflow interface.  
 
Terence Blackburn 66 Enterprise-enabled Ubiquitous WorkSpaces 
 
Figure 5.2 ODSI model for providing services through peers 
 
The workflow is executed, however, using a peer methodology. Breeze passes requests to 
the peer infrastructure for task execution. Other than the enterprise focus, ODSI is an 
architecture that is peer oriented for service provision. 
 
A limitation of ODSI is that peer service wrappers and internal communications are written 
entirely in Python. While it may be argued that Python is a sensible choice for a programming 
language, it may involve another learning curve for the enterprise IT department. A greater 
problem, though, is the issue of interoperability between different operating environments. 
Creating an interface to Python from another language may not always be straightforward. It 
would be beneficial if a graphical interface could be designed to manage the translation 
processes such as mapping data types from one language to the other. In this way code 
could be auto generated. 
 
MetaGlue uses the Catalog agent for the provision of core naming services. This is a 
lightweight set of services but, as with the ODSI enterprise database, it still represents a 
single point of failure. The Catalog stores and provides agent information but database 
services are also used separately to store agent attribute information and device state 
information. It is not clear at this time how vital these extra database services are to 
maintaining a functioning agent system. MetaGlue has a less centralised approach to service 
provision  
Terence Blackburn 67 Enterprise-enabled Ubiquitous WorkSpaces 
 
Figure 5.3 The MetaGlue Approach to Providing Services 
 
than ODSI and this is probably due to its micro focus on devices and applications rather than 
enterprise issues and goals. 
 
The Notifier is the equivalent of ODSI’s Elvin messaging engine and it provides a publish-
subscribe communications layer that allows the agents to perform service fulfillment. 
 
Both models allow a client to request a service and peers handle the implementation details. 
A client in either model is an entity that asks for service provision. This could be a human 
client, but often it will be a piece of software, which will be either a peer or agent. This allows 
an ODSI peer and a MetaGlue agent to act as a client or a server.  
 
ODSI advertises its public methods but does not disclose details of what and how it provides 
services. MetaGlue does not advertise its services and an implementer needs knowledge of 
the system to design a workspace. This does not mean that in the future MetaGlue services 
cannot be abstracted and advertised. Given the direction of current research, see Section 2, 
this development may happen in second-generation MetaGlue applications. Since ODSI is 
already a high level abstraction, no knowledge of the underlying processes is required. This 
enables evolution of the model without alienating exiting client services. 
 
The abstract nature of ODSI, where the methods for service provision are not defined, allows 
plugins to be inserted and applications to be “bolted on”. For example, the Breeze workflow 
engine can be used as a stand-alone product or as an integrated component of ODSI. During 
the transition from Elvin 3 to Elvin 4 at DSTO in Adelaide, a plugin module was able to listen 
to ODSI requests, translate them from Elvin 3 to Elvin 4 and send back an ODSI response. 
Terence Blackburn 68 Enterprise-enabled Ubiquitous WorkSpaces 
5.3 Architectural Design 
The enterprise bus, where data is passed from one node to the next, is one of the vital 
components in an enterprise infrastructure and Elvin was chosen for this role in ODSI. 
Messaging models can be classed into two groups, directed and undirected. 
 
The directed model, which can be client server or peer to peer, is usually synchronous, tightly 
coupled, the message destination is known and homogeneity is promoted. Examples include 
the Remote Procedure Call, message queues and multicast messages. There are 
shortcomings in this model that become apparent when communication services are 
intermittent, locations are altered and message recipients change. 
 
Undirected communications, allow loose coupling, asynchronous communications, uni-
directional messaging (event notification) and heterogeneous clients. The receiver’s address 
may not be known when the message is sent and this suggests that authentication 
techniques may sometimes be required to allow message retrieval. 
 
Elvin is an example of the undirected model. It sends simple structured messages and allows 
clients to use a subscription language for selecting messages of interest. The messages are 
sent asynchronously and it is assumed that they arrive at their destination. There is no system 
of message acknowledgements or data resending in this model. Multiple clients can receive 
the same message and this could be good or bad depending on the context. If clients are 
disconnected, however, messages may not be received. 
 
Elvin’s lightweight messaging model has practical enterprise applications in a number of 
situations including instant messaging, devices advertising their state, event notifications and 
efficient multicasting. It also has enormous benefits for scalability, as it is a very fast and 
efficient model. Lightweight messaging does not suit all enterprise applications and there are 
occasions when a more reliable model is required. Executing workflows can sometimes be 
examples of when a heavier messaging model is required. A particular workflow may rely on 
input from other applications or devices to proceed from one task to another. If a message is 
only broadcast once, and this will often be the case, and the workflow does not receive the 
updated message, it may remain in a wait state until it receives an intervention. Clearly this 
could be detrimental to a mission critical task in an enterprise. In this situation, a message 
server that guarantees message delivery is of more use to an organisation. A persistence 
mechanism could be added to the lightweight model to capture important messages, but this 
defeats the philosophy of lightweight messaging. It is likely that a directed messaging model 
would be more appropriate in this case. 
 
Another shortcoming to the lightweight Elvin model is that nested data structures like XML 
files and data types like hash tables are not supported although the protocol has been 
Terence Blackburn 69 Enterprise-enabled Ubiquitous WorkSpaces 
extended to include opaque objects such as mime attachments. These are not routed easily, 
however, and clients are required to subscribe to all messages that include objects, and these 
messages must subsequently be filtered at the client end. Lists must also be flattened to a 
string and require string manipulation functions to retrieve desired values. 
 
A design limitation that will affect some applications is the lack of security. Elvin is a content-
based messaging service and any client can subscribe to any message in a federation of 
Elvin servers. The situation is similar with MetaGlue and this can allow unwanted access to 
any enterprise resources exposed within the architecture. Security is discussed in more detail 
in Section 5.5. 
 
The ODSI infrastructure supports decentralised coordination and control through a set of 
peers existing at each node in the environment. The peer is similar in many ways to the 
capsule concept from RM-ODP or a container from the Java or CORBA component worlds. It 
incubates a set of services and provides access to them in a well-defined way according to 
the workflow requirements of interactions. Each command given to a peer-managed service 
must return one of:  
 
o Succeeded - successful result returned,  
o Failed - failed during processing,  
o Aborted - access to the service was aborted, or  
o Running - an intermediate result.  
 
All communication to services is through a peer and uses an event notification service for 
addressing and delivery. Notifications give us some key advantages over the more common 
directed communication mechanisms such as RPC or RMI. New peers (and hence hosts) can 
be added to the environment without the need to explicitly redirect communication. This gives 
us a more scalable and flexible environment because we can augment or replace services at 
peers with impunity. Asynchronous notifications also support the concept of multiple 
intermediate results that are key to our workflow-oriented environment 
 
One of the useful features of MetaGlue is the relies_On() method. It is used when multiple 
agents require simultaneous access to a particular device or service. It allows more than one 
agent to attach to a particular wrapper agent that is controlling the device or application. 
Instead of agents creating new instances of an application wrapper object each time a service 
is required, the relies_On() method allows the agents to share the one instance. In this way, if 
one agent changes the device’s state, all agents are notified. This would not happen if each 
agent was associated with a separate instance of the application wrapper agent object. 
 
Terence Blackburn 70 Enterprise-enabled Ubiquitous WorkSpaces 
More than one agent can interact with a device. For example, if two or more agents, 
representing entities such as applications or people, wish to send separate URLs to the 
browser, each can communicate individually. In this way collaboration is fostered by group 
interaction with the application. 
 
Another useful feature of the relies_On() method is that it ensures that there is an agent 
available to provide a particular service. If there is no instance of an agent to fulfill the service 
request, the local Manager Agent will start a new instance of the required agent. This leads to 
the tied_To() method. 
 
The tied_To() method glues a MetaGlue agent to a specified device or application host 
computer. This is important when a service is required that is only available on a certain host. 
If there is no agent available on that host to provide the service, the Agent Manager will move 
an agent to the host or start new instance of an agent. 
 
5.4 Inter-infrastructure 
One of the problems encountered when integrating software infrastructures, such as the ones 
in the case study, is creating the bridges that facilitate bi-directional messaging or event 
notification across the different architectural paradigms. In this instance there were three 
environments to span: ODSI, which has a publish-subscribe based infrastructure, the 
MetaGlue multi agent infrastructure, which also uses a publish-subscribe communications 
model and Microsoft Windows, which can use DCOM, COM+ or other proprietary 
approaches. 
 
A number of companies have created products that can bridge from a Java environment to 
Microsoft Windows for application integration and manipulation. J-Integra, a product from 
Intrinsyc Software [46], allows COM components to be accessed from the Java environment. 
This solution exposes the methods available in the target application and converts the target 
data types into Java data types. However there were initial problems with resources not being 
disposed of correctly and a second solution was chosen and implemented; R-JAX [48], from 
Stryon. This product did not seem to be as flexible as J-Integra but it was very easy to install 
and use. It provided an intuitive interface to the process of exposing the Microsoft application 
methods and provided a workable interface for MetaGlue agents to invoke the methods in 
Microsoft’s Internet Explorer. 
 
There are a number of potential solutions to enable MetaGlue to communicate with the ODSI 
environment. The need to start a workflow provides the motive to engage this process and the 
main goal is to start a workflow engine and feed input values into the workflow. The 
implementation of ODSI used in the case study was written in Python. This means that 
Terence Blackburn 71 Enterprise-enabled Ubiquitous WorkSpaces 
management software for ODSI components was written in Python and this includes 
commands to start and control, Breeze, the workflow engine. At some point then, information 
must be exchanged between the Java environment and the Python environment. Some of the 
solutions to this issue include the following: 
 
1. Embedding Python within a Java program is synonymous with calling the ODSI 
workflow stub from within a MetaGlue agent. This approach to calling Python 
methods is routed via the Elvin messaging engine. The call to ODSI is all that is 
required as ODSI handles the Breeze invocation and passing the workflow 
parameters. This was untested. 
2. Another approach, which does not look simple and was not tested, is to run a java 
program on an ODSI peer. This program would then run a system command to 
invoke a Python script, which would start the Breeze engine. If the workflow engine 
was not on the same peer, it would be started remotely through the peer to peer 
mechanism. This is a static or hardwired way of approaching a dynamic problem and 
does not look very extensible. The initial parameters that invoke the correct workflow 
must also be sent to the Java program although subsequent parameters are sent via 
the messaging engine. 
3. The solution that was selected involved running a workflow client directly from an 
agent. This program issued ODSI formatted calls to invoke the correct workflow and 
sent the request through the Elvin messaging server. The ODSI syntax to set this up 
includes the line:  
ODSI.TO == Breeze 
Breeze, an ODSI peer service, subscribes to all Elvin messages containing this text 
and can also accept extra parameters that may be required by the workflow. This 
appeared to be the easiest and most scalable answer to allowing a MetaGlue agent 
to start a Breeze workflow. It may have been more robust to implement the Java 
workflow client as two separate agents. One could subscribe to the MetaGlue 
Notifier and publish to the Elvin server and the second agent could subscribe to the 
Elvin server and publish to the MetaGlue Notifier. In this example scenario, though, 
the workflow client fulfilled both of the roles of publisher and subscriber to both 
architectures. 
In all three methods, extra input parameters to the workflow can be sent in the same way by 
using ODSI syntax and sending the message via Elvin. Receiving workflow notifications was 
straight forward and involved subscribing to appropriate Elvin messages. 
5.5 Security 
The lack of security was one of the first issues to become apparent when working with these 
infrastructures. It is quite reasonable, however, to expect a bare bones set of features to 
accompany these early version architectures, as they are still research products. For 
Terence Blackburn 72 Enterprise-enabled Ubiquitous WorkSpaces 
example, the MetaGlue implementation is Beta version 0.5. A set of secondary features 
including security mechanisms would normally accompany a more mature product, and in the 
MetaGlue instance, this is happening as more research is being undertaken using MetaGlue 
as the infrastructure as described in Section 3. 
 
This section also includes redundancy, as the topic seems to fit into a discussion on security. 
Messaging 
The main security weakness in the Elvin (Version 3) security model is the open nature of the 
messaging protocol. It allows any client to intercept and read a message meant for another 
client and may also allow producers or consumers to masquerade, although the value of a 
client masquerading is questionable in circumstances where the publisher is unaware of its 
message destination anyway. There is no authentication of either the server or the client, 
messages are sent in plain text, there is no message integrity control and there is no access 
control to the messaging network. Multiple clients can receive the same message and this 
could be good or bad depending on the context. There are obvious security issues when the 
sender does not know who is receiving the message. However, all of these criticisms describe 
the lightweight nature of the protocol and this is how it was designed. 
 
Elvin’s message processing algorithm is flexible. It handles fields in excess of those 
requested in the subscription template by evaluating them as “unknown”. However, This has 
clear ramifications for security as extra unauthorised fields could be added to a message 
before the client received the notification and there would be no way to validate the 
message’s integrity. 
 
One of the key benefits delivered by content based messaging is the loose coupling between 
producers and consumers and adding a security layer, like the authorisation of message 
delivery, creates a degree of coupling [32]. Elvin (Version 4) [33] has introduced an 
authorisation mechanism, based on one-way hash keys, that still allows loose coupling. The 
message producer creates and supplies raw keys that are encrypted by a one-way hash 
function within a server. These transformed keys are distributed to consumers who must 
supply a matching key to receive a given message. Subscribers may elect to receive only 
secured messages and this may reduce the chances of a denial of service attack on the 
subscriber. Keys can be used in either of two ways. The first is connection based where the 
key lasts while the client is connected and the second is to use a key for each message or 
notification that is sent. It is possible to combine these methods for added security although 
employing keys has an associated cost and this could have an impact on message 
throughput. 
 
Terence Blackburn 73 Enterprise-enabled Ubiquitous WorkSpaces 
The management and distribution of the keys, however, remains the responsibility of a third 
party as Elvin remains aloof from this process. This may introduce a security weakness 
through the interception of keys, which must be encrypted when being transmitted to 
subscribers. 
 
Security in the Elvin 4 implementation includes SSL encryption at the transport level and also 
allows a choice of two other client security models. Clients can choose to:  
 
o use a public/private key pair to decrypt a message 
o use two pairs of asymmetric keys for extra strength security. 
 
In the second option, the public key from each of the sets is paired with the private key of the 
other set and the resultant pairs are summed and compared. If the sums match, then the 
message has not been compromised, the source is authenticated and a secure conversation 
can take place. 
 
It is not clear as to what degree data integrity is still an issue with Elvin 4, but the authors 
have indicated that this will be covered in a future paper on Elvin 4 security. It should be 
noted that Elvin is a component of the ODSI model and constitutes the main security 
mechanism, but ODSI is not restricted to the use of Elvin’s security model alone. As with 
ODSI, the Breeze workflow engine has no security layer although some investigation has 
been undertaken into security in agent-based workflows [34]. 
Multi-agent systems 
Security issues like authentication and authorisation occur when humans or workspace 
entities want access to other workspaces or agents. Access control [39] has a number of 
facets and these include: who has access to resources, who controls the access and who can 
make decisions about the control and the delegation of control of resources. Access control 
and authentication can be handled by traditional methods where one user wants access to 
one space. However, it is harder to define roles and authentication rules where multiple users 
are interacting with multiple spaces that potentially span multiple organisations.  
 
Users in one workspace may request access, through agents, to resources in another 
workspace. How are rules created or evaluated to handle these issues? Contextual 
information may help to define rules for various roles. For example, a user, who can assume 
a particular role, has been authenticated and verified by an agent as being in a certain 
location. This means that it would be safe to allow access to printers and data, but at another 
time, the same user could be in a remote location where security violations could occur if the 
same access was allowed. 
 
Terence Blackburn 74 Enterprise-enabled Ubiquitous WorkSpaces 
One option is to explore the use of security policies [1, 38]. In the security context, this means 
that if a policy states that a particular process should be restricted or authorised at various 
levels, then this should be supported in the representation of that process in the model. This 
scenario also offers opportunities for further research. These policies can be built into trusted 
agent systems [20, 52] and can be useful in regulating access to various types of spaces. 
Investigation into security for multi-agent systems [14, 31] has existed for a many years and, 
in a similar manner as Elvin 4, current systems have also incorporated Public Key 
Infrastructure (PKI) into their security models.  
 
By using role-based approaches, agents could be used as policy managers that receive 
secure messages via a content-based message system. They could ask for security 
validation, which would then be checked against the underlying enterprise knowledge 
repositories and the tuplespaces would be used for persistence (see Future Research, 
Section 5.14). This would provide a possible approach to security issues for process 
orchestration via workflow. This model would map well to the software infrastructure in this 
case study which uses workflow as a coordination and control mechanism and supports the 
mapping of business processes across into an enterprise enabled workspace model. 
 
MetaGlue has no answers to any of these questions. The only security measure in the 
MetaGlue environment is a firewall. It was noted in Section 3.1, though, that research is 
starting to explore this issue. 
Redundancy 
MetaGlue has a central registration agent, the Catalog, which keeps track of all agents 
running at any given time and the interconnections between them. It is also the distributor of 
handles to agents and acts as a synchronisation point for ensuring that there are no naming 
conflicts among the agents. There is a problem if the Catalog crashes as all agent information 
is lost and agents become inaccessible. There is no backup mechanism to restart the system 
with agent state intact. 
 
However, if a connection between agents is severed for any reason, individual agents may try 
and reconnect to the agent or device that they were connected to. They may try for a certain 
period of time or a certain number of times before the system automatically restarts the 
service. 
 
ODSI has no backup mechanism either. In every ODSI system there must be one peer that 
runs the enterprise database. This is a collection of tables populated with workflow definitions, 
service interfaces and interface definitions, usually written in Python. (This enterprise 
database also includes the peer’s own database of service information.) If the computer 
hosting the peer and the enterprise database fails, ODSI also fails. The system will need 
Terence Blackburn 75 Enterprise-enabled Ubiquitous WorkSpaces 
human intervention to restart the system but all system state will be lost including workflow 
state, as Breeze does not store any workflow state. This would also appear to be a weakness 
if Breeze is trying to run a large number of workflows. Is there a way of determining which 
input parameter goes to which workflow? 
5.6 Scalability 
As discussed in the subsection relating to redundancy, MetaGlue has a single point of failure 
in the Catalog agent. It is less complex when each society has only one point of 
synchronisation, but it also inhibits scalability in an agent society. This does not prevent a 
number of agent societies connecting to each other through the Hyperglue mechanism, which 
is a communications layer for enabling wide scale connections between agent societies [13]. 
 
Each agent communicates through the Notifier and given that a communications channel only 
exists while a message is being sent, it seems reasonable that the Notifier could scale to 
handle the communications requirements of several thousand agents. If this were not the 
case, there would be merit in investigating the use of Elvin as a message passing 
mechanism. It would certainly be appropriate to consider using Elvin in a wider area scenario 
to communicate between groups of agents. This is not the main limiting factor in the 
MetaGlue system, though. The limiting factor in a MetaGlue society is the concept of relying 
on another agent. This can be a very useful feature as discussed in subsection 5.2 but also 
means that an agent must rely on a second agent to perform a task. This agent in turn may 
rely on a third agent for its functionality, which may rely on a fourth and so on. The web of 
inter agent reliance quickly becomes a tangled web that falls over if a system crashes or an 
agent dies. It also becomes complicated when agents maintain connections to other agents 
that have broken down or moved to other hosts. 
 
Any connection between agents may not last for long, though. If an agent needs to turn on the 
coffee machine, for example, the connection between any pair of agents may endure only for 
milliseconds. However, other connections may last for several hours, such as a microphone 
agent recording speech that is passed to another agent for processing and it is clear that this 
agent web would limit the growth of a society at some point.  
 
ODSI has more support for scaling to a larger system and this is due to its peer to peer 
design and its messaging architecture, which is an important element in scalability issues [6]. 
Peers are application servers that support interoperability with other peers to discover 
services and manage their execution. It is a dynamic environment that uses a publish-
subscribe messaging system to support communication in this society of equals. Elvin, a 
content-based message router, underpins the communication transmission and this is where 
Elvin’s lightweight design is of most benefit to an enterprise. The transmission mechanism is 
similar to that of the Notifier in MetaGlue. A channel can be established for just the amount of 
Terence Blackburn 76 Enterprise-enabled Ubiquitous WorkSpaces 
time needed to broadcast a message and then it is closed. This dynamic mechanism can 
scale to thousands of messages per second, particularly if a set of Elvin servers has been 
federated over a larger domain. 
 
ODSI is similar to MetaGlue in that it can support a point-to-point event channel for end-to-
end communication or it can also use a publish-subscribe mechanism for broadcast 
messaging, which is scalable. 
5.7 Orchestration and Synchronisation 
ODSI supports process orchestration or workflow coordination in a natural way. This is 
evident by having the workflow engine as a central component in the infrastructure. It can 
support many different activities due to its abstract approach to service fulfillment. As 
discussed earlier in this section, Breeze coordinates workflow but does not implement it. This 
responsibility is left to peers. Breeze is only concerned with whether a workflow process is 
active, is finished or has aborted. This enables a variety of services to be performed and a 
richer set of enterprise services to be made available. 
 
This scales well within an atomic structure such as a workspace or an organisation but it is 
unclear what would happen if more than one workspace required support. What would 
happen if two workflow engines from different workspaces were required to coordinate and 
synchronise their activities? This is an important scenario that can be viewed at a number of 
levels. Workspaces can be composed of individuals or large groups of people and domains 
can vary from medical or software organisations to military settings. Two bricklaying sub 
contractors coordinating their daily activities will have different requirements to a police 
organisation coordinating a manhunt in an urban terrain. Homogenous arrays of services may 
not meet the needs of these heterogeneous workspaces and synchronisation issues along 
with other enterprise attributes such as context awareness and adaptability will need careful 
consideration. 
 
MetaGlue, while it does not have a built in process orchestration attribute such as a workflow 
engine, has natural synchronisation abilities and this is evident in agent activities as they 
automatically work together in an unassisted manner. 
5.8 Adaptability 
It is difficult to conceive of a fully adaptable workspace environment, which by definition would 
have an infrastructure and a set of tools to assist in processing elements of work, but it is 
certainly conceivable to add higher levels of adaptability. The infrastructure and tool set for 
any workspace-supporting framework would need to be structured and well defined. However, 
with higher levels of abstraction, more adaptability can be added to a software infrastructure 
in the form of plugin modules and components. Ideally, adding extra functionality would be a 
Terence Blackburn 77 Enterprise-enabled Ubiquitous WorkSpaces 
dynamic process that would not involve shutting down a system and rebooting it. MetaGlue 
and ODSI both have adaptive frameworks but both infrastructures support adaptability in 
different ways.  
 
ODSI follows the approach outlined in the preceding paragraph by approaching the provision 
and implementation of services in an abstract, top down way. The transport protocol stack in 
Elvin is abstract as is the definition of service provisions in the ODSI architecture. Breeze and 
Elvin, as mentioned, are plugin modules that can be replaced by any suitable workflow engine 
and communications model. 
 
MetaGlue support for adaptability seems to take a bottom up approach. All possible agent 
types are predefined and a workspace only needs to start the appropriate agent, which will 
start other agents as needed, to obtain service fulfillment. This approach is not difficult in an 
environment where many of the variables are known. All of the existing hardware devices can 
have agent controllers and most of the software applications can also have wrapper agents to 
invoke services. However, by leaving a known environment, such as the Intelligent Room, 
new challenges exist for this type of approach. The problems here are related to the 
scalability issues discussed in Section 5.5. 
5.9 Persistence and State Management 
The lack of persistence is one of the limitations in both architectures as described in earlier 
subsections. This is manifest in single points of failure with the enterprise database in ODSI 
and the Catalog Agent databank in MetaGlue. The design and lightweight attributes of the 
Elvin content routing engine also preclude the provision of a persistence mechanism, which in 
some cases is desirable. Persistence is also a key factor in state management. 
 
State management is one of the key factors that will 
enable or inhibit collaboration, coordination and process 
orchestration across multiple workspaces or domains. 
 
Persisting state in real time is analogous to taking snapshots of system conditions every 
millisecond. Without information on the current condition of a system, it cannot be recreated 
or restored and it cannot be referred to in support of context awareness and adaptivity. 
Having an understanding of the importance of state management adds context to the amount 
of effort expended by the creators of MetaGlue into handling device state. This was an 
unexpectedly large part of the MetaGlue system and, consequently, was not included in the 
case study. 
 
State information, which will be retrieved from persistent storage, will be critical for a number 
of components and activities in enterprise-enabled workspaces and include: 
Terence Blackburn 78 Enterprise-enabled Ubiquitous WorkSpaces 
 o Dynamic template-driven workspace composition 
o Workspace replication across domains 
o Context sensitive security mechanisms 
o Adaptive business process execution 
o Collaborative activities with multimodal devices 
 
This is only a short list of examples and the essential point is that state, knowledge of the condition of 
the system, will play a major role in all of these future workspace activities. 
 
Persistence and state management attributes are also discussed in Section 5.13 when future 
research areas are explored. 
5.10 Context Awareness 
Many of the enterprise attributes are closely linked to each other. The seam between 
persistence and state management has been discussed in Section 5.8 and there is also an 
important connection between distributed components and state management. Context 
Awareness also has a direct association with state, which was defined in Section 2 as the 
condition of an object. Context Awareness, also according to our definition, is the awareness 
of state and MetaGlue and ODSI have different approaches to this important issue. 
 
MetaGlue has a reactive element in its infrastructure in that lights will be dimmed when the TV 
is activated and the heater will be turned on if the temperature drops to a certain point. These 
actions happen automatically and exemplify the natural context-awareness of the 
architecture. A number of agents are built around context but this was not a design goal. One 
of the design goals was to maintain connections between agents so that if an agent becomes 
unavailable, the service can be started elsewhere. In the context of the agent being 
unavailable, the system is motivated to start another agent service. In the same way, if an 
agent needs more processing power, the ManagerAgent can move it to a more powerful host. 
The agent context has driven the need to move the agent to another host. Similarly, a load-
balancing agent would also be motivated by agents’ context and relocate them accordingly. 
 
At another level, the agents in an intelligent environment have the ability to respond to a 
user’s needs. In an intelligent room, for example, the room collects contextual information in 
an attempt to divine what the user is doing and what they intend to do. This encapsulates the 
biggest problem in context awareness. Collecting the contextual information is one aspect but 
analysing it and deciding what to do with it is the tricky part. 
 
ODSI has been designed to actively drive its infrastructure according to enterprise polices and 
goals rather than be driven in a passive manner like MetaGlue. Even though parameters are 
sent to the workflow engine, it reacts in a predefined and predictable manner that would be 
difficult to describe as context sensitive. It is more like a command driven environment. A 
Terence Blackburn 79 Enterprise-enabled Ubiquitous WorkSpaces 
database trigger, for example, while an example of context driving an action, would not 
normally start a workflow. It would more likely send a message to a log file or raise a flag in 
someone’s workspace. 
 
The messaging engine in ODSI is similar to the workflow engine in that it reacts to commands 
in a predictable manner but does not perceive the state of its environment, as defined in 
Section 2.6. This is not a necessary attribute, though, as changes to the messaging engine 
structure would move its design away from the lightweight model. Leveraging the context 
awareness of another architecture, like MetaGlue, could address the attribute limitation. When 
the two architectures are combined, the resulting mixture of workflow driven actions and 
device driven reactions could produce some interesting scenarios. This was not part of the 
case study but may represent an area of future research. 
5.11 Collaboration 
Human collaboration has always been one of the cornerstones for successful workgroup 
environments. The emergence of new workgroup technologies, such as those described in 
the projects reviewed in Section 3, and the resulting unexplored methodologies, such as hand 
held devices interacting collaboratively on large display areas, raises a new set of questions. 
These questions revolve around how to capitalise on these new developments and increase 
workspace productivity. 
 
One of the main features of the ODSI architecture is enterprise collaboration, which is 
manifested through workflow fulfillment or business process execution. The enterprise is 
defined loosely as a collection of cooperating resources trying to achieve a common goal. 
When these enterprise resources link business processes through service requests, complex 
organisational tasks can be described and executed. This allows business managers to 
define the enterprise goals and describe business processes to achieve them. ODSI, then, 
executes these business processes. 
 
MetaGlue also supports collaboration and this is achieved through agents interacting with 
other agents. One user action, such as a command spoken into a microphone, can trigger a 
series of actions. These actions can involve a number of different agents triggering other 
agent events through the ‘relying On’ mechanism, which facilitates collaborative work. 
5.12 Distribution  
Distributed systems have existed for many years and can be considered as a reasonably 
mature technology. Objects, applications and processes have been used in a disseminated 
manner for a couple of decades and distribution represents a link to the concept of tuple 
spaces as used in the Stanford research environment. Tuple spaces were developed from the 
Linda coordination language in the early 1980s and used in parallel and distributed 
Terence Blackburn 80 Enterprise-enabled Ubiquitous WorkSpaces 
processing. They seemed to lose popularity in the mid 1990s but can be seen in modern 
laboratories and involved in current research. The benefits of tuple space models are 
explored in Section 5.13. 
 
Future workspaces will extend the distributed metaphor to concepts such as distributed 
adaptability, distributed context awareness and distributed coordination. These terms 
represent enterprise attributes as defined in Section 2 but manifested on a large scale or 
spanning diverse environments. In many of these settings, the distribution models will 
represent encapsulated aggregations of distributed state. This will pose some management 
challenges but coordination on a large scale is likely to represent a higher order of difficulty. 
ODSI supports wide area distribution through the Elvin messaging network and MetaGlue 
supports distribution through agent spreading and Hyperglue as discussed earlier. 
 
5.13 Summary 
We set out to explore enterprise-enabled workspace architecture and we used two 
frameworks in an experiment to investigate these workspace characteristics.  
 
When we started to look at the integration issues, we found two peer to peer type 
infrastructures that have some similar enterprise characteristics yet quite divergent 
approaches to satisfying organisational needs. MetaGlue is almost an out of the box 
installation and comes with many pre built agents to handle a plethora of room-based 
activities. These agents were not used in our case study but served as useful examples when 
questions arose. ODSI is a collection of Python files, which are loaded onto a host computer, 
and a set of optional components to service enterprise requests. We chose to install Elvin as 
the enterprise bus and Breeze as the workflow engine and it took a some time to understand 
the separate paradigms before we tackled the integration issues. 
 
We discussed the enterprise approaches presented by the two architectures and surmised 
that both had strong peer to peer characteristics. We did not settle on a formal definition of 
peer to peer as that may have raised more discussion that agreement but, instead, looked at 
some of the attributes that peer to peer infrastructures share. Both MetaGlue and ODSI have 
management infrastructures that can start services on request. MetaGlue goes a little further 
and is able to start the services on any specified host while an ODSI peer can only offer the 
services that have been preloaded. ODSI can advertise its available services but developers 
need some knowledge of MetaGlue to work within the framework. 
 
Communication is the nervous system of enterprise infrastructure. ODSI uses a lightweight, 
publish subscribe, content-based messaging engine that is fast, simple and scalable. It is 
driven by client subscriptions rather than publisher addressing and it lacks one or two features 
Terence Blackburn 81 Enterprise-enabled Ubiquitous WorkSpaces 
such as security and persistence, but these were deliberate design omissions. MetaGlue uses 
a version of Java’s RMI that can send point to point messages between agents or support a 
publish subscribe model. The model also supports glue spreading, which is a process for 
disseminating agents throughout the network to where they are required. 
 
There were a number of available choices for creating the bridge between ODSI and 
MetaGlue and we chose an off the shelf program that started a Breeze workflow from within a 
MetaGlue agent. Unfortunately, we didn’t read the label properly and lost some time due to 
software version mismatches. However, it was a clean simple approach to communicating 
between MetaGlue and ODSI. Messages flowing the opposite way are easy to receive as 
subscribing to Elvin messages is a breeze. The other bridging issue was sending method 
calls to MS Windows applications and this was handled smoothly by R-JAX. 
 
Neither infrastructure had mature security models. Neither framework, however, was 
designed with a security component in mind but we identified some of the issues that would 
need to be addressed if enterprise-enabled workspaces were to incorporate either of these 
models in production release software. (ODSI can leverage the new security features of Elvin 
version 4, which has a number of optional, deployable security components.) Both MetaGlue 
and ODSI have a single point of failure in their central management systems and this issue 
has been left unaddressed by the developers. 
 
MetaGlue appears to be scalable when the communications model is examined but its facility 
for agents to rely on other agents sets up a web of interconnections that would become 
massively complex as the system grew. It would also become more vulnerable to the failure 
of the Catalog, the central agent organiser. Interestingly, it is less susceptible to single agent 
failure as MetaGlue has a reconnection facility. ODSI scalability, on the other hand, is well 
supported by the Elvin messaging bus, particularly when Elvin is federated over a larger 
domain. 
 
ODSI is well designed for process orchestration and synchronisation with its built in support 
for workflow execution. The implementation of workflow is also supportive of these 
characteristics as it is abstract and, consequently, very flexible. MetaGlue, while having little 
or no concept of workflows, has natural support for synchronisation. This is due to the 
autonomous nature of the agents and their method of invoking other agents when they are 
required. 
 
MetaGlue and ODSI both have adaptive frameworks but both infrastructures support 
adaptability in different ways. ODSI takes a top down approach to adaptability and has a 
number of abstract implementation layers. It uses a set of plugin modules and components to 
support adaptability. In our case study we selected the Breeze and Elvin components to form 
Terence Blackburn 82 Enterprise-enabled Ubiquitous WorkSpaces 
the core services for our LiveSpaces environment. MetaGlue, on the other hand, approaches 
adaptability from a bottom up perspective. All possible agent types are predefined and a 
workspace only needs to start the appropriate agent, which will start other agents as needed, 
to obtain service fulfillment. This call has a limitation as all devices must be known to have pre 
built support and this precludes adapting to new devices and applications although this 
observation also applies to ODSI. 
 
Persistence and state management seem to be the most important characteristics for 
enterprise-enabling workspaces. These attributes underpin most of the characteristics that 
were identified as being important in our research. Neither MetaGlue nor ODSI are good in 
this area although some support for these characteristics is evident. Both suffer from single 
points of failure in their implementations and some form of persistent data storage may 
address this limitation. MetaGlue has taken state management quite seriously but stopped 
short of supporting the Catalog, the central agent management facility. ODSI needs to 
consider adding workflow state management to its model as executing a large number of 
workflows could become complicated. 
 
Context awareness is closely linked to state as all context information in a system is 
represented as state. The storage and management of state, then, is crucial to supporting 
context awareness. MetaGlue responds to state change and this is often manifested in agent 
activity. This context awareness can be seen in passive room responses to human activity 
and device state changes that result from other agent actions. ODSI is less supportive of 
context awareness. Elvin has no idea about who receives its messages and Breeze has no 
idea of how the workflows are implemented. Neither does it have any means of sensing its 
environment in the manner of MetaGlue, but it does not try to excel in this area. However, 
when the two infrastructures are blended, a lot of synergy is produced. 
 
ODSI rates well in enterprise collaboration and this is expressed through the workflow engine. 
When workflows are combined into higher order workflows, enterprise collaboration is 
strongly evident. MetaGlue has a collaborative agent system. This is supported by building 
autonomy into the agent framework and is promoted by the concept of relying on other 
agents. 
 
The concept of distribution is almost synonymous with the image of an enterprise. Future 
workspaces will need to incorporate this characteristic as workers become decoupled from 
their computers and traditional hand operated interfaces, and become wireless, wandering 
and hands free. State will become distributed as will context awareness and so on. The 
increased mobility of humans within an organisation will drag forward the development of 
distributed concepts. ODSI supports wide area distribution through the Elvin messaging 
network and MetaGlue also supports distribution through agent spreading and Hyperglue. 
Terence Blackburn 83 Enterprise-enabled Ubiquitous WorkSpaces 
 The end result of integrating the two architectures in the case study is a change to a more 
productive methodology for executing tasks, or units of work. This is manifested in faster 
access to relevant information, the facilitation of collaborative group interaction and more 
efficient dissemination of context appropriate information to the enterprise. It also provided a 
set of smarter interfaces to the enterprise. 
 
The case study created the foundation architecture for the LiveSpaces environment in the e-
World laboratory. It will provide a test bed for our investigations into enterprise-enabled 
workspaces. Part of the required ODSI infrastructure has been created to initiate our 
experiments with enterprise attributes and a number of MetaGlue agents have been written to 
control hardware and software devices in the interactive workspace. As part of the work we 
experimented with the following: 
 
1. An agent to process the text output from the viaVoice speech to text engine 
2. An agent to send messages within the MetaGlue environment 
3. An agent to receive messages within the MetaGlue environment 
4. An application wrapper to invoke methods on selected Microsoft Office applications 
5. Agent code to automatically start an arbitrary number of agents 
6. Agent code to tie agents to a host 
7. An agent to control x10 devices 
8. Code to communicate with serial devices 
9. An agent to publish to Elvin 
10. An agent to subscribe to Elvin 
11. An agent to invoke an ODSI workflow 
12. Java client code to start the workflow 
13. A Python peer with a service interface to invoke the workflow 
14. A Python peer to publish a message to Elvin 
 
The environment still needs some programming effort to make it robust and more functionality 
needs to be added to be able to conduct a full meeting. The status of the case study source 
code at the time of completing this thesis is that most of the code has been written but it 
needs to be glued together to be able to create a working demonstration. Time has not 
allowed this to happen. 
5.14 Future Work 
A number of significant issues have been brought to light during the course of the case study 
and many of them are related to the enterprise characteristics that were identified in Section 
2. Most of the research into enterprise workspaces is narrowly focused on a particular aspect 
of future work environments. These aspects include interaction devices, multimodal displays, 
Terence Blackburn 84 Enterprise-enabled Ubiquitous WorkSpaces 
collaboration and human-computer interaction. Our research involves integrating this work 
into an enterprise-enabled environment to support real life work domains. Our focus for 
research will investigate some of the following issues. 
Security 
The first issue was discussed in Sections 2.6 and 5.4 and relates to the lack of security in the 
infrastructure components in the case study. As discussed previously, a security component 
is usually one of several features that are added to a new architectural model after it achieves 
some degree of stability and a firm feature set. Although ODSI has been used as a test bed 
for several years, development seems to have stopped some time ago. The Elvin messaging 
server has evolved into a content-based message router and while moving from version 3 to 
version 4, it has had a security layer added. This layer has a number of encryption 
components, which can be applied optionally according to the application under development. 
Breeze appears to be in the process of being swallowed by a larger project and it is unknown 
how it will emerge. The workflow engine used in the experiment was version 0.5 Beta and a 
decision had been made not to include security, as the process had been too complicated. 
ODSI, it seems, may need to rely on Elvin’s security model as protection against intrusion, 
denial of service and other security breeches. (Section 5.4 expands on the Elvin 4 security 
model in more detail.) 
 
MetaGlue was developed in 1999 and a number of projects have been started that build on 
this infrastructure. One of the projects is concerned with security and privacy and a regulation 
mechanism controls access to workspace information based on authentication. This is not the 
heavy-duty approach needed to help MetaGlue transform from being a one-room research 
model into an intensive enterprise environment. 
 
The PKI approach addresses the lack of secure authentication inherent in multi-agent 
systems. It introduces the concept of creator accountability with agent deployment. However, 
security issues remain if the paradigm is extended beyond the firewall. A globally secure key 
repository is required. There is a significant amount of investigation being undertaken into 
mobile [9, 36] and multi-agent security and further research is necessary to address this issue 
within the LiveSpaces environment. 
 
MetaGlue is also a weak model from the perspective that, without the corporate insulation of 
firewalls, access to the room is publicly available. This lack of an access control mechanism is 
not desirable in most circumstances. There is a lot of research in access controls for agent 
spaces and some type of sentinel is required in MetaGlue. 
 
 
Terence Blackburn 85 Enterprise-enabled Ubiquitous WorkSpaces 
Persistence and State Management 
The other limitation that was highlighted was the lack of persistent storage in a number of 
situations and this issue was cross-linked to the security limitations in several areas. The first 
area where a persistent data storage facility would be useful is with the lightweight messaging 
model. Disconnectedness and intermittent connectivity [36] are two communications modes 
that will need to be accommodated in future workspaces and this will make a message 
persistence mechanism mandatory. As an example, it may be important in some situations for 
a notification to be received regarding the success or failure of an event. An ODSI workflow 
may block or wait until there is human intervention if a notification status message is not 
received. Elvin makes no guarantee of message delivery when clearly some messages need 
to be delivered. 
 
MetaGlue also has a security issue with the lack of a support mechanism for Catalog failure. If 
the Catalog stops, the agent system would also fail. The catalog seems to store agent stub 
information in a database but there is no documentation to explain the reasons behind this 
storage facility. The documentation does make it clear that system failure will result from 
Catalog failure. Can the Catalog Agent be mirrored or can a Doctor Agent start another 
instance of the Catalog if it falls over? In either case, persistent storage of Catalog data will 
assist in the process of restoring from a failure. 
Tuple Spaces 
The final area for further research is in tuple spaces (and it ties in some of the other areas of 
future research). The tuple space is one of the fundamental components of the Stanford 
project and the theory behind tuple spaces is solid, simple and powerful. A shared blackboard 
with simple primitive data types allows any client software to post messages and read others. 
The messages or tuples can persist for as long as they are needed before being garbage 
collected. This provides a solution to the message persistence issue with Elvin and it may 
also provide a data store for Catalog state in a MetaGlue agent system. 
 
Developments in content-based messaging and multi-agent systems have partly addressed 
the security issues but concerns remain. Both would benefit from a secure data repository. It 
is possible that a content-based, shared memory model, such as a tuple space, could provide 
a persistence mechanism for a content-based message routing architecture. It could 
simultaneously provide a secure, global key repository for an extended, multi-agent 
infrastructure. Further work is warranted in this area and particularly in the opportunities 
afforded by tuple spaces, which were designed as a persistence mechanism. 
 
Possibly the most interesting subject for research is the concept of mixing elements from the 
architectures mentioned in this thesis to create new components for experimenting with future 
workspaces. Ingredients in these hybrid architectures would include messaging engines, tuple 
Terence Blackburn 86 Enterprise-enabled Ubiquitous WorkSpaces 
spaces, workflow engines, ontology servers and agent systems. For example, multiple tuple 
spaces could form the backbone for a set of interactive workspaces and a messaging server 
could be used as the communications medium. These workspaces could all host different 
meetings that interact on a level to support collaboration, information passing and distributed 
work processes to achieve a common goal. How would these work activities be synchronised 
across multiple workspaces in accordance with enterprise policies? Coordinating these hybrid 
environments would increase the complexity of issues such as adaptivity, security and state 
management, particularly if a person existed physically in one environment and virtually in 
another. This could also be confusing for issues such as context awareness. 
 
Agents could be used to manage access to the tuple spaces and, with a small code footprint, 
these workspaces could be installed on hand held devices. This would decouple workspaces 
from static rooms and buildings and enable more flexible mobile [9, 36] environments. In this 
manner, we may be able to create persistent workspaces. 
 
Research has been undertaken that explores methods for utilising tuple spaces to try and 
solve some of the security problems experienced with multi-agent models [23-6]. Some of 
these mechanisms rely on access control mechanisms and strict policy enforcement. Part of 
this work also includes the concept of budgets where access to a resource is only permitted if 
there is a positive budget. Another consideration is the plethora of different policies that would 
exist in a normal distributed heterogeneous enterprise system. What sort of security 
mechanism would cope with such diversity? 
 
Client software for tuple spaces has a 15K footprint and this makes them candidate 
infrastructures for PDAs and other handheld devices. They could be used as a 
communication mechanism where objects could be passed to mobile phones, kitchen 
appliances or watches. They could allow a richer set of features on small devices in a 
workspace and facilitate communication between all types of enterprise computing devices. 
Further Case Studies 
When the LiveSpaces infrastructure is stable, it would be useful to consider further case 
studies in various other domains. This would enable enterprise characteristics to be perceived 
under different circumstances. In particular, military environments undertake considerable 
planning activities, which are conducted across multiple workspaces. This would be an ideal 
environment to investigate collaboration and synchronisation. Large software projects are 
subject to regular reviews and experiments in this domain would enable inquiry into workflow 
execution and business process orchestration. 
Terence Blackburn 87 Enterprise-enabled Ubiquitous WorkSpaces 
6. Conclusions 
Research is often built on the shoulders of previous work and this is our approach with the 
LiveSpaces experimental test bed. “Enterprise-enabled ubiquitous workspaces” is a very 
important and stimulating area in which to conduct research. It is a field that has attracted a 
number of institutions such as Sony, Stanford and MIT and their areas of focus have included 
new display devices, novel interface technologies, holistic security mechanisms and 
enterprise workflow. However, there appears to be little work in the area of creating 
workspaces that have the technological eyes and ears of the MIT iRoom, the interactive and 
display capabilities of Stanford’s WorkSpace and the enterprise focus of DSTC’s research. 
Our aim for this project, then, was to integrate some of these components into a higher order 
structure to support enterprise goals and objectives expressed as business processes. 
 
We started out by conducting an extensive review of the existing literature and analysing the 
research initiatives in this field. Work is being undertaken with human computer interfaces in 
the Sony laboratories and the European Disappearing Computer Project has thrusts in many 
original directions. We decided to examine two of the Disappearing Computer projects in 
more detail. The Ambient project at GMD in Germany has embedded technology into room 
elements such as tables and chairs and these can be used for collaborative work. The 
University of Aarhus in Denmark has pushed the enterprise workspace boundaries by 
creating a real time distributed 3D collaborative work environment. The US government, 
through its agencies, funds an enormous amount of research and two of these programs are 
the Intelligent Room at MIT and the Interactive WorkSpaces project at Stanford University. 
Both of these programs focus on human/environment interaction but their respective 
approaches are quite different. Research into enterprise requirements for ubiquitous work 
environments is partially funded by the Australian government through DSTC in Queensland 
and they have created a number of products that address some aspects of enterprise work 
processing. Another significant source of Australian government funding for research is 
through the Department of Defence’s DSTO and it is through their association with the 
University of South Australia that we are conducting the LiveSpaces project in the e-World 
laboratory. 
 
We selected the MetaGlue infrastructure from MIT and the ODSI architecture from DSTC as 
the foundations for our research. 
 
The aim of the case study in this project was to try and identify the 
issues and problems that result from building enterprise workspaces by 
creating a hybrid infrastructure from the two architectures. 
 
Terence Blackburn 88 Enterprise-enabled Ubiquitous WorkSpaces 
The most notable results from this work highlight the importance of the different workspace 
characteristics. We had preconceived ideas of how attributes such as collaboration and 
context awareness fitted workspace models but it seems that there are more fundamental 
issues that need to be addressed to support the type of enterprise work environments we 
wish to research. 
 
The major conclusions from this thesis are summarised in the following bullets. 
 
o Context awareness is required to underpin the move from keyboard/mouse interfaces 
to new ways of interacting with technology such as gesture and speech 
o Multiple, distributed enterprise workspaces will require higher orders of support for 
collaborative workflow execution and this will be underpinned by real time 
synchronisation and process orchestration 
o A distributed memory model may support coordination across multiple workspaces 
and domains and tuple spaces could provide an appropriate mechanism 
o Current security models are inadequate to cope with new hybrid enterprise 
workspace structures that may include agent systems, messaging engines, peer to 
peer infrastructures, client server models and tuple spaces 
o The fundamental building block for these future workspaces will be state 
management, an activity that will include state capture, replication, persistence and 
retrieval 
 
Preliminary results suggest that there is merit in pursuing this avenue of research. The 
resulting integrated framework highlighted several potential weaknesses, for example, more 
work is required to integrate the respective failure mechanisms to create a more manageable 
and predictable architecture. However, it is also important to consider how hybrid 
infrastructures can be utilised within an enterprise by illustrating with a real world example. 
 
Technology is utilised by an individual in a workspace to increase productivity and this could 
be expressed as faster, smarter or higher quality work. Workspaces may contain multiple 
individuals (or no individuals where virtual presence is employed) and technology in an 
enterprise-enabled workspace can be leveraged to create higher levels of collaboration and 
workflow processing. As an example, software production enterprises are required to conduct 
regular software reviews. These will often take the form of a structured meeting where 
individuals will have roles and activities will be predefined, for example, one person may be 
appointed to paraphrase the code that is being reviewed. In our future workspace, the room 
can be initialized to recall the state of the room when the previous meeting was saved, the 
displays can retrieve the appropriate code files for the designated paraphraser, the room will 
be aware of the people involved in the meeting, it can automatically connect to the 
appropriate enterprise data sources, code review policies can be displayed, the correct 
Terence Blackburn 89 Enterprise-enabled Ubiquitous WorkSpaces 
workflows can be activated, monitoring applications can be invoked, security mechanisms can 
be installed, peripherals can be initialised and so on. This setting can be created 
automatically by retrieving the required state and established the environment according to 
the contextual parameters. This will facilitate more efficient process orchestration and 
workflow implementation. 
 
Work will continue on further defining and validating requirements for architectures and 
software infrastructure for future work environments of the type outlined in this project. The 
LiveSpaces environment will be enhanced to support a greater range of environmental 
interfaces such as interactive display devices, augmented reality interfaces and dialog 
interfaces. Experiments will be conducted with Stanford’s iROS to investigate the use of 
tuples spaces for enhanced display, interaction management in multidisplay, multi-user 
environments and shared memory models for distributed workspaces. 
 
Further case studies will be undertaken to address enterprise-wide aspects related to the 
deployment and use of interactive workspaces. Of specific interest will be issues related to 
the orchestration and synchronization of workspace activities, information management and 
augmentation resulting from the inclusion of additional enterprise services such as simulation. 
Case studies will be conducted in the domains of software production, medical research and 
future military command and intelligence environments. 
 
We have set the groundwork for research in this area by creating the foundations for the 
LiveSpaces experimental test bed. This work will be extended by researchers with projects 
that explore other aspects of the LiveSpaces environment, which will, in turn, become an 
enterprise-enabled ubiquitous workspace. 
 
Terence Blackburn 90 Enterprise-enabled Ubiquitous WorkSpaces 
References 
[1] AO, X., MINSKY, N. and NGUYEN, T. (2000) A Hierarchical Policy Specification Language 
and Enforcement Mechanism for Governing Digital Enterprises, Rutgers University, New 
Brunswick, NJ 08854 USA. 
 
[2] BOND, A. (2001) ODSI: Enterprise Service Co-ordination, available at 
www.dstc.edu.au/Research/Projects/Integrator/documents/DOA-abstract.htm last visited June 
2002. 
 
[3] BOND, A. (2001) Open Distributed Services Infrastructure ODSI, White Paper, available at 
http://www.dstc.edu.au/Research/Projects/Integrator/documents/whitepaper.pdf  
 
[4] BOND, A. (2001) Service Composition for Enterprise Programming, Working Conference 
on Complex and Dynamic Systems Architecture, 2001. 
 
[5] BROOKS, R. with contributions from COEN, M., DANG, D., DEBONET, J., KRAMER, J., 
LOZANO-PEREZ, T., MELLOR, J., POOK, P., STAUFFER, C., STEIN, L., TORRANCE, M. 
and WESSLER, M. (1997) The Intelligent Room Project, Proc. Second International Cognitive 
Technology Conference, Aizu, Japan. 
 
[6] CARZANIGA, A., ROSENBLUM, D. and WOLF, A. (2000) Achieving Scalability and 
Expressiveness in an Internet-Scale Event Notification Service, Proc. Nineteenth ACM 
Symposium on Principles of Distributed Computing, Portland, OR, July 2000. 
 
[7] CHANG, A. (2001) A Help System for the Intelligent Room, Masters thesis, Massachusetts 
Institute of Technology, Cambridge, MA, USA available at 
http://sow.lcs.mit.edu/2001/proceedings/changa.pdf  
 
[8] COEN, M., PHILLIPS, B., WARSHAWSKY, N., WEISMAN, L., PETERS, S. and FININ, P. 
(1999) Meeting the Computational Needs of Intelligent Environments: The MetaGlue System, 
Proc. MANSE'99. Dublin, Ireland. 
 
[9] DASGUPTA, P., MOSER, L. and MELLIAR-SMITH, P. (2000) The Security Architecture 
for MAgNET: A Mobile Agent E-commerce System, University of California, Santa Barbara, 
CA USA. 
 
[10] FITZPATRICK, G., MANSFIELD, T., KAPLAN, S., ARNOLD, D., PHELPS, T. and 
SEGALL, B. (1999) Augmenting the Workaday World with Elvin, Proc. ECSCW’99, 
Copenhagen, 431-451, Kluwer Academic Publishers. 
Terence Blackburn 91 Enterprise-enabled Ubiquitous WorkSpaces 
 [11] GAJOS, K. (2001) Rascal - a Resource Manager For Multi Agent Systems In Smart 
Spaces. Proc. CEEMAS’01, Kraków, Poland, 2001. 
 
[12] HAMMOND, T., GAJOS, K., Davis, R. and SHROBE, H. (2002) An Agent-Based System 
For Capturing And Indexing Software Design Meetings. Proc. The International Workshop On 
Agents in Design, Cambridge, MA, August 2002. 
 
[13] HANSSENS, N., KULKARNI, A., TUCHINDA, R. and HORTON, T. (2002) Building 
Agent-Based Intelligent Workspaces, Proc. The International Workshop on Agents for 
Business Automation. Las Vegas, NV, 2002. 
 
[14] HE, Q., SYCARA, K. and FINN, T. (1988) Personal security agent: Kqml-based pki. Proc. 
Second International Conference on Autonomous Agents, May 1998. 
 
[15] JOHANSON, B. and FOX, A. (2002) The Event Heap: A Coordination Infrastructure for 
Interactive Workspaces, Stanford University, Serra Mall, Stanford, CA. USA. 
 
[16] JOHANSON, B., FOX, A., HANRAHAN, P. and WINOGRAD, T. (2000) Integrating 
Information Appliances into an Interactive Workspace, IEEE Computer Graphics and 
Applications, May/June 2000. 
 
[17] JOHANSON, B., FOX, A., HANRAHAN, P. and WINOGRAD, T. (2000) The Event Heap: 
An Enabling Infrastructure for Interactive Workspaces CS Tech Report CS  2000. 
 
[18] JOHANSON, B., FOX, A. and WINOGRAD, T. (2002) The Interactive Workspaces 
Project: Experiences with Ubiquitous Computing Rooms, In press for IEEE Pervasive 
Computing Special Issue on Overviews of Real-World Ubiquitous Computing Environments, 
April-June 2002. 
 
[19] JOHANSON, B., PONNEKANTI, S., KICIMAN, E., SENGUPTA, C. and FOX, A. (2001) 
System Support for Interactive Workspaces, Unpublished, available at 
http://graphics.stanford.edu/papers/iwork-sosp18/ 
 
[20] KAGAL, L., FININ, T. and JOSHI, A. (2001) Moving from Security to Distributed Trust in 
Ubiquitous Computing Environments, University of Maryland Baltimore. 
 
[21] LANGHEINRICH, M., COROAMA, V., BOHN, J. and ROHS, M. (2002) As we may live – 
Real-world implications of ubiquitous computing, Swiss Federal Institute of Technology, ETH 
Zurich, 8092 Zurich, Switzerland. 
Terence Blackburn 92 Enterprise-enabled Ubiquitous WorkSpaces 
 [22] Linda Group Technical Reports, (1996) available at http://www.cs.yale.edu/Linda/tech-
reports.html 
 
[23] MINSKY, N., MINSKY, Y. and UNGUREANU, V. (2000) Making Tuple Spaces Safe for 
Heterogeneous Distributed Systems. 
 
[24] MINSKY, N. and UNGUREANU, V. (2000) Regulated Coordination in Open Distributed 
Systems, Rutgers University New Brunswick, NJ, 08903 USA. 
 
[25] MINSKY, N., MINSKY, Y. and UNGUREANU, V. (2000) Safe Tuplespace-Based 
Coordination in Multi Agent Systems, Rutgers University, New Brunswick, NJ, 08903 USA. 
 
[26] MINSKY, N. and UNGUREANU, V. (2000) Law-Governed Interaction: a Coordination and 
Control Mechanism for Heterogeneous Distributed Systems, Rutgers University, New 
Brunswick, NJ, 08903 USA. 
 
[27] OH, A., FOX, H., Van KLEEK, M., ADLER, A., GAJOS. K., MORENCY, L. and 
DARRELL, T. (2002) Evaluating Look-to-Talk: A Gaze-Aware Interface in a Collaborative 
Environment, Proc. CHI 2002. Minneapolis, MN, 2002. 
 
[28] OH, A., TUCHINDA, R. and WU, L. (2001) MeetingManager: A Collaborative Tool in the 
Intelligent Room, Student Oxygen Workshop, Cambridge, MA, 2001. 
 
[29] ØRBAEK, P., MOGENSEN, P. and GRØNBAEK, K. (2001) Interaction Techniques for 
Spatial Organization of Digital and Physical materials - the Topos Approach, Position paper 
for the first Danish HCI Symposium November 2001, Aarhus, Denmark. 51-52. 
 
[30] PHILLIPS, B. (1999) MetaGlue: A Programming Language for Multi-Agent Systems. 
M.Eng. Thesis. MIT, Cambridge, MA. available at 
http://www.ai.mit.edu/projects/iroom/publications/brenton-thesis.pdf 
 
[31] POGGI, A., RIMASSA, G. and TOMAIUOLO, M. (2001) Multi-User and Security Support 
for Multi-Agent Systems, Università di Parma, Parma, Italy. 
 
[32] RAMDUNNY, D., DIX, A. and RODDEN, T. (1998) Exploring the design space for 
notification servers. Proc. CSCW’98. 
 
Terence Blackburn 93 Enterprise-enabled Ubiquitous WorkSpaces 
[33] SEGALL, B., ARNOLD, D., BOOT, J., HENDERSON, M. and PHELPS, T. (2000) Content 
Based Routing with Elvin4, The University of Queensland, St Lucia, 4072, Australia, available 
at http://elvin.dstc.edu.au/doc/papers/auug2k/auug2k.pdf 
39 
[34] STORMER, H., KNORR, K. and ELOFF, J. (2000) A Model for Security in Agent-based 
Workflows, Privacy in the Net 24 INFORMATIK * INFORMATIQUE June 2000. 
 
[35] STREITZ, N., TANDLER. P., MULLER, C. and KONOMI, S. (2001) Roomware: Towards 
the Next Generation of Human-Computer Interaction based on an Integrated Design of Real 
and Virtual Worlds, In: J. Carroll (Ed.): Human-Computer Interaction in the New 
Millenium, Addison-Wesley, 2001. pp. 553-578. 
 
[36] SUTTON, P., ARKINS, R. and SEGALL, B. (2001) Supporting Disconnectedness - 
Transparent Information Delivery for Mobile and Invisible Computing, The University of 
Queensland, Brisbane QLD 4072 Australia. 
 
[37] THOMPSON, P. (2002) Ruple: an XML Space Implementation, available at 
http://www.idealliance.org/papers/xmle02/dx_xmle02/papers/04-05-03/04-05-03.html 
 
[38] TRIPATHI, A., AHMED, T., KUMAR, R. and JAMAN, S. (2002) Design of a Policy-Driven 
Middleware for Secure Distributed Collaboration, University of Minnesota, To appear in Proc. 
International Conference on Distributed Computing Systems 2002. 
 
[39] TUCHINDA, R. (2002) Access Control Mechanism for Intelligent Environments, Bitstream 
- MAY 2002 27 Artificial Intelligence. 
 
[40] TUCHINDA, R. (2002) Security and Privacy in the Intelligent Environment, 
Massachusetts Institute of Technology, Cambridge, Massachusetts 02139. 
 
[41] Web site for Elvin, available at http://elvin.dstc.edu.au/ last accessed June 2002. 
 
[42] Web site for Elvin, Elvin Subscription Language, available at
http://elvin.dstc.edu.au/doc/esl4.html last accessed August 2002.
[43] Web site for Breeze workflow products, available at http://www.dstc.edu.au/ last
accessed August 2002.
[44] Web site for IBM’s alphaWorks Tspaces server, available at 
http://www.alphaworks.ibm.com/tech/tspaces last visited June 2002. 
Terence Blackburn 94 Enterprise-enabled Ubiquitous WorkSpaces 
[45] Web site for iROS and Event Heap, Stanford Interactive Workspaces, available at 
http://www.graphics.stanford.edu/projects/iwork/ last visited June 2002. 
 
[46] Web site for Intrinsyc, available at http://www.intrinsyc.com/ last visited June 2002. 
 
[47] Web site for JavaSpaces(TM), Service Specification, available at 
http://wwws.sun.com/software/jini/specs/jini1.2html/js-spec.html last visited June 2002. 
 
[48] Web site for Stryon, available at http://www.stryon.com/ last visited June 2002. 
 
[49] WEISER, M. (1991) The Computer for the 21st Century, Scientific American, Sept 1991. 
 
[50] WELLS, G. (2001) A Programmable Matching Engine for Application Development in 
Linda, Ph.D. Thesis. University of Bristol, England. 
 
[51] WINOGRAD, T. (1999) Towards a Human-Centered Interaction Architecture, Working 
paper for Stanford project on Interactive Workspaces, available at 
http://graphics.stanford.edu/projects/iwork/papers/humcent/index.html 
 
[52] WONG, H. and SYCARA, K. (1999) Adding Security and Trust to Multi-Agent Systems, 
Proc. Autonomous Agents '99 Workshop on Deception, Fraud, and Trust in Agent Societies, 
May 1999, pp. 149 - 161. 
 
[53] ARK, W. and SELKER, T. (1999) A look at human interaction with pervasive computers, 
IBM Systems journal, Vol 38, N4, 1999 
 
[54] STREITZ, A., GEISSLER, J., HOLMER, T., KONOMI, S., MULLER-TOMFELDE, C., 
REISCHL, W., REXROTH, P., SEITZ, P. and STEINMETZ, R. (1999) I-LAND: An interactive 
Landscape for Creativity and Innovation, Proc of ACM Conference on Human Factors in 
Computing Systems, Pittsburgh, USA, ACM Press New York. pp. 120-127. 
 
[55] BUSCHER, M., CHRISTENSEN, M., MOGENSEN, P., ORBAEK, P. and SHAPIRO, D. 
(2000) Creativity, Complexity and Precision: Information Visualisation for (Landscape) 
Architecture, Proc Conf. On Information Visualisation (InfoVis 2000), Salt Lake City, IEEE 
Press 
Terence Blackburn 95 Enterprise-enabled Ubiquitous WorkSpaces 
Appendix A  
MetaGlue Agent Source Code 
Speech agent 
public class SpeechAgent extends ManagedSpeechAgent implements Speech, 
RemoteTagsListener 
{ 
 public static String channel = "myproject.speech"; 
 ExplorerWrapper explorer; 
 
 public SpeechAgent() throws RemoteException 
 { 
  loadGrammar("myprojects.test.explorer"); // "explorer" is the name of the grammar file 
  say("We have loaded the Grammar");  // a diagnostic line 
  explorer = (ExplorerWrapper)reliesOn 
   ("agentland.iroom.application.explorer.ExplorerWrapper", "cis214570"); 
 } 
SendAgent 
public class SendAgent extends ManagedAgent implements Send 
{ 
 Processx10 x ; 
 Notifier not ; 
 public SendAgent() throws RemoteException 
 { 
  try 
  { 
   x   = (Processx10)reliesOn ("myprojects.test.Processx10"); // starting an agent 
   not = (Notifier)reliesOn ("agentland.util.Notifier"); // setting up a publish channel 
  } 
  catch(Exception e){e.printStackTrace(); 
  } 
 } 
 public void send(String s) throws RemoteException 
 { 
  not.notify(new Secret(getAgentID(), "test.channel", s)); // sending on test channel 
 } 
Terence Blackburn 96 Enterprise-enabled Ubiquitous WorkSpaces 
ReceiveAgent 
public class ReceiveAgent extends ManagedAgent implements Receive 
{ 
 public ReceiveAgent() throws RemoteException 
 { 
   notifier = (Notifier)reliesOn("agentland.util.Notifier");  
  notifier.addSpy(getAgentID(), "test.channel");    // subscribing to "test" 
 } 
 
 public void tell(Secret secret) throws RemoteException 
 { 
  System.out.println ("channel = "+ secret.name()); 
  System.out.println ("message = "+ secret.details()); 
  System.out.println ("agentID = "+ secret.getSource().toString()); 
 } 
} 
ExplorerTestAgent 
public void sendElvinMessage(String s) throws RemoteException 
  { 
    try 
    { 
      Producer prod = new Producer(new ElvinURL("elvin://river")) ; 
  Notification notif = new Notification() ; 
 
  notif.put("message = ", s) ; 
         notif.put("demo","from terence ") ; 
         notif.put("pi = the following: ", 3.14); 
 
         prod.notify(notif); 
   
  prod.getConnection().close(); 
 }  // end of elvin code to send or produce a message 
  catch(Exception e) 
  { 
   e.printStackTrace(); 
  } 
 } 
 
 
Terence Blackburn 97 Enterprise-enabled Ubiquitous WorkSpaces 
public ExplorerTestAgent() throws RemoteException 
{ 
 try 
     { 
  Subscription sub = new Subscription("require(demo)") ; 
  sub.addNotificationListener (this) ; 
 
  Consumer cons = new Consumer(new ElvinURL("elvin://river")) ; 
  cons.addSubscription(sub) ; 
  System.out.println("waiting for events...") ; 
  } 
  catch(Exception e) 
  { 
   e.printStackTrace() ; 
  } 
} 
 
 
 public void notificationAction(Notification event) 
 { 
   System.out.println(event + "terence's message..."); 
} 
ExplorerAgentWrapper 
public void acceptedTagsResult(Hashtable tags) 
 { 
  try 
  { 
   Enumeration keys = tags.keys( ); 
   Enumeration el = tags.elements( ); 
   while(keys.hasMoreElements( )) 
   if(tags.containsKey("rule")) 
   { 
    if(tags.get("rule").equals("open")) 
    { 
     explorer.startApplication( ); 
     explorer.gotoURL("www.unisa.edu.au"); 
     Thread.sleep(10000); 
     explorer.goHome( ); 
    } 
Terence Blackburn 98 Enterprise-enabled Ubiquitous WorkSpaces 
   } 
  } 
  catch(Exception e){e.printStackTrace( );} 
 } 
Processx10Agent 
 public void doX10( ) 
 { 
  try 
  { 
   x10 = new x10Devices ( ) ; 
   x10.turnOn ('e', 5) ; 
  } 
  catch(Exception e) { e.printStackTrace( ) ; } 
 } 
x10Devices 
public boolean turnOn(char housecode, int module) throws RemoteException 
 { 
  try 
  { 
   house = (byte)housecode;   
   mod  = (byte)module ;        
   x10  = new SerialX10 ( ) ; 
 
   System.out.println ("house = " + house) ;  // diagnostic code 
   System.out.println ("mod = " + mod) ;       // diagnostic code 
 
   x10.open ("COM2") ;  
   x10.turnOn(house, mod) ;  
   x10.close() ; 
  } 
  catch (NoSuchPortException n) 
  { 
   System.out.println ("No such port " + n.getMessage()) ; 
  } 
  catch (PortInUseException p) 
  { 
   System.out.println ("Port in use " + p.getMessage()) ; 
  } 
Terence Blackburn 99 Enterprise-enabled Ubiquitous WorkSpaces 
  catch (java.io.IOException i) 
  { 
   System.out.println ("IO exception " + i.getMessage()) ; 
  } 
  return false ; 
 }     // end turnOn(char int) 
 
 
StartWfClient 
 public void start (String s) 
 { 
  StringTokenizer tokens; 
  String[] cmds; 
  int i = 0; 
  try 
  { 
   tokens = new StringTokenizer(s);                 // adds cmd line params from string s  
   cmds = new String[tokens.countTokens( )];        // cmds is now an array of tokens 
   wf = new WfClient () ; 
   wf.run(cmds) ;  // invoke the run method from WfClient with the start params 
  } 
  catch(Exception e) 
  { 
   System.out.println ("We have a problem, Housten!  " + e.getMessage()) ; 
   e.printStackTrace(); 
  } 
 } 
 
 
WfClient 
  public static void run(String[] args) throws ServerException 
   { 
  args = Config.setProperties(args); 
  if (args.length < 1) 
  { 
    usage("You must supply a workflow to run."); 
  } 
  Map result; 
Terence Blackburn 100 Enterprise-enabled Ubiquitous WorkSpaces 
  try 
  { 
    Server.setName("breeze-" + System.currentTimeMillis()); 
     if ("--shutdown".equals(args[0]))  
   { 
    invoke("Wf Shutdown", new HashMap()); 
     }  
     else if ("--status".equals(args[0]))  
     { 
    Map dict = new HashMap(); 
    if (args.length > 1)  
    { 
      dict.put("Wf.ID", args[1]); 
    } 
    invoke("Wf Status", dict); 
     }  
     else if ("--reap".equals(args[0]))  
     { 
    Map dict = new HashMap(); 
    dict.put("Wf.ID", args[1]); 
    invoke("Wf Reap", dict); 
     }  
     else  
     { 
    String cmd = "Wf Create"; 
    int i = 0; 
    if ("--spawn".equals(args[0]))  
    { 
      cmd = "Wf Spawn"; 
        i++; 
    } 
    Map dict = new HashMap(); 
    dict.put("WfName", args[i++]); 
    for (; i < args.length; i++) 
    { 
        int j = args[i].indexOf('='); 
        if (j < 1)  
        { 
     usage("Missing '=' or name in parameter argument: " + args[i]); 
         } 
Terence Blackburn 101 Enterprise-enabled Ubiquitous WorkSpaces 
        String name = args[i].substring(0, j); 
         Object value = args[i].substring(j+1); 
       try 
      { 
      value = new Integer((String) value); 
      } 
       catch (NumberFormatException e) 
        { 
      // ignore it, it's probably a string 
        } 
        dict.put(name, value); 
    }  
    invoke(cmd, dict);  
    } 
  } 
  finally 
  { 
     Server.dispose(); 
  } 
 } 
 
ODSI Source Code 
test_client 
def start_workflow(): 
        peer = get_peer(PEER, NETWORK) 
        ret = peer.rpc('WfManager start', WfName='running_test') 
def msg(sub, msg, insec, rock): 
        id = msg['MSG.ID'] 
        reply = msg['MSG.reply'] 
        m = msg['MSG.msg'] 
        text.insert(END, '\nID = %s\nMessage = %s\nReply = %d\n' % (id, m, reply)) 
        if reply: 
                m = list(m) 
                m.reverse() 
                m = ''.join(m) 
                text.insert(END, '\nSending reply of %s in %d seconds\n' % (m, TIMEOUT)) 
                send_reply(id, m, TIMEOUT) 
def send_reply(id, msg, timeout=None):  # timeout is in seconds 
        if timeout: 
Terence Blackburn 102 Enterprise-enabled Ubiquitous WorkSpaces 
                t = threading.Timer(timeout, send_reply, [id, msg]) 
                t.start() 
        else: 
                n = {'MSG.reply': id, 'MSG.msg': msg} 
                conn.notify(n) 
client = elvin.client(elvin.ThreadedLoop) 
conn = client.connection() 
conn.set_discovery(0) 
conn.append_url(elvin_server) 
conn.open() 
sub = conn.subscribe("require(MSG.ID)", 1, None) 
sub.add_listener(msg, conn) 
sub.register() 
root = Tk() 
f = Frame(root) 
yscroll = Scrollbar(f) 
yscroll.pack(side=RIGHT, fill=Y) 
xscroll = Scrollbar(root, orient=HORIZONTAL) 
text = Text(f, xscrollcommand=xscroll.set, yscrollcommand=yscroll.set) 
text.pack(side=LEFT, fill=BOTH, expand=1) 
f.pack(side=TOP, expand=1) 
xscroll.pack(side=BOTTOM, fill=X) 
start_workflow() 
mainloop() 
 
running_test 
import elvin, time, sha, threading, copy 
 
from service import service 
from misc import * 
 
elvin_server = 'elvin://river' 
 
class running_test(service): 
        reflect = copy.deepcopy(service.reflect) 
         
        reflect.add_method('send', 
                In = [('msg', 'string')]) 
         
Terence Blackburn 103 Enterprise-enabled Ubiquitous WorkSpaces 
        reflect.add_method('query', 
                In = [('msg', 'string')], 
                Out = [('reply', 'string')]) 
         
        def __init__(self, peer, **args_d): 
                apply(service.__init__,(self, peer),args_d) 
                 
                self.recieved = threading.Event() # event to check for reply 
                self.reply = None 
                 
                #start up an elvin connection 
                self.client = elvin.client(elvin.ThreadedLoop) 
                self.conn = self.client.connection() 
                self.conn.set_discovery(0) 
                self.conn.append_url(elvin_server) 
                self.conn.open() 
         
        def send(self, msg, **args_d): 
                n = {'MSG.ID': sha.sha(time.asctime()).hexdigest(), 
                        'MSG.reply': 0, 'MSG.msg': msg} 
                 
                self.conn.notify(n) 
                 
                self.Succeeded() 
         
        def query(self, msg, **args_d): 
                id = sha.sha(time.asctime()).hexdigest() 
                sub = self.conn.subscribe('MSG.reply == "%s"' % id) 
                sub.add_listener(self.__reply, self.conn) 
                sub.register() 
                 
                n = {'MSG.ID': id, 'MSG.reply': 1, 'MSG.msg': msg} 
                self.conn.notify(n) 
                 
                # send a running response to ODSI 
                self.Running() 
                 
                while not self.recieved.isSet(): 
                        self.recieved.wait(1) 
                 
Terence Blackburn 104 Enterprise-enabled Ubiquitous WorkSpaces 
                self.recieved.clear() 
                 
                self.Succeeded(reply = self.reply) 
         
        def __reply(self, sub, msg, insec, rock): 
                self.reply = msg['MSG.msg'] 
                self.recieved.set() 
 
 
Terence Blackburn 105 Enterprise-enabled Ubiquitous WorkSpaces