Beth Gold-Bernstein: Hello and welcome back to the ebizQ Event Processing Virtual Conference. I'm Beth Gold-Bernstein, Chair of the conference. Before getting started, let's review the features and functions of our interactive virtual conference environment. We have a Networking Lounge where you can chat with other visitors.

This conference includes virtual booths where you can chat with company representatives and download information. Visit all the booths for an opportunity to win a GPS system. We're also giving away five copies of David Luckham's book The Power of Events to the best five questions of the day.

Now, I'd to introduce this session, which will present Forrester's Taxonomy for Event Processing. Our speakers are Charles Brett, Principle Analyst for Forrester Research and our sponsor, Ruma Sanyal, Director of Product Marketing for BEA Systems now a wholly owned subsidiary of Oracle. Now, I'll turn the program over to Charles Brett. Welcome Charles.

Charles Brett: Thank you, Beth and good afternoon. It is my pleasure to be speaking with you today as Beth said about the Forrester Taxonomy for Event Processing. The processing of events is attracting ever more attention. Some of this is from outside IT and some of these from inside IT. Now, the point I wish to make to here is that event processing is very broadly based.

It's not just an IT function; it's not just a non-IT function. And this is providing some of the confusion that exists in the marketplace. Another way of looking at this is to look at this Forrester Research information that was produced last year. The important parts to look at are the "Too Big" segment.

The "Too Big" segment add up to something like 70% of organizations, and this is within IT alone, are aware of events or are using events. This was a figure that was very surprising to us. It was much bigger than we thought. It's much more expensive than we thought and we expect upcoming research later this year to say that the figures are even larger and even greater.

Now, let me move on and think about why events matter. Events matter for many different reasons and I give some of them here. First of all, they occur everywhere and there are different styles of event processing for handling these forms of events and these are being used in many different ways and one of the most interesting is for an increased and more rapid delivery of processing in the lines of business. I will talk about that a bit further in the presentation.

Events are also integral to application integration and even application architecture. Now, this is something that hasn't been talked about a great deal probably in many organizations so far but it is our feeling in Forrester that over the next two years this is going to come more and more important.

Events extend processing possibilities. New forms of events are being discovered; well, perhaps discovered is not the right term, but are being found, or being used, or being deployed within organizations that they realize they can use assets previously they knew were around but they didn't know how to actually bring into the processing equation. But -- and here is the big caveat here -- the use of event processing is becoming confusing.

The reason it's becoming confusing is lots of people are using the terms in the same way but meaning something different. And the problem is when they do this, you and I as the consumers of what event processing might be become confused, we become muddled, we're not sure we're talking about the same thing. And this is the reason that Forrester put together this taxonomy of event processing.

Now, let me talk about some examples of where we at Forrester have talked to people using event processing. There are many and varied, they are plenty more examples that I could share but here are just some to sort of talk about briefly. In the first, in a financial services organization, but in the marketing department, there were using it to analyze customer responses off a website.

A customer didn't buy something its stops halfway through. Why? Was the product wrong? Was the service wrong? Was the website wrong? So they just simply changed their mind. Its understanding something about this is really interesting and is very, very effective in understanding what is good or bad about your product or service.

In the second example, a financial exchange came to a halt because they didn't know that something wasn't happening. They thought they knew what was happening; all systems showed green but an event screen wasn't coming through and the exchange grind to halt. They've now taken steps using event processing to make sure it doesn't happen again.

And the mobile phone company; they assisted the customer service representative by giving them more information. They got more information by bringing events to multiple different sources together so that the customer service representative to talk better to the customer about what the customer's specific problem was. Not only do they improve sales, but they also improved the customer service representative satisfaction.

In the next one, telecom support, this was a very complicated one using the GPS and various other things, but basically it was to do predictive analysis so that an engineer was taking longer to replace something then you could reschedule all his activities for the day, send out other engineers to be able to pick up their work, so the customers still got the jobs done that were necessary but in a different order.

