Listen to Part 1 (10:33) Download file


Listen to Part 2 (20:30) Download file

Participants in this podcast include Gian Trotta (GT) and Ruma Sanyal (RS).

Read Ruma Sanyal's bio.

GT: Welcome to another "First Look" podcast. I'm your host, ebizQ's Gian Trotta. Joining us today is BEA's Worldwide Director of Product Marketing for Time and Event-Driven Products, Ruma Sanyal. She'll talk about the increasingly apparent benefits of event-driven computing in general and its applications to SOAs in particular. Welcome, Ruma. Thanks for joining us.

RS: Thank you! I'm really excited to be here.

GT: Okay. Ruma, in a nutshell, what is event-driven computing?

RS: I'm glad you asked that question. Event-based computing, in a way, is a fairly new paradigm that has got a lot of attention lately and before we launch into event-driven SOA and how event-driven computing and SOA work together and its benefits, we should definitely discuss event-driven computing, what it is and why it is in the limelight these days.

So, very simply, event is a thing or a state change that happens that may or may not be of consequence to a business. An event could be a change in the price of a stock, the launch of a missile, the purchase of an item, the ordering of an item and the failure of a production line. Life is event-driven. In fact, the entire world is event-driven and always has been.

GT: That's a pretty relevant metaphor. I think I speak for everyone when I say we hope a missile launch doesn't come to pass. That it remains solely theoretical. But do you have any less-dangerous examples?

RS: Absolutely! We find examples of event-driven computing applicable to any business. So me give you two examples. The first example I have is that of a toy retailer. There is actually one customer that we work with pretty closely that was interested in event-driven computing and we worked with them during the last Christmas timeframe where they were trying to determine the ordering scenarios of their video games in their various stores. And they had four genres of video games that they determined the order for. They were actually tracking the order starting the first day of the holiday season, and what they found is the video game genre called "Adventure" actually superseded the demand expectations and there's another genre of video games which is "Driving," which was falling much short of expectations.

So based on this, one day order graph, they quickly turned around the entire supply chain to match the expected demand through the holiday of the "Adventure" genre and then they put the "Driving" genre on sale.

This instant responsiveness of the toy retailer based on the large amount of order data coming into their system real time, is a perfect example of event-based computing and how enterprises can respond in real-time, based on the information and the data that comes into the four walls of this enterprise.

So that's example No. 1. Example No. 2 is that of a telecom service provider. So this telecom service provider had data coming into their system monitoring their competitors’ activity. So any press release, any product news, any news that pertained to three of their competitors they were keeping close tabs on. And vis-à-vis that data, they were also monitoring customer orders that they had for their various products.

So, at one point in time, in real-time, they saw competitor A's news going up, spiking up, and commensurate with that, they saw their customer orders falling. So they did a check on the news that the competitor had come out with and they figured out that the competitor had a game-changing product announcement. And as soon as that announcement was made, within a couple of days of that, their customer orders started falling -- going downhill.

So, they figured that the customers are switching over to this competitor's new product and adopting that new product. And they quickly interjected. They announced a similar product in the market place and they saw the graph for the customer order going back up to the usual expected level.

So, this is another example of an enterprise taking corrective action based on real-time data and insights that come into their system. They not only, leverage the data and found out causation and correlation; they also took corrective action in real-time. Another example of an instantly responsive enterprise based on event-driven computing.

GT: Right. That in the end provides agility and increased competitiveness.

RS: Absolutely.

GT: What are the specific characteristics of event-driven computing and why now? I think that from your examples, we can see that product releases now are a great driver and you superimposed that upon a seasonal schedule. But I'm thinking -- what particular, what particular factors will convince companies that this is the way to go and how should they do it?

RS: it's threefold. At the highest level, it could be driven by product for some enterprises, for competitive reasons, for agility, for customer focus or customer satisfaction, but really, you boil it down to really three drivers. No. 1 is the fact that there is huge data proliferation in the enterprise -- and as we go forward, enterprises will be bombarded with more and more data. There's no really debating that.

The second thing is, increased business velocity. And let me characterize that a little bit. My favorite example is the U.S. Postal Service. 20 years back when FedEx and UPS didn't exist. People were pretty happy getting mail and there was no expectation that mail would come to you within a day. And now with UPS and FedEx that game has completely changed and people actually expect that mail comes to you within 24 hours or 18 hours -- even international mail, for example.

So, that's an example of how business velocity has increased. Another example may be, how quickly your telecommunication service provider turns on a service that you ordered. 20 years back, during our grandfather's or even our parents' generation, expected telephone service to be turned on in seven days. Now we expect it to be turned on in three hours.

So that's No. 2, and then No. 3 is the technology and mind share for event-driven computing is really there. The technology providers and the vendors that have specific products for complex event processing and event-driven computing is present today. And also the mind share of leaders like the Gartners, the David Luckhams, the Mani Chandis -- they have all converged and really brought event-driven computing to the limelight, to the mainstream.

