SL’s Architecture for CEP Visualization

In an earlier post, BAM: The Cherry on Top of the CEP Pie?, we touched on the importance of visualization at every level of the function reference architecture for event processing.  

I thought this might be a good time to take a closer look at the SL RTView visualization platform used by many CEP software vendors and their CEP partners, including Apama, BEA, TIBCO, Coral8 and StreamBase

SL's RTV Architecture

SL’s Enterprise RTView is used by many end users to implement and visualize CEP and business optimization KPIs, BAM dashboards, JMX-enabled infrastructure and application monitoring, eCommerce application monitoring, SLAs, capacity planning applications and cyber trading applications.

For example, in an earlier post, CEP Use Case: Stream Processing in Multiplayer Online Gaming, we included a few SL screenshots from a Simutronics-StreamBase on-line gaming monitoring application.  

Stay tuned for other use cases and screenshots that will help you better understand the application and value proposition of CEP to a wide range of business problems.  We will also dive into SL RTView, and other CEP visualization platform architectures, as time permits.


3 Responses to SL’s Architecture for CEP Visualization

  1. Hi Tim. The architecture of the SL’s RTview is a typical architecture used by many application performance monitoring and BAM tools such as BMC, Tivoli, CA and many other vendors where metrics are gathered from underlying data sources, processed by a server and then presented on dashboards. What makes SL’s RTView so unique in the area of CEP? I think it is important to know what attributes make it especially usefull for monitoring CEP based environment. There are also plenty of various dashboards that let users visualize theor business activity by gathering info from many sources So the question is what elements are key when it comes down to CEP?

  2. Hi Albert,

    The key elements in a real-time visualization platform involve a variety of requirements that are very specific to the monitoring, operational or BAM application that is being proposed. In some cases a systems management tool such as Tivoli, CA, a BI tool, or even a lower level web application builder such as Flex, can be an appropriate solution. However none of these tools were designed from the ground up to address many of the challenges unique to CEP. This means that when evaluating the possible options, the user must determine whether the architecture of these solutions can even handle these sorts of challenges and whether these tools can be extended to satisfy the requirements and an acceptable total cost.

    SL’s Enterprise RTView was designed specifically to address this problem set and has been evolving over the past 5 years by adding features specifically requested to rapidly put together these types of solutions. Many CEP vendors have chosen SL as their partner of choice because when it comes down to satisfying a user’s requirements, RTView can satisfy most of the tick marks for requirements, is proven in production, and it evaluates well. It can also be used for both monitoring of CEP infrastructure (infrastructure metrics) as well as for the overall business (business activity KPIs).

    Some of the key issues around visualization that are unique to CEP:

    *Real-time support

    Is the access to the particular real-time source optimized? Most CEP solutions have very specialized means to access events. After all, performance is often their key differentiator. Therefore the visualization platform needs to capitalize on the vendor’s strengths. Federation of data – Does the visualization platform provide optimized pub/sub distribution of real-time data to clients? Visualization – Are the dashboards really capable of delivering millisecond response time as is necessary in many CEP applications? Are the visual components capable of showing historical data and then adding on the current real-time values?


    These applications can often be complex. A dashboard wizard, or a set of portlets available in a Portal may not cut it. Users frequently require a configuration environment that gives WYSIWYG access to graphical objects, input controls, drilldown definition, navigation and reports. Many projects also require data persistence for historical trend analysis and client-side filtering and analytics. Many use cases may also require user interaction and alert thresholds to do things like inject new rules or bi-directional communication to the CEP engine. BAM applications in some sense suffer from the same problems that BI solutions have faced in the past: iIf you can’t prototype these things quickly, the business stakeholders tend to lose interest and the project dies. Therefore all of this configuration needs to be done quickly and without programming.

    *Data Adapters

    While specialized data adapters for CEP engines are important, access to other datasources are often essential to the whole solution. Think of the simple example where a CEP solution is looking for fraudulent ATM transaction events. Once an event is discovered and analyzed, the obvious drilldown is to access a production database that will contain account information for the customer in question. A visualization platform should have access to a variety of real-time and persistent data sources.

    I hope this answers some of your questions about architecture that will support CEP-specific visualization.


    Rodney Morrison, VP Product Management
    SL Corporation

  3. Tim Bass says:

    Dear Rodney,

    Thank you for an excellent reply!


    Yours faithfully, Tim

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: