Speech Title

1
SavantTM
2004.04.07 Kim, Chang-soon Dept. of Computer
Science Yonsei Univ.
2
Contents

• What is the SavantTM?
• EPC Network Architecture
• Savant Specification
• Savant Overview
• Reader Interface
• Processing Modules
• Standard Processing Modules
• Application Interface
• Application Interface MTB
• Implementation of Savant
• Savant Network
• Major Modules (EMS, RIED, TMS)

3
What is the SavantTM

• Savant is a unique name used in Auto-ID Center
• Savant is a SW that sits between readers and
  enterprise applications
• Providing a variety of computational functions on
  behalf of applications

4
EPC Network Architecture
5
Savant Specification
6
Savant Overview

• Savant is itself a container
• Extensibility

7
Reader Interface

• RI must support for the Auto-ID Reader Protocol
  1.0
• may other reader protocols
• RI must provide means to invoke vendor-specific
  reader protocols
• Must permit interaction with at least on reader

8
Processing Modules

• Definition
• Savant may provide a means to create
  application-specific Processing Modules
• Requirements
• Access to Standard External Interfaces
• With Reader, Control channel, Notification
  channel
• Interaction with Other External Service
• Interaction among PMs
• Registration of Capabilities
• Required to register their names with the
  autoid.core
• Support for Standard Processing Modules
• Implementation of Savant MUST include all
  Standard PM
• PM naming conventions
• PM must have a unique name
• Standard PM autoid.xxx.xxx (or
  autoidx.xxx.xxx)User-defined PM
  com.sample.inventory

9
Standard Processing Modules

• autoid.core
• What other PMs are available
• Some basic Savant management functions
• autoid.core.GetSavantID
• autoid.core.GetCapabilities
• autoid.core.Shutdown
• autoid.core.ResetAll
• autoid.readerProxy
• Inquire what readers are connected
• Passing cmd. directly to the individual readers
• Functions
• autoid.readerProxy.GetReaders
• autoid.readerProxy.RunCommand

10
Application Interface

• Content layer
• Specify the abstract content of messages
  exchanged between the Savant and Applications
• Messaging layer
• Encoded (serialized), formatting, security,
  connection establishment
• Transport layer
• Networking facilities

11
Application Interface (cont)

• Message channel
• Control channel
• Request / response msgs. between Enterprise and
  Savant
• Notification channel
• Asynchronous msgs. from Savant to an Enterprise
• MTB (only two MTB is defined in ver. 1.0)
• XML-RPC / HTTP 1.1
• Communication
• One HTTP connection is used as Control channel
• Another connection is used as Notification
  channel
• Why XML-RPC?
• Very simple and easy to implement
• SOAP-RPC / HTTP 1.1
• Defines a uniform representation for RPC requests
  and responses

12
Application Interface (cont)

• Command Structure

Savant
1.Request (PM name, CMD name, args.)
2.Dispatch
Enterprise Application
PM
4. Return result
3.Performs function
13
Implementation of Savant
14
Savant Network

• The Savants are organized in a hierarchical tree
  structure

15
Edge Savants

• Collects real-time EPC data

16
Internal Savants

• Collects EPC data from the Edge Savants that are
  its descendants

17
Event Management System

• EMS is implemented on ES to collect tag read
  events
• Allowing adapters to be written for various types
  of readers
• Collecting EPC data from readers in a standard
  format
• Allowing filters to be written to smooth or clean
  EPC data
• Allowing various loggers to be written
• Buffering events to enable loggers, filters and
  adapters to operate without blocking each other

18
Requirements for EMS

• Should be a high-performance system
• Should Support EPC readers that communicate with
  different Auto-ID Center protocols
• Should support event filters
• Smoothing, Coordination, forwarding
• Should support multiple event loggers
• Should launch its processing units in different
  threads and should be capable of buffering the
  event streams between these units
• Should be able to instantiate the processing
  units based on any configuration of these units
• Should also allow remote machines to register and
  deregister to events streams dynamically

19
Components for EMS

• Reader Interface
• Allows readers and adapters to communicate events
  detected by the Auto-ID readers

20
Components for EMS (cont)

• Reader Adapters
• Communicate with readers to capture EPC events
• Event loggers (Event consumers)
• Allow for varied processing of events
• Store the information in the database
• Store events in a memory data structure
• Broadcast the events to a remote servers

21
Components for EMS (cont)

• Event Queues (Event forwarders)
• Handles multiple reader event loggers with
  synchronous implementations

22
Components for EMS (cont)

• Event Filters
• Handle on incoming event stream and post the
  events to one or more output streams
• Smoothing, coordination or forwarding

23
Realtime In-memory Event Database

• In-memory DB that can used to story event
  information by Edge Savants
• The loggers can log events in a database.
• But, databases cannot handle more than a few
  hundred transactions a second
• RIED
• Same interface as a database
• But, offers much better performance

24
Requirements for RIED

• Should be a high-performance in-memory database
• Should be a multi-versioned database

25
System Architecture

• Features
• Reducing DML complexity
• Reducing DDL Complexity
• Efficient support only for simple joins
• Simple query optimization
• No constraint maintenance and triggers

26
Task Management System

• TMS manages tasks, just as OS manages process
• Data management and monitoring
• Simplifies the maintenance of distributed Savants
• Task examples
• Data gathering
• PML lookup
• Remote task scheduling
• Personnel Alerts
• Remote upload
• Special features
• An external interface to schedule tasks
• A platform-independent virtual machine
• Uniform libraries loaded on-demand from
  class-server
• A robust scheduler

27
Requirements for TMS

• Should be a platform-independent system
• Should automatically upgrade the tasks
• Should present a well-defined, interoperable
  external interface to schedule, monitor, and
  remove tasks
• Should be written in a platform-independent
  language

28
System Architecture

• Task manager
• Responsible for running and maintaining tasks
  running on a savant
• SOAP interface
• Expose the functionality and interface of the
  Task Manager as a SOAP service
• Class Server
• Enable the dynamic addition of task
• Database
• Provides a persistent store for the Task Manager