And the last one on this page, another telco, they used events to reduce lost sales, and to resolve order problems, and save themselves something like $1.8 million in the first year alone,

Some more business examples where event procession occurs: or prevention, this is perhaps the classic version or the classic form of event processing where let's say your credit card is being used in London and Singapore within three hours of each other so each transaction looks all right to the card in each place.

But when you put three hour limit there say or three-hour difference, and you know that takes eight hours or nine hours to fly to Singapore, then it' improbable that both transactions will be all right, but one or both are in fact fraudulent and therefore you want to do something to stop this. The introduction of time is the key here.

And the next one here, medical monitoring, this was a doctor responsible, for I think it was, six intensive care units each with half a dozen beds and you think of all the medical equipment and making all those events about what is going on with each patient. Some of them are about cardiac, some of them may be respiratory, whatever it may be.

By using event processing, you can monitor this. And let's say there is a problem with Patient A; it cannot only notify people but know that it's a respiratory problem, bring the right doctor to the right place at the right time -- enormous savings and enormous avoidance of wastage of people's time.

Another instance here: Know Your Customer. Knowing your customer matters for legal reasons now and having systems which will enforce through the process with everything you need to sign up when you open your bank account is really important; in fact, it's essential, it's a legal requirement. Event processing can handle it. Event processing can ensure that things are going right; it can also see where things are going wrong and then do something about them.

And finally, the last one here, another medical one but quite different, this was reducing the cost of care by using event processing to improve the patient process. And in this particular example, the patient will be able to a book treatment not only in his own town, but maybe where he's on vacation or she's on vacation, and the drugs, the doctors, the requisite facility, and everything else can be organized.

An in one particular case though it's not the only one, the actual payments by the patients dropped from $900 a month to $15 a month -- a very substantial saving and of course the patient was very happy not only on the financial basis, but also because of the sheer way treatment was administered and become much, much more friendly.

Now, the points I'd wish to make here on this chart is a very important one. We're in a separation between different types of events and I'm going to talk about this in a moment. But one of the most significant bits is outside IT; it tends to be business people who recognize which events are really valuable. IT doesn't necessarily know which events exist in the business and which ones could be used, or which are more relevant, or which are less relevant.

Indeed, one the big dangers in event processing is one could have too many events many of which may not actually have a great deal of relevance. Let me come onto kind of part one with the taxonomy. This is about what are the different types of events. We divided the two big groups into subgroups with each of the two big groups.

Now, the first big group is what we call internal IT events. And these are IT events which are internal to the IT organization and which are familiar to IT. And these are typically transactions, messages, alerts -- all the things that IT knows very much about, and knows as well how to handle, and have been handling for years.

There is a separate form of this, which we call external IT events. These are IT events; events that IT departments understands, but the events come from outside the business. Whether they come from a Telecor, they come from a Bloomberg; they come from the Reuters, from stock exchanges. So the essence is these are IT events, they're well understood by IT, they come into IT, they're processed by IT, and they are part of the IT function.

In contrast, the second grouping is about non-IT events. These are IT events, which may not belong to the IT department, the traditional IT department. And again, we have internal non-IT events and external non-IT events. The internal non-IT events are ones that occur within the organization but are not part of IT and very often, these are coming from sensors, from signaling, from production lines, and things like that.

And the external non-IT events are coming from a much broader base from things like radio, television, news channels, weather channels, websites, GPS, and the like. Now, in terms of that processing, the non-IT events are probably the more interesting, they're probably the more extensive, there are many more of them, but they're the ones that haven't been processed in the past but will be in the future.

Now, let me come on to the second part of the event processing taxonomy. And here really bring out the various different styles of event processing. And these are the terms that are in general use in one case, well, two cases actually, where we have invented our own terms just to try and summarize. And I'm going to talk about each of these briefly in the following slides.

The different forms, the different styles of event processing that we have identified so far -- and this is an ongoing work -- are systems and operations event processing, sometimes called SOEP, Business Event Management, Business Activity Monitoring or BAM, Ruled-Based Processing, Complex Event Processing, and the final category, General Purpose Event-based Processing or GPET.

