Paco Gomez's Blog

Paco Gómez's Homepage
Paco Gómez is senior principal systems engineer at BEA Systems where he has been helping customers architecting solutions since 1999. He holds a Master's Degree in Industrial Automation and has over seventeen years of experience in the software industry. Mr. Gómez is co-author of a WebLogic book and is a regular contributor to the technical community, with articles, presentations and innovative tools like grinder and wlshell.

Algorithmic Trading with WebLogic Event Server

In previous entries, I have discussed technical aspects of WebLogic Event Server and some exciting applications (1, 2). In the next entries I will write about Algorithmic Trading,  probably the most common application in Complex Event Processing.

I've had the opportunity to work with the WebLogic Event Server Engineering Team to make available the Algorithmic Trading Demo on CodeShare. The purpose of this demo is to illustrate some techniques used in this field, also known as Algo Trading, and how they are implemented in WLEvS. Source code, application binary and a ready-to-run Event Server domain is available for download here.

Demo Description

The Algorithmic Trading Demo implements common indicators used in automated trading. The application receives market data through a socket connection and calculates the following results:

• Percentage change. Detects when the price of a stock changes more than one percent.
• Trend. Detects when the price of a stock fluctuates in one direction (up or down) more than two successive times.
• VWAP (Volume Weighted Average Price), the ratio of the value traded to total volume traded.

These ratios are calculated and displayed in real time on a dashboard for a basket of symbols.

The dashboard also shows average latency and a distribution histogram of all latencies. The following is a screenshot of the dashboard:

How to Run the Example

The demo is distributed as two zip files:

1. "wlevs20_domain_algo.zip", it contains the WLEvS server with the demo deployed, ready to run.
2. “algo_trading.zip”, it contains the Algorithmic Trading application code and the data feed application that sends market data to the server. The application is distributed as an Eclipse project that can be imported directly into an Eclipse Workspace.

WebLogic Event Server 2.0 needs to be previously installed in order to run the example. We are assuming “c:\bea” as BEA_HOME. If WLEvS has been installed on a different BEA_HOME, see the specific notes in the steps below.

Follow these steps to run the example:

1. Unzip wlevs20_domain_algo.zip to %BEA_HOME%\user_projects\domains.
2. Unzip algo_trading.zip to %BEA_HOME%\user_projects\modules.
3. Start the data feed standalone application.
   • Open a command window
   • Change to %BEA_HOME%\user_projects\modules\algo_trading
   • Run startDataFeed
   • If BEA_HOME is not c:\bea, edit startDataFeed.cmd to specify a valid JAVA_HOME value.
4. Start the WLEvS server with the Algorithmic Trading application
   • Open another command window
   • Change to %BEA_HOME%\user_projects\domains\wlevs20_domain_algo
   • Run startwlevs
   • If BEA_HOME is not c:\bea, edit startwlevs.cmd to specify valid JAVA_HOME, USER_INSTALL, BEA_HOME and WLEVS_DOMAIN_HOME values.
5. Note: The data feed application can be started before or after WLEvS, with the same results.
6. At this point, the data feed application should be sending market data to the WLEvS server and the CPU utilization should go up.
7. On a browser window, open the following URL: http://localhost:9002/algo/dashboard.html. Push "start" button.

I will be providing more technical details about the demo in futures entries.

Technorati Tags: CEP, WLEvS, Algo Trading

GPS Tracking Demo for WLEvS

In my last article, Location-based Information Processing with WebLogic Event Server and Web 2.0, I described a WLEvS application that detects the proximity of a vehicle to a location. I have posted the source code and binary of the demo on Dev2Dev's CodeShare.

The demo is now self-contained. It runs entirely on WLEvS and just requires an Internet connection to display the map mashup.

How it Works

1. WLEvS receives the GPS information stored on a file using a file adapter.
2. The processor determines if a position is near the target destination and generates an alert.
3. Positions and alerts are stored in memory on WLEvS application (Java Bean)
4. The same Java Bean is also a servlet that displays a JavaScript page. The page is a mashup of Yahoo! Maps and the data from WLEvS.

The dashboard is shown here:

Installation

1. Download the project from CodeShare and unzip the file. The code is distributed as and Eclipse project. It can also be built from the command line.
2. Copy "openmap.jar" to the WLEvS domain directory
3. Modify "startwlevs.cmd" to add the previous file to the bootclasspath:

   set BOOTCP=-Xbootclasspath/a:openmap.jar
   "%JAVA_HOME%\bin\java" %BOOTCP% ...

4. Start WLEvS
5. Update "setEnv.cmd" (JAVA_HOME and ANT_HOME) and "build\build.properties" (wlevs.home)
6. From another command window, build and install the application:

   setEnv.cmd
   build.cmd dist
   build.cmd install

