Home

SANY Sensors Anywhere

About SANY | News | Results | Downloads | Contact | Login

Search

SANY concrete results

  • Sensor Service Architecture
    • Design Principles
    • Functional Domains
    • Implementation Platforms
    • Interaction Patterns
    • Service Interfaces
    • Uncertainity and Quality Assurance
  • SANY Software Components
  • Sensor Integration
  • Data Fusion and Modelling Services
  • Decision Support Infrastructure
  • SANY Applications

Upcoming events

  • no upcoming events available
Add to iCalendar
more
Home » Results » Sensor Service Architecture

Interaction Patterns

SensorSA Interaction PatternsSensorSA supports two main interaction patterns:

Request/Reply Interaction Pattern

In a classical request/reply interaction pattern, the consumer ‘knows’ the provider and initiates the interaction by "requesting" the information through direct call to a service interface. This interaction pattern is always synchronous, and the consumer has to keep listening until receiving the reply.

Event Driven Interaction Pattern

In "event driven" interaction, the consumer and the producer are linked through broker. In order to access the information, the consumer first declares interest in getting event notifications by issuing a subscribe operation with an event filter to a notification broker, usually together with a callback address. Independently of this action, the provider publishes events to the broker, e.g. in case of a state change of an underlying resource. The provider is unaware of the consumers that have subscribed to events. It is the task of the broker to analyse the event filters and to determine which consumer should be asynchronously informed by the broker about the event happening.

A-priory, any observation in SensorSA network may be communicated either in event-driven manner, or using the request/reply interaction pattern. Due to practical concerns, the event driven interaction pattern is primarily used in situations where request/reply interactions can not be used , or does not perform adequately. "Event-driven" use cases therefore often include some form of alerting, e.g. "new service/resource available", or "house on fire". However, the choice of interaction pattern may be also dictated by business reasons, e.g. because network configuration does not allow direct access to resources, or because the inexpensive hardware (e.g. smart sensor nodes) can not support relatively resources-hungry web services.

‹ Implementation PlatformsupService Interfaces ›
By Denis Havlik at 2009-09-20 13:19 | printer-friendly version | login to post comments