IBM WebSphere Premises Server (hereafter referred to as Premises Server) is an IBM middleware product that enables the integration of sensor event data into an enterprise business process. Sensor data includes RFID event data, but more generally includes event data from a wide variety of sources. These can be environmental monitoring devices, asset location tracking systems, plant floor management systems, and many other systems.
Service Oriented Architecture (SOA) is a software application approach that defines a component development and deployment model to enable applications to be created through the loose coupling of discrete functional components. The services themselves can be new business components or existing business functions that are exposed as services. A key attribute of SOA is the disassociation of how services can be invoked from how they have been developed (and where they execute). A key component of SOA-based business processes management is the tooling and runtime framework which is used to create business processes from those services.
Business process management (BPM) is an approach to facilitate business innovation and process improvement. To help organizations realize these goals, IBM provides a suite of SOA-based business process products that create the flexibility to adapt to business changes, help recognize where business process change is needed, and facilitate business decisions by exposing important business insights. It is those business insights that trigger and guide innovation and process improvements. Insights can be gained by a better analysis of existing business data. Insights can also be gained by expanding the reach of business observations to real-time events that occur every minute of every day in nearly all business operations.
Premises Server provides the middleware platform to reach out to that sensor-based, real-time data, to provide the event analysis that derives business events from sensor events, and to integrate those business events into SOA-based business processes. These business processes are often created with flows defined in a relatively linear fashion. For example, an order placement business process might include the steps of order validation, payment collection, and then finally order placement. The three steps in the process would be implemented as services, and the linear flow of execution based on a single order request defines the business process.
However, there are times when you want to execute business processes based on the recognition of specific patterns within disparate events. For example, applications that monitor real-time sensor data such as temperature, flow pressure, weight, and movement might need to analyze and correlate that data in order to invoke the correct recovery action. EDA defines an architectural pattern for applications that are designed to react to these events.
The interaction model in an environment that deploys both event-centric and service-centric strategies is commonly referred to as event-driven SOA. The next section descibes the key characteristics of an event-driven system and how EDA and integration into SOA are brought together in Premises Server.
Enterprise foundation for sensor event solutions
In an event-driven system, events are produced and published out on a common channel for interested subscribers to receive and react. 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.
Premises Server 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 Premises Server architecture shown in Figure 1.
Figure 1. Premises Server architecture
Event sources and simple event processing
Events can be generated from a wide variety of sources, including RFID sensors, other sensors (such as temperature, shock, or humidity), applications, services, business processes, and alert or notification systems. Events might be screened, filtered, aggregated, annotated, or augmented as part of the system’s simple event processing phase. In the Premises Server architecture, this simple event processing is typically performed at the Data Capture layer.
The Data Capture component of Premises Server 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 the event messages on a frequency that it determines. We’ll look more closely at the Data Capture environment and discuss the role it plays in a Premises Server EDA model later in this section.
As mentioned earlier, EDA event sources and event listeners are 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 prior to being placed on the event notification channel prior to processing. In Premises Server, the event format is defined as Common Base Events (CBEs). A 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 OASIS Web Services Distributed Management (WSDM) specification 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 Common Base Event. Because of the similarities in event data representation requirements and to leverage existing tools, infrastructure, and services, the CBE format has been adopted for event format specification within Premises Server.
Event communication channel
The event channel, typically a messaging system, is responsible for the inbound and outbound event communication, as well as the internal infrastructure, for a publish/subscribe event processing model. The WebSphere middleware Service Integration Bus (SIBus) is used as the common messaging engine for event processing. Sources publish event messages on the bus and event consumers subscribe to those messages.
Processing begins when events are delivered. Event processing occurs asynchronously when events are published to the bus. Premises Server delivers a set of event processing functions in the form of specialized message-driven beans called task agents. These task agents consume messages as they are made available on the SIBus.
Complex event processing
We should be clear here: within EDA an event does not explicitly invoke a service or process, or create a derived event. Similarly, the process that created the event does not know how that event should be handled. Events simply reflect the idea that something happened; the event itself takes no action. The creator of the event specifies no further action. It is up to other mechanism within the system to recognize that event and act accordingly. Within EDA, a complex event processing (CEP) engine is that mechanism.
CEP 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 Web service is called, or that other, derived events are generated and put back into the system for further processing. CEP engines have sophisticated techniques for event correlation, based on pattern matching and event definitions, and might 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.
The CEP engine in Premises Server is used to recognize event patterns to create a higher abstraction business event or directly execute a business process. Within a Premises Server deployment, the CEP engine is integrated on the event bus and monitors event traffic based on its configuration. The CEP action processing is also directly linked to invoke Web services.
Through a defined set of rules, those events are analyzed and correlated to trigger specific actions or generate derived events, which can in turn contribute to further analysis and correlation. With this approach, analysis on low-level events can progressively generate higher-level business events, or it can invoke business processes. Similarly, high-level events can be decomposed into one or more low-level events or actions, such as changing a pressure control valve; sounding an alarm, or signaling an alert. Therefore, you can see that the CEP engine acts to compose and invoke business events and actions. It also interprets business events and invokes low-level reactive processing.
The complex event processing engine, as well as Web services or other message listeners, all have the ability to generate and publish derived events on the event bus. Handlers for those events might, in turn, trigger another service or process -- or trigger the creation of one or more derived events. Through this, a single event or event sequence can trigger a series of asynchronous activities.
Web service integration
Premises Server provides a set of business-level event services that can be invoked from external business processes. These include services for 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. So, these services provide an explicit business function as well as an interaction point for generating new business events for further event-based processing.
Business process integration
Premises Server provides an integration framework into the WebSphere BPM suite of products. As mentioned above, Premises Server provides a set of business-level Web services that can be invoked by the BPM products. For example, a business process defined using BPEL and executing within IBM WebSphere Process Server can invoke Premises Server 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, Premises Server 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. Premises Server can provide this capability through the integration of complex event processing to WebSphere business event processing, and to the direct invocation of business processes defined within the BPM framework.
Data capture and delivery
Again, the Data Capture component of Premises Server manages the direct integration with the sensor devices. From the event-flow diagram in Figure 1, you see that the Data Capture environment is intended to run in a distributed model near the event data sources.
The Data Capture environment provides a Java™-based runtime platform that executes on device controllers to support critical application logic that can benefit from close physical proximity to the sensor event devices. Data Capture enables you to write application logic in Java and deploy it on a wide range of controller devices while providing native communication support to an increasing number of sensor event devices. One family of sensor devices is RFID readers. Sensor devices are not limited to RFID, and can include environmental sensors, location sensors, optical sensors, acoustic sensors, and many others. Data Capture provides the runtime framework that can be extended to support these types of devices. With Data Capture, a common Java API insulates the application logic from the device-specific API or protocol.
Data Capture provides 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). In addition, it provides a reliable messaging transport of the sensor data back to the Premises Server in a common format and protocol. Data Capture runs on OSGi to support the distributed runtime environment. Premises Server manages the configuration definition and software loading of the distributed Data Capture environments.
Putting design into practice
Up to this point we’ve discussed the event processing capabilities provided by Premises Server and, more generally, the origin of sensor events. What we haven’t discussed is how sensor devices can be connected to the Premises Server and how data captured from them is actually delivered to the Premises Server in the form of a sensor event.
Connecting sensor devices
Data Capture comprises a series of modules called agents. Each agent has a specific function. Some are responsible for interacting with hardware devices to capture raw hardware events, such as RFID tag reads, while others are responsible for filtering, aggregating and forwarding events to the Premises Server. Agents are written in Java and implemented as OSGi bundles.
Similar to the event processing on the Premises Server, Data Capture agents communicate with one another using a publish/subscribe model. Agents publish and subscribe to topics relevant to the function they provide. This loosely coupled form of interaction enables new agents to easily be plugged into the Data Capture runtime and, subsequently, a Premises Server solution. The publish/subscribe service within Data Capture is referred to as the notification service and is built on top of the OSGi Event Admin service.
Agents that interact with hardware devices are commonly referred to as device agents. These agents communicate with hardware devices using the device’s native protocol. When the device agent captures or receives data from its associated hardware, it publishes the data as an event message. For example, a device agent might publish an event message whenever it captures or receives data indicating a motion sensor has been triggered or that an RFID tag has been read. Regardless of the underlying device protocol, the published event messages conform to a common, well defined format that provides plug-and-play capability. Sensor devices from different manufacturers can be installed into a Premises Server solution without any changes to the business rules and processes that act on the sensor events generated by those devices.
Most event messages published and subscribed to by the Data Capture agents constitute local event processing. As mentioned earlier, this local event processing provides highly interactive local behavior and minimizes unnecessary server traffic. Only a subset of the Data Capture event messages is sent to the Premises Server for processing. For example, you might only be interested in a temperature change when it’s over two degrees, or unique RFID tag reads as opposed to duplicate reads. Event messages destined for the Premises Server are processed by a special agent. This agent converts the messages from the Data Capture event message format into the CBE event format expected by the Premises Server. Once converted, the event is delivered to the Premises Server via the Event Gateway. Event messages sent from Data Capture to the Premises Server are configurable, enabling new event flows to be easily added.
Adding support for new sensor devices can be accomplished through a variety of means. One way is through the creation of new Data Capture device agents. To create a new device agent you would need to implement two primary functions. First, the agent would need to communicate with the hardware device to capture the required data. Second, the agent would need to publish the captured data as an event message using the Data Capture notification service. If the sensor device is a type currently supported by the Premises Server (RFID readers for example), the device agent can publish one of the Data Capture event messages defined for that sensor device type. In this case, the event message will automatically get converted to a CBE event and get sent to the Premises Server via the event channel. If it’s a new sensor device type, or if the event message represents a new event for an existing sensor device type, the device agent would publish a custom event message.
An alternative to creating device agents is to send CBE events directly to the Premises Server using the Event Gateway. Sensor events flow into and out of the Premises Server via the Event Gateway. The Event Gateway converts incoming CBE events into sensor event objects and puts them onto the SIBus. It also pulls outgoing sensor events off the SIBus and converts them into CBE events. The Event Gateway provides three channels for sending events to the Premises Server: JMS message queue, HTTP, and Web service (Figure 2).
Figure 2. Event gateway channels
CBE events are expressed as XML documents. They consist of three main components: a header, a payload, and payload metadata. The header provides information about the origin of the event, such as who generated the event, and where and when it was generated. The payload captures the event data and the payload metadata provides additional information about the event. CBE events can be created using CBE-based Java classes or by using standard XML utilities. The Premises Server documents its predefined sensor events and provides a set of Java classes for creating them and their associated CBE representations. These classes can be easily extended to create custom sensor events to support any type of sensor event data.
With the addition of direct HTTP and Web service interfaces into the Premises Server, event producers now can send events directly to Premises Server without necessarily using the Data Capture environment. This increased flexibility enables integration from a wide variety of event sources that might not otherwise need to leverage the distributed application logic capability of Java and the OSGi programming environment provided with Data Capture. As long as your application can create an XML document and connect to one of the Event Gateway channels, you can send sensor events to the Premises Server.
So exactly how do captured sensor events result in the invocation of SOA-based business processes?
As discussed earlier, CBE events flow to the Premises Server through the Event Gateway, where they are converted to sensor event objects and put on the SIBus for further processing. Once the events are on the SIBus, they are processed by one or more Premises Server task agents; task agents are similar to Data Capture agents except they act on and process sensor events once they reach the Premises Server. Task agents perform a variety of tasks, including event persistence, event forwarding, event refinement, and heartbeat processing. One of these agents, the CEP task agent, is responsible for sending events to the CEP engine.
Task agents are implemented as message-driven beans (MDBs). The interface between an MDB and its destination is defined by a configurable JMS resource called an activation specification. The activation specification indicates whether the MDB listens for messages published to a topic or a queue. In addition, a task agent can be used to filter messages sent to the MDB by specifying a message selector. Only messages published on the SIBus whose headers and properties match the selector will be sent to that specific MDB. To enable complex event processing, you modify the CEP task agent’s message selector to match those sensor events you want forwarded to the CEP engine (the default configuration does not flow any messages to the CEP engine).
Once you’ve enabled the forwarding of event messages to the CEP engine, you’ll need to define the necessary CEP artifacts to act on those events. In general, you will need to define the rules that should be applied to the sensor events, conditions that arise based on the application of those rules, and the actions to be triggered when these conditions are detected. Within EDA, these actions would typically invoke an SOA-based business process. The general flow of sensor events through the CEP engine is illustrated in Figure 3.
Figure 3. CEP sensor event flow
To help illustrate these concepts, let’s look at an example scenario.
This scenario is based on the movement of goods through the supply chain. In this scenario, a customer wants to validate incoming shipments to ensure it matches the order placed with the supplier. If the shipment matches the expected order, the invocation of a business process is triggered to update the inventory to reflect the newly received shipment. In this example, there are four CEP events:
- A shipment arrival event. This event could be tied to the opening of a dock door, the triggering of a motion sensor, or by some other input triggered by a dock door attendant.
- A start receive shipment event. This is a derived event that includes the list of tagged items expected in the shipment.
- Tag read event.
- A stop receive shipment event. This event could be tied to a sensor event, or it could be a derived event generated after an elapsed period of time in which no tag read events occur.
One of the advantages of complex event processing is that it can apply rules to multiple events that occur within a defined time period. In this example, the time period is delineated by the start and stop receive shipment events.
The event types are defined to the CEP engine. Rules would be defined to collect tag read events until the stop receive shipment event occurs and to compare the tag IDs from the collected tag read events to the list of expected tagged items as defined on the start receive shipment event.
Remember, you want to invoke an inventory update process when a shipment has been validated. To accomplish this task, you need to define conditions indicating the receipt of a complete or an incomplete order to the CEP engine and the actions to take when those conditions occur. The Premises Server provides a generic SOA action that can be used to invoke a Web service and a generic BPC action that can be used to a business process running on WebSphere Process Server. Either of these actions (or a custom action) could be used to invoke the inventory update process.
IBM WebSphere Premises Server provides the framework on which real-time sensor event data can be integrated into enterprise business processes, and provides exposure to a new class of data that will drive new business processes or refinements to existing processing. Premises Server itself supports an Event Driven Architecture to efficiently manage the execution of event data, and also to provide an extensible platform for customers and ISVs to extend that functional capability by leveraging the loose-coupling and vertical integration of processing capability. Premises Server fully exploits and leverages a Service Oriented Architecture for business process execution by integrating into process flows and exposing critical business-level capability as services with the Premises infrastructure. The design, development, deployment, monitoring, and optimization of business processes are performed through a set of products available in IBM’s business process management suite.
- WebSphere Premises Server product information
- WebSphere Premises Server V6.1 Information Center
- Ready for IBM WebSphere Premises Server program
- Service Oriented Architecture
- WebSphere Business Process Management product information
- WebSphere Software
- IBM developerWorks WebSphere