7. Open a browser window to access the dashboard. Here is the URL: http://localhost:9002/gps
8. Click on "Start Trip" to start the demo. Click on "Reset" to bring the demo to the initial state.

The Demo in Action

Monitoring JRockit Through a Firewall

-Dconfig.registry.host=192.168.10.132
-Dconfig.registry.port=1099 
-Dconfig.rmi.host=192.168.10.132 
-Dconfig.rmi.port=9999

service:jmx:rmi://192.168.10.132:9999/jndi/rmi://192.168.10.132:1099/jmxrmi

java -Xmanagement:class=com.bea.misc.ConfigurableJMXAgent 
     -Xbootclasspath/a:config-agent.jar 
     -Dconfig.registry.host=192.168.10.132
     -Dconfig.registry.port=1099
     -Dconfig.rmi.host=192.168.10.132 
     -Dconfig.rmi.port=9999 
     -jar C:\bea\jrockit-realtime20_150_11\demo\jfc\Notepad\Notepad.jar

ConfigurableJMXAgent: Created with params = [config.registry.host=192.168.10.132, config.registry.port=1099, config.rmi.host=192.168.10.132, config.rmi.port=9999]
ConfigurableJMXAgent: Create RMI registry on port 1099
ConfigurableJMXAgent: Get the platform's MBean server
ConfigurableJMXAgent: Initialize the environment map
ConfigurableJMXAgent: Create an RMI connector server
ConfigurableJMXAgent: Start the RMI connector server
ConfigurableJMXAgent: Started, use the following URL to connect =  service:jmx:rmi://192.168.10.132:9999/jndi/rmi://192.168.10.132:1099/jmxrmi
[JRockit] Local management server started.

HTTP Adapter for WLEvS

<osgi:service interface="com.bea.wlevs.ede.api.AdapterFactory">
  <osgi:service-properties>
    <prop key="type">HttpAdapterProvider</prop>
  </osgi:service-properties>
  <bean class="com.bea.wlevs.adapter.http.HttpAdapterFactoryImpl" >
    <property name="httpService" ref="jetty"/>
  </bean>
</osgi:service>

<wlevs:event-type-repository>
  <wlevs:event-type type-name="HelloWorldEvent">
    <wlevs:class>com.bea.wlevs.event.example.helloworld.HelloWorldEvent</wlevs:class>
  </wlevs:event-type>
</wlevs:event-type-repository>

<wlevs:adapter id="httpAdapter" provider="HttpAdapterProvider" manageable="true">
  <wlevs:instance-property name="servletName" value="/adapter"/>
  <wlevs:instance-property name="eventTypeName" value="HelloWorldEvent"/>
  <wlevs:instance-property name="eventPropertyNames" value="message,number"/>
</wlevs:adapter>

• This adapter can be used during development and testing to generate any type of events without having to create a custom adapter. It is a bit more interactive than the csvadapter as users can type the event data in the browser and send it immediately
• In addition to the browser, users can use the wget utility on the command line and create shell scripts
• the http adapter can be used for performance testing with standard web testing tools like LoadRunner or Grinder
• jetty, the servlet engine in WLEvS can be configured and tuned for multithread and performance
• easy to integrate with programs via HTTP GET/POST API (Java, .NET, JavaScript, C, Perl, Phyton, Ruby, etc)
• we can use ALSB in front of WLEvS and have, with little configuration, any protocol supported by ALSB (MQ, ftp, file, etc) be able to talk to WLEvS. We just create an ALSB business service that uses HTTP GET to talk to WLEvS

WebLogic Event Server Administration

#connect
connect service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi wlevs wlevs

#change to wlevs domain
com.bea.wlevs:

#set keys
keys Type Name Application

#list current directory
ls

#show the explorer
explore

cd /ServerRuntime
invoke shutdown

invoke /ServerRuntime/shutdown

Continue Reading...

Configuring WebLogic Resources, a la wlshell

#keys
keys Type Name
#Configuration Manager
cm = edit.com.bea:/weblogic.management.mbeanservers.edit.ConfigurationManagerMBean/ConfigurationManager

#domain
domain=myDomain
#admin server
server=AdminServer
#managed server
ser=myServer01

############################################
#start change session
wm = 60000
tm = 120000
invoke $cm/startEdit $wm $tm

############################################
#make changes
edit.com.bea:
cd /Domain/$domain
invoke createServer $ser

cd /Server/$ser
set ListenPort 7111

############################################
#save and activate
keys Type Name
invoke $cm/save
invoke $cm/activate $tm

WebLogic 10, as seen through wlshell

In this first entry of the series, I will show how to connect and browse a WebLogic domain configuration.

WebLogic Server 9 and 10 changed internally the JMX implementation, which is now based on JMX 1.2 and JMX Remote API 1.0. But the change most obvious to users is the way how MBeans are organized and used to manage a domain.

