US8296413B2 - Device registration in a hierarchical monitor service - Google Patents

Device registration in a hierarchical monitor service Download PDF

Info

Publication number
US8296413B2
US8296413B2 US11/443,549 US44354906A US8296413B2 US 8296413 B2 US8296413 B2 US 8296413B2 US 44354906 A US44354906 A US 44354906A US 8296413 B2 US8296413 B2 US 8296413B2
Authority
US
United States
Prior art keywords
monitor
service
monitor service
message
registration
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US11/443,549
Other versions
US20070282988A1 (en
Inventor
Christof Bornhoevd
Brian S. Mo
Matthias M. Wiemann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SAP SE
Original Assignee
SAP SE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US11/443,549 priority Critical patent/US8296413B2/en
Application filed by SAP SE filed Critical SAP SE
Assigned to SAP AG reassignment SAP AG ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WIEMANN, MATTHIAS M., BORNHOEVD, CHRISTOF, MO, BRIAN S.
Assigned to SAP AG reassignment SAP AG ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WIEMANN, MATTHIAS M., BORNHOEVD, CHRISTOF, MO, BRIAN S.
Assigned to SAP AG reassignment SAP AG ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WIEMANN, MATTHIAS M., BORNHOEVD, CHRISTOF, MO, BRIAN S.
Assigned to SAP AG reassignment SAP AG ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WIEMANN, MATTHIAS M., BORNHOEVD, CHRISTOF, MO, BRIAN S.
Priority to EP07010654A priority patent/EP1862957A1/en
Priority to CN2007101087233A priority patent/CN101083587B/en
Publication of US20070282988A1 publication Critical patent/US20070282988A1/en
Publication of US8296413B2 publication Critical patent/US8296413B2/en
Application granted granted Critical
Assigned to SAP SE reassignment SAP SE CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: SAP AG
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management

Definitions

  • This description relates to ubiquitous computing technologies.
  • Smart item technologies may include, for example, radio-frequency identification (RFID) systems, embedded systems, sensor motes, and/or sensor networks, and may be used, for example, to provide business software applications with fast access to real-world data.
  • RFID radio-frequency identification
  • smart item technologies may be used support the detection, reading, or writing of RFID tags, as well as to support communication with, and control of, wireless sensor networks and embedded systems.
  • smart items may include devices having local processing power, memory, and/or communication capabilities, that are capable of providing data about the device and its properties, or information about a current state or environment of the smart item devices.
  • some such devices may be used in the execution of service components of back-end or underlying business applications, and, in particular, may do so in a collaborative way, e.g., by forming mobile ad-hoc networks to collect, process, or transmit business data.
  • smart item devices examples include an RFID tag, which may be passive or active, and which may be attached to a real-world object and used to provide product or handling information related to the object.
  • Other examples of smart item devices includes various sensors, such as, for example, environmental sensors (e.g., a temperature, humidity, or vibration sensor), which, as just referenced, may be capable of communicating to form one or more sensor networks.
  • environmental sensors e.g., a temperature, humidity, or vibration sensor
  • smart item devices also may include embedded systems, which may refer generally to any system in which a special-purpose processor and/or program is included, and/or in which the system is encapsulated in the device being controlled.
  • smart item technology may provide businesses with accurate and timely data about business operations, and also may help streamline and automate the business operations. Accordingly, cost reductions and additional business benefits (e.g., increased asset visibility, improved responsiveness, and extended business opportunities) may be obtained.
  • a method includes transmitting, from a registering monitor service at a first tier of a hierarchical, multi-tier monitoring architecture for a device network, a solicitation message identifying both the registering monitor service, and a registered monitor service associated with a second, higher tier of the hierarchical, multi-tier monitoring architecture.
  • the method also includes transmitting, from the registered monitor service, an advertisement message indicating an identity and availability of the registered monitoring service for registration, and transmitting, from the registering monitor service, a registration message including registration data associated with the registering monitor service.
  • the method also includes registering the registering monitor service within the hierarchical, multi-tier monitoring architecture, based on the registration data.
  • Implementations may include one or more of the following features.
  • the method may include transmitting, from the registered monitor service, a confirmation message confirming registration of the registering monitor service.
  • the solicitation message may be transmitted to the second, higher tier, after a previous transmitting to an intervening tier does not result in receiving the advertisement message.
  • Transmitting the solicitation message also may include broadcasting the solicitation message at a pre-determined time interval.
  • Transmitting the registration message may include including, within the registration data, device metadata within the registration message and associated with a device on which the connecting service is deployed, and/or including, within the registration data, service metadata within the registration message and associated with a service deployed on the device. Transmitting the registration message also may include including, within the registration data, sensor values obtained by a sensor associated with the connecting service.
  • Transmitting the registration message may include re-transmitting the registration message until the confirmation message is received or until a time-out condition is reached, and/or may include discarding, at the registering monitor services, a further advertisement message received after the registration message is transmitted. Additionally, or alternatively, transmitting the registration message may include storing the registration data using at least one device associated with the registered monitor service, and/or updating global monitor data for the hierarchical, multi-tiered monitor architecture, based on the registration data, to reflect the registration of the registering monitor service with a global monitor service.
  • a core monitor service may be deployed onto the registering monitor service, and device metadata associated with a device on which the registering monitor service is deployed may be determined. At least one monitor service module may be deployed onto the device, based on the device metadata.
  • the solicitation message may be transmitted, the advertisement message may be received, and/or the registration message may be transmitted, using the at least one monitor service module.
  • a system includes a monitor service configured to obtain and report monitor data regarding a device network at a first level of a hierarchical, multi-tiered monitor service.
  • the monitor service includes a registration system configured to send a solicitation message from the monitor service, the solicitation message specifying, by tier, a registered monitor service at a higher-level tier of the hierarchical, multi-tiered monitor architecture, the registration system being further configured to receive an advertisement message from the registered monitor service, determine that the registered monitor service is a member of the specified tier based on the advertisement message, and send a registration message to the registered monitor service.
  • Implementations may include one or more of the following features.
  • the registration system may be configured to receive a confirmation message from the registered monitor service, in response to the registration and confirming that the monitor service is registered with a global monitor service associated with the device network.
  • the registration message may include registration data that is stored, at least in part, using the global monitor service and any intervening monitor service between the registering monitor service and the global monitor service.
  • a method includes receiving a solicitation message from a monitor service at a registered monitor service of a hierarchical, multi-tiered monitor architecture for a device network, determining that the monitor service is not registered through the registered monitor service as a member of the hierarchical, multi-tiered monitor architecture, and determining an identification of a tier specified in the solicitation message, the registered monitor service being deployed on the tier.
  • the method may include sending an advertisement message to the monitor service, the advertisement specifying the registered monitor service as being deployed on the tier and available for registration, receiving a registration message from the monitor service, and registering the monitor service within the hierarchical, multi-tiered monitor architecture, based on the registration message.
  • Implementations may include one or more of the following features.
  • a confirmation message may be sent to the monitor service.
  • sending the advertisement message may include sending the advertisement message in response to the solicitation message.
  • Registering the monitor service may include storing, locally to the registered monitor service, registration data received from the monitor service as part of the registration message, and updating a memory of a higher-tier monitor service, above the registered monitor service, based on the registration data.
  • FIG. 1 is a block diagram of a system for monitoring smart items.
  • FIG. 2 is a block diagram illustrating an example deployment of the system of FIG. 1 .
  • FIG. 3 is a block diagram illustrating a second example deployment of the system of FIG. 1
  • FIG. 4 is a block diagram of a smart items infrastructure for implementing the systems of FIGS. 1 , 2 , and 3 .
  • FIG. 5 is a timing diagram illustrating an example algorithm for gathering monitor data using the system of FIG. 1 .
  • FIG. 6 is a block diagram of a modular monitor service that may represent one or more of the monitor services 132 a - 132 d of FIG. 1 .
  • FIG. 7A is a flowchart illustrating an operation of the system of FIG. 1 using the modular monitor service of FIGS. 1 and 6 .
  • FIG. 7B is a flowchart illustrating additional example operations of the system of FIG. 1 .
  • FIG. 8 is a block diagram of an example implementation of a core monitor service of FIGS. 1 and 6 .
  • FIG. 9 is a block diagram illustrating a system adaptor manager for use with the modular monitor service of FIG. 6 and/or the implementation of the core monitor service illustrated in FIG. 8 .
  • FIG. 10 is a block diagram of an example implementation of a system adaptors of FIGS. 1 , 6 , and 9 .
  • FIG. 11 is a block diagram of another example implementation of system adaptors of FIGS. 1 , 6 , and 9 .
  • FIG. 12 is a block diagram of an example implementation of a communication adaptor of the modular monitor service of FIG. 6 .
  • FIG. 13 is a block diagram of another example implementation of the communication adaptor(s) of FIG. 6 .
  • FIG. 14 is a block diagram of an example implementation of a preprocessor module of FIG. 6 .
  • FIG. 15 is a block diagram of a system illustrating a registration protocol for use with the system 100 of FIG. 1 .
  • FIG. 16 is a sequence diagram illustrating an example implementation of the registration protocol of FIG. 15 .
  • FIG. 17 is a flowchart illustrating example operations of the system of FIG. 15 .
  • FIG. 1 is a block diagram of a system 100 for monitoring smart item devices.
  • a sensor network 102 that includes various smart item devices provides real-world data to one or more business data processing systems 104 in a timely and accurate manner, using a local area network 106 (although other sizes or types of networks may be used).
  • the sensor network 102 may include smart item devices 108 , 110 , 112 , and 114 , referred to herein as “smart item devices” or simply as “devices” (or similar terminology), which may include, for example, RFID readers (for reading RFID tags associated with real-world objects having an RFID tag), various embedded systems, and/or various types of sensors and/or sensor motes.
  • sensor networks may refer to any network that gathers or obtains information, even if not all of the devices of the sensor network do not have specific sensor functionality associated therewith (e.g., one of the devices of the sensor network 102 may include an actuator).
  • devices of such device networks may communicate with one another (e.g., in a peer-to-peer fashion), and/or may communicate, e.g., through appropriate middleware, with the business data processing systems 104 , or other systems.
  • the device 108 is illustrated as including a central processing unit (CPU) 116 , as well as a memory 118 .
  • the device 108 should be understood to be capable of various levels of computing capabilities, including, for example, processing or transmitting sensed data (e.g., in the case where the device 108 includes, or is associated with, a sensor).
  • the devices 110 , 112 , and 114 also may include the same or different computing capabilities, including, for example, the capability to form and participate in the sensor network 102 , such as a wireless network and/or a peer-to-peer network.
  • the sensor network 102 may be used to collect, process, filter, aggregate, or transmit data that may be useful to the business data processing systems 104 .
  • the business data processing systems 104 may include inventory management systems, supply chain management systems, retail store management systems, warehouse management systems, and any other system(s) that may be used to execute business processes with respect to real-world objects, where such real-world objects may include, for example, products for sale, pallets or other shipment elements, patients, or manufacturing materials/equipment.
  • the business data processing systems 104 may be used, for example, to determine inventory levels, set pricing levels, evaluate marketing strategies, evaluate manufacturing or production technologies, reduce theft, or maintain safety.
  • processing may be performed very early in the data-collection process(es), so that a burden placed on the business data processing applications 104 may be reduced or eliminated.
  • the business data processing applications 104 may be located at a corporate headquarters, and the sensor network 102 may represent one of many (types of) networks that may be dispersed across a large geographical region connected by the wide area network 106 .
  • the business data processing systems 104 may only require certain sub-sets or characterizations of data collected by the network 102 (and related networks), and may not need or want all collected data.
  • the business data processing systems 104 may include compound or composite applications that are made from re-usable software components or services that are designed to perform some well-defined task(s). Also, in these or other implementations, the business data processing systems 104 may include legacy applications that may not easily communicate with data-collection devices (or with other business data processing systems), and, in such cases, services or service components may be provided as interfaces between the legacy applications and the data collection devices and/or other systems.
  • the system 100 allows these and other applications and services to be deployed directly on the devices 108 , 110 , 112 , and 114 , so that, for example, services may be run on the devices (and data may be collected and/or processed) in a timely, efficient, reliable, automated, cost-effective, and scaleable manner.
  • business processes may be decomposed into individual services and deployed at different devices.
  • the system 100 includes a service mapper 120 that is operable to select the device 108 as a selected device from among the plurality of devices 108 , 110 , 112 , and 114 of the sensor network 102 , for deploying a service 122 thereon, as shown.
  • the service mapper 120 accesses a service repository 124 that is operable to store a plurality of services that are eligible for execution within the sensor network 102 and/or other networks (not shown in FIG. 1 ).
  • the service mapper 120 determines service metadata 126 along with an actual service executable 128 , and compares the service metadata 126 against device metadata 130 associated with each of the plurality of devices 108 , 110 , 112 , and 114 . Based at least on the service metadata 126 and the device metadata 130 , the service mapper 120 may select the device 108 as being particularly well-suited for deployment of the service 122 (including the service executable 128 ) thereon.
  • the device metadata 130 may include a description of each device, the description being constructed according to an ontology and/or schema that is known to the service mapper 120 and common to the various devices 108 , 110 , 112 , and 114 . Additionally, or alternatively, the device metadata 130 may be collected in a device-specific format or structure for each of the devices 108 , 110 , 112 , and 114 , e.g., by a system monitor 132 , and may thereafter be converted into such a common schema for use by the service mapper 120 .
  • the device metadata may include a description of various technical capabilities of the devices 108 , 110 , 112 , and 114 , provided in an extensible Markup Language (XL)-based language, e.g., by using an XL schema, as described in more detail, below.
  • XL extensible Markup Language
  • other formats, languages, and/or structures may be used, as well.
  • the device metadata 130 may include, for example, a device description, a software description, a hardware description, and a device status.
  • the device description may include a device name, identifier, or type, or may include vendor information including a vendor name or vendor website.
  • the software description may include an operating system description, including version and/or vendor, or may include a description of services running or allowed to run on the device platform.
  • the hardware description may include information about attributes of the CPU 116 (e.g., name and/or speed), memory 118 (e.g., total and/or free amount of memory), or connection capabilities (e.g., connection speed or connection type) of the device(s).
  • the device status may include more volatile information, including a device location, current CPU usage, or remaining power or memory.
  • the device metadata 130 may include information about other devices, such as where the device 108 includes an RFID reader, and the device metadata 130 may include a description of types of RFID tags that may be read and/or written to by the RFID reader.
  • the service metadata 126 may somewhat analogously include various service descriptions and/or requirements that relate to whether and how the service(s) may be executed on one or more devices.
  • the service metadata may include a service behavior description, technical constraints of the service, or information regarding input, output, preconditions, or effects (IOPE) of the service.
  • technical constraints may include a required CPU type or speed, an amount of (free) memory that is needed, a type or speed of connection that is required or preferred, an operating system version/name/description, or a type or status of a battery or other device power source(s).
  • static and dynamic service requirements such as hardware requirements.
  • a static value such as a total memory or maximum processing speed required by a service may be included, along with dynamic values such as available memory/processing/power and/or a number or type of other services that may be allowed to concurrently run on a device together with the service(s) in question, at an execution time of the service(s).
  • the service mapper 120 may map a given service onto the devices 108 , 110 , 112 , or 114 of the sensor network 102 .
  • Such a mapping is designed not only to value-match various aspects of the service metadata 126 and the device metadata 130 , where necessary (e.g., matching a required memory specified in the service metadata 126 with a device memory specified in the device metadata 130 ), but also to enable and optimize a deployment and execution of the service in question.
  • both the device 108 and the device 110 are nominally or ostensibly capable of running the service 122 (e.g., both devices 108 and 110 may posses some minimum required values of memory, processing capabilities, or power).
  • the service mapper 120 may map the service 122 to the device 108 if the device 108 is currently able to provide more power relative to the other candidate device 110 , even if the device 110 currently provides more free memory than the device 108 .
  • a service injector may be used to install and start the mapped service (e.g., the service 122 ) on the device 108 .
  • a service injector also may be used, for example, to manage a life cycle of the service(s), e.g., by performing service updates or stopping the service when necessary.
  • the system monitor 132 is configured to determine, track, and/or provide a current state of the system 100 .
  • state information may include, for example, which of the devices 108 , 110 , 112 , 114 are currently available for service deployments, or what services are currently running on which of the devices 108 , 110 , 112 , 114 .
  • the system monitor 132 may detect and collect device metadata 130 , including static, discrete-dynamic, or continuous dynamic device metadata, as described in more detail, below, as well as network metadata 140 related to the sensor network 102 , also described in more detail, below.
  • monitor data such as the device metadata 130 and/or the network metadata 140 may thus be made available to the service mapper 120 , the business data processing systems 104 , and/or to a system administrator.
  • the system monitor 132 is implemented using a four-tier architecture to provide for a scalable, distributed monitoring service(s). That is, the system monitor 132 may be implemented using one or more monitoring services, where the monitoring services may be stored in the service repository 124 , and may be mapped, in whole or in part, to the sensor network 102 (and to devices associated with the sensor network 102 ) by the service mapper 120 .
  • Such a four-tier architecture may be used in conjunction with algorithms described herein, so as to efficiently gather monitor data in a distributed system landscape, such as that of the system 100 .
  • Such monitor data may include, for example, the device metadata 130 (which may include, for example and as described herein, connectivity information, battery life, or CPU/memory usage of the devices 108 , 110 , 112 , 114 ) and/or the network metadata 140 .
  • the network metadata 140 may include, for example, various network parameters, particularly where such parameters are dynamic and not necessarily discernable from information about any single device.
  • One such example of the network metadata 140 may include available bandwidth on the sensor network 102 .
  • Other examples include network topology information, mobility characteristics of the network as a whole, and reliability of network connections.
  • such monitor services may be implemented using a modular approach, in which a core monitor service is mapped to one or more devices included in, or associated with, the sensor network 102 . Then, additional monitoring-related functionality may be provided to such devices using plug-ins, add-on services or service components, or other service modules, which interact with the core monitor service. As should be understood, the core monitor service(s) and any supplemental monitor services may be mapped, for example, using the service mapper 120 and based on, for example, application-specific requirements and relevant device metadata (e.g., capabilities). In additional or alternative implementations, various protocols may be used to register new devices and deployed monitor service(s) with the distributed monitoring service(s) in a fast, secure, energy-efficient, and reliable manner, even as devices join or leave the sensor network 102 .
  • various protocols may be used to register new devices and deployed monitor service(s) with the distributed monitoring service(s) in a fast, secure, energy-efficient, and reliable manner, even as devices join or leave the sensor network 102 .
  • the above-referenced four-tier architecture includes four types or classes of monitor services, which may be hierarchically layered.
  • the uppermost tier also referred to herein as the global layer
  • the global monitor service 132 a provides a highest-level storage and view of monitor data, not just for the sensor network 102 , but potentially for a plurality of sensor networks (see, e.g., FIG. 2 ).
  • the global monitor service 132 a may provide a central contact point for system monitoring information for other system components (e.g., the service mapper 120 ), the business data processing system(s) 104 , a system administrator, and/or a system administration graphical user interface (GUI).
  • Global-level monitor data may be stored in a memory represented in FIG. 1 by global monitor data 136 , which may thus be considered to represent or include global device metadata describing devices of the sensor network 102 and other networks, at least at a high level, as well as current service information about which services are running on which networks, for example.
  • the global monitor service 132 a is conceptually above, and updated by, a second layer or tier, referred to herein as the local layer or local tier, and including a local monitor service(s) 132 b .
  • the local monitor service 132 b is configured to provide the global monitor service 132 a with information about changes in the underlying sensor network 102 .
  • the local monitor service 132 b may be configured to use a memory represented in FIG. 1 as local monitor data 138 to store more detailed monitor data about the devices 108 , 110 , 112 , 114 in the sensor network 102 than may practically be stored in association with the global monitor service 132 a (and the global monitor data 136 ).
  • the local monitor service 132 b may be responsible for one or more sensor networks or other device clusters, and that such networks/devices may include potentially heterogeneous devices deployed in relatively close physical proximity to one another.
  • the local monitor data 138 may be considered to represent local device metadata regarding networks within the purview of the local monitor service 132 , such as the sensor network 102 , where it should be understood that the local monitor data 138 may generally be more specific than the global monitor data 136 with regard to particular devices of the sensor network 102 , and other supervised networks.
  • the third layer or tier includes a group leader monitor service 132 c , which may be configured for the collection, filtering, and aggregation of monitor data for the devices 108 , 110 , 112 , and 114 .
  • the group leader monitor service 132 c may be configured to manage collection of monitor data from associated devices 108 , 110 , 112 , 114 by using, for example, polling or heartbeat techniques.
  • the group leader monitor service 132 c is then responsible for reporting the resulting monitor data back to its respective local monitor service 132 b .
  • the group leader monitor service 132 c does not store monitor data, due to, for example, limited resources at the device 108 , or because a rate of change of the monitor data processed by the group leader monitor service 132 c makes storage impractical.
  • the group leader monitor service 132 c may be considered to present group-level device metadata regarding the particular devices 108 - 114 within its group, including, for example, dynamic or static device characteristics, or information about which services are running on which of the devices 108 - 114 .
  • the fourth layer or tier of the example four-tier architecture of FIG. 1 includes an edge monitor service 132 d .
  • the edge monitor service 132 d collects the monitor data for its associated device (here, the device 110 ) and the local services of the associated device. That is, it should be understood that, just as the device 108 is illustrated as executing the service 122 , the device 110 also may be executing one or more services, and the edge monitor service 132 d may be configured, for example, to monitor information about such services, as well as to monitor static or dynamic data specific to the device 110 itself (e.g., total memory, currently-available memory, device type, and/or other device characteristics).
  • the edge monitor service 132 d is further configured to report collected monitor data to the group leader monitor service 132 c .
  • the edge monitor service 132 d provides edge-level device metadata about a particular, (usually single) device, such as the device 110 .
  • the monitor services 132 a - 132 d may be configured to be responsible for different tasks, and may generally become more lightweight towards the edge of the infrastructure of the system 100 . Consequently, for example, the edge monitor service 132 d may be implemented on the device 110 , which may have very limited computing capabilities, while the global monitor service 132 a may be implemented on a device(s) 142 and/or 144 , such as, for example, a personal computer (PC) or a similarly-powerful server machine. Meanwhile, the local monitor service 132 b may be implemented, for example, on a device 146 , such as, for example, a smart RFID reader, or a personal digital assistant (PDA).
  • PDA personal digital assistant
  • the group leader monitor service 132 c may be deployed, as shown in FIG. 1 , on one of the devices of the sensor network 102 (although it should be understood that the devices 108 , 110 , 112 , 114 may be heterogeneous devices having differing computing capabilities, so that the device 108 may be selected as the group leader based on, for example, its relatively-superior resources), or the group leader monitor service 132 c may be deployed, in another example, on a wireless access point that is in communication with the devices 110 , 112 , and 114 .
  • monitor services 132 a - 132 d may be physically deployed on some or all of the various devices 108 - 114 , 142 , 144 and/or 146 , as well as other devices, are provided below with respect to FIGS. 2-3 .
  • monitor service module 150 may be associated with the core monitor service 148 within the devices 108 (and, analogously, although not shown in FIG. 1 , within devices 142 , 144 , 146 , and 110 - 114 ), such that the core monitor service 148 , which may be very slim so as to run on small or resource-poor devices, may be specialized/extended according to application-specific needs and/or the capabilities of the respective devices.
  • functionality related to communication, data storage, or data preprocessing may be added or replaced to a given device without changing the core monitor service 148 .
  • core monitor service(s) and associated monitor service modules are discussed in more detail with respect to FIGS. 6-14
  • the system 100 may gather monitor data, including, for example, the device metadata 130 or the network metadata 140 , using the following example algorithm.
  • the monitor data may be gathered at the group leader monitor service 132 c , from which it is propagated to the local monitor service 132 b , and then to the global monitor service 132 a .
  • the group leader monitor service 132 c may execute a system adaptor 134 , which may itself be, for example, a service mapped to the device 108 from the service repository 134 by the service mapper 120 .
  • the system adaptor 134 which may conceptually represent a plurality of different types of adaptors, and which also may be considered to be an additional or alternative example of the monitor service module 150 , may be configured to interface with the service 122 , and thereby may gather data from or about the service 122 .
  • the system adaptor 134 may represent a device adaptor that is configured to interface with the components of the device 108 , e.g., the CPU 116 or the memory 118 , so as to provide, for example, hardware-specific information related to the device 108 .
  • the group leader monitor service 132 c may execute the system adaptor(s) 134 , which thereby serve as data sources to provide the monitor data regarding devices and services.
  • the monitor data may include information about the device 108 , and/or about the service 122 .
  • the monitor data is sent to upper tiers, e.g., via the local monitor service 132 b to the global monitor service 132 a .
  • the group leader monitor service 132 c collects monitor data from the edge devices 110 , 112 , 114 .
  • each of the edge devices 110 , 112 , 114 may be associated with its own monitor service, e.g., the edge monitor service 132 d of the edge device 110 .
  • the edge monitor service 132 d may be implemented using (instances of) the core monitor service 148 , along with various examples and types of the monitor service module 150 .
  • the group leader monitor service 132 d and the local monitor service 132 b may be configured to perform message aggregation, in which messages from different devices (e.g., from different group leader devices, and/or from different edge devices) are summarized into a single message.
  • the monitor data may be preprocessed (e.g., filtered or aggregated), and such pre-processors may be performed by the monitor service module 150 , or a similar module. Accordingly, an amount of monitor data that is passed to the global monitor service 132 a may be reduced.
  • monitor data is propagated up from lower to higher tiers, e.g., from the edge monitor service 132 d to the global monitor service 132 a .
  • the monitor data may be stored in various forms and to various extents, within different ones of the tiers/layers.
  • data may be stored at the global monitor data 136 , and/or at the local monitor data 138 , where it should be understood that the local monitor service 132 b and the local monitor data 138 (and the device 146 ) may represent multiple services, memories, and devices associated with the system 100 (see, e.g., FIGS. 2-4 ).
  • Various techniques may be used to determine the type and extent of the monitor data that is to be stored (or not stored) at a given one of the tiers of the architecture of the system 100 of FIG. 1 . For example, decisions on whether and where to store monitor data may be based on battery lifetime, memory availability, device reliability, network utilization, response times, and outdated information (e.g., there may be a requirement to keep certain types of monitor date up-to-date to a specified extent). For example, the device 146 associated with the local monitor service 132 b may have a certain amount of available memory, while another device (not shown) may implement another local monitor service associated hierarchically with the global monitor service 132 a , and which may have a relatively-significant amount of free memory.
  • One aspect of whether to store monitor data at a given location relates to a priority of the monitor data. For example, information such as a device ID, a device classification, and alive-status may have a high priority for being stored.
  • Another aspect relates to a nature of the monitor data. For example, static and discrete-dynamic data from the group leader monitor service 132 c may be stored when queried, so that often-queried monitor data is read less often (e.g., is effectively cached at the local monitor data 138 ).
  • (potentially) outdated data must be managed, so as to be updated, as necessary. Meanwhile, continuous-dynamic data may not be stored, since it may be outdated as soon as it is stored. Therefore, continuous-dynamic data may simply be read (e.g., queried) from the relevant device, as needed.
  • the decision of whether and how to store monitor data at a given location may be made dynamically, e.g., by evaluating an expression that incorporates aspects such as, for example, hardware capabilities needed for the storage, a proximity of the storage location to the sensor, or a type of information to be stored.
  • each device e.g., the device 146
  • the resulting value may be defined using a mathematical expression (implemented, for example, during registration of a particular service or device, where an example of such registration is described in more detail, below, with respect to FIGS. 7B and FIGS. 15-17 ), in which the considered aspects are represented numerically and weighted for subsequent combination and comparison to a defined threshold.
  • a mathematical expression is shown in Eq. (1):
  • a manual storage decision may be made. For example, a system administrator may want to define types or instances of monitor data that should or should not be stored on designated device(s). For example, an administrator may have the authority to overrule the automated decision, above, and define additional or alternative storage rules. Such manual decisions may be made, for example, for each specific device, or for each device type, or based on the type/role of each monitor service (e.g., all local monitor services 132 b may be required to store certain types of monitor data).
  • a monitor service(s) may leave or join a network.
  • the device 110 may initially not be a part of the sensor network 102 , and may be a mobile or portable device that may be moved from one location to another. As such, the device 110 may be transported to a location of the sensor network 102 , and the device 110 (e.g., the edge monitor service 132 d ) may try to register at the group leader monitor service 132 c , or at any device that is itself connected to the global monitor service 132 a .
  • a dedicated protocol may be used for such registration, so that devices and monitor services may easily or automatically be configured to leave one sensor network and join another. Examples of such dedicated protocols are discussed in more detail, below, with respect to FIGS. 15-17
  • FIG. 2 is a block diagram 200 illustrating an example deployment of the system 100 of FIG. 1 .
  • FIG. 2 illustrates that, as described above, the system 100 may be deployed across four conceptual tiers or layers, which are represented in FIG. 2 as a global layer 202 , a local layer 204 , a group layer 206 , and an edge layer 208 .
  • the layers 202 - 208 have different tasks, and are each associated with their respective type of monitor service (e.g., the global monitor service 132 a , the local monitor service 132 b , the group leader monitor service 132 c , and the edge monitor service 132 d ).
  • Each type or class of monitor service may be associated with a physical device (e.g., the device 144 , 146 , 108 , and 110 of FIG. 1 ) based on the capabilities of the device(s).
  • the relatively light-weight edge monitor service 132 d may run on a device, e.g., a sensor mote, with very limited computing capabilities, while the global monitor service 132 a may run on a device with significantly more computing resources, e.g., a PC or server.
  • the above-referenced variations in the monitor services 132 a - 132 d may be achieved by way of a modular deployment of the monitor services 132 a - 132 d .
  • the edge monitor service 132 d may be deployed at the edge layer 208 using only an instance of the core monitor service 148 , shown as core monitor service 148 d in FIG. 2 .
  • the group leader monitor service 132 c may be deployed using an instance of the core monitor service 148 c , along with an instance of a monitor service module 150 , shown in FIG. 2 as the monitor service module(s) 150 c . That is, it should be understood that the monitor service module 150 c may represent one or more monitor service modules, where the monitor service modules are configured to implement the monitoring functionality described above with respect to the group leader device 108 of FIG. 1 .
  • the monitor service module 150 c may be associated with aggregating monitor data (e.g., messages) received from all of the edge monitor services 132 d of the edge layer 208 , for reporting thereof to the local monitor service 132 b.
  • the local monitor service(s) 132 b of FIG. 2 may include the core monitor service 148 b , as well as the monitor service module(s) 150 b , where the monitor service module 150 b may be configured to implement functionality associated with the local layer 204 (e.g., storage of monitor data in the local monitor data 138 , or updating of the global monitor data 136 ).
  • the global monitor service 132 a may include the core monitor service 148 a , along with the global layer-specific monitor service module(s) 150 a.
  • FIG. 2 is merely an example, and that many variations are possible.
  • the core monitor services 148 a - 148 d may be identical or substantially identical, while in other examples, there may be substantial differences.
  • the core monitor services 148 a and 148 b may be different from the core monitor services 148 c and 148 d , and, for example, may include functionality associated with data storage that is not required by the core monitor services 148 c and 148 d , rather than relying on monitor service modules 150 a and 150 b for this functionality.
  • the global monitor service 132 a may be implemented in an integrated, non-modular manner, while the remaining monitor services 132 b - 132 d may use the modular construction described herein.
  • Template(s) for the core monitor services 148 a - 148 d may be stored in the service repository 124 , so that the devices 144 , 146 , 108 , 110 may receive instances of the core monitor services 148 a - 148 d , as instantiated for deployment, e.g., by the service mapper 120 .
  • FIG. 2 also illustrates a hierarchical nature of the system 100 . That is, in FIG. 2 , the global monitor service 132 a is maintained over, and in communication with, a plurality of local monitor services 132 b , each of which may itself be maintained over, and in communication with, a plurality of group leader monitor services 108 . Finally, as already illustrated in FIG. 1 , each group leader monitor service 132 c may be maintained over, and in communication with, a plurality of edge devices 132 d.
  • each monitor service 132 a - 132 d is deployed on a single physical device. More generally, however, it may be the case that a plurality of (types of) physical systems or devices are associated with one of the logical tiers or layers 202 - 208 . Conversely, it may be the case that a plurality of the layers 202 - 208 may be associated with a single (type of) physical system or device.
  • FIG. 3 is a block diagram 300 illustrating a second example deployment of the system 100 of FIG. 1 , in which the layers 202 - 208 may be associated with a plurality of (types of) physical systems or devices.
  • a company server 302 e.g., a company-wide central server
  • a production plant server 304 e.g., a server computer implemented/located at a production plant for the company
  • the production plant server 304 along with a Stargate computer 306 (e.g., a single board computer with communications and sensor signal processing abilities) and a WiFi access point 308 , may be implemented at the local layer 204 .
  • a Stargate computer 306 e.g., a single board computer with communications and sensor signal processing abilities
  • a WiFi access point 308 may be implemented at the local layer 204 .
  • one or more local monitor service(s) 132 b may be implemented using one or more of the physical devices 304 - 308 .
  • At least two local monitor services 132 b should be understood to be included, e.g., with respect (at least) to the Stargate 306 and the WiFi access point 308 . That is, each such local monitor service is maintained over at least one group leader monitor service, which should be understood to be running on a sensor mote 310 and a PDA 312 , where the sensor mote 310 is the group leader to a plurality of sensor motes 314 - 318 (the sensor motes 314 - 318 thus illustrating, potentially, examples of the (edge) devices 110 - 114 ).
  • more than four physical layers exist, and these physical layers may be mapped onto the four logical tiers or layers 202 - 208 of FIG. 2 .
  • multiple physical system layers may fill in the role of one conceptual tier.
  • devices may route information between conceptual tiers. For example, an edge device may route information from the local monitor service 132 b to the group leader monitor service 132 c , even where the edge device in question may belong to a different sensor network, but may be physically closer to the local monitor service 132 b than is the group leader monitor service 132 c.
  • physical systems/devices also may have less than four tiers.
  • there may be only two physical tiers in which case the global monitor service 132 a may be deployed on a first device, while the local monitor service 132 b , the group leader monitor service 132 c , and the edge monitor service 132 d may be deployed on a second device, perhaps with a single, combined instance of the monitor service(s) 132 b - 132 d.
  • the hierarchy of devices may be conceptually tree-structured, e.g., each device may have exactly one upper (or same) layer monitor service to report to (which may be referred to as a “parent monitor”).
  • the global layer device e.g., the device 144 , which contains the global monitor service 132 a , may be the only monitor service without such a parent monitor.
  • edge devices e.g., the edge devices 110 - 114
  • devices may communicate directly with one another (e.g., in a peer-to-peer fashion, perhaps to calculate an average temperature in a room or to perform other collaborative computing).
  • devices may be physically connected to other devices in the same network or may be connected to several networks.
  • the monitor services 132 b - 132 d may have several parents.
  • connections may be regarded as auxiliary or “shortcut” connections, so that, for example, a local-layer device with the local monitor service 132 b on a first sensor network need not go through the global layer to communicate with an edge device of a second sensor network, but, rather, may communicate with the edge device using an intervening group leader device.
  • FIG. 4 is a block diagram of a smart items infrastructure 400 for implementing the systems of FIGS. 1-3 .
  • the smart items infrastructure 400 includes five layers: a device layer 402 , a device level service layer 404 , a business process bridging layer 406 , a system connectivity layer 408 , and an enterprise application layer 410 .
  • the layer 402 may be considered to contain various ones of the devices 108 , 110 , 112 , and 114 of FIG. 1 , or similar devices, across a number of groups, local networks and/or physical locations.
  • the layers 406 , 408 , and 410 may be considered to be part of, or associated with, the business data processing systems 104 of FIG. 1 .
  • the layer 404 may be considered to represent remaining components of the system 100 of FIG. 1 , e.g., the service mapper 12 , the system monitor 132 and/or the monitor services 132 a - 132 d , and the service repository 124 , as shown in FIG. 4 .
  • the device layer 402 thus comprises the actual smart item devices, as well as any communications between them.
  • the device layer 402 also is responsible for presentation of any offered hardware services to the next higher layer, the device level service layer 404 .
  • the devices may include, for example, an RFID device 412 , embedded systems 414 , sensor networks 416 , and any other new or emerging technologies 418 , as would be appropriate. It should be understood that the examples of the device layer 402 are non-limiting, and may overlap.
  • sensor networks may include RFID devices (readers/tags), embedded systems, and/or other emerging technologies.
  • mobile tags may be attached to real-world objects, and are then read (and optionally written to) by RFID readers.
  • the active tags may also provide additional sensor data (e.g., a current value or a past value).
  • communication is typically initiated by the reader, while tags may or may not directly communicate with each other.
  • Such an RFID reader may be configurable to the extent of processing tag data, e.g., may be configured to perform verification of written data, or to avoid reporting a disappearance of a tag if the ostensibly lost tag in fact reappears within a given time window.
  • the embedded systems 414 may vary on the types of devices of the embedded systems.
  • the embedded systems may represent anything from small-scale, one-chip microcomputers, all the way to full-blown PC hardware.
  • implementation may be performed in JavaTM or based on OSGi (the latter representing a known framework for implementing a component model for remote installation and management of applications and/or application components).
  • OSGi the latter representing a known framework for implementing a component model for remote installation and management of applications and/or application components.
  • the sensor networks 416 may include any number of types of sensors that may include integrated processing power and that may be able to execute peer-to-peer communication.
  • the service repository 124 may store at least two kinds of services, compound and atomic services.
  • the compound services generally rely on other services to fulfill their tasks, and may have no directly-executable code of their own; rather, the compound services may include an executable service composition description that is stored in a corresponding service description.
  • compound services may have one service executable, i.e., the service composition description.
  • atomic services do not generally use other services, and have their own directly-executable code.
  • an atomic service since an atomic service may be deployable on different platforms, an atomic service may have more than one service executable, e.g., may have a service executable for each of the different platforms.
  • the service repository 124 also may store the service metadata 126 , where such service metadata 126 is described in detail, above, and may include a service name, identifier, version, or vendor, or may describe run-time requirements of the service, including, for example, technical deployment requirements (e.g., high bandwidth, or minimum processing power required), semantic requirements (e.g., that a receiving device have a serial connection and/or many device neighbors), and spatial requirements (e.g., that a receiving device be in the basement, or at a south side of a specified building).
  • technical deployment requirements e.g., high bandwidth, or minimum processing power required
  • semantic requirements e.g., that a receiving device have a serial connection and/or many device neighbors
  • spatial requirements e.g., that a receiving device be in the basement, or at a south side of a specified building.
  • the device repository 420 may include, for example, information about devices (e.g., the device metadata) in an manner analogous to that in which the service repository 124 maintains information about services (e.g., the service metadata).
  • device metadata may be stored in the device repository 420 based on communication with the system monitor 132 (e.g., with one or more of the monitor services 132 a - 132 d .
  • the device repository may include device metadata stored by an administrator based on externally-available information about the devices.
  • the device metadata may include a device name, power capacity, memory capacity, processing capacity, or other information that may be relevant to mapping (and ultimately deploying) a service to an associated device.
  • the device repository 420 may include generally static or high-level device metadata, and/or may include some or all of the global monitor data 136 and/or the local monitor data 138 .
  • the system monitor 132 monitors a current system state, as already described, using the monitor services 132 a - 132 d . Whether and how any part of a state of a service is exposed to the system monitor 132 may be set by a developer of the service at design-time. This state-availability information may thereafter be available both to a system administrator and to the service mapper 120 . As also described above, the service mapper 120 receives deployment requests and then determines on which device(s) the corresponding service should be deployed, e.g., by matching the service metadata to the device metadata, which may include a current state of the smart item devices and related local network(s).
  • the service mapper 120 also may react to certain events or conditions, including changes in the network state (as recognized by the system monitor 132 ), and may thereafter decide to re-map a service or add or remove instances of services to better fulfill given deployment requests/requirements.
  • the business process bridging layer 406 includes services designed to aggregate data from the devices at the device layer 402 , provided via the device level service layer 404 , and to transform the data from the device layer 402 into business-relevant information. In so doing, an amount of data sent to back-end enterprise application systems may be reduced, and business logic may be executed for different ones of the enterprise application systems.
  • one or more rule processor(s) 422 may be used to parse incoming messages, support basic operational services (e.g., item movement, association, de-association, or device reading/writing) and support information querying.
  • the rule processor 422 processes user-defined business rules that define or reference any other basic operational services that should be executed or consulted. Using such rules and basic operational services provides a flexible framework to adapt the system 400 to different business scenarios.
  • the rule processor 422 may use a data repository 424 for keeping track of all physical objects of interest, e.g., for keeping track of the current state, location, timestamp, or associated business transaction of a given object being tracked, as well as for keeping track of what future actions are expected. Aggregated information from the data repository 424 may be reported on a regular basis, e.g., daily or monthly.
  • One example of an operation of the layers 402 , 404 , and 406 includes a “goods receiving” scenario.
  • a provider delivering objects to a receiver may send an Advanced Shipment Notification (ASN) containing a list of all objects in the shipment, along with object identifiers such as Electronic Product Codes (EPCs).
  • ASN Advanced Shipment Notification
  • EPCs Electronic Product Codes
  • the ASN may be stored in the data repository 424 .
  • the EPCs are read by the RFID readers, and sent to the rule processor 422 .
  • the rule processor looks up the ID of the reader from which the message came, determines a location and role of the reader, and then calls the appropriate basic operational service responsible for handling received shipments.
  • This operational service compares the obtained EPCs with the expected EPCs from previous ASNs, and, if a match is found, reports to an enterprise application 432 that the delivery has arrived and is complete.
  • the executed operational service also may then update the data in the data repository 424 .
  • Services described above, as well as services for receiving and sending the involved messages, may be managed by a service manager 426 .
  • Components in the system connectivity layer 408 may be used to connect different application systems and to support system and data integration. For example, messages and data may be routed to the correct backend systems by an information exchange and transformation module 428 , and also may be transformed thereby to enable a semantically-correct integration.
  • the system connectivity layer 408 On top of message-routing and transformation services, the system connectivity layer 408 also provides services in a service repository 430 that can be used to access the functionality provided by the Business Bridging Layer 406 by enterprise applications 432 .
  • the enterprise application layer 410 includes, for example, traditional enterprise IT systems responsible for controlling and managing enterprise business applications.
  • An enterprise application 432 covering a specific business process may not be a single program, but rather may be composed of different services that work together to achieve a desired functionality. Such services may be provided by the same enterprise system, by another enterprise system within the enterprise application layer 410 (possibly located at a site of a business partner), or by systems from lower layers (e.g., by smart item devices at the device layer 402 ).
  • development tools 434 may refer to tools for creating enterprise application(s) 432 and other applications/services.
  • Using a development environment integrated with the infrastructure 400 may support the implementation of basic services in manners that are similar to known development tools in the enterprise application space.
  • the development tools 434 may allow the creation of the required service metadata 126 , as well as the inclusion of existing services into new applications.
  • the development tools 434 allow a developer to specify where a certain service should run, to configure individual service instances, and to deploy the services in a desired manner.
  • a developer may develop service metadata/executable(s) 436 using the development tools 434 , and may then provide desired ones of the service metadata/executable(s) 436 for storage in the service repository 124 , and/or for mapping/re-mapping by the service mapper 120 at the same or later time.
  • FIG. 5 is a timing diagram illustrating an example algorithm for gathering monitor data using the system 100 of FIG. 1 .
  • the algorithm of FIG. 5 is implemented using the global monitor service 132 a , which, as already described, is configured to gather information about all devices and services within its underlying hierarchy, and which thus provides a global system landscape view.
  • the global monitor service 132 a may run as a part of the device level service layer 404 and/or the business process bridging layer 406 of the infrastructure 400 of FIG. 4 .
  • the global monitor service may be requested/called by high-level services that also are running at the device level service layer 404 or the business process bridging layer 406 , or through separate device and service monitoring graphical user interfaces (GUIs).
  • GUIs graphical user interfaces
  • the local layer may include a plurality of the local monitoring services 132 b , which are each configured to gather monitor data from edge devices, using, for example, polling and heartbeat techniques, as described in more detail, below.
  • the local monitor service 132 b is configured to manage collected monitor data, including, for example, filtering, aggregating, and storing the monitor data.
  • the group layer includes multiple devices at or near the edge of the infrastructure (e.g., the infrastructure 400 of FIG. 4 ) which fill in the role of the group leaders, such as the device 108 of FIG. 1 .
  • the group leaders gather information about edge devices (e.g., devices 110 - 114 ) in their vicinity having the edge monitoring service 132 d installed. In the example of FIG.
  • monitor data obtained by the group leader is not stored at the group leader, but may be filtered, aggregated, or otherwise processed, before being forwarded to the local monitor service 132 b to be stored.
  • devices e.g., devices 110 - 114
  • group leader monitor services 132 c and edge monitor services 132 d may be essentially identical in terms of providing, preprocessing, and not storing monitor data, although the edge monitor service 132 d is not responsible for managing other devices. In the example of FIG.
  • the edge monitor service 132 d is configured to provide monitor data and send it to its group leader using heartbeat messages (e.g., messages sent using an active send queue at some pre-defined interval). More generally, however, gathering monitor data from edge layer devices may be triggered either by timers of the edge devices for sending the heartbeat messages, or by poll messages received at the edge devices from upper tiers/layers.
  • heartbeat messages e.g., messages sent using an active send queue at some pre-defined interval.
  • a timer triggers the local monitor service 132 b to check for outdated data in the local monitor data 138 , which results in polling ( 502 ) several edge layer devices.
  • the local monitor service 132 b does not communicate directly with the edge layer devices, but rather uses the group leader device 108 at a gateway, and thus sends a polling message to the group leader monitor service ( 504 ).
  • the group leader monitor service 132 c splits the single poll message into different poll messages (although FIG. 5 shows only one poll message, for the sake of simplicity), which are sent to the individual edge layer devices 110 - 114 ( 506 ).
  • Each edge layer device 110 - 114 reads a local system adaptor ( 508 ), which should be understood to be the same or similar to the system adaptor 134 of FIG. 1 , to obtain up-to-date monitor data.
  • system adaptors and related elements are provided in more detail below, with respect to FIGS. 9-11 .
  • system adaptors serve as data sources to provide monitor data about their respective edge device, as well as about any service(s) running on their respective edge device.
  • the edge monitor service 132 d then executes preprocessing ( 510 ) of the monitor data (e.g., filtering and/or aggregation). Then, without storing the pre-processed monitor data, sends a heartbeat message ( 512 ) with the pre-processed monitor data to the group leader monitor service 132 c .
  • the group leader monitor service 132 c receives messages with the monitor data from a plurality of edge devices, and provides further pre-processing ( 514 ), including, for example, calculation of an average of the CPU utilizations of all managed edge devices. Then, the group leader monitor service 132 c performs message aggregation ( 516 ), in which messages from different devices are summarized into a single heartbeat message for transmission to the local monitor service 132 b ( 518 ).
  • the local monitor service 132 b receives such heartbeat messages from a plurality of group leader monitor services 132 c , and performs pre-processing ( 520 ), including, e.g., filtering of non-critical data, and/or aggregation thereof.
  • the pre-processed message(s) are then stored ( 522 ), e.g., at the local monitor data 138 .
  • a timer of the local monitor service 132 b triggers a heartbeat indicator ( 524 ) that causes the local monitor service 132 b to compute a delta synchronization ( 526 ) between the local monitor data 138 and the global monitor data 136 .
  • the local monitor service 132 b determines which relevant information within the local monitor data 138 has been changed or updated as a result of the execution of the monitoring algorithm of FIG. 5 , and only this changed data is submitted to the global monitor data 136 , e.g., as part of a delta synchronization message ( 528 ). In this way, an amount of transferred and processed data is reduced.
  • the delta synchronization may be initiated by a message from the global monitor service 132 a to the local monitor service 132 b.
  • the updated data is preprocessed by the global monitor service 132 a ( 530 ), and stored in the global monitor data 136 .
  • the business data processing systems 104 e.g., supply chain management applications, may access the data from the global monitor data 136 . It should be understood from the above description that monitor data from a given edge device is stored in the landscape tree on the path from the edge device itself to the global monitor service 132 a . As a result, the monitor data is easily located for use or deletion thereof.
  • FIG. 6 is a block diagram of a modular monitor service 600 that may represent one or more of the monitor services 132 a - 132 d of FIG. 1 . That is, the modular monitor service 600 includes the core monitor service 148 , which is illustrated in FIG. 1 in the context of the group leader monitor service 132 c , but which, as explained above, also may be implemented in the context of some or all of the remaining monitor services 132 a , 132 b , and/or 132 d . The modular monitor service 600 also includes the monitor service module 150 , which, again, is illustrated in FIG. 1 in the context of the group leader monitor service 132 c , but which, again, also may be implemented in the context of some or all of the remaining monitor services 132 a , 132 b , and/or 132 d.
  • the modular monitor service 600 includes the core monitor service 148 , which is illustrated in FIG. 1 in the context of the group leader monitor service 132 c , but which, as explained above, also may be implemented in
  • the core monitor service 148 may be configured to implement fundamental functionalities that may be used by most or all of the monitor services 132 a - 132 d (e.g., query routing, role-based data handling, and coordination of communication with other monitor services running on other devices), while the monitor service module(s) 150 may be configured to implement functionality that may be more particular to a given one of the monitor services 132 a - 132 d .
  • the monitor service module(s) 150 may thus be implemented as plug-in components that are added to the core monitor service 148 on an as-needed basis, so that the core monitor service 148 may be specialized according to individual needs and capabilities of each monitor service and/or device.
  • the monitor service module(s) 150 include the system adaptor 134 , a communication adaptor 602 , a data storage module 604 , and a data preprocessor 606 . Consequently, associated functionality for these plug-ins, and other functionality, may be added or replaced to the module monitor service 600 , without changing the core monitor service 148 . Moreover, as described in more detail below, the monitor service module(s) 150 of the same category (e.g., different instances of the communication adaptor 602 or of the data storage module 604 ) may share a common interface, so that the core monitor service 148 need not be aware of the usage of the different instances/plug-ins.
  • module manager(s) 608 may be used to manage modules of the same category.
  • the module manager(s) 608 may include a manager for the system adaptor(s) 134 , and may be configured to select and implement an appropriate one of the system adaptor(s) 134 , based on a current situation and/or need of the core monitor service 148 . Specific examples of such a system adaptor manager are provided below, e.g., with respect to FIGS. 9 and 10 , and other examples of module managers 608 are also discussed.
  • the module manager(s) may act as actual intermediaries to messages between the core monitor service 148 and a given monitor service module 150 , e.g., forwarding the messages from the core monitor service 148 to the appropriate monitor service module 150 , or vice versa.
  • the module manager(s) 608 may be configured to load or select an appropriate one of the monitor service module(s) 150 , and may then remove itself from further communications.
  • FIG. 7A is a flowchart illustrating an operation of the system 100 using the modular monitor service 600 .
  • instances of the core monitor service 148 are deployed onto one or more of the architectural tiers ( 702 ), e.g., of the system 100 .
  • the service mapper 120 may be configured to deploy the core monitor service 148 onto the devices 108 - 114 , 146 , and 144 of the system 100 , perhaps during an initial set-up of the system 100 .
  • the service mapper 120 may map an instance of the core monitor service 148 onto a new device (not shown in FIG. 1 ) that comes into an area of the sensor network 102 , and that wishes to communicate with one or more of the devices 108 - 114 , 146 , and/or 144 .
  • the core monitor service 148 may be stored in the service repository 124 as a template, form, or other generic structure, and that different instances of the core monitor service 148 may be deployed within the system 100 . Moreover, the instances need not be exactly identical. For example, different instances of the core monitor service 148 may be deployed, having different functions included or enabled, depending on which layer of the system monitor 132 the instance is to be deployed.
  • the service mapper 120 may execute the service mapping of instances of the core monitor service 148 as described above, e.g., based on the device metadata 130 .
  • monitor service modules 134 , 602 , 604 , and/or 606 may be installed, depending, for example, on the device metadata 130 associated with the device(s) in question, and/or onto which level of the monitor architecture the monitor service module(s) are being deployed.
  • device metadata may be obtained using the already-installed core monitor service 148 , and/or may be obtained from memory.
  • monitor data may be collected, e.g., by implementing the algorithm of FIG. 5 using the modular monitor system 600 of FIG. 6 .
  • raw monitor data e.g., at the edge monitor service 132 d
  • the system adaptor 134 706
  • FIGS. 9-11 may include both service and device adaptors.
  • the raw monitor data (e.g., regarding relevant services and/or devices) may be provided in a way that hides different interfaces of the (heterogeneous) services/devices, and that is extensible for new services/devices.
  • system standards such as, for example, OSGi or JSR82, may be implemented.
  • the raw monitor data may be pre-processed at the pre-processor module 606 ( 708 ). Examples of such pre-processing are provided in conjunction with FIG. 5 , and further with respect to FIG. 14 . Generally, however, such pre-processing acts on incoming data to reduce an amount of data to be sent over the network connection(s), using, e.g., filtering and aggregation.
  • the (pre-processed) monitor data may be stored using the data storage module(s) 604 ( 710 ).
  • the data storage module 604 may be configured to hide different types of storage that may be available (e.g., file system, database, or in-memory data structure).
  • storage of monitor data may be limited just to the local monitor service 132 b and the global monitor service 132 a , so that, accordingly, the data storage modules 604 may be deployed only onto those monitor services, and resources are conserved.
  • the processed and stored data may be propagated, and queries for new data (e.g., by polling) may be executed using the communications adaptor 602 ( 712 ).
  • the communications adaptor 602 may be configured to ensure communication between services/devices, may hide unreliable or out-of-order data transfers, and may hide the core monitor service 148 from effects of different communications protocols/hardware.
  • the communications adaptor 602 may be considered to be separate from the monitor service 132 a - 132 d , and, e.g., may be deployed separately (i.e., at separate times) from either the core monitor service 148 or monitor service modules 134 , 602 , or 606 .
  • Different operations and uses of the communications adaptor 602 are provided below, with respect to the examples of FIGS. 8 , 12 , and 13 .
  • FIG. 7B is a flowchart illustrating additional example operations of the system 100 .
  • the core monitor service 148 is not initially installed. In many cases, however, the core monitor service 148 may be needed in order to proceed with further operations of the system 100 .
  • registration protocol may require installation and availability of the core monitor service 148 (see, e.g., the examples of FIGS. 15-17 for a discussion of an example registration protocol for registering a new device with the system 100 ).
  • a bootstrapping technique may be implemented, in which the core monitor service 148 is installed first, and then information from the installed (executing) core monitor service 148 may itself be used to register the new device, and/or to deploy the monitor service modules 134 and/or 602 - 606 .
  • the device in question may first be determined whether the device in question supports existing standards for deploying services ( 714 ) (e.g., OSGI, Jini, Services and Networks for Domotic Applications (SENDA), service management module (SMM), or JSR232). If such standards are not supported by a device in question, then appropriate action may be taken. For example, in a case where the device is of a level of a mobile phone or PDA, then a user thereof may be instructed to execute an installation wizard (e.g., follow a link to download and start an installation program) for setting up the core monitor service 148 ( 716 ). In such a case, and/or using known deployment standards, and if the core monitor service 148 is not yet installed ( 718 ), then static device metadata may be determined ( 720 ), e.g., using the standards and/or from a memory.
  • existing standards for deploying services e.g., OSGI, Jini, Services and Networks for Domotic Applications (SENDA), service management module (SMM), or JSR232
  • the core monitor service may be installed ( 722 ), and additional monitor data may be obtained therefrom ( 724 ). As described in more detail below, e.g., with respect to FIGS. 15-17 , a full-scale device registration with the system monitor 132 also may be executed at this point, if necessary. Using the additional monitor data, appropriate monitor service module(s) 150 may be deployed ( 726 ), so that collection and/or transmission of additional monitor data may proceed.
  • FIG. 8 is a block diagram of an example implementation of the core monitor service 148 .
  • a communication abstraction layer with incoming 802 a and outgoing 802 b messages, may be used by the core monitor service 148 , for example, to establish connections to monitor services on different devices, or to establish connections to GUI interfaces and to other types of services.
  • the communication abstraction layer 802 a , 802 b is discussed in more detail below, with respect to FIG. 12 .
  • other module managers 150 e.g., system adaptor manager, described with respect to FIGS. 9-11
  • the core monitor service 148 of FIG. 8 includes a query router 804 .
  • the query router 804 may be responsible, for example, for gathering and returning queried monitor data, which may either be queried by (other) monitor services 132 a - 132 d running on other devices, or by other services (e.g., temperature detection services, item tracking services, or other data-collection services).
  • a system landscape database 806 is included and activated in the FIG. 8 example of the core monitor service 148 (e.g., the core monitor service 148 may be associated with the global monitor service 132 a or the local monitor service 132 b , in which case the system landscape database 806 may represent, include, or otherwise be associated with the global monitor data 136 or the local monitor data 138 , respectively).
  • the query router 804 may attempt to obtain the requested monitor data from the system landscape database 806 .
  • the query monitor 806 may query the desired monitor data from a monitor service running on a parent device, e.g., a different device that manages the device that is implementing the core monitor service 148 (for example, the group leader monitor service 132 c may query the local monitor service 132 b , or the local monitor service 132 b may query the global monitor service 132 a ).
  • the current monitor service 148 may manage the queried system (i.e., is a parent to the queried system), in which case a lower level monitor service will be addressed to collect the desired monitor data.
  • the queried device may be unknown to the core monitor service 148 of FIG. 8 , in which case the query may be forwarded to the upper layer which manages more systems, and, ultimately, may proceed to the global monitor service 132 a , which may then forward the query to the appropriate local monitor service 132 b.
  • Query routing may be straightforward if a target system (service or device) may be addressed directly, with no intervening system(s). In cases where there is no direct connection to the target system, then intervening hops on the routing path are determined. Routing information describing such intervening hops may be fetched from stored topology information (which may be stored in the system landscape database 806 , or in separate routing tables).
  • each monitor service 132 b - 132 d is provided with a parent monitor service that is assigned during registration of the monitor service (see, e.g., FIGS. 15-17 , below).
  • This child-parent information may be stored in the system landscape database 806 , and/or in other memory, as a property, from which a tree-shaped topology may be generated.
  • the tree-shaped topology may be traversed to determine the next hop.
  • the next/intervening hop may be obtained from a routing table, using an appropriate table look-up.
  • such separate routing tables may use more memory than determining the routing information from the tree-shaped topology, but may be more efficient and/or faster.
  • Entries in the routing tables may be changed only when devices connect or disconnect from the system 100 , in order to reduce a number of required changes.
  • a next hop may be added only if the next hop is not the parent monitor service, since, the next hop may be assumed, by default, to be the parent monitor service. In this way, a number of entries in the routing tables may be reduced to the number of systems that are managed/monitored by the monitor service, along with those that are directly connected thereto.
  • Query landscape get the queried data If data not found if information is requested about the current device get system adaptor to service or device get information from adaptor else (information is not about the current device)
  • Query landscape is device managed by this device? If device is managed by this device get child device to ask get data from child device by asking the monitor on lower tier else (device is not managed by this device) get parent device to ask get data from parent device by asking the monitor on higher tier if data still not found return error else (data found) return data
  • Code Section 1 is consistent with a querying algorithm in which a request for monitor data is received at a (current) device. If the monitor data is related to the current device, but not in the system landscape database 806 , then the system adaptor 134 may be used to obtain the monitor data, as described herein. Otherwise, if the monitor data is about another service/device, but is not in the system landscape database 806 , then a parent or child monitor service may be queried, as appropriate. If the monitor data is found in either the system landscape database 806 or the parent/child monitor service, then the monitor data may be checked to see whether it is up-to-date. If not, then additional polling/queries may be executed to obtain updated monitor data.
  • the core monitor service 148 also includes a ping requestor 808 , which is configured to be used by the global monitor service 132 a and/or the local monitor service 132 b , or any monitor service that stores monitor data in some type of monitor data storage/memory (e.g., the system landscape database 806 ).
  • the ping requestor 808 may thus be configured to ping devices in the system landscape, thereby to assist in keeping system landscape data of child systems up-to-date, and to detect disconnected devices (and mark the data as ‘in doubt’). If a monitor service does not store status information in a local monitor data storage, e.g., the group leader monitor service 132 c or edge monitor service 132 d , then the ping requestor 808 may be omitted or non-activated.
  • the ping requestor 808 may be activated by a timer, and, in response, may determine all connected and managed child-systems from the monitoring data storage (e.g., from the system landscape database 806 ). For example, for all the systems, the ping requestor 808 compares the time when the last life-signal was received to the current time, in order to detect outdated monitor data (or other stored information). If outdated, then a status of the system(s) may be changed to so indicate, e.g., may be changed from “alive” to “outdated.” If the timestamp is older than a certain cut-off point, then the status may be changed from “outdated” to “in-doubt,” so as to indicate the possibility that the device in question is disconnected.
  • the monitoring data storage e.g., from the system landscape database 806
  • the ping requestor 808 compares the time when the last life-signal was received to the current time, in order to detect outdated monitor data (or other stored information). If outdated, then a status of
  • the ping requestor 808 sends a ping-request.
  • the ping requestor 808 receives the ping-response and updates the “last seen” timestamp accordingly, and then changes the relevant status back to “alive” within the system landscape database 806 .
  • FIG. 8 is discussed in terms of the ping requestor 808 , it should be understood that other techniques may be used for determining a status of elements of the system landscape of the system 100 , e.g., other echo requests used to test a reachability of the system(s) and/or to test network delays. Further, it should be understood that the core monitor service 148 also may receive, and thereafter respond to, ping requests from other monitor services, as shown. Actual implementation of a transport protocol that ensures reliable data transfer of the ping (or other) status requests may be implemented as a task of the communication adaptor 602 , as discussed in more detail below, with respect to FIG. 12 .
  • the core monitor service 148 also includes a heartbeat transmitter 810 , which may be implemented as a service configured to send a heartbeat message to a parent monitor service, so as to indicate that the device (on which the core monitor service 148 is deployed) is still running.
  • the heartbeat transmitter 810 may be triggered by a timer, where the time interval between two messages may be defined in associated heartbeat settings.
  • the interval may be chosen with respect to resource-constraints, so that small devices with limited power supply and network capabilities may use a greater time interval than more powerful devices (e.g., well-connected servers).
  • a metric may be used to define a default interval customized for each device type (e.g., for a sensor device, PDA, or laptop). Additionally, the value of the interval and other associated settings may be adjustable by the user, e.g. a system administrator of the infrastructure of FIG. 4 .
  • the heartbeat sender 810 may be configured to transmit at least some monitoring data, as well, which if received at the core monitor service 148 from another monitor service, may be used to update the system landscape database 806 .
  • the heartbeat settings may be used to define which such monitor data should be sent, along with the heartbeat messages. In so doing, an amount of network traffic, power and other resources may be conserved.
  • relatively-higher tier monitor services may avoid performing at least some polling of lower-tier services, since the upper-tier services may already have the desired monitor data.
  • the device on which the core monitor service 148 is deployed may include the additional monitor data along with heartbeat messages by executing queries on the monitoring data storage, or by reading system adaptors 134 (see FIGS. 6 and 9 - 11 ).
  • Heartbeat messages do not have to be sent over reliable communication channels, to the extent that the ping requestor 808 may, in response to an expected heartbeat message that does not come through, send an additional request, e.g., if two consecutive pings are missing. Therefore, even if the communication channels are unreliable, and heartbeat messages are lost, the core monitor service 148 may continue to function. Accordingly, protocols such as, for example, the lightweight and connection-less User Datagram Protocol (UDP) may be used.
  • UDP lightweight and connection-less User Datagram Protocol
  • the ping requestor 808 may be understood as an addition to the heartbeat transmitter 810 .
  • the ping requestor 808 may build up a reliable connection to make sure that the ping is received and processed. Further, if a child device does not have a (functional) heartbeat transmitter 810 , then the parent monitor's ping requestor 808 may replace the heartbeat transmitter 810 completely. As a result, the child system does not have to have a heartbeat transmitter installed, so fewer hardware capabilities may be used.
  • the core monitor service 148 also includes an update notification transmitter 812 , which may be configured to provide services with updates about the system landscape, such as, for example, changes in monitor data, or registration of new devices, as may be determined, e.g., from the system landscape database 806 .
  • the update notification transmitter 812 thus may emit notification messages to all registered recipients, as stored in a recipient registry 814 .
  • Services registered with the update notification transmitter 812 may precisely specify desired data, so as to obtain only the desired data (and minimize other transmissions). Constraints for what (types of) monitor data updates are transmitted may be based, for example, on the following properties: a name of the data-providing service, or device and name of the data-field (e.g., alive-status, CPU usage, RAM size, or connectivity values. Accordingly, subscription rules for receiving the updates may be stored with the following information: an identifier of the recipient system, and a constraining rule (e.g., a source-system identifier and/or a data-field name).
  • a constraining rule e.g., a source-system identifier and/or a data-field name
  • the two restraining conditions may be connected with an AND, so that, for example, both the name of the system AND of the data field must match for an update to be sent.
  • an OR rule may be realized by defining more than one subscription rule.
  • FIG. 9 is a block diagram illustrating a system adaptor manager 902 for use with the modular monitor service 600 of FIG. 6 and/or the implementation of the core monitor service 148 illustrated in FIG. 8 .
  • the system adaptor manager 902 may be used to manage the system adaptor(s) 134 .
  • the system adaptors 134 may be configured to provide connections between the core monitor service 148 and the various services and devices (e.g., the service 122 and/or the device 108 ) that are supplying monitor data. It should be understood that the services, devices, and, therefore, monitor data may vary quite dramatically, due to the potential for heterogeneity in the system landscape.
  • the system adaptors 134 may implement a common interface for communicating with the core monitor service 148 , while implementing whatever other interfaces are necessary for monitoring (and, potentially, controlling) the various heterogeneous services and/or devices that may be present, so that the core monitor service 148 need be aware of only this common interface in order to communicate with a large number of types of the system adaptors 134 (and, thereby, a large number of types of services and devices).
  • the core monitor service 148 may be capable of communicating with a large number of the system adaptors 134 (using just the common interface), the core monitor service 148 either does not or cannot determine which of the system adaptors 134 is appropriate for a given task. Rather, a system adaptor manager 902 is used in making such a determination of a particular/correct one of the system adaptors 134 for a given task or setting. As such, the system adaptor manager 902 represents an example of the module manager(s) 150 , and provides an abstraction layer between the core monitor service 148 and the system adaptor(s) 134 . Accordingly, the core monitor service 148 may be relieved of the duty of tracking, selecting, or otherwise managing the various instances or possibilities of the system adaptors 134 , much less of the services or devices themselves.
  • the system adaptor(s) 134 may include, for example, a service adaptor and/or a device adaptor (see, e.g., FIG. 10 ), so that communication between the core monitor service 148 (or other monitor service modules 150 ) and a given service (e.g., the service 122 ) or device (e.g., the device 108 ) may be executed, and corresponding monitor data may be obtained.
  • the system adaptors 134 may be considered to be a part of the modular monitor service 600 that provides an interface to the environment (e.g., to the service 122 and/or the device 108 ).
  • a given one of the system adaptors 134 may determine, for example, a CPU utilization, memory usage, or memory size of the device.
  • a given one of the system adaptors 134 may determine, for example, a software version or software vendor associated with the service 122 .
  • the system adaptors 134 may be designed and implemented to fit to the monitored system(s) in question (e.g., the system 100 ).
  • the monitoring service(s) 132 a - 132 d may read information about devices and services, whose different interfaces are hidden to the core monitor service 148 by the system adaptors 134 and the system adaptor manager 902 , so that the latter components provide an abstraction layer for use of the core monitor service 148 .
  • system adaptors 134 may be stored (or referenced) in an adaptor registry 904 , so that the system adaptor manager 902 may determine (e.g., based on a request of the core monitor service 148 , or based on a design choice of an administrator) which system adaptor 134 to use in a given situation.
  • the system adaptor manager 902 may thus be configured to load and manage a variety of system adaptors 134 that implement a common interface. On start-up, the system adaptors 134 may register at the adaptor manager 902 . The system adaptor manager 902 may execute a maintenance function of all registered adaptors 134 , where a maintenance function of the system adaptor 134 may implement internal management activity, in addition to reading and returning monitor data (e.g., information about currently-running services, device-specific information, or sensor data collected by the device on which the modular monitor service 600 is running).
  • monitor data e.g., information about currently-running services, device-specific information, or sensor data collected by the device on which the modular monitor service 600 is running.
  • the system adaptors 134 include a basic information adaptor 906 and an OSGi adaptor 908 .
  • the basic information adaptor 906 refers generally to service and/or device information that may be collected and used, e.g., in the system 100 , such as the many and various examples of device metadata 130 provided above.
  • the OSGi adaptor 908 generally refers to the fact that the system adaptors 134 may support such standardized protocols as OSGi to get information about devices that do not have one of the monitor services 132 a - 132 d installed.
  • Other examples for such protocol standards include the Java API platform JSR232 (which includes OSGi), as well as Java APIs for Bluetooth, JSR82.
  • FIG. 10 is a block diagram of an example implementation of the system adaptors of FIGS. 1 , 6 , and 9 .
  • an upper-tier (e.g., global or local layer) device 144 , 146 is shown, which may include, for example, a personal computer or server computer.
  • the device(s) 144 , 146 include a core monitor service 148 a and/or 148 b , along with two system adaptors: a service adaptor 1002 (for interfacing with a plurality of services 1004 ) and a device adaptor 1006 (for interfacing with a plurality of instances/types of device hardware 1008 ).
  • the core monitor service 148 a , 148 b also may communicate with pre-registered devices 1010 , which may be configured to interface directly with the core monitor service 148 .
  • a lower-tier (e.g., group leader or edge) device 108 , 110 , 112 , and/or 114 may represent a relatively more resource-poor device, and may include the core monitor service(s) 148 c , 148 d .
  • the devices 108 , 110 , 112 , 114 include a service adaptor 1012 (for interfacing with a plurality of services 1014 ) and a device adaptor 1016 (for interfacing with a plurality of instances/types of device hardware 1018 ).
  • the devices 108 , 110 , 112 , 114 also include a separate device adaptor(s) 1020 that may be used to communicate with devices, e.g., a device 1024 , that implements such standards 1022 .
  • the device 1024 may represent a sensor mote or cell phone that is running the management standard 1022 (e.g., OSGi), so that the core monitor service 148 may communicate therewith using the standard 1022 .
  • the management standard 1022 e.g., OSGi
  • FIG. 11 is a block diagram of another example implementation of the system adaptors of FIGS. 1 , 6 , and 9 .
  • the system adaptor(s) 134 is illustrated as communicating with the core monitor service 148 .
  • the system adaptor(s) 134 may communicate with the core monitor service 148 using an API 1102 of the core monitor service 148 that is common to all of the system adaptor(s) 134 .
  • the system adaptor(s) 134 also communicate with a service and/or device 1104 using an API 1106 , which is specific to the service/device 1104 and to the specific, associated instance of the system adaptor 134 in FIG. 11 .
  • the system adaptor 134 includes a notification system 1108 that is configured to receive notifications from the core monitor service 148 (e.g., from the update notification transmitter 812 of FIG. 8 ).
  • the core monitor service 148 may send updates regarding changes in monitor data, or registration of new services or new devices.
  • the notification system 1108 (which may thus be understood to be included in the recipient registry 814 ) may subscribe to particular notifications, or types of notifications, and so may receive notifications on a periodic or scheduled interval.
  • the notification system 1008 also may receive notifications from other services, such as, for example, a business logic rule engine service 1110 (which implement business logic and may trigger reactions to certain real-world events), or a logger or watchdog service (not shown in FIG. 11 ).
  • the notifications may be forwarded or handled, depending on the implementation of the system adaptor 134 , and the system adaptor 134 defines and implements an appropriate reaction to each possible notification.
  • the system adaptor 134 also includes a system reader 1112 that is configured to read monitor data from the service/device 1104 , such as, for example, CPU utilization, battery lifetime, or status of the service (e.g., whether a service is running, or stopped). The system reader 1112 may then provide the monitor data to the core monitor service 148 that is polling the system adaptor 134 .
  • monitor data such as, for example, CPU utilization, battery lifetime, or status of the service (e.g., whether a service is running, or stopped).
  • the system reader 1112 may then provide the monitor data to the core monitor service 148 that is polling the system adaptor 134 .
  • the system reader 1112 may provide the monitor data to a heartbeat transmitter 1114 .
  • the heartbeat transmitter 1114 generally speaking, is configured to periodically send a life-signal to the core monitor service 148 .
  • the heartbeat transmitter 1014 also may receive and transmit monitor data from the service/device 1104 (e.g., status values), which allows for a reduction in messaging overhead.
  • heartbeat settings 1116 may include parameters associated with the heartbeat transmitter 1114 , such as, for example, a time interval between heartbeat messages.
  • an initializer 1118 is configured to set up the heartbeat settings 1116 , and register the monitor data at the monitor data storage (e.g., the system landscape database 806 of FIG. 8 ).
  • the initializer 1118 also may be configured to register with the recipient registry 814 for update notification messages at the update notification transmitter 812 .
  • processing threads may be used for various tasks, including monitor service maintenance threads, or adaptor threads. Such threads (for, e.g., context switching, thread scheduling, or inter-thread communication) may be created and managed, as needed.
  • the monitor service thread may be used to keep monitor data, as stored in system landscape databases 806 and/or the global/local monitor data 136 / 138 , up-to-date, and may further be used to manage a status of lower-tier services and devices.
  • System adaptor threads may be implemented separately from the monitor service maintenance thread, so that system adaptors 134 do not block the monitor service maintenance thread by performing complex or time-intensive tasks.
  • the system adaptors 134 may run as separate threads, or may be executed by a thread of an associated monitor maintenance service. In the latter case, the monitor service maintenance thread may be blocked for the time of executing a maintenance function of the system adaptors 134 .
  • the system adaptors 134 which may be called by the monitor service, still can create temporary threads that do time-consuming work in the background, so the monitor service thread is not blocked.
  • System adaptors that use their own threads may generally be more powerful. Also, such system adaptors do not block the monitor service, and so may perform time-consuming tasks, and/or wait for I/O interrupts. Additionally, such system adaptors have more freedom in deciding when to be activated. Thus, such system adaptors are not dependent on calls by the monitor service at an undefined point in time. Timers can be used to actively send heartbeats messages and to update landscape values.
  • system adaptors may be implemented as passive components that use the monitor service thread. In such cases, an overhead of creating and managing threads may be avoided, at a cost of blocking the monitor service while executing the system adaptor in question.
  • FIG. 12 is a block diagram of an example implementation of the communication adaptor 602 of the modular monitor service 600 of FIG. 6 .
  • a communication adaptor manager 802 a , 802 b may act as the communication abstraction layer of FIG. 8 that communicates with the core monitor service 148 .
  • the communication adaptor manager 802 a , 802 b analogously to the system adaptor manager 902 , manages and communicates with a communication adaptor 1202 for devices (so as to communicate with device(s) 1204 ), as well as with a communication adaptor 1206 (so as to communicate with the service(s) 1208 ).
  • the communication adaptor manager 802 a , 802 b may be configured to load/unload the communication adaptors 1202 , 1206 , and to register (or de-register) the communication adaptors 1202 , 1206 .
  • FIG. 13 is a block diagram of another example implementation of the communication adaptor(s) 602 of FIG. 6 .
  • the communication adaptor manager (abstraction layer) 802 a , 802 b may support both local method calls and network communication.
  • the communication adaptor manager (abstraction layer) 802 a , 802 b may operate to make communication protocols and network devices opaque to the core monitor service 148 .
  • message handling and socket communication may be used for network communication.
  • local communication may be realized using messages, APIs, sockets, pipes, and/or shared memory.
  • the communication adaptor manager 802 a , 802 b hides currently-used protocols (e.g., Transfer Control Protocol (TCP), Uniform Datagram Protocol (UDP), Internet Protocol (IP), Hyper Text Transfer Protocol (HTTP), or File Transfer Protocol (FTP), which may work on different ISO/OSI layers, and/or which may be combined.
  • the communication adaptor manager 802 a , 802 b also may hide network devices 1204 (e.g., Bluetooth, modem, or WiFi devices).
  • the communication adaptor manager 802 a , 802 b also may hide certain communication concepts (e.g., message passing, sockets, shared memory, or API calls).
  • the communication adaptor manager 802 a , 802 b may load or unload, for example, a TCP adaptor 1302 , a UDP adaptor 1304 , or an API call Adaptor 1306 , which may each present a common interface to the core monitor service 148 .
  • a TCP adaptor 1302 a UDP adaptor 1304
  • an API call Adaptor 1306 which may each present a common interface to the core monitor service 148 .
  • FIGS. 12 and 13 may allow avoidance of dealing with protocols, network devices, sequence numbers, or transmission errors.
  • each of the adaptors 1302 - 1304 is identified as being associated with either network ( 1302 , 1304 ) or local ( 1306 ) communication. Further, each of the adaptors 1302 - 1304 is identified as being associated with either reliable ( 1302 , 1306 ) or unreliable ( 1306 ) communication. Each of the adaptors 1302 - 1306 also may be associated with a unique identifier (Adaptor ID), for use by the communication adaptor manager 802 a , 802 b in selecting or loading the respective adaptor.
  • Adaptor ID unique identifier
  • unreliable data transfer may be much simpler and therefore less resource consuming than reliable transfer. Therefore, unreliable data transfer may be preferred, where possible.
  • Some functionality, however, such as pinging a system, may require reliable data transfer (and corresponding communication adaptor).
  • the core monitor service 148 may send and receive different types of messages, and the communication adaptor manager 802 a , 802 b may be used to select a corresponding, appropriate communication adaptor to execute the sending or receiving.
  • the core monitor service 148 may need to send a message over a network, using a lightweight and unreliable transport protocol.
  • the communication adaptor manager 802 b may locate the UDP adaptor 1304 , among all loaded adaptors, which implements an unreliable network communication. The communication adaptor manager 802 b then forwards the message to the UDP adaptor 1304 , which performs the actual communication.
  • FIG. 14 is a block diagram of an example implementation of the preprocessor module 606 of FIG. 6 .
  • the preprocessor module 606 may be used by one or more of the various monitor services 132 b - 132 d to process monitor data locally before forwarding the processed monitor data to the next higher tier of the architecture of the system 100 of FIG. 1 .
  • a preprocessor manager 1402 is configured to operate similarly or analogously to the adaptor managers 802 a / 802 b and 902 , described above.
  • the preprocessor manager 1402 may interface with a preprocessor registry 1404 to determine an appropriate one of the possible preprocessor modules 606 , for use with the core monitor service 148 .
  • the preprocessor manager 1402 may be configured to receive incoming monitor data, such as from a local service or device, and perhaps by way of the core monitor service 148 and appropriate system adaptor 902 and/or communication adaptor 802 b .
  • the preprocessor manager 1402 may output the preprocessed monitor data, e.g., back to the core monitor service 148 for transmission to the next-higher tier of the system monitor architecture.
  • the preprocessor module(s) 606 may include a filter 1406 , an aggregator 1408 , and an update notification transmitter 1410 .
  • the filter 1406 may be configured to remove certain types of monitor data, or certain amounts.
  • the aggregator 1408 may be configured to combine received messages for transmission of a combined message.
  • the group leader monitor service 132 c may receive a message from each edge device 110 - 114 for aggregation thereof, or may receive a series of message from a single edge device (e.g., the edge device 110 ).
  • the update notification transmitter 1410 may be configured to provide updates, similarly to the update notification transmitter 812 .
  • the update notification transmitter 1410 communicates updates to a GUI 1412 , for viewing, e.g., by a system administrator.
  • the example of the GUI 1412 may be most appropriate at higher-level tiers of the monitoring architecture.
  • aggregation and filtering, logging, computation of statistics, and other data preprocessors may be used for monitoring data.
  • the system adaptor 134 may deliver the CPU utilization every second, with a requirement that the average utilization over the last two minutes be determined.
  • the monitored data values may be preprocessed near to the measuring system adaptor. In this way, communication resources are conserved, since the need to send each data value (once a second) to the upper tier(s) may be avoided. Instead, e.g., on demand, only the aggregated value may be sent.
  • different ones of the preprocessor modules may register at the core monitor service 148 .
  • monitor data e.g., status values
  • each of the registered preprocessors is executed.
  • a first preprocessing module may receive the raw monitor data as a parameter(s), and may return a preprocessed data set. Subsequently, the next preprocessor is started, and received the preprocessed output data from the first preprocessor. Accordingly, each preprocessor may be executed, working on the output data of its predecessor.
  • modules e.g., plug-ins
  • two modules may register with the core monitor service 148 and/or the preprocessor manager 1402 .
  • the first module may delete all data of a specific service or device, while the second module may compute the average CPU utilization over all monitored devices.
  • the result is different if the order of the two modules changes, because then all monitored services and devices are taken into account, including the specific service or device to be deleted.
  • the preprocessor manager 1402 may, e.g., during registration, set the appropriate execution order.
  • a number and type of preprocessor modules 606 may be unknown at design-time, it may be difficult to assign an absolute execution order, particularly when the preprocessor modules may be loaded dynamically at runtime. Consequently, one option is to create groups of the preprocessor modules 606 , so as to order the preprocessor modules 606 according to group.
  • Each preprocessor module 606 may be associated with a group identifier, so as to be put into the correct group during registration. Then, the groups may be executed in order on a group-level, if not at the level of individual preprocessor modules.
  • Groups may be ordered based on, for example, a priority and/or type of pre-processing performed. For example, a first group may include preprocessor modules that must work on raw data, while a second group may work on already-preprocessed data, and a third group may process final data.
  • a modular or plug-in concept for the preprocessing modules 606 e.g., 1406 - 1410
  • the modular architecture allows the monitor service 132 a - 132 b configurable to the needs and capabilities of each device.
  • monitor service modules 150 may be implemented.
  • a data storage module 604 may be used.
  • a different technology for storing monitor data in the global monitor data 138 may be chosen than is chosen for storing monitor data in the local monitor data 136 , e.g., either may store data in one or more of a database, a text file, an in memory data-structure, or virtually any other kind of data storage.
  • Use of the data storage module 604 may make such differences opaque to the monitoring service in question, using the various techniques described above with respect to FIGS. 6-14 .
  • the monitor data storage may be encapsulated by a well-defined interface, and the interface may serve as an abstraction layer from the actual data storage system.
  • FIG. 15 is a block diagram of a system 1500 illustrating a registration protocol for use with the system 100 of FIG. 1 .
  • a group leader device 1502 which may be a portable device (e.g., a PDA or laptop), enters into an area of a group leader device 1504 .
  • the group leader device 1504 is a group leader of a plurality of edge devices 1506 a , 1506 b , 1506 c of a sensor network.
  • the group leader device 1504 and the edge devices 1506 a , 1506 b , 1506 c may be involved in any number of sensor network applications, including, for example, inventory management or hazardous material tracking.
  • the group leader device 1504 (which may be, for example, the same as the edge devices 1506 a , 1506 b , 1506 c , or which may be a WiFi access point or a base station, as referenced above) may be in the process of collecting information (i.e., monitor data) associated with inventory in a warehouse.
  • monitor data may include a type and quantity of stocked goods for sale, and/or current temperature information in a vicinity of the stocked goods (e.g., to detect possible spoilage of food products).
  • the group leader device 1502 may enter the area of the group leader device 1504 , such as when an employee enters the area with a PDA or other computing device, and wishes to obtain desired monitor data.
  • the group leader device 1502 may wish to collect the monitor data for local use by the employee, and/or may itself collect/transmit monitor data to a global monitor service 1508 . In the latter case, for example, the group leader device 1502 may have certain computing resources or capabilities not available (or, at least, not currently available) in the group leader device 1504 . It should be understood that, in the example of FIG. 15 , the group leader device 1502 may actually be currently acting as a group leader to a plurality of edge devices (not shown in FIG.
  • group leader device 150 may be referred to as a group leader device in the sense that sufficient computing resources are present to act at the group leader tier of the infrastructure described herein (e.g., to split messages for distribution to edge devices, or to filter/aggregate messages from the edge devices for subsequent transmission).
  • the group leader device 1504 it may be the case that the group leader device 1504 has failed, or is about to fail (e.g., due to low battery power), or is required to re-locate, so that the group leader device 1502 is being re-located for the purpose of assuming the duties of the group leader device 1504 .
  • the global monitor service 1508 includes global monitor data 1510 , and operates on a device 1512 (which may include, as described herein, a PC or similarly-powerful computer).
  • the global monitor data 1510 may include global landscape data related to the system 1500 as a whole, including other elements not shown in FIG. 15 .
  • the global monitor data 1510 may include device metadata describing the group leader 1504 and the edge devices 1506 a , 1506 b , 1506 c (including, for example, both static and dynamic device capabilities).
  • the global monitor service 1508 may include device metadata related to the group leader device 1502 .
  • the group leader device 1502 may previously have been registered with the global monitor service 1508 as part of a separate network(s) (not shown in FIG. 15 ). As the employee operating the group leader device 1502 re-locates from the separate network to the area of the devices shown in FIG. 15 , the group leader device 1502 may disconnect as part of the separate network (and be marked as such within the global monitor data 1510 , as already described), although information regarding the group leader device may be maintained in the global monitor data 1510 for some period of time.
  • the system 1500 further includes a local monitor service 1514 , with local monitor data 1516 and running on a device 1518 .
  • the device 1518 may include, for example, a laptop computer or a Stargate computer, as described.
  • the system 1500 may include a local monitor service 1520 , with local monitor data 1522 and running on a device 1524 .
  • the group leader device 1502 may need to register with the global monitor service 1508 in order, for example, to establish a connection 1526 with the group leader 1504 .
  • the group leader device 1502 and the group leader device 1504 may have overlapping abilities to communicate with one another; e.g., both may have Bluetooth capabilities. Even so, the group leader device 1502 may be unaware that the group leader device 1504 has Bluetooth capabilities, and, moreover, the group leader device 1502 may have no local communication service (e.g., adaptor/module) that is compatible both with Bluetooth and with whatever service(s) are being run on the group leader device 1504 (e.g., the temperature reporting service referenced above).
  • a local communication service e.g., adaptor/module
  • the global monitor service 1508 may be well aware of all such information, as stored within the global monitor data 1510 (e.g., appropriate service metadata and/or device metadata).
  • information regarding the group leader device 1504 also may be stored in the local monitor data 1516 , as should be understood from the description above.
  • the global monitor service 1508 is (indirectly) capable of establishing the connection 1526 , since, for example, the global monitor service 1508 may be able to determine which communications services (adaptors/modules) are needed, and may then download and/or inject such a service(s) onto the group leader device 1502 .
  • the global monitor service 1510 also may communicate with the group leader device 1504 , in order to ensure (by injecting, if necessary) that the group leader device 1504 not only has Bluetooth (or other communication protocols/standards), but also has a local service that is compatible both with Bluetooth and with a corresponding service on the group leader device 1502 .
  • connection 1526 may be established.
  • the group leader 1502 may otherwise communicate with other devices/services of the system 1500 .
  • registration of the group leader device 1502 within the system 1500 may provide a number of advantages, for example, to a user of the group leader device 1502 .
  • Such registration may be associated with a number of difficulties. For example, such registration may represent a security issue, since unregistered and possibly malicious devices should not generally be monitored and integrated into the system 1500 . Also, frequent exchanges of registration messages may consume valuable bandwidth, battery power, or other communications resources. If devices are not registered, though, then such devices may be un-identified and un-accessed by the rest of the system 1500 .
  • FIGS. 15-17 provide examples of how the group leader device 1502 may register with the global monitor service 1508 .
  • this is but one example, and many other examples may be used to implement the described registration protocol, or variations of the described registration protocol, as would be apparent.
  • the group leader device 1502 has a monitor service installed thereon (although not shown in FIG. 15 ).
  • a monitor service may include the various implementations described herein, including the modular monitor service of FIG. 6 , or may include a non-modular, e.g., integrated, monitor service.
  • the group leader device 1502 and its installed monitor service thus attempt to join the network(s) of the system 1500 , including registering at the global monitor service 1508 .
  • the group leader device 1502 includes a registration system 1528 and registration data 1530 .
  • the registration system 1528 is configured to exchange registration messages 1532 , 1534 , 1536 , and 1538 with one or more of the local monitor services 1514 , 1520 (and/or with the global monitor service 1508 ).
  • the registration data includes information about the connecting monitor service of the group leader device 1502 , such as, for example, metadata related to a current status of the group leader device 1502 , or device metadata related to the group leader device 1502 .
  • the registration data also may include initial sensor status/values information (e.g., to avoid overhead caused by an initial polling for such values, which would take place right after registration, since data is outdated or not existent. In cases where an excessive amount of values would be included in the registration data, then at least static data values may be sent).
  • registration data 1530 is illustrated conceptually as/in a memory in FIG. 15 , it should be understood that the registration data 1530 may simply represent values collected by the group leader device 1502 (e.g., by the registration system 1528 and/or by a monitor service of the group leader device), either during or before registration takes place.
  • the group leader device 1502 may have a memory in some example implementations.
  • a local memory e.g., the local monitor data 1516 , 1522
  • the registration system 1528 and registration data 1530 may be implemented within other ones of the devices and monitor services of FIG. 15 .
  • the described registration protocol may be implemented as a simple, e.g., connectionless, protocol, that is robust. Additionally, the registration protocol is configured to support both active registration (e.g., initiated by a connecting device) and passive registration (e.g., initiated by a connected network device). Consequently, as described, the registration process may be started by either device.
  • the group leader device 1502 as an unregistered-but-now registering device sends out a solicitation message 1532 .
  • the solicitation message 1532 which may be sent as a broadcast message, may contain a request for, or identification of, a specific type of same or next-higher level monitor service, and the request may be based in part on device capabilities of the connecting device.
  • the (registering) group leader device 1502 may try to locate other group leader devices (e.g., the group leader device 1504 , i.e., a monitor service thereof) and/or local monitor services (e.g., 1514 , 1520 ), rather than the global monitor service 1508 .
  • group leader devices e.g., the group leader device 1504 , i.e., a monitor service thereof
  • local monitor services e.g., 1514 , 1520
  • the registration system 1528 may re-send the solicitation message 1532 with an identification of a next-higher level (going up from lower to higher level monitor services). Further, if the solicitation message 1532 is lost, then the registration system 1528 may simply send another solicitation message, e.g., after a timeout. Solicitation messages that are received twice are not an issue, since this is the initial step of the protocol. Therefore, a lightweight and connectionless transportation protocol, e.g., UDP, may be sufficient.
  • UDP connectionless transportation protocol
  • the solicitation message 1532 may be sent out periodically if no answer is received.
  • the group leader i.e., registering, or connecting
  • the group leader assumes that there is no monitor service, and stops sending messages for at least a specified time interval, which saves power and computation time.
  • the advertisement message 1534 may be sent, for example, either in response to a timer or to the solicitation message 1532 .
  • the advertisement message 1534 may include an identification of a type of monitor service that is sending the advertisement message 1534 (e.g., the local monitor service 1520 in the example of FIG. 15 ).
  • the advertisement message 1534 may be sent as a broadcast message, and may be sent by any or all of the devices described herein (except, generally, the various edge devices, to the extent that the edge devices do not typically have any child monitor services connected thereto).
  • the advertisement message 1534 provides a fail-safe mechanism in case the solicitation message 1534 is lost, and also may act as an initiator of the registration process, e.g., for devices that do not send solicitation messages.
  • the group leader device 1502 may, as referenced above, stop sending solicitations after a specified time period, or if devices cannot detect network changes.
  • the advertisement message 1530 such devices may be “reactivated.”
  • lost advertisement message are not disruptive, in that they may be resent from time to time.
  • a connecting/registering device such as the group leader device 1502 may respond to the advertisement message 1534 once by sending a registration message 1536 .
  • the registration message 1536 may contain, for example, information about monitored data, landscape metadata, device metadata, and/or actual monitored (e.g., sensor) values.
  • registration data may be saved in all devices on the path from the receiving, parent monitor to the global monitor service 1508 (e.g., in the example of FIG. 15 , may be stored at the device 1524 and 1512 , as well as at any intervening devices). In other words, the registration message 1536 is forwarded to the upper layer monitor services.
  • Outdated data within the memories (e.g., 1510 , 1522 ) of the upper layer monitor service may be marked as “in doubt,” and/or may be deleted to avoid inconsistencies.
  • the global monitor data 1510 may have information from a previous registration event that the group leader device 1502 is currently connected to another network (not shown in FIG. 15 ). As the group leader device 1502 is moved away from devices of the former network, however, the former connection is lost, so that data within the global monitor data 1510 becomes outdated. Once the group leader device 1502 registers again through the local monitor service 1520 , as shown in FIG. 15 , then a current registration status, location, and other information/data within the global monitor data 1510 may be updated accordingly.
  • the registration system 1536 may ensure that duplicates of the registration message 1536 are not problematic, by allowing only one message-triggered registration message 1536 during a registration process. That is, the registration system 1536 may be configured to ignore any additional advertisement message(s) 1534 , once the registration message 1536 is sent.
  • the registration message 1536 then obtains a confirmation message 1538 to ensure that the registration was processed successfully. If no confirmation has arrived after a pre-determined time, the registration message 1536 may be resent. Duplicate registration messages are no problem in such implementations, because one registration may be allowed to override another registration without causing any harm. Additionally, or alternatively, duplicated registration messages may simply be ignored if the relevant service or device is already registered.
  • the confirmation message 1538 may be sent by the managing monitor service (e.g., the local monitor service 1520 ).
  • the registration process finishes when the registering device (the group leader device 1502 ) receives the confirmation message 1538 (if the confirmation message 1538 is not received, e.g., is lost, then the group leader device 1502 may simply re-send the registration message 1536 ).
  • the now-registered monitor service of the group leader device 1502 may then begin its assigned monitoring tasks.
  • the registration protocol of FIG. 15 allows for connectionless and unreliable data transfer, so that simple and robust protocols, e.g., UDP, may be used.
  • FIG. 16 is a sequence diagram illustrating an example implementation of the registration protocol of FIG. 15 .
  • various exceptions occur, in order to illustrate the robust nature of the protocol.
  • a solicitation message is sent from the group leader device 1502 (e.g., from a group leader monitor service installed thereon) to the local monitor service 1520 , but is not received ( 1602 ). That is, the solicitation message includes an identification that it is a local monitor service that is desired as a parent device, but no such potential parent device receives or responds to the message.
  • a second solicitation message(s) is/are sent ( 1604 ), which is received at both the local monitor service 1520 and the global monitor service 1508 .
  • the registration system 1528 may determine that because the sending of the first solicitation message ( 1602 ) was unsuccessful, it may be necessary to send a second solicitation message.
  • both the local monitor service 1520 and the global monitor service 1508 receive the solicitation message ( 1604 ). However, the global monitor service 1508 simply ignores ( 1606 ) the solicitation, since the solicitation specifies the local monitor service 1520 .
  • the local monitor service 1520 sends out an advertisement message ( 1608 a and 1608 b ).
  • the advertisement message may be sent ( 1608 a ) in response to the sending of the solicitation message(s) ( 1604 ), or may be sent based on a timer value.
  • the sending of the additional advertisement message ( 1608 b ) as part of a broadcast thus arrives at the global monitor service 1508 , but is ignored ( 1610 ).
  • the group leader device 1502 then sends a registration message ( 1612 ), causing the local monitor service to register associated metadata ( 1614 ).
  • the registered metadata may be forwarded to the global monitor service 1508 (e.g., using delta synchronization).
  • a confirmation message may be sent, but, in the example of FIG. 16 , is not received at the registration system 1528 ( 1616 ).
  • the registration system 1528 of the group leader device 1502 simply resends the registration message ( 1618 ), which is then received again at the local monitor service 1520 , and either re-registered ( 1620 ) or ignored.
  • a confirmation message is sent again, and this time is received at the group leader device 1502 ( 1622 ), thus ending the registration process.
  • FIG. 17 is a flowchart 1700 illustrating example operations of the system 1500 of FIG. 15 .
  • a connecting monitor service e.g., a monitor service of the group leader device 1502 , which may include or be associated with the registration system 1528
  • broadcasts a solicitation message e.g., the solicitation message 1532
  • the solicitation message 1532 including an identification of a desired parent service from within the hierarchical monitor architecture of the system 1500 ( 1702 ).
  • the parent monitor service may continue waiting for a pre-defined timer ( 1706 ). Thus, if the timer is reached, or if the solicitation message is received at the parent monitor service, then the parent monitor service may receive the resulting advertisement message, e.g., the advertisement message 1534 ( 1708 ). As should be understood, then, the advertisement message 1534 may be sent whether the solicitation message 1532 is received or not, thus increasing the likelihood of connection/registration of the connecting device.
  • the connecting device may re-send the solicitation message 1532 ( 1712 ), perhaps identifying a next-higher level of the hierarchical monitor architecture as the desired parent service (e.g., the global monitor service 1508 instead of the local monitor service 1520 , 1514 ).
  • the process may continue until a registration and/or advertisement message(s) are exchanged. Otherwise, the process is stopped ( 1716 ).
  • the time-out condition may refer literally to a period of time that has passed, or may refer to the sending of a pre-defined number of (a certain type of) message(s).
  • the advertisement message may be resent ( 1708 ), according to its associated timer ( 1706 ), even if the process was previously stopped or failed.
  • any “stop” condition in FIG. 17 including the stop condition ( 1716 ), may be temporary, and the process may continue after some further-defined period is reached.
  • the connecting device may send a registration message, e.g., the registration message 1536 , to the parent monitor service identified in the advertisement message ( 1718 ). If the registration message is not received ( 1720 ), and a timer is not reached ( 1722 ), then the connecting device may re-send the registration message ( 1718 ). As described, the registration message may include monitor data, so that, if the registration message is received ( 1720 ), the registration message may be propagated up the hierarchy ( 1726 ), e.g., to the global monitor service 1508 .
  • the monitor data including metadata about the connecting device and actual sensor values may be saved at some or all of the intervening devices ( 1728 ), e.g., the local monitor service 1520 .
  • the global monitor service 1508 may keep track of the existence of the connecting service/device, and may delete eventual left-over data marked as “in doubt” that may otherwise cause inconsistencies (e.g., the same device registered in different networks simultaneously).
  • the parent monitor service may send a confirmation message ( 1730 ), e.g., the confirmation message 1538 . If the confirmation message is not received ( 1732 ), and a time-out has not been reached ( 1734 ), then the registration message may be re-sent ( 1718 ), and the above-described process may be repeated, in whole or in part. If the time-out is exceeded ( 1734 ), or if the confirmation message is received, then the registration process ends, as well ( 1724 ).
  • the just-described registration protocol(s) may be implemented when the connecting device (e.g., the group leader device 1502 ) already has a monitor service installed thereon. As described above with respect to FIG. 7B , however, if the connecting device does not have a monitor service installed thereon, then a pre-registration process may be conducted in which, as described above, a boot-strapping technique may be used in which the core monitor service 148 is installed, and then is used to execute the remaining registration processes of FIGS. 15-17 .
  • a boot-strapping technique may be used in which the core monitor service 148 is installed, and then is used to execute the remaining registration processes of FIGS. 15-17 .
  • a robust and reliable registration protocol of FIGS. 15-17 allows for the use of unreliable/connectionless communications protocols, while minimizing an amount of network bandwidth required for the registration process. For example, network bandwidth may be conserved by stopping re-sending of one or more of the messages after a certain period of time.
  • network bandwidth may be conserved by stopping re-sending of one or more of the messages after a certain period of time.
  • each time the registration protocol requires resending messages after timeouts there is a possibility that either the connecting device or parent service may have lost a connection, and this possibility may lead to a “stuck” state for some or all of the system 1500 .
  • each re-sent message may be re-sent for a limited number of times only, and, if no successful registration is achieved the entire registration process may restart.
  • Implementations of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Implementations may implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
  • data processing apparatus e.g., a programmable processor, a computer, or multiple computers.
  • a computer program such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
  • a computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
  • Method steps may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method steps also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
  • FPGA field programmable gate array
  • ASIC application-specific integrated circuit
  • processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer.
  • a processor will receive instructions and data from a read-only memory or a random access memory or both.
  • Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data.
  • a computer also may include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks.
  • Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices
  • magnetic disks e.g., internal hard disks or removable disks
  • magneto-optical disks e.g., CD-ROM and DVD-ROM disks.
  • the processor and the memory may be supplemented by, or incorporated in special purpose logic circuitry.
  • implementations may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.
  • a display device e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor
  • keyboard and a pointing device e.g., a mouse or a trackball
  • Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
  • Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components.
  • Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
  • LAN local area network
  • WAN wide area network

Abstract

Monitor services deployable on device networks may be implemented using a modular approach, in which a core monitor service is mapped to one or more devices included in, or associated with, the device networks. Additional monitoring-related functionality may be provided to such devices using plug-ins, add-on services or service components, or other service modules, which interact with the core monitor service. The core monitor service(s) and any monitor service modules may be mapped, to specific ones of the devices, based on, for example, requirements of other services and/or relevant device metadata (e.g., capabilities) of the devices. In additional or alternative implementations, various protocols may be used to register new devices and deployed monitor service(s) with the distributed monitoring service(s) in a fast, secure, energy-efficient, and reliable manner, even as devices join or leave the device network(s).

Description

TECHNICAL FIELD
This description relates to ubiquitous computing technologies.
BACKGROUND
Smart item technologies may include, for example, radio-frequency identification (RFID) systems, embedded systems, sensor motes, and/or sensor networks, and may be used, for example, to provide business software applications with fast access to real-world data. For example, smart item technologies may be used support the detection, reading, or writing of RFID tags, as well as to support communication with, and control of, wireless sensor networks and embedded systems. In many instances, smart items may include devices having local processing power, memory, and/or communication capabilities, that are capable of providing data about the device and its properties, or information about a current state or environment of the smart item devices. Accordingly, some such devices may be used in the execution of service components of back-end or underlying business applications, and, in particular, may do so in a collaborative way, e.g., by forming mobile ad-hoc networks to collect, process, or transmit business data.
Examples of smart item devices include an RFID tag, which may be passive or active, and which may be attached to a real-world object and used to provide product or handling information related to the object. Other examples of smart item devices includes various sensors, such as, for example, environmental sensors (e.g., a temperature, humidity, or vibration sensor), which, as just referenced, may be capable of communicating to form one or more sensor networks. These and other types of smart item devices also may include embedded systems, which may refer generally to any system in which a special-purpose processor and/or program is included, and/or in which the system is encapsulated in the device being controlled.
Through automatic real-time object tracking, smart item technology may provide businesses with accurate and timely data about business operations, and also may help streamline and automate the business operations. Accordingly, cost reductions and additional business benefits (e.g., increased asset visibility, improved responsiveness, and extended business opportunities) may be obtained.
SUMMARY
According to one general aspect, a method includes transmitting, from a registering monitor service at a first tier of a hierarchical, multi-tier monitoring architecture for a device network, a solicitation message identifying both the registering monitor service, and a registered monitor service associated with a second, higher tier of the hierarchical, multi-tier monitoring architecture. The method also includes transmitting, from the registered monitor service, an advertisement message indicating an identity and availability of the registered monitoring service for registration, and transmitting, from the registering monitor service, a registration message including registration data associated with the registering monitor service. The method also includes registering the registering monitor service within the hierarchical, multi-tier monitoring architecture, based on the registration data.
Implementations may include one or more of the following features. For example, the method may include transmitting, from the registered monitor service, a confirmation message confirming registration of the registering monitor service.
In transmitting the solicitation message, the solicitation message may be transmitted to the second, higher tier, after a previous transmitting to an intervening tier does not result in receiving the advertisement message. Transmitting the solicitation message also may include broadcasting the solicitation message at a pre-determined time interval.
Transmitting the advertisement message may include transmitting the advertisement message based on the solicitation message. Transmitting the advertisement message may include transmitting the advertisement message based on a pre-determined time interval, and independently of the solicitation message.
Transmitting the registration message may include including, within the registration data, device metadata within the registration message and associated with a device on which the connecting service is deployed, and/or including, within the registration data, service metadata within the registration message and associated with a service deployed on the device. Transmitting the registration message also may include including, within the registration data, sensor values obtained by a sensor associated with the connecting service.
Transmitting the registration message may include re-transmitting the registration message until the confirmation message is received or until a time-out condition is reached, and/or may include discarding, at the registering monitor services, a further advertisement message received after the registration message is transmitted. Additionally, or alternatively, transmitting the registration message may include storing the registration data using at least one device associated with the registered monitor service, and/or updating global monitor data for the hierarchical, multi-tiered monitor architecture, based on the registration data, to reflect the registration of the registering monitor service with a global monitor service.
A core monitor service may be deployed onto the registering monitor service, and device metadata associated with a device on which the registering monitor service is deployed may be determined. At least one monitor service module may be deployed onto the device, based on the device metadata. The solicitation message may be transmitted, the advertisement message may be received, and/or the registration message may be transmitted, using the at least one monitor service module.
According to another general aspect, a system includes a monitor service configured to obtain and report monitor data regarding a device network at a first level of a hierarchical, multi-tiered monitor service. The monitor service includes a registration system configured to send a solicitation message from the monitor service, the solicitation message specifying, by tier, a registered monitor service at a higher-level tier of the hierarchical, multi-tiered monitor architecture, the registration system being further configured to receive an advertisement message from the registered monitor service, determine that the registered monitor service is a member of the specified tier based on the advertisement message, and send a registration message to the registered monitor service.
Implementations may include one or more of the following features. For example, the registration system may be configured to receive a confirmation message from the registered monitor service, in response to the registration and confirming that the monitor service is registered with a global monitor service associated with the device network. The registration message may include registration data that is stored, at least in part, using the global monitor service and any intervening monitor service between the registering monitor service and the global monitor service.
According to another general aspect, a method includes receiving a solicitation message from a monitor service at a registered monitor service of a hierarchical, multi-tiered monitor architecture for a device network, determining that the monitor service is not registered through the registered monitor service as a member of the hierarchical, multi-tiered monitor architecture, and determining an identification of a tier specified in the solicitation message, the registered monitor service being deployed on the tier. The method may include sending an advertisement message to the monitor service, the advertisement specifying the registered monitor service as being deployed on the tier and available for registration, receiving a registration message from the monitor service, and registering the monitor service within the hierarchical, multi-tiered monitor architecture, based on the registration message.
Implementations may include one or more of the following features. For example, a confirmation message may be sent to the monitor service. Additionally, or alternatively, sending the advertisement message may include sending the advertisement message in response to the solicitation message. Registering the monitor service may include storing, locally to the registered monitor service, registration data received from the monitor service as part of the registration message, and updating a memory of a higher-tier monitor service, above the registered monitor service, based on the registration data.
The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a system for monitoring smart items.
FIG. 2 is a block diagram illustrating an example deployment of the system of FIG. 1.
FIG. 3 is a block diagram illustrating a second example deployment of the system of FIG. 1
FIG. 4 is a block diagram of a smart items infrastructure for implementing the systems of FIGS. 1, 2, and 3.
FIG. 5 is a timing diagram illustrating an example algorithm for gathering monitor data using the system of FIG. 1.
FIG. 6 is a block diagram of a modular monitor service that may represent one or more of the monitor services 132 a-132 d of FIG. 1.
FIG. 7A is a flowchart illustrating an operation of the system of FIG. 1 using the modular monitor service of FIGS. 1 and 6.
FIG. 7B is a flowchart illustrating additional example operations of the system of FIG. 1.
FIG. 8 is a block diagram of an example implementation of a core monitor service of FIGS. 1 and 6.
FIG. 9 is a block diagram illustrating a system adaptor manager for use with the modular monitor service of FIG. 6 and/or the implementation of the core monitor service illustrated in FIG. 8.
FIG. 10 is a block diagram of an example implementation of a system adaptors of FIGS. 1, 6, and 9.
FIG. 11 is a block diagram of another example implementation of system adaptors of FIGS. 1, 6, and 9.
FIG. 12 is a block diagram of an example implementation of a communication adaptor of the modular monitor service of FIG. 6.
FIG. 13 is a block diagram of another example implementation of the communication adaptor(s) of FIG. 6.
FIG. 14 is a block diagram of an example implementation of a preprocessor module of FIG. 6.
FIG. 15 is a block diagram of a system illustrating a registration protocol for use with the system 100 of FIG. 1.
FIG. 16 is a sequence diagram illustrating an example implementation of the registration protocol of FIG. 15.
FIG. 17 is a flowchart illustrating example operations of the system of FIG. 15.
DETAILED DESCRIPTION
FIG. 1 is a block diagram of a system 100 for monitoring smart item devices. In the example of FIG. 1, a sensor network 102 that includes various smart item devices provides real-world data to one or more business data processing systems 104 in a timely and accurate manner, using a local area network 106 (although other sizes or types of networks may be used). For example, the sensor network 102 may include smart item devices 108, 110, 112, and 114, referred to herein as “smart item devices” or simply as “devices” (or similar terminology), which may include, for example, RFID readers (for reading RFID tags associated with real-world objects having an RFID tag), various embedded systems, and/or various types of sensors and/or sensor motes.
Although the following description refers primarily to the sensor network 102 or other sensor network(s) as an example implementation(s), it should be understood that such sensor networks may refer to any network that gathers or obtains information, even if not all of the devices of the sensor network do not have specific sensor functionality associated therewith (e.g., one of the devices of the sensor network 102 may include an actuator). Moreover, it should be understood that virtually any network of devices may be used, alone or in conjunction with one another. Further, devices of such device networks may communicate with one another (e.g., in a peer-to-peer fashion), and/or may communicate, e.g., through appropriate middleware, with the business data processing systems 104, or other systems.
In FIG. 1, the device 108 is illustrated as including a central processing unit (CPU) 116, as well as a memory 118. Thus, the device 108 should be understood to be capable of various levels of computing capabilities, including, for example, processing or transmitting sensed data (e.g., in the case where the device 108 includes, or is associated with, a sensor). Although not specifically illustrated in FIG. 1 for the sake of clarity, it should be understood that the devices 110, 112, and 114 also may include the same or different computing capabilities, including, for example, the capability to form and participate in the sensor network 102, such as a wireless network and/or a peer-to-peer network.
Thus, the sensor network 102 may be used to collect, process, filter, aggregate, or transmit data that may be useful to the business data processing systems 104. For example, the business data processing systems 104 may include inventory management systems, supply chain management systems, retail store management systems, warehouse management systems, and any other system(s) that may be used to execute business processes with respect to real-world objects, where such real-world objects may include, for example, products for sale, pallets or other shipment elements, patients, or manufacturing materials/equipment. By tracking and analyzing such real-world objects, the business data processing systems 104 may be used, for example, to determine inventory levels, set pricing levels, evaluate marketing strategies, evaluate manufacturing or production technologies, reduce theft, or maintain safety.
By including smart item devices as, or in association with, the devices 108, 110, 112, and 114 of the sensor network 102, processing may be performed very early in the data-collection process(es), so that a burden placed on the business data processing applications 104 may be reduced or eliminated. For example, the business data processing applications 104 may be located at a corporate headquarters, and the sensor network 102 may represent one of many (types of) networks that may be dispersed across a large geographical region connected by the wide area network 106. As such, for example, the business data processing systems 104 may only require certain sub-sets or characterizations of data collected by the network 102 (and related networks), and may not need or want all collected data.
In some implementations, the business data processing systems 104 may include compound or composite applications that are made from re-usable software components or services that are designed to perform some well-defined task(s). Also, in these or other implementations, the business data processing systems 104 may include legacy applications that may not easily communicate with data-collection devices (or with other business data processing systems), and, in such cases, services or service components may be provided as interfaces between the legacy applications and the data collection devices and/or other systems. The system 100 allows these and other applications and services to be deployed directly on the devices 108, 110, 112, and 114, so that, for example, services may be run on the devices (and data may be collected and/or processed) in a timely, efficient, reliable, automated, cost-effective, and scaleable manner. Thus, for example, business processes may be decomposed into individual services and deployed at different devices.
The system 100 includes a service mapper 120 that is operable to select the device 108 as a selected device from among the plurality of devices 108, 110, 112, and 114 of the sensor network 102, for deploying a service 122 thereon, as shown. In so doing, the service mapper 120 accesses a service repository 124 that is operable to store a plurality of services that are eligible for execution within the sensor network 102 and/or other networks (not shown in FIG. 1). The service mapper 120 determines service metadata 126 along with an actual service executable 128, and compares the service metadata 126 against device metadata 130 associated with each of the plurality of devices 108, 110, 112, and 114. Based at least on the service metadata 126 and the device metadata 130, the service mapper 120 may select the device 108 as being particularly well-suited for deployment of the service 122 (including the service executable 128) thereon.
For example, the device metadata 130 may include a description of each device, the description being constructed according to an ontology and/or schema that is known to the service mapper 120 and common to the various devices 108, 110, 112, and 114. Additionally, or alternatively, the device metadata 130 may be collected in a device-specific format or structure for each of the devices 108, 110, 112, and 114, e.g., by a system monitor 132, and may thereafter be converted into such a common schema for use by the service mapper 120. For example, the device metadata may include a description of various technical capabilities of the devices 108, 110, 112, and 114, provided in an extensible Markup Language (XL)-based language, e.g., by using an XL schema, as described in more detail, below. Of course, other formats, languages, and/or structures may be used, as well.
More generally, the device metadata 130 may include, for example, a device description, a software description, a hardware description, and a device status. For example, the device description may include a device name, identifier, or type, or may include vendor information including a vendor name or vendor website. The software description may include an operating system description, including version and/or vendor, or may include a description of services running or allowed to run on the device platform. The hardware description may include information about attributes of the CPU 116 (e.g., name and/or speed), memory 118 (e.g., total and/or free amount of memory), or connection capabilities (e.g., connection speed or connection type) of the device(s). The device status may include more volatile information, including a device location, current CPU usage, or remaining power or memory. Of course, other device aspects or information may be included in the device metadata 130, as described below and/or as would be apparent. For example, the device metadata 130 may include information about other devices, such as where the device 108 includes an RFID reader, and the device metadata 130 may include a description of types of RFID tags that may be read and/or written to by the RFID reader.
The service metadata 126 may somewhat analogously include various service descriptions and/or requirements that relate to whether and how the service(s) may be executed on one or more devices. For example, the service metadata may include a service behavior description, technical constraints of the service, or information regarding input, output, preconditions, or effects (IOPE) of the service. For example, technical constraints may include a required CPU type or speed, an amount of (free) memory that is needed, a type or speed of connection that is required or preferred, an operating system version/name/description, or a type or status of a battery or other device power source(s).
Thus, as with the device metadata 130, distinctions may be made between static and dynamic service requirements, such as hardware requirements. For example, a static value such as a total memory or maximum processing speed required by a service may be included, along with dynamic values such as available memory/processing/power and/or a number or type of other services that may be allowed to concurrently run on a device together with the service(s) in question, at an execution time of the service(s).
Using at least the service metadata 126 and the device metadata 130, the service mapper 120 may map a given service onto the devices 108, 110, 112, or 114 of the sensor network 102. Such a mapping is designed not only to value-match various aspects of the service metadata 126 and the device metadata 130, where necessary (e.g., matching a required memory specified in the service metadata 126 with a device memory specified in the device metadata 130), but also to enable and optimize a deployment and execution of the service in question. For example, it may be the case that both the device 108 and the device 110 are nominally or ostensibly capable of running the service 122 (e.g., both devices 108 and 110 may posses some minimum required values of memory, processing capabilities, or power). However, it may be the case that the service 122 is more power-hungry than memory-hungry (or vice-versa), so that the service mapper 120 may map the service 122 to the device 108 if the device 108 is currently able to provide more power relative to the other candidate device 110, even if the device 110 currently provides more free memory than the device 108.
Once an appropriate service mapping has been performed, a service injector (not shown in FIG. 1) may be used to install and start the mapped service (e.g., the service 122) on the device 108. Such a service injector also may be used, for example, to manage a life cycle of the service(s), e.g., by performing service updates or stopping the service when necessary.
As referenced above, during run-time of the system 100, the system monitor 132 is configured to determine, track, and/or provide a current state of the system 100. Such state information may include, for example, which of the devices 108, 110, 112, 114 are currently available for service deployments, or what services are currently running on which of the devices 108, 110, 112, 114. More generally, the system monitor 132 may detect and collect device metadata 130, including static, discrete-dynamic, or continuous dynamic device metadata, as described in more detail, below, as well as network metadata 140 related to the sensor network 102, also described in more detail, below. As should be apparent, monitor data such as the device metadata 130 and/or the network metadata 140 may thus be made available to the service mapper 120, the business data processing systems 104, and/or to a system administrator.
In the example of FIG. 1, the system monitor 132 is implemented using a four-tier architecture to provide for a scalable, distributed monitoring service(s). That is, the system monitor 132 may be implemented using one or more monitoring services, where the monitoring services may be stored in the service repository 124, and may be mapped, in whole or in part, to the sensor network 102 (and to devices associated with the sensor network 102) by the service mapper 120. Such a four-tier architecture may be used in conjunction with algorithms described herein, so as to efficiently gather monitor data in a distributed system landscape, such as that of the system 100.
Such monitor data may include, for example, the device metadata 130 (which may include, for example and as described herein, connectivity information, battery life, or CPU/memory usage of the devices 108, 110, 112, 114) and/or the network metadata 140. The network metadata 140 may include, for example, various network parameters, particularly where such parameters are dynamic and not necessarily discernable from information about any single device. One such example of the network metadata 140 may include available bandwidth on the sensor network 102. Other examples include network topology information, mobility characteristics of the network as a whole, and reliability of network connections.
In some implementations, as described herein, such monitor services may be implemented using a modular approach, in which a core monitor service is mapped to one or more devices included in, or associated with, the sensor network 102. Then, additional monitoring-related functionality may be provided to such devices using plug-ins, add-on services or service components, or other service modules, which interact with the core monitor service. As should be understood, the core monitor service(s) and any supplemental monitor services may be mapped, for example, using the service mapper 120 and based on, for example, application-specific requirements and relevant device metadata (e.g., capabilities). In additional or alternative implementations, various protocols may be used to register new devices and deployed monitor service(s) with the distributed monitoring service(s) in a fast, secure, energy-efficient, and reliable manner, even as devices join or leave the sensor network 102.
In the example of FIG. 1, then, the above-referenced four-tier architecture includes four types or classes of monitor services, which may be hierarchically layered. Specifically, the uppermost tier (also referred to herein as the global layer), includes a global monitor service (GMS) 132 a. The global monitor service 132 a provides a highest-level storage and view of monitor data, not just for the sensor network 102, but potentially for a plurality of sensor networks (see, e.g., FIG. 2). Thus, for example, the global monitor service 132 a may provide a central contact point for system monitoring information for other system components (e.g., the service mapper 120), the business data processing system(s) 104, a system administrator, and/or a system administration graphical user interface (GUI). Global-level monitor data may be stored in a memory represented in FIG. 1 by global monitor data 136, which may thus be considered to represent or include global device metadata describing devices of the sensor network 102 and other networks, at least at a high level, as well as current service information about which services are running on which networks, for example.
The global monitor service 132 a is conceptually above, and updated by, a second layer or tier, referred to herein as the local layer or local tier, and including a local monitor service(s) 132 b. The local monitor service 132 b is configured to provide the global monitor service 132 a with information about changes in the underlying sensor network 102. Thus, the local monitor service 132 b may be configured to use a memory represented in FIG. 1 as local monitor data 138 to store more detailed monitor data about the devices 108, 110, 112, 114 in the sensor network 102 than may practically be stored in association with the global monitor service 132 a (and the global monitor data 136). It should thus be understood that the local monitor service 132 b may be responsible for one or more sensor networks or other device clusters, and that such networks/devices may include potentially heterogeneous devices deployed in relatively close physical proximity to one another. Thus, the local monitor data 138 may be considered to represent local device metadata regarding networks within the purview of the local monitor service 132, such as the sensor network 102, where it should be understood that the local monitor data 138 may generally be more specific than the global monitor data 136 with regard to particular devices of the sensor network 102, and other supervised networks.
The third layer or tier includes a group leader monitor service 132 c, which may be configured for the collection, filtering, and aggregation of monitor data for the devices 108, 110, 112, and 114. In various implementations described herein, the group leader monitor service 132 c may be configured to manage collection of monitor data from associated devices 108, 110, 112, 114 by using, for example, polling or heartbeat techniques. The group leader monitor service 132 c is then responsible for reporting the resulting monitor data back to its respective local monitor service 132 b. In the example of FIG. 1, the group leader monitor service 132 c does not store monitor data, due to, for example, limited resources at the device 108, or because a rate of change of the monitor data processed by the group leader monitor service 132 c makes storage impractical. Thus, the group leader monitor service 132 c may be considered to present group-level device metadata regarding the particular devices 108-114 within its group, including, for example, dynamic or static device characteristics, or information about which services are running on which of the devices 108-114.
The fourth layer or tier of the example four-tier architecture of FIG. 1 includes an edge monitor service 132 d. In the example of FIG. 1, the edge monitor service 132 d collects the monitor data for its associated device (here, the device 110) and the local services of the associated device. That is, it should be understood that, just as the device 108 is illustrated as executing the service 122, the device 110 also may be executing one or more services, and the edge monitor service 132 d may be configured, for example, to monitor information about such services, as well as to monitor static or dynamic data specific to the device 110 itself (e.g., total memory, currently-available memory, device type, and/or other device characteristics). The edge monitor service 132 d is further configured to report collected monitor data to the group leader monitor service 132 c. Thus, the edge monitor service 132 d provides edge-level device metadata about a particular, (usually single) device, such as the device 110.
In the above-described architecture, the monitor services 132 a-132 d may be configured to be responsible for different tasks, and may generally become more lightweight towards the edge of the infrastructure of the system 100. Consequently, for example, the edge monitor service 132 d may be implemented on the device 110, which may have very limited computing capabilities, while the global monitor service 132 a may be implemented on a device(s) 142 and/or 144, such as, for example, a personal computer (PC) or a similarly-powerful server machine. Meanwhile, the local monitor service 132 b may be implemented, for example, on a device 146, such as, for example, a smart RFID reader, or a personal digital assistant (PDA). The group leader monitor service 132 c may be deployed, as shown in FIG. 1, on one of the devices of the sensor network 102 (although it should be understood that the devices 108, 110, 112, 114 may be heterogeneous devices having differing computing capabilities, so that the device 108 may be selected as the group leader based on, for example, its relatively-superior resources), or the group leader monitor service 132 c may be deployed, in another example, on a wireless access point that is in communication with the devices 110, 112, and 114. A number of different examples of how the monitor services 132 a-132 d may be physically deployed on some or all of the various devices 108-114, 142, 144 and/or 146, as well as other devices, are provided below with respect to FIGS. 2-3.
Some or all of the monitor services 132 a-132 d may be implemented using a core monitor service 148 for certain fundamental monitoring functionality, in conjunction with a plurality of potential plug-ins, attachments, service components, or other modules, represented in FIG. 1 by the monitor service module 150. In this way, for example, the monitor service module 150 may be associated with the core monitor service 148 within the devices 108 (and, analogously, although not shown in FIG. 1, within devices 142, 144, 146, and 110-114), such that the core monitor service 148, which may be very slim so as to run on small or resource-poor devices, may be specialized/extended according to application-specific needs and/or the capabilities of the respective devices. Accordingly, for example, functionality related to communication, data storage, or data preprocessing may be added or replaced to a given device without changing the core monitor service 148. Although not shown specifically in FIG. 1, examples of uses of core monitor service(s) and associated monitor service modules are discussed in more detail with respect to FIGS. 6-14
During operation, the system 100 may gather monitor data, including, for example, the device metadata 130 or the network metadata 140, using the following example algorithm. Specifically, the monitor data may be gathered at the group leader monitor service 132 c, from which it is propagated to the local monitor service 132 b, and then to the global monitor service 132 a. To gather data, the group leader monitor service 132 c may execute a system adaptor 134, which may itself be, for example, a service mapped to the device 108 from the service repository 134 by the service mapper 120. The system adaptor 134, which may conceptually represent a plurality of different types of adaptors, and which also may be considered to be an additional or alternative example of the monitor service module 150, may be configured to interface with the service 122, and thereby may gather data from or about the service 122. In other examples, the system adaptor 134 may represent a device adaptor that is configured to interface with the components of the device 108, e.g., the CPU 116 or the memory 118, so as to provide, for example, hardware-specific information related to the device 108.
Thus, to gather data, the group leader monitor service 132 c may execute the system adaptor(s) 134, which thereby serve as data sources to provide the monitor data regarding devices and services. For example, in example of FIG. 1, the monitor data may include information about the device 108, and/or about the service 122. Via, for example, heartbeat messages, the monitor data is sent to upper tiers, e.g., via the local monitor service 132 b to the global monitor service 132 a. In example implementations, the group leader monitor service 132 c collects monitor data from the edge devices 110, 112, 114. Specifically, each of the edge devices 110, 112, 114 may be associated with its own monitor service, e.g., the edge monitor service 132 d of the edge device 110. As should be understood, and as described in more detail below, any of the monitor services 132 a-132 d may be implemented using (instances of) the core monitor service 148, along with various examples and types of the monitor service module 150.
The group leader monitor service 132 d and the local monitor service 132 b may be configured to perform message aggregation, in which messages from different devices (e.g., from different group leader devices, and/or from different edge devices) are summarized into a single message. At each of the group leader monitor service 132 c, the local monitor service 132 b, and the global monitor service 132 a, the monitor data may be preprocessed (e.g., filtered or aggregated), and such pre-processors may be performed by the monitor service module 150, or a similar module. Accordingly, an amount of monitor data that is passed to the global monitor service 132 a may be reduced.
In the architecture of the system 100 of FIG. 1, then, (updated) monitor data is propagated up from lower to higher tiers, e.g., from the edge monitor service 132 d to the global monitor service 132 a. As shown, the monitor data may be stored in various forms and to various extents, within different ones of the tiers/layers. For example, as shown, data may be stored at the global monitor data 136, and/or at the local monitor data 138, where it should be understood that the local monitor service 132 b and the local monitor data 138 (and the device 146) may represent multiple services, memories, and devices associated with the system 100 (see, e.g., FIGS. 2-4).
Various techniques may be used to determine the type and extent of the monitor data that is to be stored (or not stored) at a given one of the tiers of the architecture of the system 100 of FIG. 1. For example, decisions on whether and where to store monitor data may be based on battery lifetime, memory availability, device reliability, network utilization, response times, and outdated information (e.g., there may be a requirement to keep certain types of monitor date up-to-date to a specified extent). For example, the device 146 associated with the local monitor service 132 b may have a certain amount of available memory, while another device (not shown) may implement another local monitor service associated hierarchically with the global monitor service 132 a, and which may have a relatively-significant amount of free memory.
One aspect of whether to store monitor data at a given location (e.g., at the local monitor data 138 or the global monitor data 136) relates to a priority of the monitor data. For example, information such as a device ID, a device classification, and alive-status may have a high priority for being stored. Another aspect relates to a nature of the monitor data. For example, static and discrete-dynamic data from the group leader monitor service 132 c may be stored when queried, so that often-queried monitor data is read less often (e.g., is effectively cached at the local monitor data 138). As another example, (potentially) outdated data must be managed, so as to be updated, as necessary. Meanwhile, continuous-dynamic data may not be stored, since it may be outdated as soon as it is stored. Therefore, continuous-dynamic data may simply be read (e.g., queried) from the relevant device, as needed.
The decision of whether and how to store monitor data at a given location may be made dynamically, e.g., by evaluating an expression that incorporates aspects such as, for example, hardware capabilities needed for the storage, a proximity of the storage location to the sensor, or a type of information to be stored. For example, each device (e.g., the device 146) may compute a value, based on, e.g., an associated hardware profile, response time(s) for a query, a distance to the edge device(s) 110-114, a data priority, and/or a dynamic type of the data (e.g., static, discrete-dynamic, or continuous-dynamic). The resulting value may be defined using a mathematical expression (implemented, for example, during registration of a particular service or device, where an example of such registration is described in more detail, below, with respect to FIGS. 7B and FIGS. 15-17), in which the considered aspects are represented numerically and weighted for subsequent combination and comparison to a defined threshold. An example of such an expression is shown in Eq. (1):
Device - capability - describing value = ( residual lifetime ) × w 1 + ( CPU speed ) × w 2 + ( CPU utilization ) × w 3 + ( memory size ) × w 4 + ( memory utilization ) × w 5 + ( network bandwidth ) × w 6 + ( network utilization ) × w 7 + ( device classification ) × w 8 + ( kind of information ) × w 9 Eq . ( 1 )
In addition to the dynamic/automatic approach just described, a manual storage decision may be made. For example, a system administrator may want to define types or instances of monitor data that should or should not be stored on designated device(s). For example, an administrator may have the authority to overrule the automated decision, above, and define additional or alternative storage rules. Such manual decisions may be made, for example, for each specific device, or for each device type, or based on the type/role of each monitor service (e.g., all local monitor services 132 b may be required to store certain types of monitor data).
Finally with respect to FIG. 1, and again as described in more detail herein, e.g., with respect to FIGS. 7B and 15-17, it should be understood that a monitor service(s) (and associated device(s)) may leave or join a network. For example, the device 110 may initially not be a part of the sensor network 102, and may be a mobile or portable device that may be moved from one location to another. As such, the device 110 may be transported to a location of the sensor network 102, and the device 110 (e.g., the edge monitor service 132 d) may try to register at the group leader monitor service 132 c, or at any device that is itself connected to the global monitor service 132 a. Accordingly, a dedicated protocol may be used for such registration, so that devices and monitor services may easily or automatically be configured to leave one sensor network and join another. Examples of such dedicated protocols are discussed in more detail, below, with respect to FIGS. 15-17
FIG. 2 is a block diagram 200 illustrating an example deployment of the system 100 of FIG. 1. FIG. 2 illustrates that, as described above, the system 100 may be deployed across four conceptual tiers or layers, which are represented in FIG. 2 as a global layer 202, a local layer 204, a group layer 206, and an edge layer 208. As should be understood from the description of FIG. 1, the layers 202-208 have different tasks, and are each associated with their respective type of monitor service (e.g., the global monitor service 132 a, the local monitor service 132 b, the group leader monitor service 132 c, and the edge monitor service 132 d). Each type or class of monitor service may be associated with a physical device (e.g., the device 144, 146, 108, and 110 of FIG. 1) based on the capabilities of the device(s). As a result, for example, the relatively light-weight edge monitor service 132 d may run on a device, e.g., a sensor mote, with very limited computing capabilities, while the global monitor service 132 a may run on a device with significantly more computing resources, e.g., a PC or server.
In some example implementations, and as shown in FIG. 1, the above-referenced variations in the monitor services 132 a-132 d may be achieved by way of a modular deployment of the monitor services 132 a-132 d. For example, the edge monitor service 132 d may be deployed at the edge layer 208 using only an instance of the core monitor service 148, shown as core monitor service 148 d in FIG. 2.
Meanwhile, the group leader monitor service 132 c may be deployed using an instance of the core monitor service 148 c, along with an instance of a monitor service module 150, shown in FIG. 2 as the monitor service module(s) 150 c. That is, it should be understood that the monitor service module 150 c may represent one or more monitor service modules, where the monitor service modules are configured to implement the monitoring functionality described above with respect to the group leader device 108 of FIG. 1. For example, the monitor service module 150 c may be associated with aggregating monitor data (e.g., messages) received from all of the edge monitor services 132 d of the edge layer 208, for reporting thereof to the local monitor service 132 b.
Along similar lines, the local monitor service(s) 132 b of FIG. 2 may include the core monitor service 148 b, as well as the monitor service module(s) 150 b, where the monitor service module 150 b may be configured to implement functionality associated with the local layer 204 (e.g., storage of monitor data in the local monitor data 138, or updating of the global monitor data 136). Finally, and similarly, the global monitor service 132 a may include the core monitor service 148 a, along with the global layer-specific monitor service module(s) 150 a.
It should be understood that FIG. 2 is merely an example, and that many variations are possible. For example, in some examples, the core monitor services 148 a-148 d may be identical or substantially identical, while in other examples, there may be substantial differences. For example, the core monitor services 148 a and 148 b may be different from the core monitor services 148 c and 148 d, and, for example, may include functionality associated with data storage that is not required by the core monitor services 148 c and 148 d, rather than relying on monitor service modules 150 a and 150 b for this functionality. In other examples, the global monitor service 132 a may be implemented in an integrated, non-modular manner, while the remaining monitor services 132 b-132 d may use the modular construction described herein. Template(s) for the core monitor services 148 a-148 d may be stored in the service repository 124, so that the devices 144, 146, 108, 110 may receive instances of the core monitor services 148 a-148 d, as instantiated for deployment, e.g., by the service mapper 120.
FIG. 2 also illustrates a hierarchical nature of the system 100. That is, in FIG. 2, the global monitor service 132 a is maintained over, and in communication with, a plurality of local monitor services 132 b, each of which may itself be maintained over, and in communication with, a plurality of group leader monitor services 108. Finally, as already illustrated in FIG. 1, each group leader monitor service 132 c may be maintained over, and in communication with, a plurality of edge devices 132 d.
In FIG. 2, as contemplated in the example of FIG. 1, it may be the case that each monitor service 132 a-132 d is deployed on a single physical device. More generally, however, it may be the case that a plurality of (types of) physical systems or devices are associated with one of the logical tiers or layers 202-208. Conversely, it may be the case that a plurality of the layers 202-208 may be associated with a single (type of) physical system or device.
FIG. 3 is a block diagram 300 illustrating a second example deployment of the system 100 of FIG. 1, in which the layers 202-208 may be associated with a plurality of (types of) physical systems or devices. In the example of FIG. 3, a company server 302 (e.g., a company-wide central server) may be located in a first geographical location (e.g., Europe), and may implement the global service monitor 132 a.
Meanwhile, a production plant server 304 (e.g., a server computer implemented/located at a production plant for the company) may be located at a production plant of the company in, e.g., San Francisco. The production plant server 304, along with a Stargate computer 306 (e.g., a single board computer with communications and sensor signal processing abilities) and a WiFi access point 308, may be implemented at the local layer 204. In other words, one or more local monitor service(s) 132 b may be implemented using one or more of the physical devices 304-308.
In the example of FIG. 3, at least two local monitor services 132 b should be understood to be included, e.g., with respect (at least) to the Stargate 306 and the WiFi access point 308. That is, each such local monitor service is maintained over at least one group leader monitor service, which should be understood to be running on a sensor mote 310 and a PDA 312, where the sensor mote 310 is the group leader to a plurality of sensor motes 314-318 (the sensor motes 314-318 thus illustrating, potentially, examples of the (edge) devices 110-114).
In the example of FIG. 3, then, more than four physical layers exist, and these physical layers may be mapped onto the four logical tiers or layers 202-208 of FIG. 2. Thus, multiple physical system layers may fill in the role of one conceptual tier. In examples using more than four physical layers, devices may route information between conceptual tiers. For example, an edge device may route information from the local monitor service 132 b to the group leader monitor service 132 c, even where the edge device in question may belong to a different sensor network, but may be physically closer to the local monitor service 132 b than is the group leader monitor service 132 c.
As referenced above, however, physical systems/devices also may have less than four tiers. For example, there may be only two physical tiers, in which case the global monitor service 132 a may be deployed on a first device, while the local monitor service 132 b, the group leader monitor service 132 c, and the edge monitor service 132 d may be deployed on a second device, perhaps with a single, combined instance of the monitor service(s) 132 b-132 d.
In the examples of FIGS. 1-3, the hierarchy of devices may be conceptually tree-structured, e.g., each device may have exactly one upper (or same) layer monitor service to report to (which may be referred to as a “parent monitor”). The global layer device, e.g., the device 144, which contains the global monitor service 132 a, may be the only monitor service without such a parent monitor. For purposes of collecting monitor data, edge devices (e.g., the edge devices 110-114) may not need to communicate with one another directly, but, rather, may simply forward monitor data to their parent device(s). Of course, in these or other contexts, devices may communicate directly with one another (e.g., in a peer-to-peer fashion, perhaps to calculate an average temperature in a room or to perform other collaborative computing).
More generally, devices may be physically connected to other devices in the same network or may be connected to several networks. Thus, in other implementations, the monitor services 132 b-132 d may have several parents. In some additional or alternative implementations, there may be exactly one main network connection, as referenced above and defined as the connection with the shortest path (in terms of hops) to the global layer device 144. Other connections (e.g., peer-to-peer and/or multiple network connections) may be regarded as auxiliary or “shortcut” connections, so that, for example, a local-layer device with the local monitor service 132 b on a first sensor network need not go through the global layer to communicate with an edge device of a second sensor network, but, rather, may communicate with the edge device using an intervening group leader device.
FIG. 4 is a block diagram of a smart items infrastructure 400 for implementing the systems of FIGS. 1-3. The smart items infrastructure 400 includes five layers: a device layer 402, a device level service layer 404, a business process bridging layer 406, a system connectivity layer 408, and an enterprise application layer 410. The layer 402 may be considered to contain various ones of the devices 108, 110, 112, and 114 of FIG. 1, or similar devices, across a number of groups, local networks and/or physical locations. Meanwhile, the layers 406, 408, and 410 may be considered to be part of, or associated with, the business data processing systems 104 of FIG. 1. Thus, the layer 404 may be considered to represent remaining components of the system 100 of FIG. 1, e.g., the service mapper 12, the system monitor 132 and/or the monitor services 132 a-132 d, and the service repository 124, as shown in FIG. 4.
The device layer 402 thus comprises the actual smart item devices, as well as any communications between them. The device layer 402 also is responsible for presentation of any offered hardware services to the next higher layer, the device level service layer 404. The devices may include, for example, an RFID device 412, embedded systems 414, sensor networks 416, and any other new or emerging technologies 418, as would be appropriate. It should be understood that the examples of the device layer 402 are non-limiting, and may overlap. For example, sensor networks may include RFID devices (readers/tags), embedded systems, and/or other emerging technologies.
For the RFID device(s) 412, mobile tags may be attached to real-world objects, and are then read (and optionally written to) by RFID readers. In an implementation using active tags, the active tags may also provide additional sensor data (e.g., a current value or a past value). In RFID, communication is typically initiated by the reader, while tags may or may not directly communicate with each other. Such an RFID reader may be configurable to the extent of processing tag data, e.g., may be configured to perform verification of written data, or to avoid reporting a disappearance of a tag if the ostensibly lost tag in fact reappears within a given time window.
Techniques for communicating with the embedded systems 414 may vary on the types of devices of the embedded systems. For example, the embedded systems may represent anything from small-scale, one-chip microcomputers, all the way to full-blown PC hardware. Thus, for example, for devices that have the capabilities of a mobile phone or more (e.g., are able to run a Java Virtual Machine™), implementation may be performed in Java™ or based on OSGi (the latter representing a known framework for implementing a component model for remote installation and management of applications and/or application components). As also described above, the sensor networks 416 may include any number of types of sensors that may include integrated processing power and that may be able to execute peer-to-peer communication.
The service repository 124 may store at least two kinds of services, compound and atomic services. The compound services generally rely on other services to fulfill their tasks, and may have no directly-executable code of their own; rather, the compound services may include an executable service composition description that is stored in a corresponding service description. Thus, compound services may have one service executable, i.e., the service composition description. In contrast, atomic services do not generally use other services, and have their own directly-executable code. Also, as mentioned above, since an atomic service may be deployable on different platforms, an atomic service may have more than one service executable, e.g., may have a service executable for each of the different platforms.
The service repository 124 also may store the service metadata 126, where such service metadata 126 is described in detail, above, and may include a service name, identifier, version, or vendor, or may describe run-time requirements of the service, including, for example, technical deployment requirements (e.g., high bandwidth, or minimum processing power required), semantic requirements (e.g., that a receiving device have a serial connection and/or many device neighbors), and spatial requirements (e.g., that a receiving device be in the basement, or at a south side of a specified building).
Finally at the device-level service layer 404, a device repository 420 may be included. As should be understood from the above description, the device repository 420 may include, for example, information about devices (e.g., the device metadata) in an manner analogous to that in which the service repository 124 maintains information about services (e.g., the service metadata). For example, device metadata may be stored in the device repository 420 based on communication with the system monitor 132 (e.g., with one or more of the monitor services 132 a-132 d. In other example implementations, the device repository may include device metadata stored by an administrator based on externally-available information about the devices. For example, as already mentioned, the device metadata may include a device name, power capacity, memory capacity, processing capacity, or other information that may be relevant to mapping (and ultimately deploying) a service to an associated device. Of course, in these examples, the device repository 420 may include generally static or high-level device metadata, and/or may include some or all of the global monitor data 136 and/or the local monitor data 138.
At run-time, the system monitor 132 monitors a current system state, as already described, using the monitor services 132 a-132 d. Whether and how any part of a state of a service is exposed to the system monitor 132 may be set by a developer of the service at design-time. This state-availability information may thereafter be available both to a system administrator and to the service mapper 120. As also described above, the service mapper 120 receives deployment requests and then determines on which device(s) the corresponding service should be deployed, e.g., by matching the service metadata to the device metadata, which may include a current state of the smart item devices and related local network(s). As also described herein, the service mapper 120 also may react to certain events or conditions, including changes in the network state (as recognized by the system monitor 132), and may thereafter decide to re-map a service or add or remove instances of services to better fulfill given deployment requests/requirements.
The business process bridging layer 406 includes services designed to aggregate data from the devices at the device layer 402, provided via the device level service layer 404, and to transform the data from the device layer 402 into business-relevant information. In so doing, an amount of data sent to back-end enterprise application systems may be reduced, and business logic may be executed for different ones of the enterprise application systems.
For example, one or more rule processor(s) 422 may be used to parse incoming messages, support basic operational services (e.g., item movement, association, de-association, or device reading/writing) and support information querying. The rule processor 422 processes user-defined business rules that define or reference any other basic operational services that should be executed or consulted. Using such rules and basic operational services provides a flexible framework to adapt the system 400 to different business scenarios.
The rule processor 422 may use a data repository 424 for keeping track of all physical objects of interest, e.g., for keeping track of the current state, location, timestamp, or associated business transaction of a given object being tracked, as well as for keeping track of what future actions are expected. Aggregated information from the data repository 424 may be reported on a regular basis, e.g., daily or monthly.
One example of an operation of the layers 402, 404, and 406 includes a “goods receiving” scenario. For example, a provider delivering objects to a receiver may send an Advanced Shipment Notification (ASN) containing a list of all objects in the shipment, along with object identifiers such as Electronic Product Codes (EPCs). The ASN may be stored in the data repository 424. When the shipment arrives and passes the RFID readers at the device layer 402, e.g., at a receiving dock door, then the EPCs are read by the RFID readers, and sent to the rule processor 422. The rule processor looks up the ID of the reader from which the message came, determines a location and role of the reader, and then calls the appropriate basic operational service responsible for handling received shipments. This operational service compares the obtained EPCs with the expected EPCs from previous ASNs, and, if a match is found, reports to an enterprise application 432 that the delivery has arrived and is complete. The executed operational service also may then update the data in the data repository 424. Services described above, as well as services for receiving and sending the involved messages, may be managed by a service manager 426.
Components in the system connectivity layer 408 may be used to connect different application systems and to support system and data integration. For example, messages and data may be routed to the correct backend systems by an information exchange and transformation module 428, and also may be transformed thereby to enable a semantically-correct integration. On top of message-routing and transformation services, the system connectivity layer 408 also provides services in a service repository 430 that can be used to access the functionality provided by the Business Bridging Layer 406 by enterprise applications 432.
The enterprise application layer 410 includes, for example, traditional enterprise IT systems responsible for controlling and managing enterprise business applications. An enterprise application 432 covering a specific business process may not be a single program, but rather may be composed of different services that work together to achieve a desired functionality. Such services may be provided by the same enterprise system, by another enterprise system within the enterprise application layer 410 (possibly located at a site of a business partner), or by systems from lower layers (e.g., by smart item devices at the device layer 402).
Finally in FIG. 4, development tools 434 may refer to tools for creating enterprise application(s) 432 and other applications/services. Using a development environment integrated with the infrastructure 400 may support the implementation of basic services in manners that are similar to known development tools in the enterprise application space. Further, the development tools 434 may allow the creation of the required service metadata 126, as well as the inclusion of existing services into new applications. Furthermore, the development tools 434 allow a developer to specify where a certain service should run, to configure individual service instances, and to deploy the services in a desired manner. That is, a developer may develop service metadata/executable(s) 436 using the development tools 434, and may then provide desired ones of the service metadata/executable(s) 436 for storage in the service repository 124, and/or for mapping/re-mapping by the service mapper 120 at the same or later time.
Having described the above example implementations and settings associated with the system 100 of FIG. 1, FIG. 5 is a timing diagram illustrating an example algorithm for gathering monitor data using the system 100 of FIG. 1. The algorithm of FIG. 5 is implemented using the global monitor service 132 a, which, as already described, is configured to gather information about all devices and services within its underlying hierarchy, and which thus provides a global system landscape view. In the context of FIG. 4, the global monitor service 132 a may run as a part of the device level service layer 404 and/or the business process bridging layer 406 of the infrastructure 400 of FIG. 4. The global monitor service may be requested/called by high-level services that also are running at the device level service layer 404 or the business process bridging layer 406, or through separate device and service monitoring graphical user interfaces (GUIs).
As referenced above, the local layer may include a plurality of the local monitoring services 132 b, which are each configured to gather monitor data from edge devices, using, for example, polling and heartbeat techniques, as described in more detail, below. The local monitor service 132 b is configured to manage collected monitor data, including, for example, filtering, aggregating, and storing the monitor data. The group layer includes multiple devices at or near the edge of the infrastructure (e.g., the infrastructure 400 of FIG. 4) which fill in the role of the group leaders, such as the device 108 of FIG. 1. The group leaders gather information about edge devices (e.g., devices 110-114) in their vicinity having the edge monitoring service 132 d installed. In the example of FIG. 5, monitor data obtained by the group leader (e.g., 108) is not stored at the group leader, but may be filtered, aggregated, or otherwise processed, before being forwarded to the local monitor service 132 b to be stored. Finally, devices (e.g., devices 110-114) run the edge monitor service 132 d and form the edge layer. In some implementations, group leader monitor services 132 c and edge monitor services 132 d may be essentially identical in terms of providing, preprocessing, and not storing monitor data, although the edge monitor service 132 d is not responsible for managing other devices. In the example of FIG. 5, the edge monitor service 132 d is configured to provide monitor data and send it to its group leader using heartbeat messages (e.g., messages sent using an active send queue at some pre-defined interval). More generally, however, gathering monitor data from edge layer devices may be triggered either by timers of the edge devices for sending the heartbeat messages, or by poll messages received at the edge devices from upper tiers/layers.
In the example of FIG. 5, a timer triggers the local monitor service 132 b to check for outdated data in the local monitor data 138, which results in polling (502) several edge layer devices. The local monitor service 132 b does not communicate directly with the edge layer devices, but rather uses the group leader device 108 at a gateway, and thus sends a polling message to the group leader monitor service (504). The group leader monitor service 132 c splits the single poll message into different poll messages (although FIG. 5 shows only one poll message, for the sake of simplicity), which are sent to the individual edge layer devices 110-114 (506).
Each edge layer device 110-114 reads a local system adaptor (508), which should be understood to be the same or similar to the system adaptor 134 of FIG. 1, to obtain up-to-date monitor data. Examples of system adaptors and related elements are provided in more detail below, with respect to FIGS. 9-11. Generally, however, it should be understood that such system adaptors serve as data sources to provide monitor data about their respective edge device, as well as about any service(s) running on their respective edge device.
The edge monitor service 132 d then executes preprocessing (510) of the monitor data (e.g., filtering and/or aggregation). Then, without storing the pre-processed monitor data, sends a heartbeat message (512) with the pre-processed monitor data to the group leader monitor service 132 c. The group leader monitor service 132 c receives messages with the monitor data from a plurality of edge devices, and provides further pre-processing (514), including, for example, calculation of an average of the CPU utilizations of all managed edge devices. Then, the group leader monitor service 132 c performs message aggregation (516), in which messages from different devices are summarized into a single heartbeat message for transmission to the local monitor service 132 b (518).
The local monitor service 132 b receives such heartbeat messages from a plurality of group leader monitor services 132 c, and performs pre-processing (520), including, e.g., filtering of non-critical data, and/or aggregation thereof. The pre-processed message(s) are then stored (522), e.g., at the local monitor data 138. Then, a timer of the local monitor service 132 b triggers a heartbeat indicator (524) that causes the local monitor service 132 b to compute a delta synchronization (526) between the local monitor data 138 and the global monitor data 136. That is, the local monitor service 132 b determines which relevant information within the local monitor data 138 has been changed or updated as a result of the execution of the monitoring algorithm of FIG. 5, and only this changed data is submitted to the global monitor data 136, e.g., as part of a delta synchronization message (528). In this way, an amount of transferred and processed data is reduced. In additional or alternative implementations, the delta synchronization may be initiated by a message from the global monitor service 132 a to the local monitor service 132 b.
Finally in FIG. 5, the updated data is preprocessed by the global monitor service 132 a (530), and stored in the global monitor data 136. Then, the business data processing systems 104, e.g., supply chain management applications, may access the data from the global monitor data 136. It should be understood from the above description that monitor data from a given edge device is stored in the landscape tree on the path from the edge device itself to the global monitor service 132 a. As a result, the monitor data is easily located for use or deletion thereof.
FIG. 6 is a block diagram of a modular monitor service 600 that may represent one or more of the monitor services 132 a-132 d of FIG. 1. That is, the modular monitor service 600 includes the core monitor service 148, which is illustrated in FIG. 1 in the context of the group leader monitor service 132 c, but which, as explained above, also may be implemented in the context of some or all of the remaining monitor services 132 a, 132 b, and/or 132 d. The modular monitor service 600 also includes the monitor service module 150, which, again, is illustrated in FIG. 1 in the context of the group leader monitor service 132 c, but which, again, also may be implemented in the context of some or all of the remaining monitor services 132 a, 132 b, and/or 132 d.
Thus, the core monitor service 148 may be configured to implement fundamental functionalities that may be used by most or all of the monitor services 132 a-132 d (e.g., query routing, role-based data handling, and coordination of communication with other monitor services running on other devices), while the monitor service module(s) 150 may be configured to implement functionality that may be more particular to a given one of the monitor services 132 a-132 d. The monitor service module(s) 150 may thus be implemented as plug-in components that are added to the core monitor service 148 on an as-needed basis, so that the core monitor service 148 may be specialized according to individual needs and capabilities of each monitor service and/or device.
For example, in the example of FIG. 6, the monitor service module(s) 150 include the system adaptor 134, a communication adaptor 602, a data storage module 604, and a data preprocessor 606. Consequently, associated functionality for these plug-ins, and other functionality, may be added or replaced to the module monitor service 600, without changing the core monitor service 148. Moreover, as described in more detail below, the monitor service module(s) 150 of the same category (e.g., different instances of the communication adaptor 602 or of the data storage module 604) may share a common interface, so that the core monitor service 148 need not be aware of the usage of the different instances/plug-ins.
Further in FIG. 6, module manager(s) 608 may be used to manage modules of the same category. For example, the module manager(s) 608 may include a manager for the system adaptor(s) 134, and may be configured to select and implement an appropriate one of the system adaptor(s) 134, based on a current situation and/or need of the core monitor service 148. Specific examples of such a system adaptor manager are provided below, e.g., with respect to FIGS. 9 and 10, and other examples of module managers 608 are also discussed. It should be understood that the module manager(s), in some implementations, may act as actual intermediaries to messages between the core monitor service 148 and a given monitor service module 150, e.g., forwarding the messages from the core monitor service 148 to the appropriate monitor service module 150, or vice versa. In other implementations, the module manager(s) 608 may be configured to load or select an appropriate one of the monitor service module(s) 150, and may then remove itself from further communications.
FIG. 7A is a flowchart illustrating an operation of the system 100 using the modular monitor service 600. In FIG. 7A, instances of the core monitor service 148 are deployed onto one or more of the architectural tiers (702), e.g., of the system 100. For example, the service mapper 120 may be configured to deploy the core monitor service 148 onto the devices 108-114, 146, and 144 of the system 100, perhaps during an initial set-up of the system 100. In another example(s), discussed in more detail below with respect to FIG. 7B and FIGS. 15-17, the service mapper 120 may map an instance of the core monitor service 148 onto a new device (not shown in FIG. 1) that comes into an area of the sensor network 102, and that wishes to communicate with one or more of the devices 108-114, 146, and/or 144.
It should be understood that the core monitor service 148 may be stored in the service repository 124 as a template, form, or other generic structure, and that different instances of the core monitor service 148 may be deployed within the system 100. Moreover, the instances need not be exactly identical. For example, different instances of the core monitor service 148 may be deployed, having different functions included or enabled, depending on which layer of the system monitor 132 the instance is to be deployed. The service mapper 120 may execute the service mapping of instances of the core monitor service 148 as described above, e.g., based on the device metadata 130.
Once the core monitor service module 148 is installed within the system 100, various monitor service modules may be installed (704). For example, the monitor service modules 134, 602, 604, and/or 606 may be installed, depending, for example, on the device metadata 130 associated with the device(s) in question, and/or onto which level of the monitor architecture the monitor service module(s) are being deployed. As is also discussed in more detail below, such device metadata may be obtained using the already-installed core monitor service 148, and/or may be obtained from memory.
With the core monitor service 148 and the monitor service module(s) in place, monitor data may be collected, e.g., by implementing the algorithm of FIG. 5 using the modular monitor system 600 of FIG. 6. For example, from the above discussion of FIG. 5, it should be understood that raw monitor data (e.g., at the edge monitor service 132 d) may initially be collected using the core monitor service 148 and/or the system adaptor 134 (706) (which, as described in more detail herein, e.g., with respect to FIGS. 9-11, may include both service and device adaptors). In this way, the raw monitor data (e.g., regarding relevant services and/or devices) may be provided in a way that hides different interfaces of the (heterogeneous) services/devices, and that is extensible for new services/devices. Further, system standards, such as, for example, OSGi or JSR82, may be implemented.
The raw monitor data may be pre-processed at the pre-processor module 606 (708). Examples of such pre-processing are provided in conjunction with FIG. 5, and further with respect to FIG. 14. Generally, however, such pre-processing acts on incoming data to reduce an amount of data to be sent over the network connection(s), using, e.g., filtering and aggregation.
The (pre-processed) monitor data may be stored using the data storage module(s) 604 (710). For example, the data storage module 604 may be configured to hide different types of storage that may be available (e.g., file system, database, or in-memory data structure). As described above, storage of monitor data may be limited just to the local monitor service 132 b and the global monitor service 132 a, so that, accordingly, the data storage modules 604 may be deployed only onto those monitor services, and resources are conserved.
The processed and stored data may be propagated, and queries for new data (e.g., by polling) may be executed using the communications adaptor 602 (712). For example, as should be understood, the communications adaptor 602 may be configured to ensure communication between services/devices, may hide unreliable or out-of-order data transfers, and may hide the core monitor service 148 from effects of different communications protocols/hardware. In some implementations, the communications adaptor 602 may be considered to be separate from the monitor service 132 a-132 d, and, e.g., may be deployed separately (i.e., at separate times) from either the core monitor service 148 or monitor service modules 134, 602, or 606. Different operations and uses of the communications adaptor 602 are provided below, with respect to the examples of FIGS. 8, 12, and 13.
FIG. 7B is a flowchart illustrating additional example operations of the system 100. In FIG. 7B, it is assumed that the core monitor service 148 is not initially installed. In many cases, however, the core monitor service 148 may be needed in order to proceed with further operations of the system 100. For example, during a registration process of a new device within the system 100, registration protocol may require installation and availability of the core monitor service 148 (see, e.g., the examples of FIGS. 15-17 for a discussion of an example registration protocol for registering a new device with the system 100). In this and other scenarios, a bootstrapping technique may be implemented, in which the core monitor service 148 is installed first, and then information from the installed (executing) core monitor service 148 may itself be used to register the new device, and/or to deploy the monitor service modules 134 and/or 602-606.
For example, it may first be determined whether the device in question supports existing standards for deploying services (714) (e.g., OSGI, Jini, Services and Networks for Domotic Applications (SENDA), service management module (SMM), or JSR232). If such standards are not supported by a device in question, then appropriate action may be taken. For example, in a case where the device is of a level of a mobile phone or PDA, then a user thereof may be instructed to execute an installation wizard (e.g., follow a link to download and start an installation program) for setting up the core monitor service 148 (716). In such a case, and/or using known deployment standards, and if the core monitor service 148 is not yet installed (718), then static device metadata may be determined (720), e.g., using the standards and/or from a memory.
At this point, the core monitor service may be installed (722), and additional monitor data may be obtained therefrom (724). As described in more detail below, e.g., with respect to FIGS. 15-17, a full-scale device registration with the system monitor 132 also may be executed at this point, if necessary. Using the additional monitor data, appropriate monitor service module(s) 150 may be deployed (726), so that collection and/or transmission of additional monitor data may proceed.
FIG. 8 is a block diagram of an example implementation of the core monitor service 148. In the example of FIG. 8, a communication abstraction layer, with incoming 802 a and outgoing 802 b messages, may be used by the core monitor service 148, for example, to establish connections to monitor services on different devices, or to establish connections to GUI interfaces and to other types of services. The communication abstraction layer 802 a, 802 b is discussed in more detail below, with respect to FIG. 12. As should be apparent from FIGS. 6 and 7, other module managers 150 (e.g., system adaptor manager, described with respect to FIGS. 9-11) also may be in communication with the core monitor service 148, and, depending on how such managers are defined and implemented, may overlap with some of the functionality of the communication abstraction layer(s) 802 a, 802 b.
The core monitor service 148 of FIG. 8 includes a query router 804. The query router 804 may be responsible, for example, for gathering and returning queried monitor data, which may either be queried by (other) monitor services 132 a-132 d running on other devices, or by other services (e.g., temperature detection services, item tracking services, or other data-collection services).
A system landscape database 806 is included and activated in the FIG. 8 example of the core monitor service 148 (e.g., the core monitor service 148 may be associated with the global monitor service 132 a or the local monitor service 132 b, in which case the system landscape database 806 may represent, include, or otherwise be associated with the global monitor data 136 or the local monitor data 138, respectively). In this case, the query router 804 may attempt to obtain the requested monitor data from the system landscape database 806.
If the desired monitor data, or other desired data, is outdated or not found, the query monitor 806 may query the desired monitor data from a monitor service running on a parent device, e.g., a different device that manages the device that is implementing the core monitor service 148 (for example, the group leader monitor service 132 c may query the local monitor service 132 b, or the local monitor service 132 b may query the global monitor service 132 a). In another situation, the current monitor service 148 may manage the queried system (i.e., is a parent to the queried system), in which case a lower level monitor service will be addressed to collect the desired monitor data. In yet another scenario, the queried device may be unknown to the core monitor service 148 of FIG. 8, in which case the query may be forwarded to the upper layer which manages more systems, and, ultimately, may proceed to the global monitor service 132 a, which may then forward the query to the appropriate local monitor service 132 b.
Query routing may be straightforward if a target system (service or device) may be addressed directly, with no intervening system(s). In cases where there is no direct connection to the target system, then intervening hops on the routing path are determined. Routing information describing such intervening hops may be fetched from stored topology information (which may be stored in the system landscape database 806, or in separate routing tables).
For example, each monitor service 132 b-132 d is provided with a parent monitor service that is assigned during registration of the monitor service (see, e.g., FIGS. 15-17, below). This child-parent information may be stored in the system landscape database 806, and/or in other memory, as a property, from which a tree-shaped topology may be generated. The tree-shaped topology may be traversed to determine the next hop. In other implementations, the next/intervening hop may be obtained from a routing table, using an appropriate table look-up. Generally, such separate routing tables may use more memory than determining the routing information from the tree-shaped topology, but may be more efficient and/or faster.
Entries in the routing tables may be changed only when devices connect or disconnect from the system 100, in order to reduce a number of required changes. To reduce the number of entries in the routing table, a next hop may be added only if the next hop is not the parent monitor service, since, the next hop may be assumed, by default, to be the parent monitor service. In this way, a number of entries in the routing tables may be reduced to the number of systems that are managed/monitored by the monitor service, along with those that are directly connected thereto.
An algorithm for the query routing is illustrated below in Code Section 1, which embodies the query routing guidelines just described.
Code Section 1
Query landscape: get the queried data
If data not found
  if information is requested about the current device
    get system adaptor to service or device
    get information from adaptor
else (information is not about the current device)
  Query landscape: is device managed by this device?
  If device is managed by this device
    get child device to ask
    get data from child device by asking the monitor on lower tier
  else (device is not managed by this device)
    get parent device to ask
    get data from parent device by asking the monitor on higher tier
if data still not found
  return error
else (data found)
  return data
Generally speaking, as already described, Code Section 1 is consistent with a querying algorithm in which a request for monitor data is received at a (current) device. If the monitor data is related to the current device, but not in the system landscape database 806, then the system adaptor 134 may be used to obtain the monitor data, as described herein. Otherwise, if the monitor data is about another service/device, but is not in the system landscape database 806, then a parent or child monitor service may be queried, as appropriate. If the monitor data is found in either the system landscape database 806 or the parent/child monitor service, then the monitor data may be checked to see whether it is up-to-date. If not, then additional polling/queries may be executed to obtain updated monitor data.
The core monitor service 148 also includes a ping requestor 808, which is configured to be used by the global monitor service 132 a and/or the local monitor service 132 b, or any monitor service that stores monitor data in some type of monitor data storage/memory (e.g., the system landscape database 806). The ping requestor 808 may thus be configured to ping devices in the system landscape, thereby to assist in keeping system landscape data of child systems up-to-date, and to detect disconnected devices (and mark the data as ‘in doubt’). If a monitor service does not store status information in a local monitor data storage, e.g., the group leader monitor service 132 c or edge monitor service 132 d, then the ping requestor 808 may be omitted or non-activated.
The ping requestor 808 may be activated by a timer, and, in response, may determine all connected and managed child-systems from the monitoring data storage (e.g., from the system landscape database 806). For example, for all the systems, the ping requestor 808 compares the time when the last life-signal was received to the current time, in order to detect outdated monitor data (or other stored information). If outdated, then a status of the system(s) may be changed to so indicate, e.g., may be changed from “alive” to “outdated.” If the timestamp is older than a certain cut-off point, then the status may be changed from “outdated” to “in-doubt,” so as to indicate the possibility that the device in question is disconnected. For all “outdated” systems, the ping requestor 808 sends a ping-request. The ping requestor 808 receives the ping-response and updates the “last seen” timestamp accordingly, and then changes the relevant status back to “alive” within the system landscape database 806.
An algorithm consistent with the above explanation of the ping requestor 808 is provided below in the context of Code Section 2:
Code Section 2
Landscape query: get all systems and their status
For all systems do
  If the timestamp is old enough to mark the system as “in-doubt”
  then
    Mark all related data as “in doubt”
Else if it is old enough to mark the system as “outdated” then do so
If the status is “outdated” then
  Send a ping signal to this system
Although FIG. 8 is discussed in terms of the ping requestor 808, it should be understood that other techniques may be used for determining a status of elements of the system landscape of the system 100, e.g., other echo requests used to test a reachability of the system(s) and/or to test network delays. Further, it should be understood that the core monitor service 148 also may receive, and thereafter respond to, ping requests from other monitor services, as shown. Actual implementation of a transport protocol that ensures reliable data transfer of the ping (or other) status requests may be implemented as a task of the communication adaptor 602, as discussed in more detail below, with respect to FIG. 12.
The core monitor service 148 also includes a heartbeat transmitter 810, which may be implemented as a service configured to send a heartbeat message to a parent monitor service, so as to indicate that the device (on which the core monitor service 148 is deployed) is still running. The heartbeat transmitter 810 may be triggered by a timer, where the time interval between two messages may be defined in associated heartbeat settings. The interval may be chosen with respect to resource-constraints, so that small devices with limited power supply and network capabilities may use a greater time interval than more powerful devices (e.g., well-connected servers). A metric may be used to define a default interval customized for each device type (e.g., for a sensor device, PDA, or laptop). Additionally, the value of the interval and other associated settings may be adjustable by the user, e.g. a system administrator of the infrastructure of FIG. 4.
In addition to the information that the device in question is alive and connected, the heartbeat sender 810 may be configured to transmit at least some monitoring data, as well, which if received at the core monitor service 148 from another monitor service, may be used to update the system landscape database 806. The heartbeat settings may be used to define which such monitor data should be sent, along with the heartbeat messages. In so doing, an amount of network traffic, power and other resources may be conserved. Moreover, by receiving monitor data in the heartbeat messages, relatively-higher tier monitor services may avoid performing at least some polling of lower-tier services, since the upper-tier services may already have the desired monitor data. The device on which the core monitor service 148 is deployed may include the additional monitor data along with heartbeat messages by executing queries on the monitoring data storage, or by reading system adaptors 134 (see FIGS. 6 and 9-11).
Heartbeat messages do not have to be sent over reliable communication channels, to the extent that the ping requestor 808 may, in response to an expected heartbeat message that does not come through, send an additional request, e.g., if two consecutive pings are missing. Therefore, even if the communication channels are unreliable, and heartbeat messages are lost, the core monitor service 148 may continue to function. Accordingly, protocols such as, for example, the lightweight and connection-less User Datagram Protocol (UDP) may be used.
An algorithm consistent with the above explanation of the heartbeat transmitter 810 is provided below in the context of Code Section 3:
Code Section 3
Read heartbeat settings
If time interval has changed then
  Update timer component
Get all data that should be included in the heartbeat message
Send heartbeat message to parent with all queried data
Sleep according to heartbeat settings
The ping requestor 808 may be understood as an addition to the heartbeat transmitter 810. For example, as referenced above, in the event of some consecutively lost heartbeat messages, the ping requestor 808 may build up a reliable connection to make sure that the ping is received and processed. Further, if a child device does not have a (functional) heartbeat transmitter 810, then the parent monitor's ping requestor 808 may replace the heartbeat transmitter 810 completely. As a result, the child system does not have to have a heartbeat transmitter installed, so fewer hardware capabilities may be used.
The core monitor service 148 also includes an update notification transmitter 812, which may be configured to provide services with updates about the system landscape, such as, for example, changes in monitor data, or registration of new devices, as may be determined, e.g., from the system landscape database 806. The update notification transmitter 812 thus may emit notification messages to all registered recipients, as stored in a recipient registry 814.
Services registered with the update notification transmitter 812 may precisely specify desired data, so as to obtain only the desired data (and minimize other transmissions). Constraints for what (types of) monitor data updates are transmitted may be based, for example, on the following properties: a name of the data-providing service, or device and name of the data-field (e.g., alive-status, CPU usage, RAM size, or connectivity values. Accordingly, subscription rules for receiving the updates may be stored with the following information: an identifier of the recipient system, and a constraining rule (e.g., a source-system identifier and/or a data-field name). In some implementations, the two restraining conditions may be connected with an AND, so that, for example, both the name of the system AND of the data field must match for an update to be sent. In other implementations, an OR rule may be realized by defining more than one subscription rule.
An algorithm consistent with the above explanation of the update notification transmitter 812 is provided below in the context of Code Section 4:
Code Section 4
Query recipient database: get all recipients that are registered for this
  service or device and data field
For all found recipients do
  Send update trigger message
FIG. 9 is a block diagram illustrating a system adaptor manager 902 for use with the modular monitor service 600 of FIG. 6 and/or the implementation of the core monitor service 148 illustrated in FIG. 8. Specifically, the system adaptor manager 902 may be used to manage the system adaptor(s) 134. As referenced above, the system adaptors 134 may be configured to provide connections between the core monitor service 148 and the various services and devices (e.g., the service 122 and/or the device 108) that are supplying monitor data. It should be understood that the services, devices, and, therefore, monitor data may vary quite dramatically, due to the potential for heterogeneity in the system landscape. Accordingly, the system adaptors 134 may implement a common interface for communicating with the core monitor service 148, while implementing whatever other interfaces are necessary for monitoring (and, potentially, controlling) the various heterogeneous services and/or devices that may be present, so that the core monitor service 148 need be aware of only this common interface in order to communicate with a large number of types of the system adaptors 134 (and, thereby, a large number of types of services and devices).
Since the core monitor service 148 may be capable of communicating with a large number of the system adaptors 134 (using just the common interface), the core monitor service 148 either does not or cannot determine which of the system adaptors 134 is appropriate for a given task. Rather, a system adaptor manager 902 is used in making such a determination of a particular/correct one of the system adaptors 134 for a given task or setting. As such, the system adaptor manager 902 represents an example of the module manager(s) 150, and provides an abstraction layer between the core monitor service 148 and the system adaptor(s) 134. Accordingly, the core monitor service 148 may be relieved of the duty of tracking, selecting, or otherwise managing the various instances or possibilities of the system adaptors 134, much less of the services or devices themselves.
As referenced above, the system adaptor(s) 134 may include, for example, a service adaptor and/or a device adaptor (see, e.g., FIG. 10), so that communication between the core monitor service 148 (or other monitor service modules 150) and a given service (e.g., the service 122) or device (e.g., the device 108) may be executed, and corresponding monitor data may be obtained. For example, the system adaptors 134 may be considered to be a part of the modular monitor service 600 that provides an interface to the environment (e.g., to the service 122 and/or the device 108). In the case of the device 108, a given one of the system adaptors 134 may determine, for example, a CPU utilization, memory usage, or memory size of the device. In the case of the service 122, a given one of the system adaptors 134 may determine, for example, a software version or software vendor associated with the service 122.
Accordingly, it should be understood that there may be no defined standard interface to the environment (e.g., to various services/devices), since each such service and device may have its own specific interface(s). Rather, the system adaptors 134 may be designed and implemented to fit to the monitored system(s) in question (e.g., the system 100). As such, the monitoring service(s) 132 a-132 d may read information about devices and services, whose different interfaces are hidden to the core monitor service 148 by the system adaptors 134 and the system adaptor manager 902, so that the latter components provide an abstraction layer for use of the core monitor service 148.
The various types and instances of system adaptors 134 may be stored (or referenced) in an adaptor registry 904, so that the system adaptor manager 902 may determine (e.g., based on a request of the core monitor service 148, or based on a design choice of an administrator) which system adaptor 134 to use in a given situation.
The system adaptor manager 902 may thus be configured to load and manage a variety of system adaptors 134 that implement a common interface. On start-up, the system adaptors 134 may register at the adaptor manager 902. The system adaptor manager 902 may execute a maintenance function of all registered adaptors 134, where a maintenance function of the system adaptor 134 may implement internal management activity, in addition to reading and returning monitor data (e.g., information about currently-running services, device-specific information, or sensor data collected by the device on which the modular monitor service 600 is running).
In the example of FIG. 9, the system adaptors 134 include a basic information adaptor 906 and an OSGi adaptor 908. The basic information adaptor 906 refers generally to service and/or device information that may be collected and used, e.g., in the system 100, such as the many and various examples of device metadata 130 provided above. The OSGi adaptor 908 generally refers to the fact that the system adaptors 134 may support such standardized protocols as OSGi to get information about devices that do not have one of the monitor services 132 a-132 d installed. Other examples for such protocol standards include the Java API platform JSR232 (which includes OSGi), as well as Java APIs for Bluetooth, JSR82.
FIG. 10 is a block diagram of an example implementation of the system adaptors of FIGS. 1, 6, and 9. In the example of FIG. 10, an upper-tier (e.g., global or local layer) device 144, 146 is shown, which may include, for example, a personal computer or server computer. The device(s) 144, 146 include a core monitor service 148 a and/or 148 b, along with two system adaptors: a service adaptor 1002 (for interfacing with a plurality of services 1004) and a device adaptor 1006 (for interfacing with a plurality of instances/types of device hardware 1008). As shown, the core monitor service 148 a, 148 b also may communicate with pre-registered devices 1010, which may be configured to interface directly with the core monitor service 148.
Further in FIG. 10, a lower-tier (e.g., group leader or edge) device 108, 110, 112, and/or 114 may represent a relatively more resource-poor device, and may include the core monitor service(s) 148 c, 148 d. Similarly to the devices 144, 146, the devices 108, 110, 112, 114 include a service adaptor 1012 (for interfacing with a plurality of services 1014) and a device adaptor 1016 (for interfacing with a plurality of instances/types of device hardware 1018). The devices 108, 110, 112, 114 also include a separate device adaptor(s) 1020 that may be used to communicate with devices, e.g., a device 1024, that implements such standards 1022. For example, the device 1024 may represent a sensor mote or cell phone that is running the management standard 1022 (e.g., OSGi), so that the core monitor service 148 may communicate therewith using the standard 1022.
FIG. 11 is a block diagram of another example implementation of the system adaptors of FIGS. 1, 6, and 9. In the example of FIG. 11, the system adaptor(s) 134 is illustrated as communicating with the core monitor service 148. As described above, the system adaptor(s) 134 may communicate with the core monitor service 148 using an API 1102 of the core monitor service 148 that is common to all of the system adaptor(s) 134. The system adaptor(s) 134 also communicate with a service and/or device 1104 using an API 1106, which is specific to the service/device 1104 and to the specific, associated instance of the system adaptor 134 in FIG. 11.
In FIG. 11, the system adaptor 134 includes a notification system 1108 that is configured to receive notifications from the core monitor service 148 (e.g., from the update notification transmitter 812 of FIG. 8). For example, as explained above in the context of FIG. 8, the core monitor service 148 may send updates regarding changes in monitor data, or registration of new services or new devices. The notification system 1108 (which may thus be understood to be included in the recipient registry 814) may subscribe to particular notifications, or types of notifications, and so may receive notifications on a periodic or scheduled interval.
The notification system 1008 also may receive notifications from other services, such as, for example, a business logic rule engine service 1110 (which implement business logic and may trigger reactions to certain real-world events), or a logger or watchdog service (not shown in FIG. 11). The notifications may be forwarded or handled, depending on the implementation of the system adaptor 134, and the system adaptor 134 defines and implements an appropriate reaction to each possible notification.
The system adaptor 134 also includes a system reader 1112 that is configured to read monitor data from the service/device 1104, such as, for example, CPU utilization, battery lifetime, or status of the service (e.g., whether a service is running, or stopped). The system reader 1112 may then provide the monitor data to the core monitor service 148 that is polling the system adaptor 134.
in these and other implementations, the system reader 1112 may provide the monitor data to a heartbeat transmitter 1114. The heartbeat transmitter 1114, generally speaking, is configured to periodically send a life-signal to the core monitor service 148. As just referenced, and as referenced above with respect to FIG. 8, the heartbeat transmitter 1014 also may receive and transmit monitor data from the service/device 1104 (e.g., status values), which allows for a reduction in messaging overhead. As described with respect to FIG. 8, heartbeat settings 1116 may include parameters associated with the heartbeat transmitter 1114, such as, for example, a time interval between heartbeat messages.
Finally in FIG. 11, an initializer 1118 is configured to set up the heartbeat settings 1116, and register the monitor data at the monitor data storage (e.g., the system landscape database 806 of FIG. 8). The initializer 1118 also may be configured to register with the recipient registry 814 for update notification messages at the update notification transmitter 812.
In the examples described herein, processing threads may be used for various tasks, including monitor service maintenance threads, or adaptor threads. Such threads (for, e.g., context switching, thread scheduling, or inter-thread communication) may be created and managed, as needed. The monitor service thread may be used to keep monitor data, as stored in system landscape databases 806 and/or the global/local monitor data 136/138, up-to-date, and may further be used to manage a status of lower-tier services and devices.
System adaptor threads may be implemented separately from the monitor service maintenance thread, so that system adaptors 134 do not block the monitor service maintenance thread by performing complex or time-intensive tasks. The system adaptors 134 may run as separate threads, or may be executed by a thread of an associated monitor maintenance service. In the latter case, the monitor service maintenance thread may be blocked for the time of executing a maintenance function of the system adaptors 134. The system adaptors 134, which may be called by the monitor service, still can create temporary threads that do time-consuming work in the background, so the monitor service thread is not blocked.
System adaptors that use their own threads may generally be more powerful. Also, such system adaptors do not block the monitor service, and so may perform time-consuming tasks, and/or wait for I/O interrupts. Additionally, such system adaptors have more freedom in deciding when to be activated. Thus, such system adaptors are not dependent on calls by the monitor service at an undefined point in time. Timers can be used to actively send heartbeats messages and to update landscape values.
Nonetheless, for limited devices, it may be more appropriate to implement the system adaptors as passive components that use the monitor service thread. In such cases, an overhead of creating and managing threads may be avoided, at a cost of blocking the monitor service while executing the system adaptor in question.
FIG. 12 is a block diagram of an example implementation of the communication adaptor 602 of the modular monitor service 600 of FIG. 6. As shown, a communication adaptor manager 802 a, 802 b may act as the communication abstraction layer of FIG. 8 that communicates with the core monitor service 148. The communication adaptor manager 802 a, 802 b, analogously to the system adaptor manager 902, manages and communicates with a communication adaptor 1202 for devices (so as to communicate with device(s) 1204), as well as with a communication adaptor 1206 (so as to communicate with the service(s) 1208). As should also be understood from the above description of the system adaptor manager 902, the communication adaptor manager 802 a, 802 b (communication abstraction layer) may be configured to load/unload the communication adaptors 1202, 1206, and to register (or de-register) the communication adaptors 1202, 1206.
FIG. 13 is a block diagram of another example implementation of the communication adaptor(s) 602 of FIG. 6. In FIG. 13 (as in FIG. 12), the communication adaptor manager (abstraction layer) 802 a, 802 b may support both local method calls and network communication. Furthermore, the communication adaptor manager (abstraction layer) 802 a, 802 b may operate to make communication protocols and network devices opaque to the core monitor service 148.
For example, message handling and socket communication may be used for network communication. Further, local communication may be realized using messages, APIs, sockets, pipes, and/or shared memory.
Thus, the communication adaptor manager 802 a, 802 b (communication abstraction layer) hides currently-used protocols (e.g., Transfer Control Protocol (TCP), Uniform Datagram Protocol (UDP), Internet Protocol (IP), Hyper Text Transfer Protocol (HTTP), or File Transfer Protocol (FTP), which may work on different ISO/OSI layers, and/or which may be combined. The communication adaptor manager 802 a, 802 b (communication abstraction layer) also may hide network devices 1204 (e.g., Bluetooth, modem, or WiFi devices). The communication adaptor manager 802 a, 802 b (communication abstraction layer) also may hide certain communication concepts (e.g., message passing, sockets, shared memory, or API calls).
In other words, as already described with respect to the system adaptor 134, the communication adaptor manager 802 a, 802 b may load or unload, for example, a TCP adaptor 1302, a UDP adaptor 1304, or an API call Adaptor 1306, which may each present a common interface to the core monitor service 148. Thus, by making communication opaque for the core monitor service 148 and other services, the example of FIGS. 12 and 13 may allow avoidance of dealing with protocols, network devices, sequence numbers, or transmission errors.
In FIG. 13, each of the adaptors 1302-1304 is identified as being associated with either network (1302, 1304) or local (1306) communication. Further, each of the adaptors 1302-1304 is identified as being associated with either reliable (1302, 1306) or unreliable (1306) communication. Each of the adaptors 1302-1306 also may be associated with a unique identifier (Adaptor ID), for use by the communication adaptor manager 802 a, 802 b in selecting or loading the respective adaptor.
In general, unreliable data transfer may be much simpler and therefore less resource consuming than reliable transfer. Therefore, unreliable data transfer may be preferred, where possible. Some functionality, however, such as pinging a system, may require reliable data transfer (and corresponding communication adaptor).
So, in general, it should be understood from the example of FIG. 8 that the core monitor service 148 may send and receive different types of messages, and the communication adaptor manager 802 a, 802 b may be used to select a corresponding, appropriate communication adaptor to execute the sending or receiving. For example, the core monitor service 148 may need to send a message over a network, using a lightweight and unreliable transport protocol. In this example, the communication adaptor manager 802 b may locate the UDP adaptor 1304, among all loaded adaptors, which implements an unreliable network communication. The communication adaptor manager 802 b then forwards the message to the UDP adaptor 1304, which performs the actual communication.
FIG. 14 is a block diagram of an example implementation of the preprocessor module 606 of FIG. 6. For example, the preprocessor module 606 may be used by one or more of the various monitor services 132 b-132 d to process monitor data locally before forwarding the processed monitor data to the next higher tier of the architecture of the system 100 of FIG. 1.
In FIG. 14, a preprocessor manager 1402 is configured to operate similarly or analogously to the adaptor managers 802 a/802 b and 902, described above. For example, the preprocessor manager 1402 may interface with a preprocessor registry 1404 to determine an appropriate one of the possible preprocessor modules 606, for use with the core monitor service 148. As shown, the preprocessor manager 1402 may be configured to receive incoming monitor data, such as from a local service or device, and perhaps by way of the core monitor service 148 and appropriate system adaptor 902 and/or communication adaptor 802 b. After preprocessing by the preprocessor module(s) 606, the preprocessor manager 1402 may output the preprocessed monitor data, e.g., back to the core monitor service 148 for transmission to the next-higher tier of the system monitor architecture.
For example, the preprocessor module(s) 606 may include a filter 1406, an aggregator 1408, and an update notification transmitter 1410. For example, the filter 1406 may be configured to remove certain types of monitor data, or certain amounts. The aggregator 1408 may be configured to combine received messages for transmission of a combined message. For example, the group leader monitor service 132 c may receive a message from each edge device 110-114 for aggregation thereof, or may receive a series of message from a single edge device (e.g., the edge device 110).
The update notification transmitter 1410, as described above, may be configured to provide updates, similarly to the update notification transmitter 812. In the example of FIG. 14, the update notification transmitter 1410 communicates updates to a GUI 1412, for viewing, e.g., by a system administrator. Of course, the example of the GUI 1412 may be most appropriate at higher-level tiers of the monitoring architecture. Further, in addition to aggregation and filtering, logging, computation of statistics, and other data preprocessors may be used for monitoring data.
For example, the system adaptor 134 may deliver the CPU utilization every second, with a requirement that the average utilization over the last two minutes be determined. To support scalability, the monitored data values may be preprocessed near to the measuring system adaptor. In this way, communication resources are conserved, since the need to send each data value (once a second) to the upper tier(s) may be avoided. Instead, e.g., on demand, only the aggregated value may be sent.
In operation, different ones of the preprocessor modules may register at the core monitor service 148. As monitor data (e.g., status values) come in, each of the registered preprocessors is executed. For example, a first preprocessing module may receive the raw monitor data as a parameter(s), and may return a preprocessed data set. Subsequently, the next preprocessor is started, and received the preprocessed output data from the first preprocessor. Accordingly, each preprocessor may be executed, working on the output data of its predecessor.
In such examples, when using such a sequential execution of modules (e.g., plug-ins), it may be necessary to order execution of the plug-ins appropriately. For example, two modules may register with the core monitor service 148 and/or the preprocessor manager 1402. In this example, the first module may delete all data of a specific service or device, while the second module may compute the average CPU utilization over all monitored devices. Clearly, the result is different if the order of the two modules changes, because then all monitored services and devices are taken into account, including the specific service or device to be deleted.
Accordingly, the preprocessor manager 1402 may, e.g., during registration, set the appropriate execution order. To the extent that a number and type of preprocessor modules 606 may be unknown at design-time, it may be difficult to assign an absolute execution order, particularly when the preprocessor modules may be loaded dynamically at runtime. Consequently, one option is to create groups of the preprocessor modules 606, so as to order the preprocessor modules 606 according to group. Each preprocessor module 606 may be associated with a group identifier, so as to be put into the correct group during registration. Then, the groups may be executed in order on a group-level, if not at the level of individual preprocessor modules. Groups may be ordered based on, for example, a priority and/or type of pre-processing performed. For example, a first group may include preprocessor modules that must work on raw data, while a second group may work on already-preprocessed data, and a third group may process final data. Thus, a modular or plug-in concept for the preprocessing modules 606 (e.g., 1406-1410) may increase a scalability of the system 100 of FIG. 1, and may address resource-constraint issues. For example, scalability may be increased by relieving the global monitor service 132 a and the local monitor service 132 b from some or all preprocessing tasks. Furthermore, the modular architecture allows the monitor service 132 a-132 b configurable to the needs and capabilities of each device.
Other types of monitor service modules 150 may be implemented. For example, as shown in FIG. 6, a data storage module 604 may be used. For example, depending on capabilities of a device on which the global monitor service 132 a and the local monitor service 132 b are installed, a different technology for storing monitor data in the global monitor data 138 may be chosen than is chosen for storing monitor data in the local monitor data 136, e.g., either may store data in one or more of a database, a text file, an in memory data-structure, or virtually any other kind of data storage. Use of the data storage module 604 may make such differences opaque to the monitoring service in question, using the various techniques described above with respect to FIGS. 6-14. For example, the monitor data storage may be encapsulated by a well-defined interface, and the interface may serve as an abstraction layer from the actual data storage system.
FIG. 15 is a block diagram of a system 1500 illustrating a registration protocol for use with the system 100 of FIG. 1. In FIG. 15, a group leader device 1502, which may be a portable device (e.g., a PDA or laptop), enters into an area of a group leader device 1504. As shown, the group leader device 1504 is a group leader of a plurality of edge devices 1506 a, 1506 b, 1506 c of a sensor network. Thus, for example, the group leader device 1504 and the edge devices 1506 a, 1506 b, 1506 c may be involved in any number of sensor network applications, including, for example, inventory management or hazardous material tracking.
Accordingly, for example, the group leader device 1504 (which may be, for example, the same as the edge devices 1506 a, 1506 b, 1506 c, or which may be a WiFi access point or a base station, as referenced above) may be in the process of collecting information (i.e., monitor data) associated with inventory in a warehouse. For example, such monitor data may include a type and quantity of stocked goods for sale, and/or current temperature information in a vicinity of the stocked goods (e.g., to detect possible spoilage of food products). Thus, the group leader device 1502 may enter the area of the group leader device 1504, such as when an employee enters the area with a PDA or other computing device, and wishes to obtain desired monitor data.
In the above example, and similar examples, the group leader device 1502 may wish to collect the monitor data for local use by the employee, and/or may itself collect/transmit monitor data to a global monitor service 1508. In the latter case, for example, the group leader device 1502 may have certain computing resources or capabilities not available (or, at least, not currently available) in the group leader device 1504. It should be understood that, in the example of FIG. 15, the group leader device 1502 may actually be currently acting as a group leader to a plurality of edge devices (not shown in FIG. 15), or may be referred to as a group leader device in the sense that sufficient computing resources are present to act at the group leader tier of the infrastructure described herein (e.g., to split messages for distribution to edge devices, or to filter/aggregate messages from the edge devices for subsequent transmission). In still other examples, it may be the case that the group leader device 1504 has failed, or is about to fail (e.g., due to low battery power), or is required to re-locate, so that the group leader device 1502 is being re-located for the purpose of assuming the duties of the group leader device 1504.
In the example of FIG. 15, the global monitor service 1508 includes global monitor data 1510, and operates on a device 1512 (which may include, as described herein, a PC or similarly-powerful computer). The global monitor data 1510, as already described, may include global landscape data related to the system 1500 as a whole, including other elements not shown in FIG. 15. For example, the global monitor data 1510 may include device metadata describing the group leader 1504 and the edge devices 1506 a, 1506 b, 1506 c (including, for example, both static and dynamic device capabilities).
Moreover, the global monitor service 1508 may include device metadata related to the group leader device 1502. For example, the group leader device 1502 may previously have been registered with the global monitor service 1508 as part of a separate network(s) (not shown in FIG. 15). As the employee operating the group leader device 1502 re-locates from the separate network to the area of the devices shown in FIG. 15, the group leader device 1502 may disconnect as part of the separate network (and be marked as such within the global monitor data 1510, as already described), although information regarding the group leader device may be maintained in the global monitor data 1510 for some period of time.
The system 1500 further includes a local monitor service 1514, with local monitor data 1516 and running on a device 1518. The device 1518 may include, for example, a laptop computer or a Stargate computer, as described. Further, the system 1500 may include a local monitor service 1520, with local monitor data 1522 and running on a device 1524.
In the example of FIG. 15, then, the group leader device 1502 may need to register with the global monitor service 1508 in order, for example, to establish a connection 1526 with the group leader 1504. For example, it may be the case that the group leader device 1502 and the group leader device 1504 may have overlapping abilities to communicate with one another; e.g., both may have Bluetooth capabilities. Even so, the group leader device 1502 may be unaware that the group leader device 1504 has Bluetooth capabilities, and, moreover, the group leader device 1502 may have no local communication service (e.g., adaptor/module) that is compatible both with Bluetooth and with whatever service(s) are being run on the group leader device 1504 (e.g., the temperature reporting service referenced above).
In contrast, however, the global monitor service 1508 may be well aware of all such information, as stored within the global monitor data 1510 (e.g., appropriate service metadata and/or device metadata). Of course, information regarding the group leader device 1504 also may be stored in the local monitor data 1516, as should be understood from the description above. Thus, the global monitor service 1508 is (indirectly) capable of establishing the connection 1526, since, for example, the global monitor service 1508 may be able to determine which communications services (adaptors/modules) are needed, and may then download and/or inject such a service(s) onto the group leader device 1502. The global monitor service 1510 also may communicate with the group leader device 1504, in order to ensure (by injecting, if necessary) that the group leader device 1504 not only has Bluetooth (or other communication protocols/standards), but also has a local service that is compatible both with Bluetooth and with a corresponding service on the group leader device 1502.
In this way, the connection 1526 may be established. In analogous situations, the group leader 1502 may otherwise communicate with other devices/services of the system 1500. Thus, registration of the group leader device 1502 within the system 1500 may provide a number of advantages, for example, to a user of the group leader device 1502.
Such registration, however, may be associated with a number of difficulties. For example, such registration may represent a security issue, since unregistered and possibly malicious devices should not generally be monitored and integrated into the system 1500. Also, frequent exchanges of registration messages may consume valuable bandwidth, battery power, or other communications resources. If devices are not registered, though, then such devices may be un-identified and un-accessed by the rest of the system 1500.
Thus, the following description, along with FIGS. 15-17, provide examples of how the group leader device 1502 may register with the global monitor service 1508. Of course, it should be understood that this is but one example, and many other examples may be used to implement the described registration protocol, or variations of the described registration protocol, as would be apparent.
In FIG. 15, then, it is assumed for the example that the group leader device 1502 has a monitor service installed thereon (although not shown in FIG. 15). Such a monitor service may include the various implementations described herein, including the modular monitor service of FIG. 6, or may include a non-modular, e.g., integrated, monitor service. The group leader device 1502 and its installed monitor service thus attempt to join the network(s) of the system 1500, including registering at the global monitor service 1508.
The group leader device 1502 includes a registration system 1528 and registration data 1530. The registration system 1528 is configured to exchange registration messages 1532, 1534, 1536, and 1538 with one or more of the local monitor services 1514, 1520 (and/or with the global monitor service 1508). The registration data includes information about the connecting monitor service of the group leader device 1502, such as, for example, metadata related to a current status of the group leader device 1502, or device metadata related to the group leader device 1502. The registration data also may include initial sensor status/values information (e.g., to avoid overhead caused by an initial polling for such values, which would take place right after registration, since data is outdated or not existent. In cases where an excessive amount of values would be included in the registration data, then at least static data values may be sent).
Although registration data 1530 is illustrated conceptually as/in a memory in FIG. 15, it should be understood that the registration data 1530 may simply represent values collected by the group leader device 1502 (e.g., by the registration system 1528 and/or by a monitor service of the group leader device), either during or before registration takes place. Of course, the group leader device 1502 may have a memory in some example implementations. Moreover, in cases where a local monitor service attempts to register with a new network, then it should be understood from the above description that a local memory (e.g., the local monitor data 1516, 1522) may be used. More generally, it should be understood that the registration system 1528 and registration data 1530, or variations thereof, may be implemented within other ones of the devices and monitor services of FIG. 15.
The described registration protocol may be implemented as a simple, e.g., connectionless, protocol, that is robust. Additionally, the registration protocol is configured to support both active registration (e.g., initiated by a connecting device) and passive registration (e.g., initiated by a connected network device). Consequently, as described, the registration process may be started by either device.
In FIG. 15, then, the group leader device 1502, as an unregistered-but-now registering device sends out a solicitation message 1532. The solicitation message 1532, which may be sent as a broadcast message, may contain a request for, or identification of, a specific type of same or next-higher level monitor service, and the request may be based in part on device capabilities of the connecting device. For example, if the (registering) group leader device 1502 has certain capabilities (e.g., is a mobile phone), then it may try to locate other group leader devices (e.g., the group leader device 1504, i.e., a monitor service thereof) and/or local monitor services (e.g., 1514, 1520), rather than the global monitor service 1508.
If no suitable instance of the preferred monitor service type is found, then the registration system 1528 may re-send the solicitation message 1532 with an identification of a next-higher level (going up from lower to higher level monitor services). Further, if the solicitation message 1532 is lost, then the registration system 1528 may simply send another solicitation message, e.g., after a timeout. Solicitation messages that are received twice are not an issue, since this is the initial step of the protocol. Therefore, a lightweight and connectionless transportation protocol, e.g., UDP, may be sufficient.
Accordingly, the solicitation message 1532 may be sent out periodically if no answer is received. After some repetitions, the group leader (i.e., registering, or connecting) device assumes that there is no monitor service, and stops sending messages for at least a specified time interval, which saves power and computation time.
Meanwhile, already-connected and registered services of the system 1500 (e.g., the local monitor service 1520) may send out an advertisement message 1534. The advertisement message 1534 may be sent, for example, either in response to a timer or to the solicitation message 1532. The advertisement message 1534 may include an identification of a type of monitor service that is sending the advertisement message 1534 (e.g., the local monitor service 1520 in the example of FIG. 15). By receipt of the advertisement message 1534, other monitor services in the network become aware that there is a monitor service of a designated type that is currently accepting child monitor services, and become aware of how to communicate with this available monitor service. The advertisement message 1534 may be sent as a broadcast message, and may be sent by any or all of the devices described herein (except, generally, the various edge devices, to the extent that the edge devices do not typically have any child monitor services connected thereto).
The advertisement message 1534 provides a fail-safe mechanism in case the solicitation message 1534 is lost, and also may act as an initiator of the registration process, e.g., for devices that do not send solicitation messages. For example, the group leader device 1502 may, as referenced above, stop sending solicitations after a specified time period, or if devices cannot detect network changes. Using the advertisement message 1530, such devices may be “reactivated.” Also, lost advertisement message are not disruptive, in that they may be resent from time to time.
A connecting/registering device, such as the group leader device 1502, may respond to the advertisement message 1534 once by sending a registration message 1536. As referenced above, the registration message 1536 may contain, for example, information about monitored data, landscape metadata, device metadata, and/or actual monitored (e.g., sensor) values.
Once the registration message 1536 is successfully received at the sender of the advertisement message 1534 (i.e., the local monitor service 1520), registration data may be saved in all devices on the path from the receiving, parent monitor to the global monitor service 1508 (e.g., in the example of FIG. 15, may be stored at the device 1524 and 1512, as well as at any intervening devices). In other words, the registration message 1536 is forwarded to the upper layer monitor services.
Outdated data within the memories (e.g., 1510, 1522) of the upper layer monitor service may be marked as “in doubt,” and/or may be deleted to avoid inconsistencies. For example, the global monitor data 1510 may have information from a previous registration event that the group leader device 1502 is currently connected to another network (not shown in FIG. 15). As the group leader device 1502 is moved away from devices of the former network, however, the former connection is lost, so that data within the global monitor data 1510 becomes outdated. Once the group leader device 1502 registers again through the local monitor service 1520, as shown in FIG. 15, then a current registration status, location, and other information/data within the global monitor data 1510 may be updated accordingly.
The registration system 1536 may ensure that duplicates of the registration message 1536 are not problematic, by allowing only one message-triggered registration message 1536 during a registration process. That is, the registration system 1536 may be configured to ignore any additional advertisement message(s) 1534, once the registration message 1536 is sent.
The registration message 1536 then obtains a confirmation message 1538 to ensure that the registration was processed successfully. If no confirmation has arrived after a pre-determined time, the registration message 1536 may be resent. Duplicate registration messages are no problem in such implementations, because one registration may be allowed to override another registration without causing any harm. Additionally, or alternatively, duplicated registration messages may simply be ignored if the relevant service or device is already registered.
The confirmation message 1538 may be sent by the managing monitor service (e.g., the local monitor service 1520). The registration process finishes when the registering device (the group leader device 1502) receives the confirmation message 1538 (if the confirmation message 1538 is not received, e.g., is lost, then the group leader device 1502 may simply re-send the registration message 1536). The now-registered monitor service of the group leader device 1502 may then begin its assigned monitoring tasks. Thus, the registration protocol of FIG. 15 allows for connectionless and unreliable data transfer, so that simple and robust protocols, e.g., UDP, may be used.
FIG. 16 is a sequence diagram illustrating an example implementation of the registration protocol of FIG. 15. In the example of FIG. 16, various exceptions occur, in order to illustrate the robust nature of the protocol.
In particular, a solicitation message is sent from the group leader device 1502 (e.g., from a group leader monitor service installed thereon) to the local monitor service 1520, but is not received (1602). That is, the solicitation message includes an identification that it is a local monitor service that is desired as a parent device, but no such potential parent device receives or responds to the message.
After a designated time, a second solicitation message(s) is/are sent (1604), which is received at both the local monitor service 1520 and the global monitor service 1508. As described above, the registration system 1528 may determine that because the sending of the first solicitation message (1602) was unsuccessful, it may be necessary to send a second solicitation message.
In this case, both the local monitor service 1520 and the global monitor service 1508 receive the solicitation message (1604). However, the global monitor service 1508 simply ignores (1606) the solicitation, since the solicitation specifies the local monitor service 1520.
Then, the local monitor service 1520 sends out an advertisement message (1608 a and 1608 b). The advertisement message may be sent (1608 a) in response to the sending of the solicitation message(s) (1604), or may be sent based on a timer value. The sending of the additional advertisement message (1608 b) as part of a broadcast thus arrives at the global monitor service 1508, but is ignored (1610).
The group leader device 1502 then sends a registration message (1612), causing the local monitor service to register associated metadata (1614). At this point, although not shown, the registered metadata may be forwarded to the global monitor service 1508 (e.g., using delta synchronization). Then, a confirmation message may be sent, but, in the example of FIG. 16, is not received at the registration system 1528 (1616). Accordingly, the registration system 1528 of the group leader device 1502 simply resends the registration message (1618), which is then received again at the local monitor service 1520, and either re-registered (1620) or ignored. A confirmation message is sent again, and this time is received at the group leader device 1502 (1622), thus ending the registration process.
FIG. 17 is a flowchart 1700 illustrating example operations of the system 1500 of FIG. 15. In the example of FIG. 17, a connecting monitor service (e.g., a monitor service of the group leader device 1502, which may include or be associated with the registration system 1528) broadcasts a solicitation message (e.g., the solicitation message 1532), including an identification of a desired parent service from within the hierarchical monitor architecture of the system 1500 (1702).
If the solicitation message 1532 is not received at the parent service (e.g., at the local monitor service 1520) (1704), then the parent monitor service may continue waiting for a pre-defined timer (1706). Thus, if the timer is reached, or if the solicitation message is received at the parent monitor service, then the parent monitor service may receive the resulting advertisement message, e.g., the advertisement message 1534 (1708). As should be understood, then, the advertisement message 1534 may be sent whether the solicitation message 1532 is received or not, thus increasing the likelihood of connection/registration of the connecting device.
If the advertisement message 1534 is not received at the connecting device (1710), then the connecting device may re-send the solicitation message 1532 (1712), perhaps identifying a next-higher level of the hierarchical monitor architecture as the desired parent service (e.g., the global monitor service 1508 instead of the local monitor service 1520, 1514). In this case, as long as a time-out is not reached (1714), then the process may continue until a registration and/or advertisement message(s) are exchanged. Otherwise, the process is stopped (1716). In this regard, it should be understood that the time-out condition may refer literally to a period of time that has passed, or may refer to the sending of a pre-defined number of (a certain type of) message(s).
It should be understood, of course, that the advertisement message may be resent (1708), according to its associated timer (1706), even if the process was previously stopped or failed. Moreover, virtually any “stop” condition in FIG. 17, including the stop condition (1716), may be temporary, and the process may continue after some further-defined period is reached.
If the advertisement message is received (1710), then the connecting device may send a registration message, e.g., the registration message 1536, to the parent monitor service identified in the advertisement message (1718). If the registration message is not received (1720), and a timer is not reached (1722), then the connecting device may re-send the registration message (1718). As described, the registration message may include monitor data, so that, if the registration message is received (1720), the registration message may be propagated up the hierarchy (1726), e.g., to the global monitor service 1508. In this case, the monitor data, including metadata about the connecting device and actual sensor values may be saved at some or all of the intervening devices (1728), e.g., the local monitor service 1520. By propagating the registration/monitor data in this way, the global monitor service 1508 may keep track of the existence of the connecting service/device, and may delete eventual left-over data marked as “in doubt” that may otherwise cause inconsistencies (e.g., the same device registered in different networks simultaneously).
Then, the parent monitor service may send a confirmation message (1730), e.g., the confirmation message 1538. If the confirmation message is not received (1732), and a time-out has not been reached (1734), then the registration message may be re-sent (1718), and the above-described process may be repeated, in whole or in part. If the time-out is exceeded (1734), or if the confirmation message is received, then the registration process ends, as well (1724).
The just-described registration protocol(s) may be implemented when the connecting device (e.g., the group leader device 1502) already has a monitor service installed thereon. As described above with respect to FIG. 7B, however, if the connecting device does not have a monitor service installed thereon, then a pre-registration process may be conducted in which, as described above, a boot-strapping technique may be used in which the core monitor service 148 is installed, and then is used to execute the remaining registration processes of FIGS. 15-17.
As just described, a robust and reliable registration protocol of FIGS. 15-17 allows for the use of unreliable/connectionless communications protocols, while minimizing an amount of network bandwidth required for the registration process. For example, network bandwidth may be conserved by stopping re-sending of one or more of the messages after a certain period of time. In this case(s), each time the registration protocol requires resending messages after timeouts, there is a possibility that either the connecting device or parent service may have lost a connection, and this possibility may lead to a “stuck” state for some or all of the system 1500. To avoid this state, and as referenced above, each re-sent message may be re-sent for a limited number of times only, and, if no successful registration is achieved the entire registration process may restart.
It should be understood that the above description is merely intended to provide examples of a hierarchical layering of a monitor architecture, and that greater or fewer layers of such a hierarchy may be used. By implementing such hierarchically-layered architectures, e.g., as described in more detail above, various features and advantages may be obtained. For example, as referenced above, the system(s) described herein 100 may easily be scaled up to include a large number of smart item devices, while still being able to perform efficient monitoring of services and/or devices.
Implementations of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Implementations may implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program, such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
Method steps may be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Method steps also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer also may include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in special purpose logic circuitry.
To provide for interaction with a user, implementations may be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.
While certain features of the described implementations have been illustrated as described herein, many modifications, substitutions, changes and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the embodiments of the invention.

Claims (17)

1. A method comprising:
transmitting, from a registering monitor service at a first tier of a hierarchical, multi-tier monitoring architecture for a plurality of separate device networks, each device network including a plurality of wireless devices in wireless communications with one another and with a group leader device executing a group leader monitor service at another level of the hierarchical, multi-tier monitoring architecture, a broadcast solicitation message identifying both the registering monitor service and a registered monitor service associated with a second tier of the hierarchical, multi-tier monitoring architecture, wherein the second tier is specified relative to a plurality of available tiers of the hierarchical, multi-tier monitoring architecture, wherein each group leader device is in communications with a local monitor device executing a local monitor service at another level of the hierarchical, multi-tier monitoring architecture and each local monitor device is in communications with a global monitor device executing a global monitor service at another level of the hierarchical, multi-tier monitoring architecture;
transmitting, from the registered monitor service, a broadcast advertisement message indicating an identity and availability of the registered monitoring service for registration, the advertisement message including an identification of the registered monitor service at the second tier, wherein the advertising message is sent in response to the solicitation message or independently thereof;
transmitting, from the registering monitor service and in response to the advertisement message, a registration message including registration data associated with the registering monitor service; and
registering the registering monitor service at the second tier within the hierarchical, multi-tier monitoring architecture, based on the registration data, including storing at least a portion of the registration data at each higher tier of the hierarchical, multi-tier monitoring architecture; and
establishing a communications link between the registering monitor service and additional registered monitor services running on devices at the first tier and lower tiers, if any, based on the stored registration data.
2. The method of claim 1 comprising transmitting, from the registered monitor service, a confirmation message confirming registration of the registering monitor service.
3. The method of claim 1 wherein transmitting the solicitation message comprises transmitting the solicitation message to the second tier, after a previous solicitation message identifying an intervening tier from among the plurality of available tiers of the hierarchical, multi-tier monitoring architecture does not result in receiving the advertisement message.
4. The method of claim 1 wherein transmitting the solicitation message comprises broadcasting the solicitation message at a pre-determined time interval.
5. The method of claim 3 wherein transmitting the advertisement message comprises:
ignoring the previous solicitation message for failure to identify the second tier; and
transmitting the advertisement message based on the solicitation message including its identification of the second tier.
6. The method of claim 1 wherein transmitting the advertisement message comprises transmitting the advertisement message based on a pre-determined time interval.
7. The method of claim 1 wherein transmitting the registration message comprises:
including, within the registration data, device metadata within the registration message and associated with a device on which the connecting service is deployed, and/or
including, within the registration data, service metadata within the registration message and associated with a service deployed on the device.
8. The method of claim 1 wherein transmitting the registration message comprises including, within the registration data, sensor values obtained by a sensor associated with the connecting service.
9. The method of claim 1 wherein transmitting the registration message comprises:
re-transmitting the registration message until the confirmation message is received or until a time-out condition is reached.
10. The method of claim 1 wherein transmitting the registration message comprises:
discarding, at the registering monitor services, a further advertisement message received after the registration message is transmitted.
11. The method of claim 1 wherein transmitting the registration message comprises:
storing the registration data using at least one device associated with the registered monitor service.
12. The method of claim 1 comprising:
deploying a core monitor service onto the registering monitor service;
determining device metadata associated with a device on which the registering monitor service is deployed;
deploying at least one monitor service module onto the device, based on the device metadata; and
transmitting the solicitation message, receiving the advertisement message, and/or transmitting the registration message, using the at least one monitor service module.
13. A system comprising:
a registering monitor service at a first tier of a hierarchical, multi-tiered monitoring architecture that is configured to obtain and report monitor data collected by a plurality of separate device networks, each device network including a plurality of wireless devices in wireless communications with one another and with a group leader device executing a group leader monitor service at another level of the hierarchical, multi-tiered monitoring architecture, wherein each group leader device is in communications with a local monitor device executing a local monitor service at another level of the hierarchical, multi-tiered monitoring architecture and each local monitor device is in communications with a global monitor device executing a global monitor service at another level of the hierarchical, multi-tiered monitoring architecture, the registering monitor service comprising:
a registration system configured to broadcast a solicitation message from the registering monitor service, the solicitation message specifying a tier from among a plurality of tiers of the hierarchical, multi-tiered monitoring architecture that are potentially available for registration, a registered monitor service at a higher-level tier of the hierarchical, multi-tiered monitoring architecture, the registration system being further configured to receive an advertisement message that is broadcast from the registered monitor service in response to the solicitation message or independently thereof, determine that the registered monitor service is a member of the specified tier based on the advertisement message, and send a registration message to the registered monitor service, the registration message including registration data associated with the registering monitor service,
wherein at least a portion of the registration data is stored at each higher tier of the hierarchical, multi-tier monitoring architecture, and wherein the monitor service is configured to establish a communications link between the registering monitor service and additional registered monitor services running on devices at the first tier and lower tiers, if any, based on the stored registration data.
14. The system of claim 13 wherein the registration system is configured to receive a confirmation message from the registered monitor service, in response to the registration and confirming that the monitor service is registered with the global monitor service.
15. A method comprising:
receiving a solicitation message broadcast by a registering monitor service at a registered monitor service of a hierarchical, multi-tiered monitor architecture for a plurality of separate device networks, each device network including a plurality of wireless devices in wireless communications with one another and with a group leader device executing a group leader monitor service at another level of the hierarchical, multi-tiered monitor architecture, wherein each group leader device is in communications with a local monitor device executing a local monitor service at another level of the hierarchical, multi-tiered monitor architecture and each local monitor device is in communications with a global monitor device executing a global monitor service at another level of the hierarchical, multi-tiered monitor architecture;
determining that the registering monitor service is not registered through the registered monitor service as a member of the hierarchical, multi-tiered monitor architecture;
determining an identification of a tier from among a plurality of tiers of the hierarchical, multi-tiered monitor architecture that are potentially available for registration, the tier being specified in the solicitation message, the registered monitor service being deployed on the tier;
broadcasting an advertisement message to the registering monitor service, in response to the solicitation message or independently thereof, the advertisement specifying the registered monitor service as being deployed on the tier and available for registration;
receiving a registration message from the registering monitor service in response to the advertisement message, the registration message including registration data associated with the registering monitor service;
registering the registering monitor service within the hierarchical, multi-tiered monitor architecture, based on the registration message, wherein at least a portion of the registration data is stored at each higher tier of the hierarchical, multi-tiered monitor architecture; and
establishing a communications link between the registering monitor service and additional registered monitor services running on devices at the first tier and lower tiers, if any, based on the stored registration data.
16. The method of claim 15 comprising sending a confirmation message to the registering monitor service.
17. The method of claim 15, comprising
receiving a second solicitation message from a second monitor service at the registered monitor service, the second solicitation message identifying a different tier from among the plurality of tiers; and
ignoring the solicitation message, based on the identification of the different tier.
US11/443,549 2006-05-31 2006-05-31 Device registration in a hierarchical monitor service Active 2029-07-07 US8296413B2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US11/443,549 US8296413B2 (en) 2006-05-31 2006-05-31 Device registration in a hierarchical monitor service
EP07010654A EP1862957A1 (en) 2006-05-31 2007-05-30 Device registration in a hierarchical monitor service
CN2007101087233A CN101083587B (en) 2006-05-31 2007-05-31 Device registration in a hierarchical monitor service

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/443,549 US8296413B2 (en) 2006-05-31 2006-05-31 Device registration in a hierarchical monitor service

Publications (2)

Publication Number Publication Date
US20070282988A1 US20070282988A1 (en) 2007-12-06
US8296413B2 true US8296413B2 (en) 2012-10-23

Family

ID=38458189

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/443,549 Active 2029-07-07 US8296413B2 (en) 2006-05-31 2006-05-31 Device registration in a hierarchical monitor service

Country Status (3)

Country Link
US (1) US8296413B2 (en)
EP (1) EP1862957A1 (en)
CN (1) CN101083587B (en)

Cited By (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080235366A1 (en) * 2007-03-21 2008-09-25 Inetco Systems Limited Method and system for monitoring messages passed over a network
US20100161804A1 (en) * 2008-12-18 2010-06-24 Electronics And Telecommunications Research Institute System and method for providing device file using device identifier
US20120150892A1 (en) * 2009-08-18 2012-06-14 Nec Corporation Information processing apparatus, information processing system, information processing method, and information processing program
US20120262292A1 (en) * 2011-04-14 2012-10-18 Martin Moser Portable device inventory tracking
US8522341B2 (en) 2006-03-31 2013-08-27 Sap Ag Active intervention in service-to-device mapping for smart items
US8751644B2 (en) 2006-05-31 2014-06-10 Sap Ag Modular monitor service for smart item monitoring
US8756305B2 (en) 2003-04-23 2014-06-17 Canon Kabushiki Kaisha Information processing apparatus and connection control method for joining a wireless network and searching for a printer having a predetermined function
US8769095B2 (en) * 2006-10-03 2014-07-01 Axeda Acquisition Corp. System and method for dynamically grouping devices based on present device conditions
US8788632B2 (en) 2006-12-26 2014-07-22 Axeda Acquisition Corp. Managing configurations of distributed devices
US8996588B2 (en) 2012-02-02 2015-03-31 Salesforce.Com, Inc. Mechanism for facilitating dynamic management of assets in an on-demand services environment
US9026563B2 (en) 2012-02-02 2015-05-05 Salesforce.Com, Inc. Mechanism for facilitating dynamic social media-based management of assets in an on-demand services environment
US9098312B2 (en) 2011-11-16 2015-08-04 Ptc Inc. Methods for dynamically generating an application interface for a modeled entity and devices thereof
US9158532B2 (en) 2013-03-15 2015-10-13 Ptc Inc. Methods for managing applications using semantic modeling and tagging and devices thereof
US9167371B2 (en) * 2003-04-23 2015-10-20 Canon Kabushiki Kaisha Wireless communication system, and wireless communication device and control method for establishing a connection with another wireless device before an elapsed time period without the intervention of a base station
US9178939B2 (en) 2013-12-23 2015-11-03 International Business Machines Corporation Auto incorporation of new components into a hierarchical network
US9311109B2 (en) 2013-05-29 2016-04-12 Microsoft Technology Licensing, Llc Synchronizing device association data among computing devices
US9350812B2 (en) 2014-03-21 2016-05-24 Ptc Inc. System and method of message routing using name-based identifier in a distributed computing environment
US9348943B2 (en) 2011-11-16 2016-05-24 Ptc Inc. Method for analyzing time series activity streams and devices thereof
US9350791B2 (en) 2014-03-21 2016-05-24 Ptc Inc. System and method of injecting states into message routing in a distributed computing environment
US9405932B2 (en) 2013-05-24 2016-08-02 Microsoft Technology Licensing, Llc User centric data maintenance
US9462085B2 (en) 2014-03-21 2016-10-04 Ptc Inc. Chunk-based communication of binary dynamic rest messages
US9467533B2 (en) 2014-03-21 2016-10-11 Ptc Inc. System and method for developing real-time web-service objects
US9560170B2 (en) 2014-03-21 2017-01-31 Ptc Inc. System and method of abstracting communication protocol using self-describing messages
US9576046B2 (en) 2011-11-16 2017-02-21 Ptc Inc. Methods for integrating semantic search, query, and analysis across heterogeneous data types and devices thereof
US9699040B2 (en) 2014-09-30 2017-07-04 Vivint, Inc. Systems and methods for monitoring globally distributed remote storage devices
US9762637B2 (en) 2014-03-21 2017-09-12 Ptc Inc. System and method of using binary dynamic rest messages
US9961058B2 (en) 2014-03-21 2018-05-01 Ptc Inc. System and method of message routing via connection servers in a distributed computing environment
US10025942B2 (en) 2014-03-21 2018-07-17 Ptc Inc. System and method of establishing permission for multi-tenancy storage using organization matrices
US10313410B2 (en) 2014-03-21 2019-06-04 Ptc Inc. Systems and methods using binary dynamic rest messages
US10338896B2 (en) 2014-03-21 2019-07-02 Ptc Inc. Systems and methods for developing and using real-time data applications
US10447705B2 (en) 2008-08-14 2019-10-15 Microsoft Technology Licensing, Llc Cloud-based device information storage
US11297688B2 (en) 2018-03-22 2022-04-05 goTenna Inc. Mesh network deployment kit
US11681669B2 (en) 2020-06-22 2023-06-20 HCL Technologies Italy S.p.A. Method and system for correlating multiple device entries within domain

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8156208B2 (en) 2005-11-21 2012-04-10 Sap Ag Hierarchical, multi-tiered mapping and monitoring architecture for service-to-device re-mapping for smart items
US7860968B2 (en) 2005-11-21 2010-12-28 Sap Ag Hierarchical, multi-tiered mapping and monitoring architecture for smart items
US7890568B2 (en) * 2006-04-28 2011-02-15 Sap Ag Service-to-device mapping for smart items using a genetic algorithm
US8296408B2 (en) * 2006-05-12 2012-10-23 Sap Ag Distributing relocatable services in middleware for smart items
US8065411B2 (en) 2006-05-31 2011-11-22 Sap Ag System monitor for networks of nodes
US20080005317A1 (en) * 2006-06-30 2008-01-03 International Business Machines Corporation Method and apparatus for cross-tier management in multi-tier computing system architecture
US8396788B2 (en) 2006-07-31 2013-03-12 Sap Ag Cost-based deployment of components in smart item environments
US20080178198A1 (en) * 2007-01-22 2008-07-24 Media Ripple, Llc Distributed digital media management
US20080306798A1 (en) * 2007-06-05 2008-12-11 Juergen Anke Deployment planning of components in heterogeneous environments
US8156219B2 (en) * 2007-08-03 2012-04-10 At&T Intellectual Property I, L.P. System and method of health monitoring and fault monitoring in a network system
US8527622B2 (en) 2007-10-12 2013-09-03 Sap Ag Fault tolerance framework for networks of nodes
CN101983366B (en) * 2008-03-30 2014-02-12 科瑞尔森思有限公司 Apparatus and method for tracking requests in multi threaded multi tier computerized environment
US8848659B2 (en) * 2008-05-12 2014-09-30 Telefonaktiebolaget L M Ericsson (Publ) Tracking network resources
EP2304590A4 (en) * 2008-06-20 2012-04-25 Leostream Corp Management layer method and apparatus for dynamic assignment of users to computer resources
US20100146002A1 (en) * 2008-12-08 2010-06-10 International Business Machines Corporation Capturing enterprise architectures
KR101041988B1 (en) * 2009-02-24 2011-06-16 부산대학교 산학협력단 RFID Middleware system and method to support real-time balancing load of reader connections
US8874526B2 (en) 2010-03-31 2014-10-28 Cloudera, Inc. Dynamically processing an event using an extensible data model
US9082127B2 (en) 2010-03-31 2015-07-14 Cloudera, Inc. Collecting and aggregating datasets for analysis
US9317572B2 (en) * 2010-03-31 2016-04-19 Cloudera, Inc. Configuring a system to collect and aggregate datasets
US9081888B2 (en) 2010-03-31 2015-07-14 Cloudera, Inc. Collecting and aggregating log data with fault tolerance
JP2011249933A (en) * 2010-05-24 2011-12-08 Smk Corp Radio communication module, remote control device and radio system
EP2439686B1 (en) * 2010-09-23 2019-09-18 BlackBerry Limited Radio frequency identification (RFID) system providing meeting room reservation and scheduling features and related methods
US8880592B2 (en) 2011-03-31 2014-11-04 Cloudera, Inc. User interface implementation for partial display update
US9185066B2 (en) * 2011-09-01 2015-11-10 Sony Corporation Enabling wireless device communication
US9128949B2 (en) 2012-01-18 2015-09-08 Cloudera, Inc. Memory allocation buffer for reduction of heap fragmentation
US9172608B2 (en) 2012-02-07 2015-10-27 Cloudera, Inc. Centralized configuration and monitoring of a distributed computing cluster
US9405692B2 (en) 2012-03-21 2016-08-02 Cloudera, Inc. Data processing performance enhancement in a distributed file system
US9338008B1 (en) 2012-04-02 2016-05-10 Cloudera, Inc. System and method for secure release of secret information over a network
US9842126B2 (en) 2012-04-20 2017-12-12 Cloudera, Inc. Automatic repair of corrupt HBases
US9753954B2 (en) 2012-09-14 2017-09-05 Cloudera, Inc. Data node fencing in a distributed file system
ES2491491B1 (en) * 2013-03-05 2015-06-16 Vodafone España, S.A.U. Method for anonymously associating measurements of a sanitary monitoring device with a user ID
US9342557B2 (en) 2013-03-13 2016-05-17 Cloudera, Inc. Low latency query engine for Apache Hadoop
US9672724B2 (en) 2013-03-31 2017-06-06 Schneider Electric USA, Inc. Automatic configuration of alarm aggregations
JP2015041947A (en) * 2013-08-23 2015-03-02 ソニー株式会社 Information processing device, information processing method and program
US9477731B2 (en) 2013-10-01 2016-10-25 Cloudera, Inc. Background format optimization for enhanced SQL-like queries in Hadoop
US9934382B2 (en) 2013-10-28 2018-04-03 Cloudera, Inc. Virtual machine image encryption
US9690671B2 (en) 2013-11-01 2017-06-27 Cloudera, Inc. Manifest-based snapshots in distributed computing environments
CN103942330B (en) * 2014-04-30 2018-05-01 深圳先进技术研究院 A kind of processing method of big data, system
JP6282204B2 (en) * 2014-09-12 2018-02-21 インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation System and method for monitoring access to network in secure site
US9747333B2 (en) 2014-10-08 2017-08-29 Cloudera, Inc. Querying operating system state on multiple machines declaratively
US20160358013A1 (en) * 2015-06-02 2016-12-08 Aerdos, Inc. Method and system for ambient proximity sensing techniques between mobile wireless devices for imagery redaction and other applicable uses
JP6398894B2 (en) * 2015-06-30 2018-10-03 オムロン株式会社 Data flow control device and data flow control method
CN106375102B (en) * 2015-07-22 2019-08-27 华为技术有限公司 A kind of service registration method, application method and relevant apparatus
CN105678639A (en) * 2016-02-01 2016-06-15 中国海洋石油总公司 Natural gas Internet construction method
US11175966B2 (en) * 2016-02-26 2021-11-16 Arista Networks, Inc. System and method of a managing multiple data centers
CN109155789B (en) * 2016-03-04 2022-01-14 康维达无线有限责任公司 Method, apparatus and storage medium for request processing in a service layer
CN107479963A (en) * 2016-06-08 2017-12-15 国家计算机网络与信息安全管理中心 A kind of method for allocating tasks and system
US10157529B2 (en) * 2017-02-27 2018-12-18 Sharkk, Llc Device and system for alerting caregivers to a child abandoned in a potentially dangerous environment
RU2651142C1 (en) * 2017-08-18 2018-04-18 Валентин Львович Ким Method and system of automated programming using the expert system, intellectual management systems based on program-logic controllers (plcs) and on microcontrollers
US20190164087A1 (en) * 2017-11-30 2019-05-30 B.yond, Inc. Decomposing tasks through artificial intelligence chaining
US10862988B2 (en) * 2017-12-18 2020-12-08 The Chinese University Of Hong Kong On-demand real-time sensor data distribution system
US11070421B2 (en) * 2019-03-19 2021-07-20 Microsoft Technology Licensing, Llc Combined registration and telemetry reporting
CN112995258B (en) * 2019-12-17 2023-12-29 南京品尼科自动化有限公司 Front-end processor for monitoring environment of machine room
CN113055640B (en) * 2019-12-28 2023-06-20 浙江宇视科技有限公司 Method and device for managing equipment in monitoring system
CN113038291B (en) * 2021-02-07 2024-02-23 网宿科技股份有限公司 Box type setting method and server
CN114640607B (en) * 2022-05-12 2022-08-12 武汉四通信息服务有限公司 Monitoring service registration method and device, computer equipment and storage medium
CN114666554B (en) * 2022-05-23 2023-04-11 创意信息技术股份有限公司 Edge gateway cloud service management system

Citations (168)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0697654A1 (en) 1994-07-19 1996-02-21 Canon Kabushiki Kaisha Load distribution method and system
US5740357A (en) * 1990-04-26 1998-04-14 Digital Equipment Corporation Generic fault management of a computer system
US5768568A (en) 1994-04-29 1998-06-16 International Business Machines Corp. System and method for initializing an information processing system
US5805820A (en) 1996-07-15 1998-09-08 At&T Corp. Method and apparatus for restricting access to private information in domain name systems by redirecting query requests
US5809012A (en) * 1991-01-31 1998-09-15 Fujitsu Limited Connectionless communication system
EP0810755A3 (en) 1996-05-31 1999-03-24 Hewlett-Packard Company Method for enhancing operation of a network management system
US5940593A (en) 1997-03-31 1999-08-17 International Business Machines Corporation Simulating a multi-tiered computer environment on a single development system for debugging
US6016499A (en) 1997-07-21 2000-01-18 Novell, Inc. System and method for accessing a directory services respository
US6023702A (en) 1995-08-18 2000-02-08 International Business Machines Corporation Method and apparatus for a process and project management computer system
US6065052A (en) * 1996-07-01 2000-05-16 Sun Microsystems, Inc. System for maintaining strongly sequentially ordered packet flow in a ring network system with busy and failed nodes
US6138162A (en) 1997-02-11 2000-10-24 Pointcast, Inc. Method and apparatus for configuring a client to redirect requests to a caching proxy server based on a category ID with the request
US6167438A (en) 1997-05-22 2000-12-26 Trustees Of Boston University Method and system for distributed caching, prefetching and replication
US6178173B1 (en) 1996-12-30 2001-01-23 Paradyne Corporation System and method for communicating pre-connect information in a digital communication system
US6184778B1 (en) * 1996-11-12 2001-02-06 Kabushiki Kaisha Toshiba Communication network system and rebuilding method thereof
US6199195B1 (en) 1999-07-08 2001-03-06 Science Application International Corporation Automatically generated objects within extensible object frameworks and links to enterprise resources
US6226788B1 (en) 1998-07-22 2001-05-01 Cisco Technology, Inc. Extensible network management system
US6256739B1 (en) 1997-10-30 2001-07-03 Juno Online Services, Inc. Method and apparatus to determine user identity and limit access to a communications network
US6262726B1 (en) 1998-10-09 2001-07-17 Dell U.S.A., L.P. Factory installing desktop components for an active desktop
US6292856B1 (en) 1999-01-29 2001-09-18 International Business Machines Corporation System and method for application influence of I/O service order post I/O request
US6308178B1 (en) 1999-10-21 2001-10-23 Darc Corporation System for integrating data among heterogeneous systems
US20010051981A1 (en) * 2000-06-05 2001-12-13 Microsoft Corporation Methods and systems for discovering object-exchange resources on a network
JP2002500785A (en) 1996-12-09 2002-01-08 サン・マイクロシステムズ・インコーポレーテッド Load balancing and failover of network services
US20020007422A1 (en) 2000-07-06 2002-01-17 Bennett Keith E. Providing equipment access to supply chain members
US6343287B1 (en) 1999-05-19 2002-01-29 Sun Microsystems, Inc. External data store link for a profile service
US6363411B1 (en) 1998-08-05 2002-03-26 Mci Worldcom, Inc. Intelligent network
US6378128B1 (en) 1998-10-08 2002-04-23 Microsoft Corporation System and method for dynamically modifying an install-set
US20020100036A1 (en) 2000-09-22 2002-07-25 Patchlink.Com Corporation Non-invasive automatic offsite patch fingerprinting and updating system and method
US6442748B1 (en) 1999-08-31 2002-08-27 Accenture Llp System, method and article of manufacture for a persistent state and persistent object separator in an information services patterns environment
US20020131386A1 (en) * 2001-01-26 2002-09-19 Docomo Communications Laboratories Usa, Inc. Mobility prediction in wireless, mobile access digital networks
US20020161751A1 (en) 2001-01-17 2002-10-31 Mulgund Sandeep S. System for and method of relational database modeling of ad hoc distributed sensor networks
US6480977B1 (en) 1999-10-29 2002-11-12 Worldcom, Inc. Multi-protocol monitor
US20020174169A1 (en) 2001-05-21 2002-11-21 Schmid Hans Albrecht Process for operating a distributed computer network comprising several distributed computers
US20020188866A1 (en) 2001-06-07 2002-12-12 Jalaludeen Ca Method and apparatus for protecting a device connected to a newtwork
US20020199173A1 (en) 2001-01-29 2002-12-26 Matt Bowen System, method and article of manufacture for a debugger capable of operating across multiple threads and lock domains
US20030005350A1 (en) 2001-06-29 2003-01-02 Maarten Koning Failover management system
US20030016664A1 (en) 2001-07-23 2003-01-23 Melampy Patrick J. System and method for providing rapid rerouting of real-time multi-media flows
US20030018810A1 (en) * 2000-10-18 2003-01-23 Telefonaktiebolaget L M Ericsson (Publ) Seamless handoff in mobile IP
JP2003067351A (en) 2001-08-28 2003-03-07 Nec System Technologies Ltd Configuration control system of distributed computer
US20030050902A1 (en) 2001-04-06 2003-03-13 Buczak Anna L. Genetic algorithm optimization method
US20030078946A1 (en) 2001-06-05 2003-04-24 Laurie Costello Clustered filesystem
US20030097443A1 (en) 2001-11-21 2003-05-22 Richard Gillett Systems and methods for delivering content over a network
US20030144001A1 (en) * 2002-01-29 2003-07-31 Keiichi Nakatsugawa Router and mobile communication terminal for mobile communication network
US6606740B1 (en) 1998-10-05 2003-08-12 American Management Systems, Inc. Development framework for case and workflow systems
US6643669B1 (en) 2000-03-14 2003-11-04 Telefonaktiebolaget Lm Ericsson (Publ) Method for optimization of synchronization between a client's database and a server database
US20030217186A1 (en) 2002-05-16 2003-11-20 Bushey Robert D. Apparatus for and method of seamless wireless multimedia download path to peer networked appliances
US6654953B1 (en) 1998-10-09 2003-11-25 Microsoft Corporation Extending program languages with source-program attribute tags
US20030228910A1 (en) 2002-06-10 2003-12-11 Sridhar Jawaharlal Lottery management system
EP1372073A2 (en) 2002-06-10 2003-12-17 Hewlett-Packard Company Mapping service demands in a distributed computer system
US6686838B1 (en) * 2000-09-06 2004-02-03 Xanboo Inc. Systems and methods for the automatic registration of devices
US6687846B1 (en) 2000-03-30 2004-02-03 Intel Corporation System and method for error handling and recovery
US20040024768A1 (en) 2002-07-31 2004-02-05 Stephan Haller Integration framework
US6694335B1 (en) 1999-10-04 2004-02-17 Microsoft Corporation Method, computer readable medium, and system for monitoring the state of a collection of resources
US20040059810A1 (en) * 2002-09-20 2004-03-25 International Business Machines Corporation Method and apparatus for publishing and monitoring entities providing services in a distributed data processing system
JP2004110318A (en) 2002-09-18 2004-04-08 Nec Corp Hierarchical distributed processing system and hierarchical distributed processing method
US20040088231A1 (en) 2002-01-04 2004-05-06 Davis Tommy L. System and method for tracking authenticated items
US20040111499A1 (en) 2002-12-10 2004-06-10 Dobrowski Patrick M. Method for launching applications
US20040121792A1 (en) 2002-12-18 2004-06-24 Allen Vernon A. Multi-protocol network and method of switching protocols
US6757720B1 (en) 1999-05-19 2004-06-29 Sun Microsystems, Inc. Profile service architecture
US6769000B1 (en) * 1999-09-08 2004-07-27 Nortel Networks Limited Unified directory services architecture for an IP mobility architecture framework
US20040146064A1 (en) * 2003-01-21 2004-07-29 Glen Kramer Method and apparatus for discovering remote nodes in an ethernet passive optical network
US6785707B2 (en) 2000-11-14 2004-08-31 Bitfone Corp. Enhanced multimedia mobile content delivery and message system using cache management
US20040181541A1 (en) 2003-03-14 2004-09-16 Computer Associates Think, Inc. Relational model for management information in network devices
US20040193703A1 (en) 2003-01-10 2004-09-30 Guy Loewy System and method for conformance and governance in a service oriented architecture
US20040243352A1 (en) 2001-09-13 2004-12-02 Akio Morozumi Data collection method
US20040250113A1 (en) 2003-04-16 2004-12-09 Silicon Graphics, Inc. Clustered filesystem for mix of trusted and untrusted nodes
US20040249944A1 (en) 2001-09-28 2004-12-09 Hosking Michael R Client server model
US6832373B2 (en) 2000-11-17 2004-12-14 Bitfone Corporation System and method for updating and distributing information
US20040264395A1 (en) * 2003-06-25 2004-12-30 Canon Kabushiki Kaisha Configuration of wireless network client
US6842903B1 (en) 1999-05-19 2005-01-11 Sun Microsystems, Inc. System and method for providing dynamic references between services in a computer system
US6847974B2 (en) 2001-03-26 2005-01-25 Us Search.Com Inc Method and apparatus for intelligent data assimilation
US6859831B1 (en) 1999-10-06 2005-02-22 Sensoria Corporation Method and apparatus for internetworked wireless integrated network sensor (WINS) nodes
US20050060365A1 (en) 2002-01-24 2005-03-17 Robinson Scott L. Context-based information processing
US20050071443A1 (en) 2001-09-10 2005-03-31 Jai Menon Software platform for the delivery of services and personalized content
US20050080892A1 (en) 2003-10-08 2005-04-14 Manfred Moser Method for predicting a development over time of a system quantity
US6891823B1 (en) 1999-06-15 2005-05-10 Pluris, Inc. Apparatus and method for scaling a switching fabric in a network switching node
US6892236B1 (en) 2000-03-16 2005-05-10 Microsoft Corporation System and method of generating computer system performance reports
CN1620653A (en) 2001-05-23 2005-05-25 国际商业机器公司 Dynamic arrangement of service in computing network
US20050114431A1 (en) 2003-11-25 2005-05-26 Singh Uma K. System and method for a generic mobile synchronization framework
US20050119001A1 (en) * 2003-11-28 2005-06-02 Hitachi Communication Technologies, Ltd. Wireless communication system, server and mobile station therefor
US6927686B2 (en) 2002-12-11 2005-08-09 General Electric Company Method and apparatus for internet enabled, wireless remote sensor measurement
US20050183061A1 (en) 2001-01-24 2005-08-18 Thomas Papanikolaou Arrangement and a method relating to access of applications/services
US20050198228A1 (en) 2004-02-13 2005-09-08 Bajwa Raminder S. Radio frequency identification (RFID) network system and method
US20050228763A1 (en) 2004-04-03 2005-10-13 Altusys Corp Method and Apparatus for Situation-Based Management
US20050235058A1 (en) 2003-10-10 2005-10-20 Phil Rackus Multi-network monitoring architecture
US20050235136A1 (en) 2004-04-16 2005-10-20 Lucent Technologies Inc. Methods and systems for thread monitoring
US6961763B1 (en) * 1999-08-17 2005-11-01 Microsoft Corporation Automation system for controlling and monitoring devices and sensors
US20050249131A1 (en) * 2004-04-20 2005-11-10 Ntt Docomo, Inc. Mobile host, paging agent, packet communication system, and movement detection method
WO2005106666A1 (en) 2004-04-29 2005-11-10 International Business Machines Corporation A system and method for modeling and dynamically deploying services into a distributed networking architecture
US6970902B1 (en) * 2001-05-24 2005-11-29 Cisco Technology, Inc. Method and apparatus for providing a distributed service in a network
US6977938B2 (en) * 1999-12-20 2005-12-20 Telefonaktiebolaget Lm Ericsson (Publ) Mobile IP for mobile ad hoc networks
US6980993B2 (en) 2001-03-14 2005-12-27 Microsoft Corporation Schemas for a notification platform and related information services
US6986148B2 (en) 2001-07-17 2006-01-10 Appforge, Inc. Methods and systems for providing platform-independent shared software components for mobile devices
US20060026591A1 (en) 2004-08-02 2006-02-02 International Business Machines Corporation Method and apparatus for providing a pluggable and extendable J2EE architecture
US20060022801A1 (en) 2004-07-30 2006-02-02 Reva Systems Corporation RFID tag data acquisition system
US20060052882A1 (en) 2004-09-03 2006-03-09 Uwe Kubach Real-time monitoring using sensor networks
US20060058102A1 (en) * 2004-09-10 2006-03-16 Nguyen Binh T Apparatus and methods for wireless gaming communications
US7024430B1 (en) 1998-12-08 2006-04-04 Starfish Software, Inc. Method and system for implementing a filter in a data synchronization system
US20060074912A1 (en) 2004-09-28 2006-04-06 Veritas Operating Corporation System and method for determining file system content relevance
US20060085798A1 (en) 2000-05-05 2006-04-20 Bristol Technology Inc. Method and apparatus for correlation of events in a distributed multi-system computing environment
US20060106581A1 (en) 2004-10-29 2006-05-18 Christof Bornhoevd Aggregating sensor data
US20060107284A1 (en) 2004-11-18 2006-05-18 Crawford Timothy J Management system for computer support systems
US20060129367A1 (en) 2004-11-09 2006-06-15 Duke University Systems, methods, and computer program products for system online availability estimation
US20060143181A1 (en) * 2002-09-06 2006-06-29 Xiangdong Liu Method of searching for the devices automatically in network
US20060143592A1 (en) 2004-12-28 2006-06-29 Bender Lothar H Pluggable model framework
US20060146991A1 (en) 2005-01-06 2006-07-06 Tervela, Inc. Provisioning and management in a message publish/subscribe system
US7075960B2 (en) 2003-01-10 2006-07-11 Matsushita Electric Industrial Co., Ltd. Semiconductor laser apparatus and production method thereof
US20060161909A1 (en) 2005-01-20 2006-07-20 Raju Pandey Synthesizing a scalable and incrementally updatable system software infrastructure for sensor networks
US20060173726A1 (en) 2005-01-31 2006-08-03 Hall William M Online business case software and decision support system
US7096461B1 (en) 1999-11-17 2006-08-22 Sony Corporation Method and apparatus for digital signal processing and method of providing extension function
US7099582B2 (en) 2002-05-31 2006-08-29 Lucent Technologies Inc. Method and apparatus for multi-protocol and multi-rate optical channel performance monitoring
US7099946B2 (en) 2000-11-13 2006-08-29 Canon Kabushiki Kaishsa Transferring a media browsing session from one device to a second device by transferring a session identifier and a session key to the second device
US20060206582A1 (en) 2003-11-17 2006-09-14 David Finn Portable music device with song tag capture
US20060212453A1 (en) 2005-03-18 2006-09-21 International Business Machines Corporation System and method for preserving state for a cluster of data servers in the presence of load-balancing, failover, and fail-back events
US20060212698A1 (en) 2005-03-16 2006-09-21 Douglas Peckover System, method and apparatus for electronically protecting data and digital content
US7114146B2 (en) 2003-05-02 2006-09-26 International Business Machines Corporation System and method of dynamic service composition for business process outsourcing
US20060215692A1 (en) * 2005-03-11 2006-09-28 Samsung Electronics Co., Ltd. Method for generating and registering identification in wireless sensor network
US20060215601A1 (en) * 2005-03-14 2006-09-28 H-Stream Wireless, Inc. Method and apparatus for coordinating a wireless PAN network and a wireless LAN network
US7116674B2 (en) 2003-01-16 2006-10-03 Utstarcom, Inc. Method and apparatus for digital subscriber line access multiplexer stacking
US20060225064A1 (en) 2003-03-19 2006-10-05 Habin Lee Flexible multi-agent system architecture
US20060235976A1 (en) 2005-04-14 2006-10-19 Ying Chen Method and apparatus for metadata driven web service mediation
US20060277079A1 (en) 2005-04-22 2006-12-07 Gilligan Geffrey D Groupware travel itinerary creation
US20070011334A1 (en) * 2003-11-03 2007-01-11 Steven Higgins Methods and apparatuses to provide composite applications
US7171471B1 (en) 2002-08-15 2007-01-30 Cisco Technology, Inc. Methods and apparatus for directing a resource request
US20070032244A1 (en) 2005-08-08 2007-02-08 Microsoft Corporation Group-centric location tagging for mobile devices
US7206289B2 (en) 2001-02-06 2007-04-17 Oki Electric Industry Co., Ltd. Method of and apparatus for calculating traffic from data on packet transmission collected from routers
US7209739B1 (en) * 2004-12-28 2007-04-24 Sprint Spectrum L.P. Method and system for processing calls within a local micro network
US20070093991A1 (en) * 2005-10-20 2007-04-26 Hoogenboom Christopher L Initialization of a sensor for minitoring the structural integrity of a building
US7219254B2 (en) 2003-03-19 2007-05-15 Lucent Technologies Inc. Method and apparatus for high availability distributed processing across independent networked computer fault groups
US20070112574A1 (en) 2003-08-05 2007-05-17 Greene William S System and method for use of mobile policy agents and local services, within a geographically distributed service grid, to provide greater security via local intelligence and life-cycle management for RFlD tagged items
US20070118549A1 (en) 2005-11-21 2007-05-24 Christof Bornhoevd Hierarchical, multi-tiered mapping and monitoring architecture for smart items
US20070118560A1 (en) 2005-11-21 2007-05-24 Christof Bornhoevd Service-to-device re-mapping for smart items
US20070118496A1 (en) 2005-11-21 2007-05-24 Christof Bornhoevd Service-to-device mapping for smart items
US20070123256A1 (en) * 2005-11-30 2007-05-31 Vtech Telecommunications Limited,Hong Kong System and method for cordless handset registration
US7227889B1 (en) 1998-06-30 2007-06-05 Cisco Technology, Inc. Media access layer ping protocol for diagnosing cable modem links
US20070130208A1 (en) 2005-11-21 2007-06-07 Christof Bornhoevd Hierarchical, multi-tiered mapping and monitoring architecture for service-to-device re-mapping for smart items
US20070130217A1 (en) 2005-10-13 2007-06-07 Unwired Software, Inc. Many to many data synchronization
US7237243B2 (en) 2001-06-11 2007-06-26 Microsoft Corporation Multiple device management method and system
US20070168690A1 (en) 2005-11-18 2007-07-19 Ross Alan D Highly available computing platform
US20070168919A1 (en) 2005-12-01 2007-07-19 Cassatt Corporation Automated deployment and configuration of applications in an autonomically controlled distributed computing system
US20070192464A1 (en) * 2005-12-22 2007-08-16 Axis Ab Monitoring system and method for connecting a monitoring device to a service server
US20070204261A1 (en) 2003-05-20 2007-08-30 Christof Fetzer Robust software library wrapper method and apparatus
US20070233881A1 (en) 2006-03-31 2007-10-04 Zoltan Nochta Active intervention in service-to-device mapping for smart items
US20070249286A1 (en) * 2006-04-21 2007-10-25 Ma Dung T Automated bonding for wireless devices
US20070251998A1 (en) 2006-04-28 2007-11-01 Mikhail Belenki Service-to-device mapping for smart items using a genetic algorithm
US7302401B1 (en) 1999-04-06 2007-11-27 Single Source Oy Data management mechanism for project planning
US20070276674A1 (en) 2002-08-19 2007-11-29 Merzad Hemmat Defining and sizing feasible approaches to business needs within an integrated development process
US7304976B2 (en) 2004-10-13 2007-12-04 Virginia Tech Intellectual Properties, Inc. Method and apparatus for control and routing of wireless sensor networks
EP1863223A1 (en) 2006-05-31 2007-12-05 Sap Ag System monitor for networks of nodes
US20070283002A1 (en) 2006-05-31 2007-12-06 Christof Bornhoevd Modular monitor service for smart item monitoring
US20070282746A1 (en) 2006-05-12 2007-12-06 Juergen Anke Distributing relocatable services in middleware for smart items
US7313467B2 (en) 2000-09-08 2007-12-25 Automotive Technologies International Inc. System and method for in-vehicle communications
US20080010284A1 (en) 2001-06-05 2008-01-10 Silicon Graphics, Inc. Snapshot copy of data volume during data access
US7319976B1 (en) * 1996-01-17 2008-01-15 Paradox Technical Solutions Llc Intelligent agents for electronic commerce
US20080033785A1 (en) 2006-07-31 2008-02-07 Juergen Anke Cost-based deployment of components in smart item environments
US20080052314A1 (en) 2006-08-25 2008-02-28 Ritwik Batabyal e-ENABLER FRAMEWORK
US7362731B2 (en) * 2004-03-23 2008-04-22 Nokia Corporation Selection of network access entity in a communication system
US20080270486A1 (en) 2000-04-10 2008-10-30 Hugh Hind System and method for synchronizing data records between multiple databases
US7506338B2 (en) 2004-08-30 2009-03-17 International Business Machines Corporation Method and apparatus for simplifying the deployment and serviceability of commercial software environments
US20090097397A1 (en) 2007-10-12 2009-04-16 Sap Ag Fault tolerance framework for networks of nodes
US7554920B2 (en) * 2001-12-27 2009-06-30 Microsoft Corporation Method and system for dynamically adjusting transmit and receive parameters for handling negative acknowledgments in reliable multicast
US7557707B2 (en) 2004-09-01 2009-07-07 Microsoft Corporation RFID enabled information systems utilizing a business application
US7584471B2 (en) 2002-09-23 2009-09-01 Telefonaktiebolaget L M Ericsson (Publ) Plug-in model
US7616642B2 (en) 2006-01-04 2009-11-10 Sap Ag Priority assignment and transmission of sensor data
US20100122236A1 (en) 2005-08-26 2010-05-13 Taras Markian Bugir System, program product, and methods to enhance content management
US7752068B1 (en) 2006-09-22 2010-07-06 Sprint Communications Company L.P. Synergy tracking tool
US7756969B1 (en) 2001-09-07 2010-07-13 Oracle America, Inc. Dynamic provisioning of identification services in a distributed system
US7853946B2 (en) 2003-02-28 2010-12-14 Canon Kabushiki Kaisha Information processing apparatus, information processing method, and control program
US7930143B2 (en) 2004-11-30 2011-04-19 Oracle International Corporation Systems and methods for sensor-based computing

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1547120A (en) * 2003-12-10 2004-11-17 沈阳东软软件股份有限公司 Network monitoring management system

Patent Citations (179)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5740357A (en) * 1990-04-26 1998-04-14 Digital Equipment Corporation Generic fault management of a computer system
US5809012A (en) * 1991-01-31 1998-09-15 Fujitsu Limited Connectionless communication system
US5768568A (en) 1994-04-29 1998-06-16 International Business Machines Corp. System and method for initializing an information processing system
EP0697654A1 (en) 1994-07-19 1996-02-21 Canon Kabushiki Kaisha Load distribution method and system
US6023702A (en) 1995-08-18 2000-02-08 International Business Machines Corporation Method and apparatus for a process and project management computer system
US7319976B1 (en) * 1996-01-17 2008-01-15 Paradox Technical Solutions Llc Intelligent agents for electronic commerce
US6189038B1 (en) 1996-05-31 2001-02-13 Hewlett-Packard Company Generic notifications framework system and method for enhancing operation of a management station on a network
EP0810755A3 (en) 1996-05-31 1999-03-24 Hewlett-Packard Company Method for enhancing operation of a network management system
US6065052A (en) * 1996-07-01 2000-05-16 Sun Microsystems, Inc. System for maintaining strongly sequentially ordered packet flow in a ring network system with busy and failed nodes
US5805820A (en) 1996-07-15 1998-09-08 At&T Corp. Method and apparatus for restricting access to private information in domain name systems by redirecting query requests
US6184778B1 (en) * 1996-11-12 2001-02-06 Kabushiki Kaisha Toshiba Communication network system and rebuilding method thereof
JP2002500785A (en) 1996-12-09 2002-01-08 サン・マイクロシステムズ・インコーポレーテッド Load balancing and failover of network services
US6178173B1 (en) 1996-12-30 2001-01-23 Paradyne Corporation System and method for communicating pre-connect information in a digital communication system
US6138162A (en) 1997-02-11 2000-10-24 Pointcast, Inc. Method and apparatus for configuring a client to redirect requests to a caching proxy server based on a category ID with the request
US5940593A (en) 1997-03-31 1999-08-17 International Business Machines Corporation Simulating a multi-tiered computer environment on a single development system for debugging
US6167438A (en) 1997-05-22 2000-12-26 Trustees Of Boston University Method and system for distributed caching, prefetching and replication
US6016499A (en) 1997-07-21 2000-01-18 Novell, Inc. System and method for accessing a directory services respository
US6256739B1 (en) 1997-10-30 2001-07-03 Juno Online Services, Inc. Method and apparatus to determine user identity and limit access to a communications network
US7227889B1 (en) 1998-06-30 2007-06-05 Cisco Technology, Inc. Media access layer ping protocol for diagnosing cable modem links
US6226788B1 (en) 1998-07-22 2001-05-01 Cisco Technology, Inc. Extensible network management system
US6363411B1 (en) 1998-08-05 2002-03-26 Mci Worldcom, Inc. Intelligent network
US6606740B1 (en) 1998-10-05 2003-08-12 American Management Systems, Inc. Development framework for case and workflow systems
US6378128B1 (en) 1998-10-08 2002-04-23 Microsoft Corporation System and method for dynamically modifying an install-set
US6262726B1 (en) 1998-10-09 2001-07-17 Dell U.S.A., L.P. Factory installing desktop components for an active desktop
US6654953B1 (en) 1998-10-09 2003-11-25 Microsoft Corporation Extending program languages with source-program attribute tags
US7024430B1 (en) 1998-12-08 2006-04-04 Starfish Software, Inc. Method and system for implementing a filter in a data synchronization system
US6292856B1 (en) 1999-01-29 2001-09-18 International Business Machines Corporation System and method for application influence of I/O service order post I/O request
US7302401B1 (en) 1999-04-06 2007-11-27 Single Source Oy Data management mechanism for project planning
US6343287B1 (en) 1999-05-19 2002-01-29 Sun Microsystems, Inc. External data store link for a profile service
US6757720B1 (en) 1999-05-19 2004-06-29 Sun Microsystems, Inc. Profile service architecture
US6842903B1 (en) 1999-05-19 2005-01-11 Sun Microsystems, Inc. System and method for providing dynamic references between services in a computer system
US6891823B1 (en) 1999-06-15 2005-05-10 Pluris, Inc. Apparatus and method for scaling a switching fabric in a network switching node
US6199195B1 (en) 1999-07-08 2001-03-06 Science Application International Corporation Automatically generated objects within extensible object frameworks and links to enterprise resources
US6961763B1 (en) * 1999-08-17 2005-11-01 Microsoft Corporation Automation system for controlling and monitoring devices and sensors
US6442748B1 (en) 1999-08-31 2002-08-27 Accenture Llp System, method and article of manufacture for a persistent state and persistent object separator in an information services patterns environment
US6769000B1 (en) * 1999-09-08 2004-07-27 Nortel Networks Limited Unified directory services architecture for an IP mobility architecture framework
US6694335B1 (en) 1999-10-04 2004-02-17 Microsoft Corporation Method, computer readable medium, and system for monitoring the state of a collection of resources
US6859831B1 (en) 1999-10-06 2005-02-22 Sensoria Corporation Method and apparatus for internetworked wireless integrated network sensor (WINS) nodes
US6308178B1 (en) 1999-10-21 2001-10-23 Darc Corporation System for integrating data among heterogeneous systems
US6480977B1 (en) 1999-10-29 2002-11-12 Worldcom, Inc. Multi-protocol monitor
US7096461B1 (en) 1999-11-17 2006-08-22 Sony Corporation Method and apparatus for digital signal processing and method of providing extension function
US6977938B2 (en) * 1999-12-20 2005-12-20 Telefonaktiebolaget Lm Ericsson (Publ) Mobile IP for mobile ad hoc networks
US6643669B1 (en) 2000-03-14 2003-11-04 Telefonaktiebolaget Lm Ericsson (Publ) Method for optimization of synchronization between a client's database and a server database
US6892236B1 (en) 2000-03-16 2005-05-10 Microsoft Corporation System and method of generating computer system performance reports
US6687846B1 (en) 2000-03-30 2004-02-03 Intel Corporation System and method for error handling and recovery
US20080270486A1 (en) 2000-04-10 2008-10-30 Hugh Hind System and method for synchronizing data records between multiple databases
US20060085798A1 (en) 2000-05-05 2006-04-20 Bristol Technology Inc. Method and apparatus for correlation of events in a distributed multi-system computing environment
US20010051981A1 (en) * 2000-06-05 2001-12-13 Microsoft Corporation Methods and systems for discovering object-exchange resources on a network
US20020007422A1 (en) 2000-07-06 2002-01-17 Bennett Keith E. Providing equipment access to supply chain members
US6686838B1 (en) * 2000-09-06 2004-02-03 Xanboo Inc. Systems and methods for the automatic registration of devices
US7313467B2 (en) 2000-09-08 2007-12-25 Automotive Technologies International Inc. System and method for in-vehicle communications
US20020100036A1 (en) 2000-09-22 2002-07-25 Patchlink.Com Corporation Non-invasive automatic offsite patch fingerprinting and updating system and method
US6990660B2 (en) 2000-09-22 2006-01-24 Patchlink Corporation Non-invasive automatic offsite patch fingerprinting and updating system and method
US20030018810A1 (en) * 2000-10-18 2003-01-23 Telefonaktiebolaget L M Ericsson (Publ) Seamless handoff in mobile IP
US7099946B2 (en) 2000-11-13 2006-08-29 Canon Kabushiki Kaishsa Transferring a media browsing session from one device to a second device by transferring a session identifier and a session key to the second device
US6785707B2 (en) 2000-11-14 2004-08-31 Bitfone Corp. Enhanced multimedia mobile content delivery and message system using cache management
US6832373B2 (en) 2000-11-17 2004-12-14 Bitfone Corporation System and method for updating and distributing information
US6816862B2 (en) 2001-01-17 2004-11-09 Tiax Llc System for and method of relational database modeling of ad hoc distributed sensor networks
US20020161751A1 (en) 2001-01-17 2002-10-31 Mulgund Sandeep S. System for and method of relational database modeling of ad hoc distributed sensor networks
US20050183061A1 (en) 2001-01-24 2005-08-18 Thomas Papanikolaou Arrangement and a method relating to access of applications/services
US20020131386A1 (en) * 2001-01-26 2002-09-19 Docomo Communications Laboratories Usa, Inc. Mobility prediction in wireless, mobile access digital networks
US20020199173A1 (en) 2001-01-29 2002-12-26 Matt Bowen System, method and article of manufacture for a debugger capable of operating across multiple threads and lock domains
US7206289B2 (en) 2001-02-06 2007-04-17 Oki Electric Industry Co., Ltd. Method of and apparatus for calculating traffic from data on packet transmission collected from routers
US6980993B2 (en) 2001-03-14 2005-12-27 Microsoft Corporation Schemas for a notification platform and related information services
US6847974B2 (en) 2001-03-26 2005-01-25 Us Search.Com Inc Method and apparatus for intelligent data assimilation
US20030050902A1 (en) 2001-04-06 2003-03-13 Buczak Anna L. Genetic algorithm optimization method
US20020174169A1 (en) 2001-05-21 2002-11-21 Schmid Hans Albrecht Process for operating a distributed computer network comprising several distributed computers
CN1620653A (en) 2001-05-23 2005-05-25 国际商业机器公司 Dynamic arrangement of service in computing network
US6970902B1 (en) * 2001-05-24 2005-11-29 Cisco Technology, Inc. Method and apparatus for providing a distributed service in a network
US20080010284A1 (en) 2001-06-05 2008-01-10 Silicon Graphics, Inc. Snapshot copy of data volume during data access
US20030078946A1 (en) 2001-06-05 2003-04-24 Laurie Costello Clustered filesystem
US20020188866A1 (en) 2001-06-07 2002-12-12 Jalaludeen Ca Method and apparatus for protecting a device connected to a newtwork
US7237243B2 (en) 2001-06-11 2007-06-26 Microsoft Corporation Multiple device management method and system
US20030005350A1 (en) 2001-06-29 2003-01-02 Maarten Koning Failover management system
US6986148B2 (en) 2001-07-17 2006-01-10 Appforge, Inc. Methods and systems for providing platform-independent shared software components for mobile devices
US20030016664A1 (en) 2001-07-23 2003-01-23 Melampy Patrick J. System and method for providing rapid rerouting of real-time multi-media flows
JP2003067351A (en) 2001-08-28 2003-03-07 Nec System Technologies Ltd Configuration control system of distributed computer
US7756969B1 (en) 2001-09-07 2010-07-13 Oracle America, Inc. Dynamic provisioning of identification services in a distributed system
US20050071443A1 (en) 2001-09-10 2005-03-31 Jai Menon Software platform for the delivery of services and personalized content
US20040243352A1 (en) 2001-09-13 2004-12-02 Akio Morozumi Data collection method
US20040249944A1 (en) 2001-09-28 2004-12-09 Hosking Michael R Client server model
US20030097443A1 (en) 2001-11-21 2003-05-22 Richard Gillett Systems and methods for delivering content over a network
US7554920B2 (en) * 2001-12-27 2009-06-30 Microsoft Corporation Method and system for dynamically adjusting transmit and receive parameters for handling negative acknowledgments in reliable multicast
US20040088231A1 (en) 2002-01-04 2004-05-06 Davis Tommy L. System and method for tracking authenticated items
US20050060365A1 (en) 2002-01-24 2005-03-17 Robinson Scott L. Context-based information processing
US20030144001A1 (en) * 2002-01-29 2003-07-31 Keiichi Nakatsugawa Router and mobile communication terminal for mobile communication network
US20030217186A1 (en) 2002-05-16 2003-11-20 Bushey Robert D. Apparatus for and method of seamless wireless multimedia download path to peer networked appliances
US7099582B2 (en) 2002-05-31 2006-08-29 Lucent Technologies Inc. Method and apparatus for multi-protocol and multi-rate optical channel performance monitoring
US20030228910A1 (en) 2002-06-10 2003-12-11 Sridhar Jawaharlal Lottery management system
US7072960B2 (en) 2002-06-10 2006-07-04 Hewlett-Packard Development Company, L.P. Generating automated mappings of service demands to server capacities in a distributed computer system
EP1372073A2 (en) 2002-06-10 2003-12-17 Hewlett-Packard Company Mapping service demands in a distributed computer system
US20040024768A1 (en) 2002-07-31 2004-02-05 Stephan Haller Integration framework
US7171471B1 (en) 2002-08-15 2007-01-30 Cisco Technology, Inc. Methods and apparatus for directing a resource request
US20070276674A1 (en) 2002-08-19 2007-11-29 Merzad Hemmat Defining and sizing feasible approaches to business needs within an integrated development process
US20060143181A1 (en) * 2002-09-06 2006-06-29 Xiangdong Liu Method of searching for the devices automatically in network
JP2004110318A (en) 2002-09-18 2004-04-08 Nec Corp Hierarchical distributed processing system and hierarchical distributed processing method
US20040059810A1 (en) * 2002-09-20 2004-03-25 International Business Machines Corporation Method and apparatus for publishing and monitoring entities providing services in a distributed data processing system
US7584471B2 (en) 2002-09-23 2009-09-01 Telefonaktiebolaget L M Ericsson (Publ) Plug-in model
US20040111499A1 (en) 2002-12-10 2004-06-10 Dobrowski Patrick M. Method for launching applications
US6927686B2 (en) 2002-12-11 2005-08-09 General Electric Company Method and apparatus for internet enabled, wireless remote sensor measurement
US20040121792A1 (en) 2002-12-18 2004-06-24 Allen Vernon A. Multi-protocol network and method of switching protocols
US7075960B2 (en) 2003-01-10 2006-07-11 Matsushita Electric Industrial Co., Ltd. Semiconductor laser apparatus and production method thereof
US20040193703A1 (en) 2003-01-10 2004-09-30 Guy Loewy System and method for conformance and governance in a service oriented architecture
US7116674B2 (en) 2003-01-16 2006-10-03 Utstarcom, Inc. Method and apparatus for digital subscriber line access multiplexer stacking
US20040146064A1 (en) * 2003-01-21 2004-07-29 Glen Kramer Method and apparatus for discovering remote nodes in an ethernet passive optical network
US7853946B2 (en) 2003-02-28 2010-12-14 Canon Kabushiki Kaisha Information processing apparatus, information processing method, and control program
US20040181541A1 (en) 2003-03-14 2004-09-16 Computer Associates Think, Inc. Relational model for management information in network devices
US7219254B2 (en) 2003-03-19 2007-05-15 Lucent Technologies Inc. Method and apparatus for high availability distributed processing across independent networked computer fault groups
US20060225064A1 (en) 2003-03-19 2006-10-05 Habin Lee Flexible multi-agent system architecture
US20040250113A1 (en) 2003-04-16 2004-12-09 Silicon Graphics, Inc. Clustered filesystem for mix of trusted and untrusted nodes
US7114146B2 (en) 2003-05-02 2006-09-26 International Business Machines Corporation System and method of dynamic service composition for business process outsourcing
US20070204261A1 (en) 2003-05-20 2007-08-30 Christof Fetzer Robust software library wrapper method and apparatus
US20040264395A1 (en) * 2003-06-25 2004-12-30 Canon Kabushiki Kaisha Configuration of wireless network client
US20070112574A1 (en) 2003-08-05 2007-05-17 Greene William S System and method for use of mobile policy agents and local services, within a geographically distributed service grid, to provide greater security via local intelligence and life-cycle management for RFlD tagged items
US20050080892A1 (en) 2003-10-08 2005-04-14 Manfred Moser Method for predicting a development over time of a system quantity
US20050235058A1 (en) 2003-10-10 2005-10-20 Phil Rackus Multi-network monitoring architecture
US20070011334A1 (en) * 2003-11-03 2007-01-11 Steven Higgins Methods and apparatuses to provide composite applications
US20060206582A1 (en) 2003-11-17 2006-09-14 David Finn Portable music device with song tag capture
US20050114431A1 (en) 2003-11-25 2005-05-26 Singh Uma K. System and method for a generic mobile synchronization framework
US20050119001A1 (en) * 2003-11-28 2005-06-02 Hitachi Communication Technologies, Ltd. Wireless communication system, server and mobile station therefor
US20050198228A1 (en) 2004-02-13 2005-09-08 Bajwa Raminder S. Radio frequency identification (RFID) network system and method
US7362731B2 (en) * 2004-03-23 2008-04-22 Nokia Corporation Selection of network access entity in a communication system
US20050228763A1 (en) 2004-04-03 2005-10-13 Altusys Corp Method and Apparatus for Situation-Based Management
US20050235136A1 (en) 2004-04-16 2005-10-20 Lucent Technologies Inc. Methods and systems for thread monitoring
US20050249131A1 (en) * 2004-04-20 2005-11-10 Ntt Docomo, Inc. Mobile host, paging agent, packet communication system, and movement detection method
US20060029054A1 (en) 2004-04-29 2006-02-09 International Business Machines Corporation System and method for modeling and dynamically deploying services into a distributed networking architecture
WO2005106666A1 (en) 2004-04-29 2005-11-10 International Business Machines Corporation A system and method for modeling and dynamically deploying services into a distributed networking architecture
US20060022801A1 (en) 2004-07-30 2006-02-02 Reva Systems Corporation RFID tag data acquisition system
US20060026591A1 (en) 2004-08-02 2006-02-02 International Business Machines Corporation Method and apparatus for providing a pluggable and extendable J2EE architecture
US7506338B2 (en) 2004-08-30 2009-03-17 International Business Machines Corporation Method and apparatus for simplifying the deployment and serviceability of commercial software environments
US7557707B2 (en) 2004-09-01 2009-07-07 Microsoft Corporation RFID enabled information systems utilizing a business application
US20060052882A1 (en) 2004-09-03 2006-03-09 Uwe Kubach Real-time monitoring using sensor networks
US20060058102A1 (en) * 2004-09-10 2006-03-16 Nguyen Binh T Apparatus and methods for wireless gaming communications
US20060074912A1 (en) 2004-09-28 2006-04-06 Veritas Operating Corporation System and method for determining file system content relevance
US7304976B2 (en) 2004-10-13 2007-12-04 Virginia Tech Intellectual Properties, Inc. Method and apparatus for control and routing of wireless sensor networks
US20060106581A1 (en) 2004-10-29 2006-05-18 Christof Bornhoevd Aggregating sensor data
US7292963B2 (en) 2004-10-29 2007-11-06 Sap Aktiengesellschaft Aggregating sensor data
US20060129367A1 (en) 2004-11-09 2006-06-15 Duke University Systems, methods, and computer program products for system online availability estimation
US20060107284A1 (en) 2004-11-18 2006-05-18 Crawford Timothy J Management system for computer support systems
US7930143B2 (en) 2004-11-30 2011-04-19 Oracle International Corporation Systems and methods for sensor-based computing
US7209739B1 (en) * 2004-12-28 2007-04-24 Sprint Spectrum L.P. Method and system for processing calls within a local micro network
US20060143592A1 (en) 2004-12-28 2006-06-29 Bender Lothar H Pluggable model framework
US20060146991A1 (en) 2005-01-06 2006-07-06 Tervela, Inc. Provisioning and management in a message publish/subscribe system
US20060161909A1 (en) 2005-01-20 2006-07-20 Raju Pandey Synthesizing a scalable and incrementally updatable system software infrastructure for sensor networks
US20060173726A1 (en) 2005-01-31 2006-08-03 Hall William M Online business case software and decision support system
US20060215692A1 (en) * 2005-03-11 2006-09-28 Samsung Electronics Co., Ltd. Method for generating and registering identification in wireless sensor network
US20060215601A1 (en) * 2005-03-14 2006-09-28 H-Stream Wireless, Inc. Method and apparatus for coordinating a wireless PAN network and a wireless LAN network
US20060212698A1 (en) 2005-03-16 2006-09-21 Douglas Peckover System, method and apparatus for electronically protecting data and digital content
US20060212453A1 (en) 2005-03-18 2006-09-21 International Business Machines Corporation System and method for preserving state for a cluster of data servers in the presence of load-balancing, failover, and fail-back events
US20060235976A1 (en) 2005-04-14 2006-10-19 Ying Chen Method and apparatus for metadata driven web service mediation
US20060277079A1 (en) 2005-04-22 2006-12-07 Gilligan Geffrey D Groupware travel itinerary creation
US20070032244A1 (en) 2005-08-08 2007-02-08 Microsoft Corporation Group-centric location tagging for mobile devices
US20100122236A1 (en) 2005-08-26 2010-05-13 Taras Markian Bugir System, program product, and methods to enhance content management
US20070130217A1 (en) 2005-10-13 2007-06-07 Unwired Software, Inc. Many to many data synchronization
US20070093991A1 (en) * 2005-10-20 2007-04-26 Hoogenboom Christopher L Initialization of a sensor for minitoring the structural integrity of a building
US20070168690A1 (en) 2005-11-18 2007-07-19 Ross Alan D Highly available computing platform
US20070118560A1 (en) 2005-11-21 2007-05-24 Christof Bornhoevd Service-to-device re-mapping for smart items
US20070130208A1 (en) 2005-11-21 2007-06-07 Christof Bornhoevd Hierarchical, multi-tiered mapping and monitoring architecture for service-to-device re-mapping for smart items
US20070118549A1 (en) 2005-11-21 2007-05-24 Christof Bornhoevd Hierarchical, multi-tiered mapping and monitoring architecture for smart items
US8005879B2 (en) 2005-11-21 2011-08-23 Sap Ag Service-to-device re-mapping for smart items
US7860968B2 (en) 2005-11-21 2010-12-28 Sap Ag Hierarchical, multi-tiered mapping and monitoring architecture for smart items
US20070118496A1 (en) 2005-11-21 2007-05-24 Christof Bornhoevd Service-to-device mapping for smart items
US20070123256A1 (en) * 2005-11-30 2007-05-31 Vtech Telecommunications Limited,Hong Kong System and method for cordless handset registration
US20070168919A1 (en) 2005-12-01 2007-07-19 Cassatt Corporation Automated deployment and configuration of applications in an autonomically controlled distributed computing system
US20070192464A1 (en) * 2005-12-22 2007-08-16 Axis Ab Monitoring system and method for connecting a monitoring device to a service server
US7616642B2 (en) 2006-01-04 2009-11-10 Sap Ag Priority assignment and transmission of sensor data
US20070233881A1 (en) 2006-03-31 2007-10-04 Zoltan Nochta Active intervention in service-to-device mapping for smart items
US20070249286A1 (en) * 2006-04-21 2007-10-25 Ma Dung T Automated bonding for wireless devices
US7890568B2 (en) 2006-04-28 2011-02-15 Sap Ag Service-to-device mapping for smart items using a genetic algorithm
US20070251998A1 (en) 2006-04-28 2007-11-01 Mikhail Belenki Service-to-device mapping for smart items using a genetic algorithm
US20070282746A1 (en) 2006-05-12 2007-12-06 Juergen Anke Distributing relocatable services in middleware for smart items
US20070283002A1 (en) 2006-05-31 2007-12-06 Christof Bornhoevd Modular monitor service for smart item monitoring
US8065411B2 (en) 2006-05-31 2011-11-22 Sap Ag System monitor for networks of nodes
US20070283001A1 (en) 2006-05-31 2007-12-06 Patrik Spiess System monitor for networks of nodes
EP1863223A1 (en) 2006-05-31 2007-12-05 Sap Ag System monitor for networks of nodes
US20080033785A1 (en) 2006-07-31 2008-02-07 Juergen Anke Cost-based deployment of components in smart item environments
US20080052314A1 (en) 2006-08-25 2008-02-28 Ritwik Batabyal e-ENABLER FRAMEWORK
US7752068B1 (en) 2006-09-22 2010-07-06 Sprint Communications Company L.P. Synergy tracking tool
US20090097397A1 (en) 2007-10-12 2009-04-16 Sap Ag Fault tolerance framework for networks of nodes

Non-Patent Citations (205)

* Cited by examiner, † Cited by third party
Title
"Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0", W3C Recommendation (Jan. 15, 2004), pp. 1-78.
"FAQ: Fault management-How does Fault Management Work?" GoAhead Software (2000), 9 pgs.
"FIPA Device Ontology Specification", Foundation for Intelligent Physical Agents (Apr. 9, 2001), pp. 1-15.
"Java Native Interface (JNI)", Wikepedia, the free encyclopedia, Retrieved on Dec. 20, 2005, from http://en.wikipedia.org/wiki/Jini, 6 pages.
"MVP Brochure", Bitfone Corporation (2005), www.bitfone.com/usa/uploads/mvp.brochure (Retrieved Sep. 20, 2005), pp. 1-3.
"OSGI Service Platform", Release 3, IOS Press, Mar. 2003, 602 pages.
"Service Location Protocol (SLP)", Wikepedia, the free encyclopedia, Retrieved on Dec. 20, 2005, from http://en.wikipedia.org/wiki/Service—Location—Protocol, 1 page.
"The OSGi Service Platform-Dynamic services for networked devices", Retrieved Nov. 16, 2005 from http://www.osgi.org/osgi-technology/index.asp?section=2, 5 pgs.
"TINYOS: Mission Statement", Retrieved Nov. 16, 2005 from http://www.tinyos.net/special/mission, 2 pgs.
"Universal Plug and Play (UPnP)", Wikepedia, the free encyclopedia, Retrieved on Dec. 20, 2005, from http://en.wikipedia.org/wiki/Universal—Plug—and—Play, 6 pages.
"UPnP Device Architecture 1.0", UPnP Forum, 1999, 80 pages.
Advisory Action mailed Oct. 9, 2008 for U.S. Appl. No. 11/284,195, 4 pgs.
Akehurst, D H., et al., "Design Support for Distributed Systems: DSE4DS", Procedings of the 7th Cabernet Radicals Workshop (Oct. 2002), pp. 1-6.
Anke, J. et al., "A Planning Method for Component Placement in Smart Item Environments Using Heuristic Search", Proceedings of the 7th IFIP WG 6.1 International Conference, Distributed Applications and Interoperable Systems, Jun. 2007, pp. 309-322.
Anke, J. et al., "A Service-Oriented Middleware for Integration and Management of Heterogeneous Smart Items Environments", Proceedings of the 4th MiNEMA Workshop, Jul. 2006, pp. 7-11.
Anke, J. et al., "Cost-based Deployment Planning for Components in Smart Item Environments", IEEE Conference on Emerging Technologies and Factory Automation, Sep. 2006, pp. 1238-1245.
Anke, J. et al., "Early Data Processing in Smart Item Environments Using Mobile Services", Proceedings of the 12th IFAC Symposium on Information Control Problems in Manufacturing-INCOM, (May 19, 2006), pp. 823-828.
Ardaiz, et al, "On Service Deployment in Ubiquitous Computing", Proceedings of the 2nd International Workshop on Ubiquitous Computing and Communications, Sep. 2001, 7 pages.
Arkin, et al, "Web Service Choreography Interface (WSCI) Version 1.0", W3C Note, Aug. 2002, 84 pages.
Arkin, et al, "Web Services Business Process Execution Language Version 2.0", Committee Draft, Sep. 2005, 81 pages.
Baker, M. et al., "Grids and Grid Technologies for wide-area Distributed Computing", Software-Practice & Experience (Sep. 27, 2002), pp. 1437-1466.
Bandara, Ayomi et al., "An Ontological Framework for Semantic Description of Devices", Nov. 11, 2004, 2 pgs.
Bellavista, Paolo et al., "The Ubiquitous Provisioning of Internet Services to Portable Devices", Pervasive Computing, Jul. 2002, pp. 81-87.
Bitkom, "RFID White Paper Technology, Systems and Applications", An Overview for companies seeking to use RFID technology to connect their IT systems directly to the "real" world, Dec. 2005, 50 pgs.
Bohn, et al, "SIRENA—Service Infrastructure for Real-time Embedded Networked Devices: A service oriented framework for different domains", International Conference on Networking, International Conference on Systems and International Conference on Mobile Communications and Learning Technologies, 2006, 6 pages.
Bornhoevd, C. et al., "Integrating Smart Items with Business Processes An Experience Report", IEEE Proceedings of the 38th Hawaii International Conference on System Sciences (Jan. 3, 2005), pp. 1-8.
Bornhoevd, Christof et al., "Integrating Automatic Data Acquisition with Business Processes Experiences with SAPs Auto-ID Infrastructure", Very Large Data Conference (Sep. 3, 2004), pp. 1-8.
Boudec, Jean-Yves L., et al., "A Theory of Deterministic Queuing Systems for the Internet", Network Calculus, Online Version of the Book Springer Verlag-LNCS 2050, (May 10, 2004), pp. 1-269.
Box, et al, "Web Services Eventing (WS-Eventing)", Aug. 2004, 16 pages.
Buschmann, C et al., "Towards Information Centric Application Development for Wireless Sensor Networks", In Proceedings of the System Support for Ubiquitous Computing Workshop (UbiSys) at the Sixth Annual Conference on Ubiquitous Computing (UbiComp 2004), pp. 1-12.
California Software Laboratories, "White Paper: The JetSend Appliance Architecture", retrieved from http://www.calsoftlabs.com/whitepapers/jetsend-architecture.html, 2002, 28 pages.
Carvalho, H et al., "A General Data Fusion Architecture", Proceedings of the 6th International Conference on Information Fusion (Jul. 2003), pp. 1-8.
Carzaniga, Antonio et al., "Designing distributed applications with mobile code paradigms", In: Proceedings of the 19th International Conference on Software Engineering, Boston, Massachusetts, (1997), pp. 22-32.
Chandra, Bharat et al., "Resource management for scalable disconnected access to web services", WWW '01: Proceedings of the 10th International Conference on World Wide Web (May 5, 2001), pp. 245-256.
Chatterjee, Mainak et al., "WCA: A Weighted Clustering Alogrithm for Mobile Ad Hoc Networks", Cluster Computing 5, Klluwer Academic Publishers, 2002, pp. 193-204.
Christensen, et al, "Web Services Description Language (WSDL) 1.1", W3C Note, Mar. 2001, 27 pages.
Clement, et al, "UDDI version 3.2, UDDI Spec Technical Committee Draft, OASIS, UDDI Spec TC", Oct. 2004, 420 pages.
Colt, Charles et al., "Oracle ® Collaboration Suite, Deployment Guide10g Release 1 (10.1.1) B14479-02", (Oct. 2005), pp. 1-230.
Crossbow, "Stargate: X-Scale Processor Platform SPB 400", retrieved on Dec. 20, 2005 from http://www.xbow.com/Products/productsdetails.aspx?sid=63, 2 pages.
Crossbow, "Wireless Sensor Networks: Sensor and Data-Acquisition Boards", 2004 Crossbow Technology, Inc., retrieved on Sep. 13, 2010 from http://web.archive.org/web/20040111135950/http://www.xbow.com/Products/productsdetails.aspx?sid=63, 1 page.
Davenport, "Process Innovation: Reengineering work through information technology", Harvard Business School Press, 1993, 6 pages.
de Sales, et al, "Towards the UPnP-Up: Enabling User Profile to Support Customized Services in UPnP Networks", Proceedings of the 2008 The Second International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies, 2008, pp. 206-211.
Decasper, D. et al., "Router Plugins: A Software Architecture for Next Generation Routers", Computer Communication Review (Oct. 1998), pp. 229-240.
Decker, et al, "CoBIs Platform Survey and State-of-the-Art Sensor Platforms", CoBIs Deliverable Report, Aug. 2005, 51 pages.
Deering, et al, "Internet Protocol, Version 6 (Ipv6) Specification", Network Working Group, Dec. 1998, 39 pages.
Deering, S. et al., "ICMP Router Discovery Messages", IETF Standard, Internet Engineering Task Force (Sep. 1991), pp. 1-19.
Domagalski, Ronald et al., "Moglichkeiten der Anfragebearbeitung in mobilen Ad-hoc-Netzwerken", English Title: Possibilties of Query Processing in Mobile Ad Hoc Networks, Contribution to the Workshop "Applications of Mobile Information Technology", Heidelburg German, Full length English translation included, Mar. 23-24, 2004, 12 pages.
ETSI, "Selection procedures for the choice of radio transmission technologies of the UMTS", Universal Mobile Telecommunications System 30.03 version 3.2.0 (Apr. 1998), pp. 1-84.
European Search Report for Application No. 07010671.1 mailed on Nov. 16, 2007, 4 pgs.
European Search Report for Application No. EP06023256.8, mailed May 9, 2007, pp. 1-5.
European Search Report for Application No. EP06023720.3, mailed Apr. 10, 2007, pp. 1-4.
European Search Report for Application No. EP07005127.1, mailed Jul. 20, 2007, pp. 1-3.
European Search Report for Application No. EP07008409.0, mailed Aug. 24, 2007, pp. 1-4.
European Search Report for Application No. EP07009428.9, mailed Oct. 4, 2007, pp. 1-4.
European Search Report for Application No. EP07014724.4, mailed Nov. 27, 2007, pp. 1-4.
European Search Report for EP Application No. 07010652.1 mailed on Oct. 26, 2007, 3 pgs.
European Search Report for EP Application No. 07010654.7 mailed on Oct. 5, 2007, 4 pgs.
Extended European Search Report for Application No. 08017795.9, mailed Feb. 10, 2009, 11 pgs.
Ferreira, L. et al., "Introduction to Grid Computing with globus", IBM International Technical Support Organization, 2nd edition (Sep. 2003), pp. 1-58.
Final Office Action for U.S. Appl. No. 11/283,618, mailed Oct. 5, 2010, 26 pages.
Final Office Action for U.S. Appl. No. 11/283,618, mailed on Sep. 29, 2011, 32 pages.
Final Office Action for U.S. Appl. No. 11/444,119, mailed Aug. 24, 2010, 28 pages.
Final Office Action for U.S. Appl. No. 11/444,279, mailed Sep. 10, 2010, 26 pages.
Final Office Action for U.S. Appl. No. 11/479,284, mailed Jun. 11, 2009, 4 pages.
Final Office Action for U.S. Appl. No. 11/496,641, mailed on Oct. 19, 2011, 19 pages.
Final Office Action mailed Feb. 23, 2009 for U.S. Appl. No. 11/479,284, 29 pgs.
Final Office Action mailed Jun. 25, 2008 for U.S. Appl. No. 11/284,195, 31 pgs.
Final Office Action mailed May 13, 2009 for U.S. Appl. No. 11/283,618, 32 pgs.
Final Office Action Response for U.S. Appl. No. 11/283,618, filed Aug. 24, 2011, 13 pages.
Foster, I. et al., "Globus: A Metacomputing Infrastructure Toolkit", The International Journal of Supercomputer Application and High performance Computing, MIT Press, US, 11 (2), (Jun. 21, 1997), pp. 115-128.
Foster, I. et al., "The Open Grid Services Architecture, Version 1.0", Informational Document, Global Frid Forum (Jan. 29, 2005), pp. 1-62.
Fredriksson, Johan et al., "Calculating Resource Trade-offs when Mapping Component Services to Real-Time Tasks", Fourth Conference on Software Engineering Research and Practice (Oct. 2004), pp. 1-8.
Gauger, "FlexCup—Flexible and Efficient Code Updates for Sensor Networks", Summer School on Wireless Sensor Networks and Smart Objects; Universitat Stuttgart, Aug. 29-Sep. 3, 2005, 8 pages.
Geller, et al, "Web Services Eventing (WS-Eventing)", Aug. 2004, 38 pages.
Golatowski, F et al., "Service-Oriented Software Architecture for Sensor Networks", International Workshop on Mobile Computing (Jun. 17-18, 2003), pp. 1-8.
Gounaris, Anastasios et al., "Adaptive Query Processing: A Survey", Lecture Notes in Computer Science, vol. 2405, Archive of Proceedings of the 19th British National Conference on Databases: Advances in Databases, 2002, pp. 11-25.
Graupner, S. et al., "A framework for analyzing and organizing complex systems", Proceedings of Seventh IEEE International Conference on Engineering of Complex Computer Systems, Jun. 11-13, 2001, Piscataway, NJ, USA, (Jun. 11, 2001), pp. 155-165.
Graupner, Sven et al., "A Framework for Analyzing and Organizing Complex Systems", Hewlett Packard, Computer Systems and Technology Laboratory, Feb. 6, 2001,17 pages.
Greenstein, Ben et al., "A Sensor Network Application Construction Kit (SNACK)", SenSys '04, Nov. 3-5, 2004, 12 pages.
Gudgin, et al, "SOAP Message Transmission Optimization Mechanism", Jan. 25, 2005, 15 pages.
Guttman, "Service Location Protocol", Version 2, Jun. 1999, 55 pages.
Haas, "Service Deployment in Programmable Networks", PhD Thesis, Eth Zurich, Switzerland, 2003, 253 pages.
Hammer, et al, "Reengineering the Corporation—A Manifesto for Business Revolution", Nicholas Brealey Publishing, May 1994, 14 pages.
Han, et al, "Sensor Network Software Update Management: A Survey", Journal of Network Management, 2005, 26 pages.
Hawick, K A., et al., "Middleware for Wireless Sensors and Robots", DHPC Technical Report DHPC-112 (Aug. 18, 2002), pp. 1-6.
Hill, Jason Lester, "System Architecture for Wireless Sensor Networks", Dissertation of Jason L. Hill, University of California, Berkeley (2003), 196 pages.
Hoareau, D et al., "Constraint-Based Deployment of Distributed Components in a Dynamic Network", LNCS, vol. 3894 (Mar. 16, 2006), pp. 450-464.
Information Society Technologies, "State of the Art in Resource Management on Wired and Wireless Access Networks with Resilience", Jul. 23, 2004, pp. 1-198.
Intel Research, "An Introduction to Wireless Sensor Networks", Technical Report, 2004, 6 pages.
Karuppiah, et al, "Design and Implementation of Multihomed IPv6 Testbed Network for Research Community: The Malaysian IPv6 Network Operation Centre Experience", IWS2000, APAN Conference, Tsukuba, 2000, 6 pages.
Kichkaylo, T et al., "Constrained Component Deployment in Wide-Area Networks Using AI Planning Techniques", Proceedings of the 17th International Symposium on Parallel and Distributed Processing 2003), pp. 1-10.
Kichkaylo, T et al., "Optimal Resource-Aware Deployment Planning for Component-Based Distributed Applications", HPDC '04: Proceedings of the 13th IEEE International Symposium on High Performance Distributed Computing (HPDC '04), IEEE Computer Society (2004), pp. 150-159.
Kim, et al, "A leader election algorithm in a distributed computing system", 5th IEEE Workshop on Future Trends of Distributed Computing Systems, 1995, 5 pages.
Kiselyov, "Functional XML parsing framework: SAX/DOM and SXML parsers with support for XML Namespaces and validation", 2001, 42 pages.
Koh, et al, "Securing the Pharmaceutical Supply Chain", White Paper, Jun. 1, 2003, 19 pages.
Lacour, S et al., "A Software Architecture for Automatic Deployment of CORBA Components Using Grid Technologies", Networking and Internet Architecture, DECOR04 (Nov. 24, 2004), pp. 187-192.
Lampe, et al, "A ubiquitous computing environment for aircraft maintenance", SAC '04: Proceedings of the 2004 ACM Symposium on Applied Computing, 2004, pp. 1586-1592.
Law, et al, "Assessing Security-Critical Energy-Efficient Sensor Networks", 2002, 10 pages.
Levis, Philip et al., "TinyOS: An Operating System for Sensor Networks", Feb. 17, 2004, pp. 1-32.
Liu, Jinshan et al., "Group Management for Mobile Ad Hoc Networks: Design, Implementation and Experiment", Proceedings of the 6th International Conference on Mobile Data Management, Ayia Napa Cyprus, May 13, 2005, 8 pages.
Liu, Jinshan et al., "QoS-aware Service Location in Mobile Ad-Hoc Networks", Proceedings of the 5th International Conference on Mobile Data Management, Berkeley, CA USA, Jan. 2004, 12 pages.
Malek, S et al., "A decentralized redeployment algorithm for improving the availability of distributed systems", LNCS, vol. 3798 (Nov. 3, 2005), 13 pgs.
Malek, S et al., "A style-aware architectural middleware for resource-constrained,distributed systems", IEEE Transactions on Software Engineering, vol. 31, Issue 3 (Mar. 2005), pp. 256-272.
Malpani, et al, "Leader election algorithms for mobile ad hoc networks", Proceedings of the 4th international Workshop on Discrete Algorithms and Methods for Mobile Computing and Communications, Aug. 11, 2000, pp. 96-103.
Mikic-Rakic, M et al., "A tailorable environment for assessing the quality of deployment architectures in highly distributed settings", Second International Working Conference on Component Deployment (2004), pp. 1-15.
Mikic-Rakic, M et al., "Improving availability in large, distributed component-based systems via redeployment", LNCS, vol. 3798 (Nov. 3, 2005), 15 pgs.
Nochta, et al, "Relocatable services and service classification scheme", Authorization Level: Public (PU) Version 1.0, Feb. 2005, 59 pages.
Nokia, "Nokia Intellisync Device Management", Overview for IT Managers, May 2007, 19 pages.
Non Final Office Action received for U.S. Appl. No. 11/444,119, mailed on Aug. 28, 2009, 19 pages.
Non Final Office Action Response for U.S. Appl. No. 11/496,641, filed Sep. 7, 2011, 13 pages.
Non-Final Office Action for U.S. Appl. No. 11/283,618, mailed Mar. 31, 2011, 33 pages.
Non-Final Office Action for U.S. Appl. No. 11/444,279, mailed Apr. 28, 2011, 36 pages.
Non-Final Office Action for U.S. Appl. No. 11/479,284, mailed Oct. 30, 2009, 19 pages.
Non-Final Office Action for U.S. Appl. No. 11/496,641, mailed on Jun. 7, 2011, 37 pages.
Non-Final Office Action for U.S. Appl. No. 11/583,274, mailed Aug. 5, 2010, 21 pages.
Non-Final Office Action for U.S. Appl. No. 11/583,274, mailed Oct. 7, 2009, 22 pages.
Non-Final Office Action mailed May 14, 2008 for U.S. Appl. No. 11/479,284, 16 pgs.
Non-Final Office Action mailed Nov. 1, 2007 for U.S. Appl. No. 11/284,195, 14 pgs.
Non-Final Office Action mailed Oct. 28, 2008 for U.S. Appl. No. 11/283,618, 35 pgs.
Non-Final Office Action received for U.S. Appl. No. 11/396,299, mailed on Jul. 9, 2009, 15 pages.
Non-Final Office Action received for U.S. Appl. No. 11/444,119, mailed on Feb. 27, 2009, 23 Pages.
Non-Final Office Action Response for U.S. Appl. No. 11/444,279, filed Oct. 7, 2011, 8 pages.
Notice of Allowance for U.S. Appl. No. 11/284,195, mailed Mar. 4, 2011, 46 pages.
Notice of Allowance for U.S. Appl. No. 11/284,195, mailed on Jun. 27, 2011, 17 pages.
Notice of Allowance for U.S. Appl. No. 11/284,195, mailed on Mar. 4, 2011, 45 pages.
Notice of Allowance for U.S. Appl. No. 11/444,119, mailed Apr. 1, 2011, 49 pages.
Notice of Allowance for U.S. Appl. No. 11/444,119, mailed on Apr. 1, 2011, 26 pages.
Notice of Allowance for U.S. Appl. No. 11/444,119, mailed on Oct. 5, 2011, 17 pages.
Notice of Allowance for U.S. Appl. No. 11/444,279, mailed on Oct. 27, 2011, 13 pages.
Notice of Allowance for U.S. Appl. No. 11/479,284, mailed Aug. 11, 2010, 19 pages.
Notice of Allowance for U.S. Appl. No. 11/479,284, mailed on May 13, 2010, 30 pages.
Notice of Allowance for U.S. Appl. No. 11/479,284, mailed on Oct. 13, 2010, 19 pages.
Notice of Allowance for U.S. Appl. No. 11/583,274, mailed on Apr. 4, 2011, 28 pages.
Office Action for Chinese Application No. 200710108723.3 (including English Translation), mailed May 21, 2010, 11 pages.
Office Action for Chinese Patent Application No. 200610149268.7 (including English Translation), mailed on Mar. 1, 2010, 16 pages.
Office Action for Chinese Patent Application No. 200610149270.4 (including English Translation), mailed on Mar. 1, 2010, 18 pages.
Office Action for CN Application No. 200710108722.9 (with English Translation), mailed Jun. 2, 2010, 9 pages.
Office Action for Japanese Patent Application No. 2006-314565 (including English Translation), mailed on Feb. 12, 2010, 9 pages.
Office Action for U.S. Appl. No. 11/283,618, mailed on May 24, 2010, 42 pages.
Office Action for U.S. Appl. No. 11/396,299, mailed on Jan. 28, 2010, 54 pages.
Office Action for U.S. Appl. No. 11/444,119, mailed on Mar. 30, 2010, 45 pages.
Office Action for U.S. Appl. No. 11/496,641, mailed on Jul. 29, 2010, 63 pages.
Office Action for U.S. Appl. No. 11/583,274, mailed on Apr. 7, 2010, 17 pages.
Office Action for U.S. Appl. No. 11/871,616, mailed on Mar. 9, 2010, 39 pages.
Overeinder, B. et al., "A Dynamic load balancing system for parallel cluster computing", Future Generations computer Systems, Elsevier Science Publishers, Amsterdam, 12, (1), (May 1996), pp. 101-115.
Paradis, L. et al., "A survey of Fault Management in Wireless Sensor Networks", Journal of Network and systems management, Kluwer Academic Publishers, NE, vol. 15 No. 2, Mar. 13, 2007, pp. 171-190.
Parikh, et al, "Security in Sensor Networks", CS 588: Cryptography, 2001, 28 pages.
Park, "Specification of the Bluetooth System: Wireless connections made easy", Covered Core Package version: 1.2, Nov. 2003, 1200 pages.
Passing, "Profiling, Monitoring and Tracing in SAP WebAS", SAP Library, Jun. 22, 2005, 9 pages.
Perkins, C. et al., "IP Mobility Support for IPv4", IETF Standard, Internet Engineering Task Force (Aug. 2002), pp. 1-100.
Perkins, C., "IP Mobility Support for IPv4", Network Working Group, Nokia Research Center, Aug. 2002, 23 pages.
Phillips, "Aqueduct: Robust and Efficient Code Propagation in Heterogeneous Wireless Sensor Networks", Master's Thesis submitted to the Graduate School of the University of Colorado, 2005, 61 pages.
Ploennigs, J et al., "A traffic model for networked devices in the building automation", In: Proceedings of the 5th IEEE International Workshop on Factory Communication Systems (WFCS 2004), Vienna, Austria, (2004), pp. 137-145.
Postel, "Internet Control Message Protocol", Protocol Specification. Request for Comments RFC 792, Sep. 1981, 21 pages.
Postel, "Internet Protocol", Protocol Specification, Request for Comments RFC 791, Sep. 1981, 51 pages.
Postel, "Transmission Control Protocol", Protocol Specification, Request for Comments RFC 793, Sep. 1981, 91 pages.
Postel, "User Datagram Protocol", Protocol Specification, Request for Comment, RFC 768, Information Sciences Institute, Aug. 1980, 3 pages.
Prabhu, B S., et al., "WinRFID-A Middleware for the Enablement of Radio Frequency Identification (RFID) Based Applications", Mobile, Wireless and Sensor Networks (Mar. 28, 2006), pp. 1-23.
Rebahi, et al, "Service Management Module (SMM)", 2004, 61 pages.
Restriction Requirement received for U.S. Appl. No. 11/444,279, mailed on May 5, 2009, 5 pages.
Rostad, et al, "Closing the Product Lifecycle Information Loops", 18th International Conference on Production Research, 2005, 5 pages.
SAP, "SAP NetWeaver: Adaptive Technology for the Networked Enterprise", Feb. 2005, retrieved on Sep. 9, 2010 from http://web.archive.org/web/*/http://www.sap.com/solutions/netweaver/index.epx, 1 page.
SAP, "Security Guide for Mobile Engine 2.1 SP02", SAP Library—SAP Mobile Engine, Dec. 1, 2004, 13 pages.
SAX, "About SAX", Dec. 29, 2004, retrieved on Sep. 9, 2010 from http://web.archive.org/web/20041229165357/http://www.saxproject.org/, 1 page.
Scheer, "Aris-Business Process Modeling", Springer 3rd edition, 2000, 10 pages.
Schlimmer, et al, "Devices Profile for Web Services", May 2005, 39 pages.
Schlimmer, et al, "Web Services Dynamic Discovery (WS-Discovery)", Apr. 2005, 42 pages.
Schneider, et al, "Application and Scenarios of RFID technology", Seminar Datenschutzaspekte im Umfeld des Pervasive Computing, 2004, 29 pages.
Schneier, "Applied Cryptography", 2nd edition, John Wiley & Sons, Inc., 1996, 18 pages.
Sgroi, Marco et al., "A Service-Based Universal Application Interface for Ad-hoc Wireless Sensor Networks", Preliminary Draft (Nov. 26, 2003), pp. 1-39.
Skouteli, Chara et al., "Concept-Based Discovery of Mobile Services", Proceedings of the 6th International Conference on Mobile Data Management, Ayia Napa Cyprus, May 13, 2005, 5 pages.
Speiss, "Collaborative Business Items: Decomposing Business Process Services for Execution of Business Logic on the Item", European Workshop on Wireless Sensor Networks, Istanbul, 2005, 3 pages.
Speiss, et al, "Collaborative Business Items", Sixth Framework Programme, Information Society Technology Technical Report, CoBIsDeliverable D101, 2005, 59 pages.
Speiss, et al, "Going beyond auto-id—a service-oriented smart items infrastructure", JEIM, Mar. 2007, 9 pages.
Spiess, P., et al, "Collaborative Business Items", Deliverable 401: Final Project Report, CoBIs Project No. IST-004270, Version 2.0 (Mar. 2007), pp. 1-42.
Spiess, P., et al, "Collaborative Business Items", Deliverable 401: Management & Maintenance Requirements, CoBIs Project No. IST-004270, Version 1.0 (Jan. 2005), 21 pgs.
Spiess, Patrik et al., "Going Beyond Auto-ID: A Service-oriented Smart Items Infrastructure", Journal of Enterprise Information Management, vol. 20, Issue 3 (2007), pp. 1-9.
Srivastava, Utkarsh et al., "Operator Placement for In-Network Stream Query Processing", Proceedings of the 24th ACM SIGMOD-SIGACT-SIGART Symposium on Principles of Database Systems (Dec. 2004), pp. 1-10.
Stewart, C et al., "Profile driven Component Placement for Cluster-based Online Services", IEEE Distributed Systems Online, vol. 5, No. 10, (Oct. 2004), p. 1-6.
Strohbach, et al, "Cooperative Artefacts:Assessing Real World Situations with Embedded Technology", In Proceedings of the 6th International Conference on Ubiquitous Computing, Nottingham, UK, 2004, pp. 250-267.
Sun Microsystems, "Connected Limited Device Configuration", Java™ 2 Platform, Micro Edition (J2MET™) Specification Version 1.1, Mar. 2003, 60 pages.
Sun Microsystems, "Jini Architecture Specification", Version 1.2, Dec. 2001, 26 pages.
Sun Microsystems, "Sun SPOT System: Turning Vision into Reality", Sun SPOT System Project description, 2005, 4 pages.
Talwar, et al, "Approaches for Service Deployment", IEEE Internet Computing, vol. 9(2), Mar.-Apr. 2005, pp. 70-80.
US 7,801,983, 09/2010, Bornhoevd et al. (withdrawn).
van de Loo, et al, "Enterprise Services Design Guide", Version 1.0, SAP, 2005, pp. 1-40.
van der Aalst, "Modelling and analysing workflow using a Petri-net based approach", Proceedings of the 2nd Workshop on Computer-Supported Cooperative Work, Petri nets and related formalisms, 1994, pp. 31-50.
Vasudevan, Sudarshan et al., "Design and Analysis of a Leader Election Algorithm for Mobile Ad Hoc Networks", Proceedings of 12th IEEE ICNP, Oct. 8, 2004, 11 pages.
Veizades, et al, "Service Location Protocol. Request for Comments RFC 2165", Network Working Group, Jun. 1997, 72 pages.
VeriSign, "The EPCglobal Network: Enhancing the Supply Chain", VeriSign Technical Report, 2004, 8 pages.
Vigna, Giovanni "Mobile Code Technologies, Paradigms, and Applications", PhD Thesis, Politecnico di Milano, Milano, Italy, (1998), pp. 1-89.
Villanueva, et al, "Context-Aware QoS Provision for Mobile Ad-hoc Network-based Ambient Intelligent Environments", Header Background Image, 12(3), 2006, 13 pages.
Waldo, "The Jini architecture for network-centric computing", Communications of the ACM archive, vol. 42 , Issue 7, Jul. 1999, pp. 76-82.
Wander, et al, "Energy Analysis of Public-Key Cryptography for Wireless Sensor Networks", UC Santa Cruz, Sun Microsystems Laboratories, 2005, 5 pages.
Wang, et al, "Timing Analysis of Real-Time Networked RFID Systems", Cambridge Auto-ID Lab, Cambridge UK, 2004, 4 pages.
Warneke, et al, "Smart dust: Communicating with a cubic-millimeter computer", Computer, 34(1), 2001, pp. 44-51.
Wegdam, M et al., "Dynamic reconfiguration and load distribution in component middleware", PhD thesis, University of Twente, Enschede, (2003), pp. 1-257.
Weiser, "The computer for the 21st century", ACM SIGMOBILE Mobile Computing and Communications Review archive, vol. 3 , Issue 3, Jul. 1999, 6 pages.
Wiemann, M. et al., "A Service and Device Monitoring Service for Smart Items Infrastructures", Third International Conference on Wireless and Mobile Communications 2007, ICWMC, 6 pages.
Wonohoesodo, R et al., "A Role Based Access Control for Web Services", Proceedings of the 2004 IEEE International Conference on Services Computing (2004), pp. 49-56.
Woods, "Enterprise Services Architecture", Galileo Press, 2003, 10 pages.
Wu, Q et al., "Adaptive component allocation in scudware middleware for ubiquitous computing", LNCS, vol. 3824 (Dec. 6, 2005), pp. 1155-1164.
Wu, X et al., "Performance modeling from software components", ACM SIGSOFT Software Engineering Notes, vol. 29, Issue 1 (Jan. 2004), pp. 290-301.
Yao, Yong et al., "Query Processing for Sensor Networks", Proceedings of the 2003 CIDR Conference, Jan. 2003, 12 pages.
Yoonhee, K. et al., "Wapee: A Fault-Tolerant Semantic Middleware in Ubiquitous Computing Environments", Proceedings of EUC Workshops, 2006, pp. 173-182.

Cited By (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9268510B2 (en) 2003-04-23 2016-02-23 Canon Kabushiki Kaisha Information processing apparatus and connection control method for searching for a printer having a predetermined function identified by identification information included in a beacon signal and sending a print request directly to the printer which is operating as an access point without going through an external access point
US9167371B2 (en) * 2003-04-23 2015-10-20 Canon Kabushiki Kaisha Wireless communication system, and wireless communication device and control method for establishing a connection with another wireless device before an elapsed time period without the intervention of a base station
US8756305B2 (en) 2003-04-23 2014-06-17 Canon Kabushiki Kaisha Information processing apparatus and connection control method for joining a wireless network and searching for a printer having a predetermined function
US8522341B2 (en) 2006-03-31 2013-08-27 Sap Ag Active intervention in service-to-device mapping for smart items
US8751644B2 (en) 2006-05-31 2014-06-10 Sap Ag Modular monitor service for smart item monitoring
US8769095B2 (en) * 2006-10-03 2014-07-01 Axeda Acquisition Corp. System and method for dynamically grouping devices based on present device conditions
US9491071B2 (en) 2006-10-03 2016-11-08 Ptc Inc. System and method for dynamically grouping devices based on present device conditions
US10212055B2 (en) 2006-10-03 2019-02-19 Ptc Inc. System and method for dynamically grouping devices based on present device conditions
US9712385B2 (en) 2006-12-26 2017-07-18 PTC, Inc. Managing configurations of distributed devices
US9491049B2 (en) 2006-12-26 2016-11-08 Ptc Inc. Managing configurations of distributed devices
US8788632B2 (en) 2006-12-26 2014-07-22 Axeda Acquisition Corp. Managing configurations of distributed devices
US9288132B2 (en) 2007-03-21 2016-03-15 Inteco Systems Limited Method and system for monitoring messages passed over a network
US20080235366A1 (en) * 2007-03-21 2008-09-25 Inetco Systems Limited Method and system for monitoring messages passed over a network
US8719411B2 (en) 2007-03-21 2014-05-06 Inetco Systems Limited Method and system for monitoring messages passed over a network
US8396959B2 (en) * 2007-03-21 2013-03-12 Inetco Systems Limited Method and system for monitoring messages passed over a network
US10447705B2 (en) 2008-08-14 2019-10-15 Microsoft Technology Licensing, Llc Cloud-based device information storage
US20100161804A1 (en) * 2008-12-18 2010-06-24 Electronics And Telecommunications Research Institute System and method for providing device file using device identifier
US8566448B2 (en) * 2008-12-18 2013-10-22 Electronics And Telecommunications Research Institute System and method for providing device file using device identifier
US20120150892A1 (en) * 2009-08-18 2012-06-14 Nec Corporation Information processing apparatus, information processing system, information processing method, and information processing program
US8751517B2 (en) * 2009-08-18 2014-06-10 Nec Corporation Information processing apparatus, information processing system, information processing method, and computer readable non-transitory medium
US20120262292A1 (en) * 2011-04-14 2012-10-18 Martin Moser Portable device inventory tracking
US9348943B2 (en) 2011-11-16 2016-05-24 Ptc Inc. Method for analyzing time series activity streams and devices thereof
US10025880B2 (en) 2011-11-16 2018-07-17 Ptc Inc. Methods for integrating semantic search, query, and analysis and devices thereof
US9965527B2 (en) 2011-11-16 2018-05-08 Ptc Inc. Method for analyzing time series activity streams and devices thereof
US9098312B2 (en) 2011-11-16 2015-08-04 Ptc Inc. Methods for dynamically generating an application interface for a modeled entity and devices thereof
US9578082B2 (en) 2011-11-16 2017-02-21 Ptc Inc. Methods for dynamically generating an application interface for a modeled entity and devices thereof
US9576046B2 (en) 2011-11-16 2017-02-21 Ptc Inc. Methods for integrating semantic search, query, and analysis across heterogeneous data types and devices thereof
US9026563B2 (en) 2012-02-02 2015-05-05 Salesforce.Com, Inc. Mechanism for facilitating dynamic social media-based management of assets in an on-demand services environment
US8996588B2 (en) 2012-02-02 2015-03-31 Salesforce.Com, Inc. Mechanism for facilitating dynamic management of assets in an on-demand services environment
US9158532B2 (en) 2013-03-15 2015-10-13 Ptc Inc. Methods for managing applications using semantic modeling and tagging and devices thereof
US9754123B2 (en) 2013-05-24 2017-09-05 Microsoft Technology Licensing, Llc User centric data maintenance
US9405932B2 (en) 2013-05-24 2016-08-02 Microsoft Technology Licensing, Llc User centric data maintenance
US9311109B2 (en) 2013-05-29 2016-04-12 Microsoft Technology Licensing, Llc Synchronizing device association data among computing devices
US9178939B2 (en) 2013-12-23 2015-11-03 International Business Machines Corporation Auto incorporation of new components into a hierarchical network
US9178770B2 (en) 2013-12-23 2015-11-03 International Business Machines Corporation Auto incorporation of new components into a hierarchical network
US9350812B2 (en) 2014-03-21 2016-05-24 Ptc Inc. System and method of message routing using name-based identifier in a distributed computing environment
US9462085B2 (en) 2014-03-21 2016-10-04 Ptc Inc. Chunk-based communication of binary dynamic rest messages
US9762637B2 (en) 2014-03-21 2017-09-12 Ptc Inc. System and method of using binary dynamic rest messages
US9961058B2 (en) 2014-03-21 2018-05-01 Ptc Inc. System and method of message routing via connection servers in a distributed computing environment
US9560170B2 (en) 2014-03-21 2017-01-31 Ptc Inc. System and method of abstracting communication protocol using self-describing messages
US9467533B2 (en) 2014-03-21 2016-10-11 Ptc Inc. System and method for developing real-time web-service objects
US10025942B2 (en) 2014-03-21 2018-07-17 Ptc Inc. System and method of establishing permission for multi-tenancy storage using organization matrices
US9350791B2 (en) 2014-03-21 2016-05-24 Ptc Inc. System and method of injecting states into message routing in a distributed computing environment
US10313410B2 (en) 2014-03-21 2019-06-04 Ptc Inc. Systems and methods using binary dynamic rest messages
US10338896B2 (en) 2014-03-21 2019-07-02 Ptc Inc. Systems and methods for developing and using real-time data applications
US10432712B2 (en) 2014-03-21 2019-10-01 Ptc Inc. System and method of injecting states into message routing in a distributed computing environment
US9699040B2 (en) 2014-09-30 2017-07-04 Vivint, Inc. Systems and methods for monitoring globally distributed remote storage devices
US10560350B2 (en) 2014-09-30 2020-02-11 Vivint, Inc. Systems and methods for monitoring globally distributed remote storage devices
US11297688B2 (en) 2018-03-22 2022-04-05 goTenna Inc. Mesh network deployment kit
US11681669B2 (en) 2020-06-22 2023-06-20 HCL Technologies Italy S.p.A. Method and system for correlating multiple device entries within domain

Also Published As

Publication number Publication date
CN101083587B (en) 2011-04-20
US20070282988A1 (en) 2007-12-06
EP1862957A1 (en) 2007-12-05
CN101083587A (en) 2007-12-05

Similar Documents

Publication Publication Date Title
US8296413B2 (en) Device registration in a hierarchical monitor service
US8751644B2 (en) Modular monitor service for smart item monitoring
US11356350B2 (en) Internet of things event management systems and methods
US8527622B2 (en) Fault tolerance framework for networks of nodes
US8065411B2 (en) System monitor for networks of nodes
US7860968B2 (en) Hierarchical, multi-tiered mapping and monitoring architecture for smart items
US8156208B2 (en) Hierarchical, multi-tiered mapping and monitoring architecture for service-to-device re-mapping for smart items
US8510732B2 (en) Distributed asset management system and method
US20070118496A1 (en) Service-to-device mapping for smart items
KR100998307B1 (en) Distributed rule processing for ubiquitous computing environments
US20090204702A1 (en) System and method for network management using self-discovering thin agents
EP4030727A1 (en) Wireless connectivity for autonomous devices
Mascolo et al. Survey of middleware for networked embedded systems
US20100185714A1 (en) Distributed communications between database instances
US8493211B2 (en) Providing event indications to prevent indication storms in an event model
US8910182B2 (en) Managing and simplifying distributed applications
Zhang et al. A distributed system for mad-cow disease monitoring and tracking

Legal Events

Date Code Title Description
AS Assignment

Owner name: SAP AG, GERMANY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BORNHOEVD, CHRISTOF;MO, BRIAN S.;WIEMANN, MATTHIAS M.;REEL/FRAME:018232/0778;SIGNING DATES FROM 20060719 TO 20060730

Owner name: SAP AG, GERMANY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BORNHOEVD, CHRISTOF;MO, BRIAN S.;WIEMANN, MATTHIAS M.;REEL/FRAME:018232/0825;SIGNING DATES FROM 20060719 TO 20060730

Owner name: SAP AG, GERMANY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BORNHOEVD, CHRISTOF;MO, BRIAN S.;WIEMANN, MATTHIAS M.;SIGNING DATES FROM 20060719 TO 20060730;REEL/FRAME:018232/0778

Owner name: SAP AG, GERMANY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BORNHOEVD, CHRISTOF;MO, BRIAN S.;WIEMANN, MATTHIAS M.;SIGNING DATES FROM 20060719 TO 20060730;REEL/FRAME:018232/0825

AS Assignment

Owner name: SAP AG, GERMANY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BORNHOEVD, CHRISTOF;MO, BRIAN S.;WIEMANN, MATTHIAS M.;REEL/FRAME:018576/0813;SIGNING DATES FROM 20060719 TO 20060730

Owner name: SAP AG, GERMANY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BORNHOEVD, CHRISTOF;MO, BRIAN S.;WIEMANN, MATTHIAS M.;SIGNING DATES FROM 20060719 TO 20060730;REEL/FRAME:018576/0813

AS Assignment

Owner name: SAP AG, GERMANY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BORNHOEVD, CHRISTOF;MO, BRIAN S.;WIEMANN, MATTHIAS M.;REEL/FRAME:018719/0460;SIGNING DATES FROM 20060719 TO 20060730

Owner name: SAP AG, GERMANY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BORNHOEVD, CHRISTOF;MO, BRIAN S.;WIEMANN, MATTHIAS M.;SIGNING DATES FROM 20060719 TO 20060730;REEL/FRAME:018719/0460

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: SAP SE, GERMANY

Free format text: CHANGE OF NAME;ASSIGNOR:SAP AG;REEL/FRAME:033625/0334

Effective date: 20140707

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8