The point of both of the slides is critical. It is that these are not mutually exclusive overlaps or ways some vendors describe themselves as being in one part when they're actually in another or I would put them in another. I was recently listening to an insurance company talk about Complex Event Processing but I'm sure they were actually doing Rules-Based Processing. It's very difficult to tell but the terms are so similar, but there are different aspects about each and which events they use which are what make the difference.

Let me talk about SOEP to start with, just some broad comments. This is really the granddaddy of event processing, it's utterly familiar to IT. Traditional uses are failure analysis in operations, network management, systems management, applications, uptime and the like. Emerging uses are application remediation and automated provisioning, particularly looking at say if a website is falling over, or if a database is beginning to slow and things like that, beginning to be proactive and inducing.

The event types used, almost 100% internally at least, are IT events; ones generated within traditional IT so it's very familiar to IT. And it's why applications are instrumented in order to be able to provide the events to the SOEP management in order that one can know what is going on in systems and take the appropriate action. Very conventional, very traditional, a very specific but very effective part of event processing, one that perhaps is not greatly concentrated on but nevertheless, it is has been around for a long time.

Now let me talk about Business Event Management. There are points on this chart; I'm not necessarily going to through all of them because they're there for you to see. But Business Event Management is the process of capturing real-time business events and assigning them to decision makers for resolution. This is really the points I want to get across about BAM. BAM is really about taking events and raising them to a level that decision-makers or people who have responsibility for taking actions can do something.

It's bringing in the human dimension. Other forms of event processing have no human involvement but BAM very much does and it is part of the process. Focused on single events and the flow sequencing and routing. Traditionally, this uses workflow or the traditional use has been workflow, emerging uses are extending application patterns in real time in the business and extending workflow capabilities in new ways.

This is an area, which we believe is going to expand and expand. In terms of event types, these are probably pretty much 100% internal IT events because they have to do with applications, have to do with existing functions. They don't necessarily have to be but probably in a short to medium term, they will be mostly about internal IT events. And effectively, BAM coordinates actions at a higher level than traditional applications.

It offers also another way of doing forms of integration and automation where people need to be involved in the process. Now, let me talk about BAM, or Business Activity Monitoring. BAM is used for real-time analytics, not only for processing and analyzing of event data, but also to feed visual dashboards and the like in order that people can see what is going on within the business -- very much intended for business users.

In our experience in Forrester, BAM is relatively new; it's taking time to be taken off and be introduced into businesses. And one of the reasons is it's very easy to over-hone users with too much information. Alternatively, to trivialize it, the information or the events what's going on by reducing it to such simplistic levels that it's just ignored.

Traditional uses, well, it's still relatively new so we don't really have much to go on. In terms of emerging uses, this form of event processing will be about presenting relatively complete information in simpler forms to business users that is the objective. In terms of event types, the combined internal IT and external IT events are the primary sources but there's no reason why non-IT events, particularly, internal non-IT events can't be integrated in, and probably business will actually require this over a period of time.

For our IT people, this is a form of event process that they will probably relate to easily and well because it's pretty familiar and it's about sort of working with their own people in their own organization, but application developers will probably not have much of issue with this. In fact, they maybe well attracted to it over time because it brings them closer to the business.

Next on the list is Rules Engine Processing. Now this is using business rules, or business rules platforms to do certain forms of processing, and they are an increasingly popular alternative to conventional programming. As mentioned a little later on the chart, it's like putting an overlayer of logic above existing applications and using the rules engine to do the integration, to do the coordination between different applications. Its uses are both traditional and emerging; they can be used to alternate all sorts of things particularly policy compliance.

Very good things like Know Your Customer; very good things like working through insurance policies, and making sure that everything has happened appropriately and correctly. A rather unfortunate phrase -- the rules tools -- they create flexible automation of business processes and policies that are external to the existing applications, which is why the are so attractive. In terms of event types, are primarily internal IT events but external IT events are readily introduced.

