Arch2Arch > Articles

---

Location-based Information Processing with WebLogic Event Server and Web 2.0

by Paco Gómez
11/14/2007

Abstract

Location-based information systems generate continuous streams of data—for example, the current position of each truck in a logistics company fleet. WebLogic Event Server (WLEvS) can efficiently process location data in real time and detect significant patterns like proximity to a certain place or deviation from a predefined route. Position information can be correlated with other type of data thanks to the powerful capabilities of WLEvS to handle high-volume data feeds and capture complex business rules with its Event Processing Language (EPL).

This article describes a location-based use case and how it can be implemented with WLEvS and Web 2.0 techniques. The use case is relevant in logistics, transportation and distribution companies, and public sector organizations.

Editor's note: See Paco's blog post which shows a video demo of the application, and source code.

A Trip to San Jose

A truck is traveling from Santa Rosa to San Jose. I want to display its location in a map and get an alert when it is within 15 miles of the destination. The scenario is captured in Figure 1.

Figure 1. A red marker indicates the truck is near San Jose

This simple use case will help demonstrate how WLEvS can be used to detect useful conditions in location-based information systems, like proximity to a position.

A second objective of this example is to illustrate how WLEvS can be integrated with existing infrastructure to build sophisticated applications. The position of the truck is displayed in real time on a map along with the proximity alerts generated by WLEvS. I will review the integration with databases, JMS servers and the Web 2.0 techniques used.

To summarize, the solution implemented has two main components:

• GPS location data processing and notification with WLEvS
• Map mashup displaying location and alerts using WebLogic Server and Yahoo! Maps.

GPS Data Processing with WLEvS

In a production environment the truck would carry a GPS unit and transmit its location to a centralized server running WLEvS. In this sample implementation, I will be simulating the GPS data feed with the loadgen utility that is part of WLEvS. I send prerecorded location coordinates (latitude and longitude) to WLEvS at predefined time intervals. The Event Processing Network (EPN) implemented in WLEvS is depicted in Figure 2.

Figure 2. Event Processing Network - EPN (click the image for a larger version)

The Location events enter the EPN and get processed by two parallel branches:

• The distance calculator branch (upper part of the figure) detects if the input location is within 15 miles of the target destination. If this condition is detected, it will send a message to a JMS topic on a WebLogic JMS Server.
• The event recording branch (lower part of the figure) captures all the events and stores the information on a database table.

Let's take a closer look at the EPN. The loadgen utility reads comma-separated values from a file and sends them to WLEvS through a TCP socket. The csvAdapter, which is distributed with WLEvS, uses a TCP server socket to receive the values and send them as events to the stream component attached to it. The stream distributes the event to all the processors linked to it.

The processor applies Event Processing Language rules to the incoming events. If the event matches the rule, the processor will send another event to the stream attached to it. I will show the rules defined in the processors later in this article.

At the end of each branch there are two POJO components receiving the events and sending data to external servers. The distance checking branch produces proximity alerts that are sent as messages to a JMS topic on an external WebLogic JMS server. The event recording branch uses JDBC to connect to an Oracle database and insert all the GPS events.

Event Processing Language Rules

EPL rules are executed on the processors of the EPN. The event recording branch processor contains a simple rule to let all the events pass through:

 select * from GPSInputEvent retain 1 event

In the rule, GPSInputEvent is one of the event types registered in the repository. It is implemented by another POJO containing the event data.

A more complex rule is found in the distance calculator branch processor:

select * from (
 insert into GPSDistanceEvent
 select id, lat, lon, time, seq, 
 Utils.distance(lat, lon, 37.352889, -121.905531) as distance, 
 'San Jose, CA' as target 
 from GPSInputEvent
) 
retain all events
 where distance < 15 and target = 'San Jose, CA'

This rule filters GPS events based on the distance to the target destination. The inner select statement calculates the distance between the position of the current location and the target. The calculation is made using a user-defined function, Utils.distance, which is a static method of a Java class. The input parameters are the latitude and longitude of the current event and the target destination. An alias (distance) is provided for the return value to be used later in the outer select statement.

The reason for using nested select statements is that the distance function is evaluated just one time. This provides better execution times, especially when the function is CPU or I/O intensive.

Business Logic Components

Standard JDBC and JMS APIs are used in the business components that receive the events filtered through the processors.

In the case of JDBC, a data source is defined in the WLEvS domain configuration file (config/config.xml):