I'll just give you a specific, concrete example. We just had the first Gartner event-driven summit in Florida last month. That's a prime example of how event computing is now becoming mainstream.

GT: Right! We've devoted a good deal of coverage to that show. Any time Gartner begins a new show, it's a sign that the concept has arrived. How can you say, how will it reach the mainstream now from beyond the show to actual practice?

RS: Absolutely. So, another data point that I wanted to bring to bear of event-driven computing become mainstream is that we had just completed an anonymous survey, to which about 450 people responded. This was a survey that was focused specifically on event processing. And 90 percent of those that responded to the survey said that they had event processing plans over the next two years.

We were astounded by that. We expected the number to be somewhat lower. But this really brings to bear the fact that event computing has reached mainstream. I think the drivers for event processing becoming mainstream is really the characteristics of event-driven computing. No. 1 is the need to respond immediately. No. 2 is more architectural -- the fact that distributed computing is really becoming more and more mainstream.

We have at BEA coined a moniker for our customers, whose aspirations is to respond immediately to business threats or opportunities and we call such an enterprise "the instantly responsive enterprise."

And I want to throw in a little word of caution here. The definition of an "instant" is different for different enterprises and different verticals. So when we talk to, for example, a telecom service provider or manufacturing company, they always come back to us and say, but we don't have the need to respond in milliseconds or microseconds. And that's just fine. Because when we did a survey, we found that a certain percentage of people defined an instant within milliseconds or microseconds. Some other people define an instant in seconds. Some other define an instant in a couple of minutes or hours, or even days.

Whatever the definition of an instant for a vertical or an enterprise might be, within those realms, if the enterprise is able to react, that's really what is required to become an instantly responsive enterprise. However, again, there is that truth about business velocity continuously increasingly, which implies that the definition of an instant is becoming smaller by the day.

So, let me sort of stop there and see if you have any comments or questions and then, also delve into the other characteristics of event-driven computing which are more on the technical side.

GT: Welcome, Ruma. Thanks for joining us.

RS: Thank you! I'm really excited to be here.

GT: Okay. I was, I'm thinking back to a Webinar we did, almost two years ago with Roy Schulte where he first talked about event-driven computing and he mentioned both the triggering of an event but also he mentioned the state of an object. He gave the example of an event would be a truck leaving, for example, the warehouse to make a delivery. But he also said the state would be how many of your trucks are in the mechanic's shop undergoing repairs Is there also an allowance for the state that a business' infrastructure might be in?

RS: Yes absolutely! The action that a business takes based on a particular state change will not only be determined by the state change but also by the state of the business itself. So, say for example, you had five trucks leaving your warehouse. However, you also saw that the state of the business is that there are no trucks which are in your shop which are undergoing any mechanical problems. So, one can conclude based on that, that the business is actually in a great state. So five trucks leaving is what is expected. That's a good event. Probably no corrective action is required.

The flip side of it is, five trucks leave your warehouse. Again -- the same event. However, the existing state right now is that are 25 other trucks that are undergoing repairs. That would trigger an alarm to the business that a corrective action is absolutely required because five trucks bearing all your load whereas there is probably an expectation of really 20 or 25 trucks bearing all your load, those two are very different scenarios, and again, maybe a corrective action could be that you lease some trucks from, your supplier or another distributor for the time being, temporarily.

The event, which is a state change, as well as the current state of the business, the two of them constitute the type of action a business takes to immediately respond to any type of event.

GT: Okay. I've got that. I'm thinking, you know, event-driven computing is distributed. And how does it relate to SOA specifically?

RS: Yeah, so let's talk about that! Event-driven computing is truly distributed computing. And I think, most people if not everyone today understands the benefit of distributed computing, loose coupling -- the benefits of the SOA paradigm. Event-driven computing is really a natural extension of the SOA paradigm. It is based on the publish-subscribe paradigm, that an event gets published. So, going on with your truck example, the fact that five trucks left your warehouse today at 9 o'clock in the morning, that's an event that gets published. There was no explicit request for that type of event and it may or may not get consumed. And can have many subscribers or consumers. So, there may be a system or an infrastructure in place within the enterprise that consumes that event and says, "Hey, you know, that is of business consequence to me and I need to do something with that event." Or the system might say that five trucks left, this is all good and filter it because it is really not of any consequence to me.

Or, you know, like the missile launch. Or maybe not, let's not go with the missile launch, but maybe there is an earthquake in Peru -- probably not of big consequence to the business and that event would get filtered out. So the event always gets published, whether one or more subscribers consume it. And once they consume it, what they do with it, is really up to the subscribers and consumers. And by that token, events actually don't come into the system with any instructions. They don't specify what the event sinks or the event consumers, would do with an event.

