Smarter Planet solutions with sensor monitoring, Part 1: Building solutions using WebSphere Sensor Events

Smarter Planet™ initiatives are playing a major role in how we recognize where technology is shaping our interactions with the world around us. Common to many of these initiatives is the observation and processing of sensor data to extract insights about the physical world. This is the first in a series of articles that shows how IBM® WebSphere® Sensor Events, IBM WebSphere Business Events, and other enterprise products can be used to develop Smarter Planet solutions that leverage sensor event processing. Part 1 discusses the commonalities of Smarter Planet initiatives, shows how sensor data collection, interpretation, and response are at the core of many of these initiatives, and explains how this all plays into the "instrumented, intelligent, and interconnect" theme. This content is part of the IBM WebSphere Developer Technical Journal.


Tim Hanis (, WebSphere Sensor Events Chief Architect, IBM

Tim Hanis is the lead architect in WebSphere Sensor Events development at IBM in Research Triangle Park, NC. He has led a number of development projects within IBM and has extensive experience helping customers solve business problems with WebSphere products.

developerWorks Contributing author

Allen Smith ( ), Senior Software Engineer, IBM

Allen Smith is a Senior Certified IT Specialist in IBM's Application and Integration Middleware Software group in Research Triangle Park, North Carolina. He works with business partners to design and implement sensor based solutions using WebSphere Sensor Events. You can contact Allen at

developerWorks Contributing author

John Senegal (, WebSphere Sensor Events Lead Developer, IBM  

John Senegal is the lead developer for WebSphere Sensor Events Server at IBM in Research Triangle Park, NC. He has broad experience working with IBM customers and partners building solutions using IBM tooling and middleware.

Ken Greenlee (, Advisory Software Engineer, IBM  

Ken Greenlee is an Advisory Software Engineer with the WebSphere Sensor Events team at IBM in Research Triangle Park, NC. He has extensive Java/WebSphere experience and is responsible for many components within the WebSphere Sensor Events server product. He has worked with customers to create solutions based upon the WebSphere Sensor Events software stack. He has reached the third patent plateau, most on RFID technologies.

Bruce Hyre (, Senior Software Engineer, IBM  

Bruce Hyre is a Senior Software Engineer with the IBM Sensor Solutions in Research Triangle Park, North Carolina. He specializes in the design and integration of WebSphere Sensor Events with business partners and device manufacturers.

04 November 2009

Also available in Chinese


Whether you are talking about a smarter traffic system in Stockholm, smarter supply chain management at a trade group in Düsseldorf, smarter railway systems developed at the IBM Global Rail Innovation Center in Beijing, or smarter water management for the Hudson River, the common, fundamental principle is similar: Each of these solutions is based on the observation and processing of sensor data to extract insights about the physical world, so that the appropriate action based on the interpretation of that data can be taken.

Let’s examine how IBM WebSphere Sensor Events can participate in critical aspects of smarter planet initiatives.

  • Instrumented

    WebSphere Sensor Events integrates and collects sensor data from a range of devices. These can include:

    • Condition data, such as temperature, humidity, shock and vibration.
    • Location-tracking data, such as fleet monitoring, hospital asset tracking, warehouse management, personnel safety, and security.
    • Identification data for use in physical gateway or threshold boundary tracking, such as supply chain monitoring, inventory, work in process, and usage.

    WebSphere Sensor Events is an integration platform that provides the infrastructure to collect, filter, and analyze this data, and then turn it into the actionable events that drive business responsiveness to real world opportunities and risks.

  • Interconnected

    While providing a platform that can be used for connecting to sensors to collect new data, WebSphere Sensor Events also provides the integration infrastructure to connect that data to business processes. WebSphere Sensor Events provides the framework to normalize both the sensor event data and the operations of sensor-control services. It uses industry standards, where available, so that businesses can easily and reliably connect with these new sources of data. However, interconnectivity doesn’t focus solely on sensor integration. You can use the business observations derived from these new data sources both within your enterprise and extended to trading partners across the globe.

  • Intelligent

    WebSphere Sensor Events links the instrumented data and provides interconnectivity services to collect and process that data. A key to gaining value from a collection of raw event data is the process by which business-actionable intelligence is derived from that data. The derived intelligence is business outcomes, like asset utilization of containers, freshness of food, or lowering of inventory. WebSphere Sensor Events is in use in deployments around the world to provide the framework on which that analysis is performed. Working closely with WebSphere Business Events, you can define and detect event patterns that enable lines-of-business personnel to establish and refine the business rules that identify business events from a continuous flow of sensor event data. With this intelligence, you can respond to opportunities and risks as they happen, in near real-time.

An enterprise foundation for sensor event solutions

In an event-driven system, events are produced and published out on a common channel, where interested subscribers can receive and react to them. Event processing is very loosely coupled and often distributed. Neither the event producer nor the event itself participates in the determination of any subsequent execution processing. This processing flow is strictly determined by the event consumers and the actions they take.

WebSphere Sensor Events supports the event-driven architecture with critical components that comprise key aspects of the event system. Let’s take a look at how that occurs in the context of the high level WebSphere Sensor Events architecture shown in Figure 1.

Figure 1. High level architecture for WebSphere Sensor Events showing event runtime infrastructure
Figure 1. High level architecture for WebSphere Sensor Events showing event runtime infrastructure
  • Sensor sources

    Events can be generated from a wide variety of sources including radio frequency identification (RFID) sensors, other types of sensors (such as temperature, shock, or humidity), health monitors, applications, services, business processes, and alert or notification systems. Events can be screened, filtered, aggregated, annotated or augmented as part of the system’s simple event processing phase.

    In the WebSphere Sensor Events architecture, this simple event processing is typically performed at the data capture layer.

  • Data capture

    The data capture component of WebSphere Sensor Events manages the direct integration with the sensor devices and pushes the event data onto the server event processing channel. Simple event processing (such as filtering, aggregation, and validation) in data capture can optimize processing on event data to support highly interactive local behavior, and also minimize unnecessary traffic to the server. Consistent with the event model, the event source is responsible for asynchronous delivery of event messages on a frequency that it determines.

    In Figure 1, you can see that the data capture environment is intended to run in a distributed model and close to the event data sources. The data capture environment provides a run time platform based on Java™ that executes on device controllers to support critical application logic, which can benefit from close physical proximity to the sensor event devices. With data capture, that application logic can be written in Java and deployed on a wide range of controller devices -- while providing native communication support to an increasing number of sensor event devices and device types.

    One family of sensor devices is RFID readers. However, sensor devices are not limited to RFID. They can include environmental sensors, location sensors, optical sensors, acoustic sensors and many others. Data capture provides the run time framework that can be extended to support these types of devices. With data capture, a common Java application programming interface (API) insulates the application logic from the device-specific API or protocol.

    Data capture provides that native device communication and mapping to the common API. It also provides a set of common low-level services to act on that sensor data (such as event filtering and aggregation). Beyond that, it provides a reliable messaging transport of the sensor data back to WebSphere Sensor Events in a common format and protocol.

    Data capture runs on OSGi to support the distributed run time environment. WebSphere Sensor Events manages the configuration definition and software loading of the distributed data-capture environments.

  • Sensor event format

    In event-driven systems, event sources and event listeners are, in general, loosely coupled. Therefore, an understanding of the format of the event data is critical to event processing. Events that are generated in non-compliant formats must be converted before being placed on the event notification channel prior to processing. In WebSphere Sensor Events, the event format is defined within a Common Base Events (CBEs) structure. CBE defines a common header with a generic payload. Payload format extensions are fully supported.

    There are no widely-adopted industry standards for business event formats. However, the Web Services Distributed Management (WSDM) specification from the Organization for the Advancement of Structured Information Standards (OASIS) includes a format specification for Web services. That format specification is known as WSDM Event Format (WEF). IBM’s implementation of that specification is the CBE. WebSphere Sensor Events relies on the CBE event format specification for the envelope of the event message for flow control and routing. The event data itself is contained within the CBE as a payload field that can either leverage predefined payload structures or be extended to create new payloads.

  • WebSphere Application Server messaging

    WebSphere Application Server messaging is used as the underlying messaging engine for event processing. Sources generate event messages that are ultimately published to the bus through the WebSphere Sensor Events gateway. The gateway is responsible for parsing the incoming event message, converting the CBE message into an object, and publishing that object on the bus with the appropriate topic name (as dictated by specific CBE header values). Services that have been configured to listen to messages on the bus can consume those messages, deliver specific functional value, and perhaps republish messages back on the bus that have been refined or enriched. These messages can also be published with a different topic name so that they can be consumed by different message services.

    Event processing occurs asynchronously and immediately when events are published to the bus. WebSphere Sensor Events provides a set of event processing services that can be invoked through a messaging interface (through message driven beans, which consume messages as they are published to the bus), an Enterprise Java Bean (EJB) interface, or through a Web Services interface.

  • WebSphere Enterprise Service Bus

    An Enterprise Service Bus (ESB), such as WebSphere ESB can be used with mediation flows that can invoke the services that are delivered with WebSphere Sensor Events. WebSphere Sensor Events delivers a set of event services that are available for external execution through their defined Web Services interface.

  • Business event processing

    Business event processing (BEP) engines manage the logical processing of events in order to recognize patterns and invoke actions based on defined rules. Those actions can specify that a specific business process is invoked, that a service is called, or that derived events are generated and put back into the system for further processing. BEP engines have sophisticated techniques for event correlation. These techniques are based on pattern matching and event definitions and can be spatial or temporal. Events happen in real time and the business rules need to be flexible enough to change which patterns of events should invoke specific business processes.

    WebSphere Business Events is bundled with WebSphere Sensor Events to provide the BEP capability of recognizing event patterns and either create an abstracted business event or directly execute a business process. Within a WebSphere Sensor Events deployment, WebSphere Business Events is integrated on the event messaging infrastructure and detects event patterns based on its rule definitions.

    Through a defined set of rules, those events are analyzed and correlated to trigger specific actions or to generate derived events. These in turn contribute to further analysis and correlation. Using this approach, analysis on low-level events can either progressively generate higher-level business events or invoke business processes. Similarly, high-level events can be decomposed into one or more low-level events or actions; for example, changing a pressure control valve, sounding an alarm, or signaling an alert.

  • Event services

    WebSphere Sensor Events provides a set of business-level event services that can be invoked from processes within WebSphere Sensor Events or from external business processes through their Web service interface. These services include event data persistence, event format conversion, integration with the complex event processing engine, administrative services, and others.

    Business-level components integrate on the bus through the publish/subscribe model, and can also be invoked from a business process. Over time, the collection of services will expand to support industry solutions as well as cross-industry generalized business services. Invocation of any given service will, in many cases, result in derived events being published out on the bus. These services, then, provide an explicit business function as well as provide an interaction point for generating new business events for further event-based processing.

  • Business process integration

    WebSphere Sensor Events provides an integration framework into the WebSphere business process management (BPM) suite of products. As mentioned earlier, WebSphere Sensor Events provides a set of business-level Web services that can be invoked from processes within the BPM products. For example, a business process defined using BPEL and running within WebSphere Process Server can invoke WebSphere Sensor Events services. The entire business process can be modeled and monitored using the appropriate BPM tools.

    In addition to providing services to be used by business processes, WebSphere Sensor Events services can also invoke business processes. As sensor data is analyzed and correlated, business events will be identified and business processes will need to be invoked. WebSphere Sensor Events can provide this capability through the mediation capability of WebSphere ESB. The details of external process invocation are mediated to insulate protocol and format differences. In addition, WebSphere Sensor Events provides integration services for integrating event messages directly with WebSphere Business Monitor, IBM InfoSphere Traceability Server and WebSphere Business Services.


Instrumentation, interconnection, and intelligence must be brought together to help you make the right decision at the right time to transform your businesses. IBM WebSphere Sensor Events provides the middleware platform for reaching out to sensor-based, real-time data to provide the event analysis that derives business events from sensor events, and to integrate those business events into business processes based on a service-oriented architecture (SOA).

The next articles in this series will look more closely at specific aspects within Smarter Planet initiatives, such as smarter supply chain, smarter health care, and process flow. Each of these articles will:

  • Describe an overall solution, its challenge areas, and a highlight of the expected business value.
  • Demonstrate how to segment the solution requirements, and show which product components and tools to use to address the key functional areas.
  • Define the approach and architecture of the overall solution.
  • Provide a detailed implementation discussion, including example code and other appropriate solution artifacts, on a set of critical components on which core elements of the solution are based.
  • Show how the proposed solution addresses the requirements and delivers business value.

The concluding article will then tie together the commonalities, recommendations, patterns, and practices discussed throughout the series. It will summarize the approach for designing Smarter Planet solutions and the reasoning used to determine how and when you should leverage available products, components, and services to build your solutions.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Smarter Planet solutions with sensor monitoring, Part 1: Building solutions using WebSphere Sensor Events