<data-source>
 <name>oracle.xe</name>
 <driver-params>
 <url>jdbc:oracle:thin:@localhost:1521:XE</url>
 ...
</data-source>

The business logic component can have this data source injected by using the @Service method annotation:

@Service(filter = "(Name=oracle.xe)")
public void setDataSourceService(DataSourceService dss) {
 this.dataSource = dss.getDataSource();
}

For accessing the remote WLS JMS Topic, a JNDI template is defined in the EPN assembly file as follows:

<bean id="wlsjndiTemplate" class="org.springframework.jndi.JndiTemplate">
 <property name="environment">
   <props>
   <prop key="java.naming.factory.initial">
    weblogic.jndi.WLInitialContextFactory
    </prop>
    <prop key="java.naming.provider.url">
    t3://localhost:7001
    </prop>
   </props>
 </property>
</bean>

<bean id="outboundMessageAdapter" 
 class="com.bea.wlevs.demo.gpstracking.OutboundMessageAdapter" 
 factory-method="createInstance">
 <constructor-arg ref="wlsjndiTemplate"/>
</bean> 

The bean is injected by the Spring framework into the component where it is used to get the connection factory and the JNDI name of the topic. By using these two JNDI objects, the component can send messages to the JMS topic.

The Big Picture

The user interface of the application was developed using Web 2.0 techniques. Figure 3 shows how the information and alerts produced by WLEvS are retrieved from JMS and DB servers to be displayed on the user's browser.

Figure 3. Overall architecture of the solution (click the image for a larger version)

The web application is a mashup of Yahoo! Maps JavaScript - Flash API with a custom Beehive application running on WebLogic Server 10. Using Ajax, the browser polls WebLogic for new location information and alerts since the last request. The application queries the database and sends the new data using the JSON format. The JavaScript in the page adds new markers on the map in the background, without any user intervention or page refresh. The final result is that the map displays the current position of the vehicle right after it is processed in real time by WLEvS. Some details of the user interface are provided in the next figures.

Figure 4. A trip from Atlanta, with two different distance alerts (click the image for a larger version)

Figure 5. Detail of the marker's extended information and text alerts

Applications

WLEvS provides the infrastructure to detect relevant patterns from location-based data in real time as the data gets produced. This capability opens many opportunities for new and exciting applications. Here are some categories and examples:

• Data reporting validation—for example, alert when a vehicle is not reporting its position within a certain period of time.
• Proximity to a given place. This is the use case presented in this article.
• Compliance with planned and regulatory constraints, for example:
  • Alert when a vehicle is not following the expected itinerary
  • Alert when a vehicle is traveling faster than the maximum speed allowed
  • Alert when a vehicle is not moving for a certain period of time
  • Alert when it is likely that the vehicle will not arrive at the destination on time
• Grouping requirements. For example, if several vehicles travel in the same group, alert when the distance between them is greater than five miles.
• Correlation of heterogeneous data—for example, combine the position information with the vehicle speed (also provided by the GPS unit) and other data feeds like temperature, movement, traffic, weather, and RFID sensor. WLEvS Complex Event Processing (CEP) capabilities allow you to design sophisticated rules and event networks to model complex patterns.

Conclusion

WebLogic Event Server is well suited for detecting relevant patterns in location-based information systems. Since the processing is designed to occur in real time with low latency, it allows you to design monitoring and alerting applications for significant events in categories like proximity, requirements compliance, grouping, and complex correlations.

The use case described in the article utilizes WebLogic Event Server to detect the proximity of a vehicle in a certain location, using Web 2.0 techniques to display the information in a dynamic graphical interface.

I want to thank Alexandre Alves, David Read, James Taylor, and Mark dos Santos for their help in this use case.

References

• Source code and screencast demonstration - Paco's blog
• WLEvS Product Center on Dev2Dev, with downloads, blogs, articles, screencasts, and more
• WLEvS Product Information on the corporate site
• WLEvS Documentation
• WLEvS Newsgroups
• BEA Event-driven SOA - our corporate site looking at the intersection of event-driven middleware and SOA
• WLEvS Developer Tools download
• My article WLEvS Administration with wlshell provides some administration tips (Dev2Dev, 2007)
• The article Ajax-powered Google Maps Mashup Tutorial, by Peter Laird, provides some background to building mashups (Dev2Dev, 2007)
• Yahoo! Maps Developer APIs

Paco Gómez is senior principal systems engineer at BEA Systems where he has been helping customers architecting solutions since 1999.

---

Return to Dev2Dev.