The big issue about rules platforms is one that they are external coordinators, but two, they can become very slow. If one gets too rich or tries to do too much, performance becomes a very distinct issue. Now, let me talk about Complex Event Processing, or as some people call it CEP. CEP automates the correlation of events into actions.

These may represent a threat or an opportunity, it may provide analytics, they may provide analyses, they may from these analyses start off new events, create new events, start off new actions. CEP is very powerful, which is also very much oriented to non-IT events so it can be combined with IT events.

This is probably the most individual of all the forms of event processing, it's also one of the newest and the very different of engines being used which are capable of handling hundreds of thousands events or millions of events per second looking for patterns, looking for correlations, looking for combinations of events that might not otherwise be seen.

In terms of event types that could be used, today, probably mostly for non-IT events but there's no reason it shouldn't be used for IT events. And I think over time, Forrester certainly thinks over time, that these will come together increasingly and more effectively.

One of the things about CEP is it often starts in the business. It's actually got a very low entry threshold in some places. Some vendors make it very easy to start and then they will make it more and more expensive if you use it more and more but that doesn't matter because it's being useful, so most organizations do not object. But we find that CEP is being used by organizations partly to get away from IT, partly to do not so much rapid application development in the conventional sense, but be able to adjust and change very quickly.

And one financial organization is using CEP, and in one case, its trading strategy failed. Failure was defined as losing money. They discovered what the problem was in the morning, they rectified in the late morning, they tested it in the afternoon, they looked back and saw if worked over previous data in the evening, and it was running live the next day, and it's made money ever since.

CEP will need link closely to IT the longer its used. But at the moment, it tends to be probably a little bit separate and this is an organizational issue that will need to be addressed over time.

And finally comments on General Purpose Event Processing. At issue here really this is catchall category, it's an important one because it is our expectation that of many of the vendors will try and move into the space from the other style in order to try and broaden their market.

Of course, the as it is described elsewhere on the chart is that you will get suboptimized or suboptimal solutions pretending to be general purpose when they're not general purpose. In event types, there's no reason why it shouldn't do IT and non-IT events whether internal or external. The important issue to speak about is whether one size will fit all; we suspect it won't.

On the other hand, one of the good points about GPET is it probably comes with a development environment that is much more familiar to IT and many of them are going to be Eclipse-based, for example, and will probably be more effectively done by IT because it fits the traditional styles. This is a very positive aspect for an IT department point of view but it's also one of the least attractive bits from the business point of view.

The caveat that I put at the bottom is absolutely correct. It may be offered as it solves everything without actually being able to have the power or the capabilities to do the more refined processing that the other styles may be more appropriate for. My next chart looks at some of the vendors involved.

This is not trying to be completely exclusive. It's not trying to list everybody but what it is trying to make the point is each of these categories has different vendors in, some of these vendors are common to several categories, other ones are specific to individual categories; many will probably try and end up in the General Purpose Event Processing at the bottom.

Expect some shuffling in the vendors here but this is really just to show how broad and how varied the various possibilities are. So to conclusions and I've got two charts withs. The first is event processing has many flavors. One should be very aware what these flavors are. Choose the most appropriate and also remember to think about which event types that you're really going to be trying to process.

Are they internal IT events or external IT events? Are they coming from the inside the organization or outside the organization? Event processing innovation often starts with one person. This is particularly true in the business area. It is something we've seen most with Complex Event Processing, perhaps less so with the other areas because they need so much IT involvement

Event processing can parallel -- even bypass -- IT in the production infrastructure and there are some very good reasons for this. Again, this often applies to Complex Event Processing but it can also apply to Rules Based Processing and various of the other forms if used in particular ways. They do not necessarily need to put a load on the existing infrastructure but the downside is you have to have to building something in parallel but it doesn't necessarily have to effect the existing the infrastructure, but to many organization is a very positive aspect.

