A Component Architecture for an Extensible, Highly Integrated ContextAware Computing Infrastructure

1
A Component Architecture for an Extensible,
Highly IntegratedContext-Aware Computing
InfrastructureAuthors William G. Griswold,
Robert Boyer, Steven W. Brown, and Tan Minh
Truong(Proceedings of 25th International
Conference of Software Engineering(ICSE03))

• Presented By
• Sastry L N Prakki

2
Keywords

• Context refers to the physical and social
  situation in which computational devices are
  embedded.
• Ubiquitous/Pervasive Computing is a term for the
  strongly emerging trend toward
• Numerous, casually accessible, often invisible
  computing devices
• Frequently mobile or embedded in the environment
• Connected to an increasingly ubiquitous network
  infrastructure composed of a wired core and
  wireless edges
• from the call for a conference on Pervasive
  Computing1

3
According to Dey et al.s work

• Define context in a very general way as any
  information that describes the setting of the
  users activities, with emphasis on the physical
  attributes time, place, people, physical
  artifacts, and computational objects.
• Identify the difficulties of handling context due
  to the myriad of sensors and devices involved,
  its distributed nature, the need to interpret the
  data into useful abstractions, and the need for
  persistent storage and access of context
  information.
• They address these issues by a conceptual
  framework consisting of context widgets (for
  capture and interaction), interpreters and
  aggregators, services, and resource discoverers.
  This framework is embodied in their Context
  Toolkit.

4
Fig.1 Architecture Diagram of Active Badge
Application using Context Tool Kit
5
What is this paper about!!

• It briefly describes two features namely Map
  Service and Buddy Service of ActiveCampus
  application developed by these authors in their
  research in University of California, San Diego.
• The Map Service and Buddy Service are shown in
  the following figure

6
Fig 2. Map Service of ActiveCampus Application
7
Fig.3 Buddy Service of ActiveService Application
8
Now dimensions of possible extensions for this
application

• A new service, such as a contextual alarm service
  3.
• A new kind of context or sensor input format,
  such as a latitude/longitude representation of
  location generated by a GPS device.
• A new kind of modeled physical entity, such as a
  web
• cam, which may also come with new kinds of
  context.
• Such entities would need to show up in the
  maps and
• entity lists of services to show where they
  are positioned
• and give access to their functionality.

9
Dimensions of Extensibility contd.

• A new representation, such as 3-D image of a
  location.
• A new end-user device, such as a pen PDA
  (personal digital assistant) could be added.

10
Tight Integration

• To facilitate the above proposed extensions it is
  clear that using Component Architecture is
  preferred that defines a component category for
  each dimension of extensibility, with
  standardized interface rules for each category.
• To contextually access one service from another
  is defines tight integration of the components.

11
Architecture proposed by the authors

• The authors follow centralized client-server
  approach (of Hong and Landay) to provide a
  context-aware application infrastructure.
• Most importantly, centralization provides greater
  freedom to allocate behavior to components and
  organize those components to meet the needs of
  extensibility, integration, and performance.
  Also, newly deployed services can integrate with
  and leverage the existing running services.
• At the highest-level there are two aspects of the
  systems component architecture the interfaces
  to external components, and the internal system
  architecture.

12
The problems faced by authors in their earlier
version of ActiveCampus Service

• Entity definitions experienced churn and bloat.
• Services were not decoupled from each other.
• Performance was becoming unacceptable.
• In the process of addressing these issues authors
  came up with the new architecture for
  ActiveCampus Service Infrastructure.

13
Fig4. The following figure gives pictorial
description of the architecture being proposed by
authors.
14
Description of layers of revised architecture

• 4. Device In the top Device layer, components
  run on devices and connect to ActiveCampus
  through RPC.
• 3. Environment Proxy The Proxy layer marshals
  data between Devices and ActiveCampuss
  internals.
• 2. Situation Modeling The Situation Modeling
  layer synthesizes the situation of an individual
  entity from multiple available data sources. For
  example, it translates quirky sensor
  representations to internal forms and associates
  them with entities. It also assembles and
  superimposes contextual representations of
  entities for end-user display (i.e., service
  execution). From the Context Toolkits point of
  view, these are Context Interpreters.

15
Description of layers of revised architecture
(Contd..)

• 1. Entity Modeling The Entity Modeling layer
  represents entities (e.g., users and sensors) in
  several forms raw external representations
  (e.g., a dynamically assigned network address),
  fast-indexing normal forms (e.g., a permanently
  assigned unique integer), and forms for
  presentation (e.g., a screen name). It also
  represents the staticrel ationships among them.
  From the Context Toolkits point of view, the
  components are (left to right) Context Widgets,
  Context Interpreters, Context Aggregators, and
  Context Interpreters.
• 0. Data (not shown) The data layer provides for
  efficient storage and retrieval of data, in our
  case through an SQL database. The data layer may
  store data differently than apparently organized
  in the Entity Modeling layer for reasons of
  performance.

16
Three Salient features of this Architecture

• How the representations of Entity Modeling layer
  are integrated by the Situation Layer !!
• Entity Bloat The Entity and Situation Layers
• Entity and Situation Modeling
• Service Coupling Introspective Interaction
• Speed Scoped, Context-Indexed Caching

17
Entity Bloat -The Entity and Situation Layers

• Entity Normalization. Following through with this
  insight entails the following architectural rules
  for representing entities relating entities to
  other data
• Only data that is intrinsic to an entity is part
  of its object. Alternate representations of
  intrinsic data should be stored separately.
• Intrinsic data should be represented in a compact
  normal form that is suitable for use as an index
  for fast retrieval of alternate representations.
• Any kind of context (e.g., location) should be
  standardized into an indexable normal form
  representation as well.

18
Entity Bloat (Contd..)

• All associations (mappings) of context (e.g.,
  buddy membership, (id1,id2) should be represented
  using their indexed forms. The association of
  alternate representations (e.g., (Sarah, Brad))
  should be reserved only for final display
• Advantages
• With these rules, adding a new service has no
  impact on an entity.
• The independence of both the representation and
  its mapping from the service makes it reusable by
  other services without further coupling services.

19
Entity and Situation Modeling

• Raw sensor data, by its nature, is not in
  entity-normal form. It is a pre-entity
  abstraction of entities until translated into a
  normal form and re-stored as entities.
• Entity Modeling Layer provides the presentation
  forms, pre-entity sensor forms and the normal
  forms of the data.
• Situation Modeling Layer provides the complex
  mapping first from raw sensor data to normal
  forms and then from entities to their rich
  presentation by services. This is achieved
  through third-party Sensor-Entity Reconciliation
  component.

20
Service Coupling Introspective Interaction

• Service Structure. All services are designated to
  run on behalf of an entity, usually a user,
  called the subject. Most services also can be run
  on the accessible context of an entity different
  than the subject, known as the object.
• boolean compatible(id subj, optional id
  obj)
• id renderID(id subj, optional id obj)
• The compatibility method is a type check to
  determine whether the types of the subject and
  object can support the successful execution of
  the service (e.g., they are of subtype Locatable
  and hence provide a location).
• The renderID method indicates how to render the
  target services activation button, without
  specifying the representation of that button
  (i.e., keeping entity references in normal form).
  For example, the renderID call on the Map service
  returns the objects (buddys) ID if object is
  bound.

21
Service Coupling Introspective
Interaction(Contd..)

• Registration. When a top-level service comes
  online, it is registered as available and is
  assigned a unique entity identifier by the
  system. If the service needs to be run regularly
  to notify users of important information, it also
  registers itself as an active service.
  Additionally, the developer of the service will
  provide values for the representations of a
  services activation button short name, icon,
  and tool tip.

22
Service Coupling Introspective
Interaction(Contd..)

• To render the services for an entity, an
  rendering service R iterates over the registered
  services S. For each service R calls its
  corresponding compatible method with invoking
  user as the subject and the entity as the object.
  For those calls returning true, R calls the
  corresponding services renderID method with the
  same arguments. R then uses the returnedID to
  obtain the represe4ntation of that service
  activation button.

23
Speed Scoped, Context-Indexed Caching

• Tolerable inconsistent and stale data is used.
• Caching is achieved through the memorization of
  method calls into the Entity Modeling layer.

24
Architecture Discussion

• Fissioning Objects across Layers
• The abstraction, distribution and storage are
  put across three layers hence there is an
  independent control of the implementation of each
  aspect. This also helps to to place other
  components in between.
• Intralayer Fissioning of Modeled entities
• The sensor representations and other entities
  are placed in the same Entity Modeling Layer.

25
Architecture Discussion (Contd..)

• Intralayer Fissioning of Situation Modeling
• Object Refinement combines data from multiple
  sensors and other sources to determine position,
  kinematics, and other attributes.
• Situation Refinement develops interpretation of
  the relationships among the objects and events in
  the context of the operational environment.
• Situation elaboration via Interservice
  Introspection.

26
Interesting points not considered in this paper

• What is the success of this architecture in the
  case of addition of new entities and services.
• Whether this will suffice the demands of new
  demands of new devices like Pen PDA as there
  could be inconsistent levels of support due to
  Advanced Javascripting techniques.

27
Conclusion

• The construction of a ubiquitous context-aware
  computing system faces the difficult tradeoff
  between the tight integration of application
  services and the ease with which they can be
  added to the system. Performance considerations
  further complicate the management of tradeoffs.

28
References

• 1 A component architecture for an extensible,
  highly integrated context-aware computing
  infrastructure- Griswold, W.G. Boyer, R. Brown,
  S.W. Tan Minh Truong Software Engineering,
  2003. Proceedings. 25th International Conference
  on , 3-10 May 2003 Pages363 - 372
• 2 Introduction to This Special Issue on
• Context-Aware Computing Thomas P. Moran
• IBM Almaden Research Center, Paul Dourish
• University of California, Irvine.Special Issue
  of Human-Computer Interaction, Volume 16, 2001

29

• Thank You