In that aspect, it's actually different from SOA and in an SOA paradigm there's a request that actually is specifically made and a specific reply is expected and the request assumes a certain kind of reply and there is somewhat of a tighter coupling in the SOA paradigm than in the event-based paradigm. So, not only BEA but even Gartner actually makes the claim that event-driven computing or event processing is a natural extension of SOA.

GT: Right. What we're seeing, it's probably going to be a member in good standing. How specifically does it bolt up to SOA?

RS: What we have found in our discussions with customers and prospects is that most enterprises don't think about event-processing as a replacement strategy but rather a complement to their existing SOA and BPM strategies. Referring back to the event processing survey that we did, over 70 percent of the respondents think of event processing as part of their SOA BPM platform. And the reason for this is that usually business problems require both SOA and event-processing capabilities to craft a complete solution.

So we look at our answer to event processing holistically. We believe that event processing and SOA are both required, to solve most, if not all business problems. And therefore, we have this term, called event-driven SOA.

GT: That is very interesting! What are their specific attributes, what should it provide?

RS: Absolutely. An event-driven SOA platform is an integrated offering. An event-driven SOA platform provides the infrastructure and the capabilities out of the box for both event processing and SOA. First, it should provide a complete infrastructure for event processing -- an event-driven application. This application server that is purpose-built for event-processing should provide basic services like all the "ilities" of an app server like security, availability, manageability and so on and so forth, and beyond that like user management, fault tolerance, logging, all of the basic services should be built in that app server.

On top of that, the event processing app server should have specific event processing capabilities -- it should come in with a complex event processing engine, it should have event-processing construct supports like event process, event sources, event sinks, event streaming. It should have scheduling services. It should have synchronization services. Those are all the capabilities required for event processing.

And then on top of that, the tools for developers, and any users that interact with this application server, so administrators, business users, business analysts. The event processing app server, should come in bundled with tools for all the users that interact with it and make them efficient in interacting with this app server. So, that's the first point -- which is a complete infrastructure, which could be an app server for event processing.

Secondly, it should provide out-of-the-box integration and interaction with typical SOA offerings, which are a service bus, ability to interface with Web services, ability to interface with and integrate with BPM and BAM, business process management and business activity monitoring. The event processing and SOA rules and artifacts may share the same repository. There will be significant interactions and transformations at run time between events and request responses. So this is the second point, which is the integration and interaction between event processing and SOA offerings at development time and run time.

Now, realize that for people that are focused solely on event processing and have not started the SOA journey, our event processing products will still bring tremendous value. SOA implement is not a prerequisite for event processing -- rather it is a typical, and probably a best practice to couple event processing and SOA for people who have already started their SOA journey.

GT: Right. No, that's understood. And it all seems to be falling into place. Which at times can be scary. Does event -- remember, this is a digression and I appreciate you answering the question -- would deploying event-driven architecture above a SOA reduce the need for the enterprise to have a BI application?

RS: It really wouldn't. It really wouldn't. Because, again, BI definitely has its place and its value in the enterprise. Event processing and real-time business activity monitoring or there is also a new term called real-time BI, complement business intelligence, the traditional BI that we are aware of. The traditional BI is historical reporting, historical dashboarding, analysis, based on a vast amount of data that is stored in a data warehouse. You typically use ETL tools and things of that nature to extract the data and analyze your business trends, your bottlenecks, your best practices and then you take some action for your business based on this historical analysis.

Event processing is sort of the flip side of that. Event processing is all about real time. An event happens. You either see it in a BAM-type dashboard or you may not even have a BAM-type dashboard. You may actually get an email alert or some other type of alert and based on that event or group of events, you determine that there is an imminent opportunity or threat for your business and you take a business action, based on that event or group of events immediately.

So there is this immediacy factor that is ingrained in the definition of event processing. That really complements BI. So, I would actually make a claim that if an enterprise, has invested in BI and then they go ahead and invest in event processing and have a BAM capability that sits on top of that, they really are covered in terms of business insights -- real-time business insights and historical business insights.

GT: Okay. No, that's -- that definitely clarifies it. I mean, to go on, to return to SOA? Can you cite some more specific examples of the benefits for a SOA stack?

RS: Absolutely. We firmly believe that we are in the beginning of the hockey stick for event processing. Therefore customers should be looking at a complete infrastructure offering for their current and future business needs as they embark on their event-processing journey. And referring back to the previous discussion, if they already have embarked on the SOA journey, they should look at event-driven computing and SOA holistically and together and not separately.

The benefits of an event-driven SOA platform are manifold. First of all, if it's an infrastructure that can scale with the customer's growth, thereby providing the benefits of scale up and scale out that would be tremendous. This is probably the most important benefit. Customers should really focus on performance, characteristics of their infrastructure offering which include throughput and responsiveness. And they should make sure that the requirements that they have today and in the future, the system that they are considering, is able to meet this requirement.