My next point is on I made a little earlier. Understand which events matter. Now, this is a real problem in some areas because some people think that all events matter. But the reality is probably a small subset of all of the different events in a business actually matter to the business; the trick is trying to find out which ones these are and its almost always the business people who will know this.

And then my last point here is that Complex Event Processing maybe the most threatening at least to IT because it can most often be undertaken with minimal IT support, with minimal investment upfront, and suddenly there is a new pocket of processing within the organization. We have found organizations that should resist this. The IT organizations that resent and resist the introduction of CEP are the ones where the business has gone and done it at any case.

The really important bits is for IT to appreciate that it should be open enough to embrace CEP not just resist it. And my last conclusions are just two caveats. One customer we talked to or one user of event processing said we cannot get enough events. The more we have the better the analyses, the faster and cheaper and so on. This is a rather extreme position but it's one that is quite easily reached. It is one to be avoided. I want and use that huge amounts of resource, rather processing resource, or people resource by not being cleaver about which events to use. And the second caveat here, actually came from one of my Forrester colleagues and I'm going to read it because he said it much better than I could.

Event processing is one of those areas that is very cool and for a specific class of computing or application and for this it is very important. But this leads to some to imagine it as more critical to more of domains than it actually is. I imagine that is why so many use the event term so loosely.

And I agree with this. I think this is one of the difficulties, its why we put this event processing taxonomy together to try and tease out some of the differences and to allow people who thinking of using event processing someway or some means to be able to sort through what they should do. And with that, let me finish there is some contact details for me in case you should be interested and for Forrester I have, but let me hand back to Beth now and thank you very much in deed.

BGB: Thank you Charles. Now, I'd like turn the program over to Ruma Sanyal, Director of Product Marketing for BEA Systems, now a wholly owned subsidiary of Oracle. Welcome Ruma.

Ruma Sanyal Thank you Beth. Hello everyone. As Charles pointed out, we only believe that event processing is going to be the start -- this is going to the start of hockey stick year for event processing. We are very excited. This last year BEA introduced a very robust portfolio of products focused on event processing. In my presentation, I want to reiterate the benefits of event processing, which really enables the enterprise to be instantly responsive.

I want to focus on the major implementation consideration. And lastly, I want to bring to your attention the exciting product portfolio BEA has brought to the market in this area and our customer success story. So just briefly, to reiterate based on what Charles said the top line and bottom line benefits of event processing. BEA has discussed with north of 50 customers about event processing and these benefits listed here.

And these have borne out out to be true, indeed. Adopting an event driven approach can have a positive impact on your revenues, lower your operating costs, and/or propel you to a market leadership position. I won't go through, of course, all the underlying drivers that are listed here; you can read them but just taking exception management as an example, if you think about harnessing the power of event processing in preventing exceptions altogether.

In many of your business processes like order management, transportation of finished goods, or service delivery, or taking action to correct the exception much sooner, you can immediately see the potential revenue impact.

So I want to urge everyone to very strongly consider event processing and get started with it. Again, from Charles' presentation on event processing, it is becoming mainstream; you want to be ahead the pack. So the number one thing is see which of your business characteristics lend themselves to event processing. Get a sense for the number of event processing sources, what type of events come from within and outside of your enterprise, the volume of events, the time criticality of streaming and processing them, etc.

Start to experiment with the pattern rules and think through some of the complex events that might be helpful and relevant in your industry or in your functional area. We at BEA have developed a very compelling tool that may be very helpful in this regard. It's an assessment tool found at www.bea.com/edsoa, E-D-S-O-A.

It'll probably take about 15 minutes of your time but could be very useful in telling you whether your business is prime for event processing and what may be the functional areas that you may target initially for event processing. The second thing to do is think big, plan for event processing applications within if you have say, for example, a large scale SOA or BPM initiative.

Think about event processing within that context, retrofitting may actually difficult. And then start small. You have to convince the organization that event processing is beneficial. Identify and prioritize the business applications that are best suited for event processing. In many case we have seen BAM to be such an example of such an application so I think those are sort of the tips in terms of getting started with event processing.

