Service CatalogNet: A RFIDOriented Service Location System

1
Service CatalogNet A RFID-Oriented Service
Location System

• Beihong Jin
• Technology Center of Software Engineering
• Institute of Software
• Chinese Academy of Sciences

2
Contents

• Background
• System Overview
• Unified Service Model
• System Architecture
• Storage and Splitting of Service Information
• Collaboration Service Query
• Conclusion and Future Work

3
Background

• SERVICE/RESOURCE LOCATING provide the necessary
  functionality for RFID applications especially
  for open-loop RFID applications.
• Services concerned here are network-enabled
  applications which perform certain computation or
  management tasks and are usually accessed by
  access points such as IP addresses/URLs or
  particular client software called service stubs.
• Characteristics of open-loop RFID applications
• large amounts of unpredictable users
• various style of user access, either wired or
  wireless

4
Background

• Application scenarios
• Query the nearest maintenance service of the
  RFID-labeled product.
• Query product information services according to
  the products RFID tag.
• Download the trial version of an Internet game
  product tagged with a RFID code.
• Requirements
• Prompt locating and accessing the appropriate
  services according to
• A RFID tag code or a range of codes
• Users context information, e.g., location
• Other attributes
• Offer stable not fluctuant locating performance
  while RFID-related services may update frequently

5
Background

• Existing approaches
• Conventional directory services such as LDAP
  servers
• Lack of describing a range of attribute values
  directly, but they can implement this function
  semantic-equivalently
• Serious performance degradation under frequent
  updating
• Does not support service access
• Service discovery systems
• Inflexible service description for diversified
  and heterogeneous services
• (SDS and INS) XML-based or XML-like service
  description, low performance due to the
  inefficient DOM processing
• Existing service discovery protocols mainly aim
  for hardware services, lack of extensibility for
  software services.

6
Contents

• Background
• System Overview
• Unified Service Model
• System Architecture
• Storage and Splitting of Service Information
• Collaboration Service Query
• Conclusion and Future Work

7
System Overview SDMDH, the Service Model

• Adopts a hierarchy structure embedded with AV
  pairs.
• Allows extensibility for user-defined tags
  tailored to a specific service.
• Some attributed tags are predefined for defining
  the following information
• Service basic information
• Service content information
• Service context information
• Service access mode
• Based on SDMDH, exact matching, partial matching
  and semantic operator matching are provided.

8
Attr. a string oper-1
Range oper-2 lt gt lt gt
NOT oper-3 AND OR val. a string
, oper-1, ( , a string, ,, a string,
) , oper-2, , a string, ,
oper-3, , (, a string, ,, a string, ,,
a string, ) av-pair , attr., ,
val., Servicedescription av-pair ,
attr., , val., servicedescription,
, attr., servicedescription,
Service Service-Specifier
Classification Regional Product Quality
Report EPCCode-Range
Range(6A7969CBD1000000, 6A7969CBD1FFFFFF)
Context Location Beijing
Device PDA Resolution
240320 Processing High
Bandwidth High
Service-Record Identifier 0000000001
Description Beijing Second Quarter Dairy
Product Quality ReportVersion 1
Proxy-Node 2 Copy-Record 1, 3 Provider
Beijing Quality Supervision Bureau Type
Document File Report_PDA.doc Expiration
2007-09-01 Access Public
9
System Overview System Architecture

• Client/multi-server structure
• Proxy servers are fully connected into a overlay
  network.
• Service provider registers the services and
  provides service stubs to proxy server.
• Service requestor can contact proxy server for
  service information, and access services by
  downloading and invoking the service stubs.
• The service adaptation module in client software
  detects the presence of a RFID tag and the
  current location, and will transparently reissue
  the service query with the current context when
  either RFID tag changes or the location varies
  beyond a certain threshold.

10
Contents

• Background
• System Overview
• Unified Service Model
• System Architecture
• Storage and Splitting of Service Information
• Collaboration Service Query
• Conclusion and Future Work

11
Storage and Splitting of Service Information

• Service information and service provider data are
  stored in overlay in a decentralized way.
• All the service information is stored in a
  service tree with hollow circles representing
  attri-butes and filled cir-cles
  representingvalues.
• A single servicetree will suffer performance
  pro-blems when there encounters a great deal
  of query and management operations.

12