We are already hearing the requirements, for example, throughput requirement in millions of events per second. And responsiveness requirements in milliseconds and microseconds. Customers really need to pay attention to this. Again, I want to underscore that this is probably the most important benefit that an event-driven SOA platform would provide, is to be able to scale up and scale out with the customers growth.

So that's No. 1. The second benefit of the platform that supports all the "ilities" like the security, availability, reliability, etc. The benefit of that is really, it reduces the time to market and saves development cost. If you didn't have a platform with all these basic services and functions, the customer's' developers will actually be developing security services or user management services. That would be a wasted effort, I would say. Really, an IT shop's job is to develop custom applications that meet the customer's specific requirements and not develop genetic services like security and availability. There are vendors like us who should do that.

The third benefit is that a platform for event-driven SOA specifically supports event processing and SOA constructs, again, improving development productivity. The fourth one is that out-of-the-box there are tools for developers, analysts, managers, administers which improve productivity and give control to the business and IT.

And the fifth one is the holistic experdience that this platform provides so that developers, analysts, managers, administrators and end users interact with the same system for solving that one particular business problem. Business problems and users don't care whether the underlying solution is supported by event processing or SOA. They really care about the business aspects of the solution and therefore, if an event-driven SOA platform provides a holistic experience to the business users, that really is of tremendous value to the business users.

GT: Okay. Ruma, now -- we've done a lot of theory. Can you tell us about BEA's specific new offerings in this area? I know the company's known for comprehensive SOA stack and strong BPM. So, we're wondering how this fits in and what current BEA users can look forward to?

RS: Absolutely! So BEA has a very exciting event-driven SOA suite. Let me first highlight the products and then discuss how the suite really offers a 1 + 1 = 3 experience so the whole is greater than the sum of the parts. Let me focus first of all on BEA's WebLogic event server, which is our primary offering for event processing. It's a lightweight Java application server specifically built for event processing.

It comes in with all the services and "itilies" that are expected of an app server, which is security, availability, reliability, clustering, failover user management, logging, fault tolerance and all of that. Secondly, it comes built-in with a CEP engine and support for specific event processing requirements like synchronization, scheduling, constructs like event sources, event sinks, event streams, event process networks are supported.

And third, it comes in with very strong tooling so we have Eclipse-based developer tools. We have a very strong BAM offering that sits on top of this product. Again, it's a lightweight Java apps server that is purpose built for events processing. And the most important characteristic of this app server is that it's extremely high performance. We are already seeing support for million events per second. Obviously, these characteristics is dependent on the type of responsiveness, size of events, the complexity of events but that is what we have seen in many customer situations.

It also is supported by another offering that we have which is very relevant for event processing, which is WebLogic real-time product. It's a nice segue to discussing WebLogic real-time , which is fastest standard Java solution in the marketplace. It's based on our JVM, which is JRockit and WebLogic Real-Time guarantees garbage collection times in ten milliseconds, which is pretty unheard of.

GT: That's quite a finale! Ruma, if you had to sum up, if you had to sum up your presentation in, let's say, 30 seconds or less -- how would you do so?

RS: I would say a couple of things. First, I really urge customers to think about event processing in the context of SOA, BPM and think of it holistically. No. 2, think of event processing as making your enterprise instantly responsive. It's all about real-time or near real-time and responding to business opportunities and threats now because if you don't do it, then your competitors will and your customers definitely demand it.

GT: No, that's an excellent summary. Where can users go on the Web for more information?

RS: There are a couple of things that I want to highlight in terms of more information. One, is a sort of an overarching URL that we have at BEA which is www.BEA.com/eventdrivensoa. If you go there, that starts you on your event-driven computing and event-driven SOA journey. It has all the marketing collateral and also product information, product download information. We do have free product downloads, free product documentation, interact with our developers when you're installing and testing the product out and things of that nature.

I also want to encourage you to read this brand new white paper that we have developed with help from ebizQ, which is called "Event-Processing Market Pulse 2007." Really, this white paper gives our readers an insight into where the event-processing market is today and how our respondents really have shown us that event-driven computing is becoming mainstream. So this would be a good read in terms of where you are relative to your peers in the marketplace as far as event-driven computing is concerned.

GT: Okay, that's wonderful. Ruma, I want to thank you for a very illuminating presentation.

RS: My pleasure!

GT: If this presentation has peaked your interest, listeners can go to www.ebizq.net/blogs/firstlook and find all the links that Ruma mentioned above and also a full transcript of the podcast, in the event that you prefer to read rather than listen. I'd also note that Ruma will be available to answer follow-up questions to this podcast. You'll also find that comment box on the ebizQ First Look page.

This is Gian Trotta of ebizQ.net; thanks again for attending.