Now, I wanted also to talk about implementation considerations. And again, I won't go through the whole sort of laundry list here. And all of this may not actually be applying to all of you but these are some elements of the implementation to think about. So the application that you choose, do you want to focus on the infrastructure for a solution that is scaleable, available, has higher availability? What type of logging does it have?

What type of security does it have? Does it have support for event-driven programming? What are your performance requirements now? And in terms of throughput and response time, do you have other metrics for performance requirement, and how are they going to grow in the future? What are you integration considerations? Where is your event coming from and what kind of connectivity do you want to establish?

Does that connectivity become a bottleneck for you? What is your development context? Are your developers comfortable only with standard-based technologies, or are they comfortable packaged solutions, things of that nature? Again, we talked about BAM. The tools for your community, your developers, your administrators, managers, are business analysts going to be using the event processing solution?

How often does your logic and rules change, and others like simulation? Do you want to simulate events? Do you want to persist your event for historical purposes? So think about those. I want to also touch upon, like I said, very exciting set of product portfolios that BEA has brought to the table in this area. The first and foremost of which is BEA's WebLogic Event Servers.

It's the first and only Java application server for high-volume, real-time time complex event driven applications. It's a lightweight Java application server so it's not the full-fledged WebLogic Server, it's actually a container that stands on its own two feet and its purpose built for event processing. But we have exploited all the expedience that we have gotten from developing WebLogic Server, which is robust and has all the RASP capabilities, extremely high throughput, a million events per second.

We have a benchmark whitepaper, which talks about that. It has event processing infrastructure that is specific to event processing, it has a very robust CEP engine. Event processing programmatic constructs and services support, time critical streaming support, SQL-like event processing language support, very easy to use development environment, and multiple choice JVM support.

The second product that we have brought to bear is BEA's WebLogic Real Time; it's the industry's fastest real-time solution for standard Java. We realize that in many event processing scenarios, microsecond and millisecond responses are predominate and completely required like in financial services and military command and control so that's where WebLogic's real time really brings its value to bear.

The design goal for this product is to make it pauseless. There's going to be not even the ten minute millisecond pause that you see eventually for this product. And you can very easily swap out any JVM with this product and see instantaneous almost performance improvement and it does comes with advance tooling for monitoring and tuning your applications in real time.

I also want to touch up on briefly on a success story that we have with a very well known online retailer. Their business challenge was tight uptime and performance. And you can imagine that tight uptime is extremely important because they do about $2,000 per second of transactions so a one-second downtime can cost them quite a bit of money.

They are in a highly competitive market phase. Their operational costs need to be contained and you can see the IT challenges that IT was facing. IT was the business and they were supporting this business challenge in business and the challenges were felt directly by them. So real-time everything for their customers, millions of messages going through their systems and new features must be delivered very quickly for time-to-market reasons.

So they have used BEA's WebLogic Event Server for heartbeat and event monitoring to discern complex patterns, to support their performance needs. And they really like the fact that's a lightweight open extensible container so they can take the container and customize it, they can change it and develop custom applications on top of it.

So the expected results is an order of magnitude increase in message monitoring and in processing without increase in hardware/software costs. This was really, really important to them and then proactive control of applications improved SLA management to the business and other parts of the organization, and elimination over reliance on proprietary legacy technology.

So they really saw the value in WebLogic Event Server, and they really derived tremendous benefit from that. So that's the end of my presentation. I want to thank you for your attention and your time and I will turn it over to Beth.

BGB: Thank you very much, Ruma. And now it's time for your questions. I'd like to remind you, you can submit your questions by clicking on the "Ask a Question" button. And before we go to your first question, please take a moment to answer this poll. What are your plans for implementing an event-processing application?

Charles, for the first question, are we also considering events that represent a legal state change that are part of the normal operation as in straight through processing in financial services?

