![](bg2.png)
ied software engineering for context-aware services.
The Context toolkit was a pioneer work of software
engineering issues in context-awareservices (Abowd,
1999; Salber et al., 1999). It aimed at allowing pro-
grammers to leverage off existing building blocks to
build interactive systems more easily. It was con-
structed as libraries as widgets for GUI. However,
since it was designed only for context-aware ser-
vices, it did not support the reuse of software for non-
context-aware services.
Ubiquitous computing defines a new domain in
which large collections of heterogeneous devices are
available to support the execution of applications.
These applications become dynamic entities with
multiple input and output alternatives. As a result,
it is difficult to predict in advance the most appro-
priate application configuration as discussed by sev-
eral researchers (Roman et al., 2003; Scholtz et al.,
2004). There have been many attempts to construct
software component technology for ubiquitous com-
puting (Flissi et al., 2005; Modahl et al., 2005). Sev-
eral researchers have studies modeling of context-
awareness in the literature of software engineering
(Henricksen and Indulska, 2005). However, there
have been no silver bullet as other systems so far.
Several researchers focuses on high-level analy-
sis on context-aware services. For example, A com-
parable model, which specify context-aware behav-
ior in only one diagram, the context-oriented domain
analysis diagram was explored (Desmet et al., 2007).
There have been several attempts to specify context-
aware services (Henricksen et al., 2002). However,
they cannot solve problems in software-level depen-
dencies with contexts.
We developed a mobile agent-based emulator to
emulate the physical mobility of its target terminal by
using the logical mobility of the emulator. It could
provide application-level software with the runtime
environment compatible to its target device and carry
it between computers through networks. However, it
intends to make it easy to test context-aware software
rather to develop such software.
Modern enterprise architectures, e.g., Enterprise
JavaBeans (EJB), (Kassem, 2000) and .Net architec-
ture (Szyperski, 1998), have employed the notion of
container to separate the business components from
the system components. The original notion has en-
abled key functionality such as transactions, persis-
tence, or security to be transparently added to the ap-
plication at deployment time rather than having to
implement it as part of the application. The notion
leads to increased reusability and interoperability of
business components. We use the notion to reuse
non-context-aware business software components in
context-aware ones. Non-context-aware components
are not designed to be used in ubiquitous computing
environments, where services appear and disappear
arbitrarily and nodescannot possibly know in advance
with which other nodes they will interact.
3 APPROACH
This section outlines our approach.
3.1 Example Scenario
To enable services that enhance user interaction with
his/her current environment, we need to enrich his/her
physical surrounding, e.g., shopping malls, museums,
and trade fares, with dedicated computing resources
that enable service to be provided. One example sce-
nario is a shopping mall that offers ambient services
to customers, enabling them to navigate through the
mall and find certain products quickly. Users moving
from shop to shop should have their services deployed
and executed at stationary terminals close to them
to support them. Annotation services on appliances,
e.g., electric lights, may be provided in shops. Such
services depend on context. For example, they present
digital signage for sales promotions while their tar-
get appliances are displayed on shelves. For example,
shops frequently replace and relocate their products
inside them. The services need to follow the move-
ment of their targets. Annotation services in appli-
ances are needed not only at shops to explain what
the appliances are but at users’ homes to explain how
they are to be used. Furthermore, such annotation ser-
vices may depend on users. Some may want audio
annotations but others may want visual annotations.
3.2 Design Principles
The Spatial Connector approach introduces the fol-
lowing three novel elements:
• Container is introduced to reuse existing non-
context-aware software components, e.g., Jav-
aBeans, as components for providing context-
aware service. Each service container is a run-
time environmentthat manages the execution of at
most one component and invokes specified meth-
ods defined in the component according contex-
tual changes in the real world by using sensing
systems.
• Counterpart is a reference to its target, e.g., a user,
physical entity, or computing device and contains
profiles about the target, e.g., the name of the user,
SpatialConnector-LooselyBindingContextualChangesandNon-Context-AwareServices
51