• //Split Service-Tree T from attribute node Ta
• Split (Service-Tree T, AttrituteNode Ta)
• //Initialize Set1 as a set of service records in
  T
• Set1 ? Service-Record-Set of T
• Set2 ? a new, empty Service-Record-Set
• K boundary for split, initialized as null
• //Get the number of service records in T
• totalNum ? Set1.size()
• //Get all value nodes in Ta
• List(Tv) getList(Ta.children)
• //Sort by certain rule
• SortedList(Tv) Sort(List(Tv))
• foreach Tv in SortedList(Tv)
• num ? Tvs Service-Record-Set.size()
• if Set2.size()numlttotalNum/2
• Append Tvs Service-Record-Set to Set2
• Delete Tvs Service-Record-Set from Set1

• //Reserve 2-bit mark for every node
• foreach Service-record in Set1
• //Mark as 1 first bit of all upper nodes
• //connecting to this service record
• Mark(Service-record, 1)
• foreach Service-record in Set2
• //Mark as 1 second bit of all upper nodes
• //connecting to this service record
• Mark(Service-record, 2)
• splittedTree ? a new, empty Service-Tree
• foreach node Tn in T
• if Tn.mark.Equals(11)
• //for common nodes used by two sets
• deep copy Tn out to splittedTree
• if Tn.mark.Equals(01)
• //for nodes used only in Set2
• deep copy SubTree(Tn) out to splittedTree

• A splitting algorithm will split a service tree
  into two when the service scale or the number of
  concurrency operations is larger than a specified
  threshold.

13
Splitting Effect Comparisons
Memory Occupied
Execution Time

• Record the memory occupied and the time required
  by executing the same management and query
  operations on 20000 service descriptions before
  and after the splitting, i.e., in the form of 1,
  2, 4, 8 and 16 trees.
• Increase the performance of concurrency
  operations at the expense of a relatively slow
  growth of memory consumption

14
Contents

• Background
• System Overview
• Unified Service Model
• System Architecture
• Storage and Splitting of Service Information
• Collaboration Service Query
• Conclusion and Future Work

15
Collaboration Service Query

• When receiving a clients query request,
• first match the query locally,
• then forward it to other peers with the
  nearest-position from client first rule until
  finding the matched service.
• the request from specific location will be
  routed along a definite path

16
Collaboration Service Query

• History-based service information replication is
  employed to support a large number of service
  queries.
• A service replication tree is maintained to
  guarantee the consistency of service information.
• When service information is updated, the updating
  information will propagate along the replication
  tree to keep all the replicas up-to-date.

17
Query Performance Evaluation

• Evaluate the query performance for Service
  CatalogNet, comparing with the other three
  approaches,
• XPath query for XML-fashion services in .NET
  framework,
• two LDAP queries for Netscape LDAP server v6.2
  and IBM Tivoli LDAP server v5.2.
• Experiment environment Our experiments are
  conducted in a Pentium4 2.8GHz PC with 512MB of
  RAM, running Windows XP.

18
Query Performance Semantic Operator Query
Execute semantic-equivalence queries in four
systems
Figure (a) Under a fixed services scale (10000
services)
Queries involving RANGE operator
Figure (b) Under a fixed concurrency query number
(2000)
19
Query Performance Partial Matching
Compare the time of executing equivalent partial
matching operations
Figure (a) Execute partial matching under a fixed
service scale (10000Services)
Figure (b) Execute partial matching under a fixed
concurrency query number (2000)
20
Query Performance Hybrid Operations
Hybrid operations consist of 80 partial matching
operations and 20 management operations
Figure (a) Execute hybrid operations under a
fixed service scale (10000Services)
Attribute unstable performance of two LDAP
servers to index adjustments in directory services
Figure (b) Execute hybrid operations under a
fixed concurrency query number (2000)
21
Contents

• Background
• System Overview
• Unified Service Model
• System Architecture
• Storage and Splitting of Service Information
• Collaboration Service Query
• Conclusion and Future Work

22
Conclusion and Future Work

• Service CatalogNet
• New service model, supporting semantic
  description oriented for RFID-related services
• Scalability for service information
• Dynamic service storage splitting
• History-based service information replication
• High query performance
• Future work
• Wide-area support
• Security and access control
• Fault tolerance
• Deploy it to actual application environment