CB: Yes, Beth. I do think that events, which change state, are part of event processing and I would think that straight-through processing falls into the event processing category in its full sense.

BGB:

RS: Yeah, absolutely. So let me take that question and answer it slightly differently make it probably, hopefully, slightly broader. I think the user is actually curious about SOA, Service Oriented Architecture with sort of lots of services defined and invoked and so on, and event processing. And what I wanted to offer is that event processing offers the promise of enabling consistent and proactive responses to both regularly recurring and exceptional IT and business events.

And they are sometimes described as event driven SOA underscoring the EDA and SOA connection. Event driven SOA can be seen as a natural evolution of the traditional SOA in which services and communications between users and service are triggered by events. And as you can see as SOA implementations become more popular, more entrenched, as event driven SOA offers advantages, it also presents challenges, especially, regarding scalability and management in the face of high volume.

So for example, for financial services, they're as many as 200,000 per-second high volume financial transactions. So event-driven SOA drives also the need for Complex Event Processing. So you can see how event SOA event processing are intertwined and will become more so in the future and then CEP plays into it as just a volume of events become really high then to be processed, specifically by CEP, and not any other technology is well suited for that.

BGB: Okay. Now, Charles in your taxonomy, how do you see the role of CEBP, which is something I never heard of but apparently stands for Communication-Enabled Business Processes, which is using CEP to reach out using telephones?

CB: I have never heard of the term myself. In fact, it's completely news to me. But given that, you mentioned telephones and CEP. Its sounds to me as if it's probably along the lines one of the examples I talked about, which were the telephone companies as it happens. And it was using CEP to bring together multiple sources of information from various different places including real time or near real time data from core records and feeding this to customer service representatives so that they could have improved conversations with customers. Now, I'm not sure if that's exactly what your questioner was asking but that's kind of the linkage I would make from the nature of the question.

RS: I'm glad that there is so much interest on WebLogic Event Server; it makes me very excited. So let me clarify just one thing because of the way the question was structured. WebLogic Event Server is an app server so just to clarify it doesn't run on top of anything. It runs on its sort of own two legs.

Now having said that, it does not have any specific dependency or interoperability requirement with the other BEA specific products so if there is a need for deriving composite or complex events in the upstream, and then handing over those composite events downstream to an IBM WebSphere platform, then event server can absolutely work in that environment. So for any of you listeners out there with multi-vendor environments, event server can interoperate and work in those environments very easily, so the answer is absolutely yes.

BGB:Now, is it Web services based?

RS: It is actually not Web services based. The premise is different. Web services is the SOA premise and does not necessarily focus on performance and those real time those type of requirements per say. WebLogic Event Server on the other hand, is very specifically built for developing event processing applications.

And one of the key, if not the most critical requirement, for event processing is performance in terms of response and in terms throughput. So I won't say it is built to support web services specifically, but again, the interoperability capabilities with SOA infrastructure, BPM infrastructure, etc., are absolutely existent, they can be absolutely handled by WebLogic Event Server.

BGB: Okay. Now, Charles this is probably the last question. Would event processing be difficult to retrofit into a SOA?

CB: It's a very good question and it's a leading question. I think the answer is in some of the earlier SOA implementations, its probably going to prove more difficult by any services in these events. They can be picked up by event processing and similarly when an event processing engine emits events out of on the downstream side, there's no reason why services shouldn't pick it up. So there's no architectural reason why they shouldn't fit together. The question really is going to be how the services were originally designed, architected, and delivered.

BGB: Okay. Well, unfortunately, that's all the time we have questions for. If you have further questions, please check out the BEA or Oracle booth that's going to popup on your screen. If you don't see it, please turn off your popup blocker here. Also at the top of the hour, you can join us in the Networking Lounge and we are giving away Starbucks cards for those who answer our question about what real time event you would like to receive real notification of.

We're also going to be announcing winners of five books of David Luckham's and also the winner of the GPS system. Please visit all the booths to be eligible. I want to thank Charles and Ruma for their part in this presentation. And thank you all for attending.