As in previous releases of wlshell, users can still connect using a simple URL:

connect localhost:7001 weblogic weblogic 

But the Administration Server has now three MBean servers: Domain, Edit and Runtime. When using the traditional URL (t3://host:port) wlshell connects to all MBean servers defined in that WebLogic server instance. It uses a prefix to differentiate between JMX domains defined in each MBean server. It prepends "domain.", "edit." and "runtime." to the names of the JMX domains defined in Domain, Edit and Runtime MBean servers respectively.

The explorer shows all the JMX domains available in the connection:

The JMX domain "domain.com.bea:" gives you information about what is configured on the WLS domain:

In the next entry, I will describe how to modify a WebLogic domain configuration.

Have fun!

Further reading:

Understanding WebLogic Server MBeans

wlshell web site

Using wlshell with WebLogic

Connecting ALSB to i5/OS and OS/400

I Just posted the ifiveos ALSB Transport for i5/OS on Code Share.

ifiveos ALSB Transport for i5/OS and OS/400.

ifiveos is a transport extension that I've developed using the ALSB Transport SDK. It uses the IBM Toolbox for Java (or the open source version, JTOpen) to connect to i5/OS and OS/400.

The ifiveos ALSB Transport supports outbound synchronous calls from ALSB to i5/OS programs, written in RPG and other languages. Business Services based on ifiveos accept XML messages in the XPCML specification and return XPCML documents. XPCML is an XML format describing program calls, input parameters and return values.

Connecting ALSB with MQ

BEA AquaLogic Service Bus (ALSB) provides interoperability with WebSphere MQ. For example, you can configure a Web Service Proxy in ALSB that sends messages to a MQ queue. Then you can have Web Service Clients using that Web Service Proxy to integrate applications with MQ, without having to install any MQ software on the clients. The Web Service Proxy can also be part of a composite application.

I have created a step-by-step guide to connect ALSB to MQ which can be found here: ConnectingALSBwithMQ

The two main steps are:

1 Bind MQ JMS objects to ALSB's JNDI tree
2 Configure the Business Service

I've also developed a small utility program, "ForeignJNDIHelper" to bind the foreign JMS objects to ALSB's JNDI tree. The utility can be downloaded here: foreignjndihelper

How JMX Saved My Day

During one of my last proof of concepts, I was helping with the migration of a home grown portal to WebLogic Portal 8.1. One of the old features to reuse was usage tracking, integrating it with WebLogic Portal. The idea was to include a WLP behavior tracking tag in the portal JSPs and to persist the tracking data using the legacy code. The portal tag looks like this:

<BehaviorTracking:displayContentEvent documentId="<%=pageCtx.getTitle()%>" documentType="PortalPage"/>

WLP offers a pluggable architecture for adding custom listeners to events. My custom listener would call the legacy code to persist the tracking information. The listener implements the com.bea.p13n.events.EventListener interface and it is developed as a utility class packaged as a JAR file in the APP-INF/lib directory.

The legacy code to persist tracking data was located under the WEB-INF/lib directory of the portal Web Application. For several reasons that code was packaged in this way and we couldn't change it. This packaging and the standard classloader hierarchy in an enterprise application made impossible to call the persisting function from the custom listener.

Having work with JMX extensively made me think I could use it to solve this dilemma. The JMX libraries are in the system classpath and the MBeanServer can be obtained from the JNDI tree. If any code running on the server can call MBeans, I could wrap the persisting functionality in a custom MBean and make it available for my custom event listener.

I developed the custom MBean and I registered on the MBeanServer from the Web Application, then I invoked one of its methods from the event listener loaded with the application classloader. The approach proved to be a good solution for the restrictions imposed by the classloaders, without having to configure custom classloader hierarchies. The added benefit was that the legacy persisting functionality was now manageable through JMX tools like wlshell.

March 2008

Search this blog:

Archives

January 2008
November 2007
September 2007
July 2007
December 2006
December 2005
April 2005

Categories

Recent Entries

Algorithmic Trading with WebLogic Event Server

GPS Tracking Demo for WLEvS

Monitoring JRockit Through a Firewall

Articles

Location-based Information Processing with WebLogic Event Server and Web 2.0
The author demonstrates how a location-based use case can be implemented with WebLogic Event Server (WLEvS) and Web 2.0 techniques. Nov. 14, 2007

WebLogic Event Server Administration with wlshell
In this tutorial Paco Gómez shows how to perform BEA WebLogic Event Server (WLEvS) administration with the wlshell scripting shell. Aug. 29, 2007

Connecting BEA AquaLogic Service Bus with i5/OS and OS/400 Applications
In this article author Paco Gomez shows how to connect BEA AquaLogic Service Bus (ALSB) directly to i5/OS and make RPG and COBOL programs reusable as services to the enterprise. Apr. 25, 2007

All articles by Paco Gómez »