This SYS-CON.TV Webinar explores "High-Performance SOA: Delivering Scalability, Reliability, and Productivity for Today's Most Demanding Applications." Until now, for companies looking to deploy extremely high-performance applications requiring complex integrations, leveraging a Service-oriented Architecture (SOA) as a solution was considered risky. But recent advances in the core technologies that enable SOAs are changing that, and are making SOA the preferred infrastructure for the highly scalable and reliable applications that drive today's on-demand world. Join Sean Rhody, editor-in-chief of SOA World magazine, and Annraí O'Toole, CEO of Cape Clear Software, for an in-depth discussion on leveraging SOA to ensure maximum scalability, reliability, and productivity for today's most demanding applications.

Click here to view this SYS-CON.TV webinar

As the leader of Cape Clear, O'Toole drives the overall vision and corporate strategy for the company. He joined Cape Clear in November 2000 to participate in the major opportunity being created by the emergence of the Web Services technologies and the massive benefits they could bring to the challenges of creating and integrating applications.

Prior to joining Cape Clear, O'Toole founded and served as Executive Vice President and Chief Technical Officer of IONA Technologies.

O'Toole began his career working with many European and international standards bodies to develop standards for software interoperability. With these and other initiatives, he has helped define the direction of the computer industry. He holds an MSc in Computer Science and an Electronic Engineering degree from Trinity College, Dublin.

TRANSCRIPT of Cape Clear SYS-CON.TV Webinar - "High-Performance SOA: Delivering Scalability, Reliability, and Productivity for Today's Most Demanding Applications"

Good morning. Welcome to today’s Webcast entitled Web Shots: Scaling Your SOA Project Reliably Via On-demand Integration, Right Way or Old Way with the CEO of Cape Clear, Annrai O’Toole, and the Editor-in-Chief of SOA World Magazine, Sean Rhody. Following the talk, we’ll have a short question and answer session. You can ask questions at any time during the presentation via the Web using your ask-a-question box. Simply click in the open area of the ask-a-question box, type your question, and click the ask-a-question button to submit. If you should need technical assistance, type your entry into the tech support box on the left side of your screen and click the send button. It is now my pleasure to turn the Webcast over to Mr. Sean Rhody.

RHODY:  Hello, everyone, thank you for joining us. We’re here to talk about some of the interesting trends that are going on in the industry in terms of SOA, service oriented architecture. When we first started SOA World Magazine a few years ago we were looking at just the beginning of what’s now become an industry-wide trend towards migrating from traditional siloed application architectures towards service oriented architecture as a concrete realization of an overall enterprise architecture strategy. In doing that, we’ve been able to overcome some of the fears that were initially in the industry around security, around scaleability and reliability of Web services and service-oriented architecture.

But in doing that we started to build a lot of point-to-point solutions, a lot of kick the tires types of things. And as we’ve tried to move from the department or division level all the way up to the enterprise we’ve started to discover the need for scaleability and lightweight service bus technology. We discovered the need to go beyond just the UDI registry and to go beyond point-to-point connections to a true bus action where services can be incorporated into business processes and enabled across the enterprise and managed effectively in a heterogenous environment. So to help us explore that we’ve got Annrai O’Toole from Cape Clear who is going to go through some of the details around doing things the old way or figuring out the new way, the best way to deal with SOA and enterprise environment. So without further ado I’m going to turn it over to Annrai.

O’TOOLE:  Thanks, Sean. So thank everybody for coming here today and I hope that there is something interesting in the presentation for you. I’ve tried to add in a reasonable amount of technical content so it’s not too boring and not too fluffy.

Okay, let’s just have a quick look at what we’re going to discuss today. I’ve got a brief introduction to a concept that we’re talking about which is the notion of on-demand integration. And then after that we want to bring you through a number of case studies and a demo. And eventually, over -- just a couple weeks ago we released the latest version of our product Cape Clear 7, and that product really reflects a lot of our experience with customers doing very large scale SOA deployments. And so in the course of working with those customers through those large SOA deployments, we’ve encountered a lot of issues that we don’t think other people have encountered, and we want to share some of the learnings from that with you and I think there should be some interesting things in there including some benchmark results that we did recently with Intel. So, a lot of hands on stuff.

But before we jump into that, let me just do a quick introduction to the whole notion of on-demand integration. Sean has quite rightly pointed out, over the last couple of years SOA has really become a mainstream technology, and what you’ve seen in that period is SOA go from being a concept to reality, and you’ve also seen some of the larger vendors, the IBMs, and the Oracles, and the BEAs, step in and try and offer SOA products. In fact, if you throw a stone in Silicone Valley you’ll hit someone talking about SOA.

But as some of the big guys have moved in, essentially the SOA offerings from the bigger vendors have become extremely complex. If you look at their product offerings you’ll see a stack of SOA offerings. In fact, it’s things that they’ve either bought from other vendors or products that they’ve OEMed, but they come around and they say in order to do SOA you really need to do – you need an ESB, which we do, but you also need BPM, and you need rules engines, and you need governance, and you need BAM, and on and on and on. You need 20 or 30 products all kind of junked together in order to get stuff done. And we think that those big SOA stacks – they’re not really in the spirit of SOA. I think certainly for us here at Cape Clear that SOA has always been about making things simpler, making life more straightforward and tying the overall business value of technology with real line of business owners so that people can see what they’re paying for and they can get stuff done quickly.

And so increasingly we here at Cape Clear, because of our experience with customers, and because of the way that we see SOA going, we think that really the future of SOA is far more intertwined with the whole phenomena of on-demand technologies that we’re seeing, in particular software as a service. And so we here at Cape Clear like to talk about on-demand integration, and as we look over what we’ve done with our customers, we’ve helped a couple of straightforward software as a service vendors solve integration problems, we’ve helped some online media companies to add music and video on-demand, and we’ve helped some of our big customers roll out essentially a kind of software as a service type model within their own organization. And so we really believe that SOA, ESBs, and all the related technologies, are going to be intertwined with this whole on-demand phenomena. And so a little bit about what we want to talk about today is just about that whole notion of on-demand integration.

I think to jump straight in and talk about some of those customers, last year we won a major contract with Workday. And Workday, if you’re not aware, is a company founded by some of the people from PeopleSoft. And they’re rolling out initially an HR application on a hosted basis, but their ultimate goal is to deliver a full ERP suite on a hosted basis. And Workday realized fairly early on that if you want to bring software as a service to the enterprise then you’re going to need to solve the integration problem because large enterprises can’t adopt the whole software-on-demand model unless they have an easy way to hook in to their existing ERP applications. And Workday is one of many customers, some well known names in there, who are also customers of ours using Cape Clear and software-on-demand scenarios.

We’ve also done quite a lot with video-on-demand. Very notably, last year we were involved in the United Kingdom with the roll-out of a thing called Channel 4. Channel 4 is a large terrestrial broadcaster in the United Kingdom, and they rolled out a video-on-demand system based on Cape Clear. And since then we’ve done similar work with Cisco and their connected home initiative, and we’ve partnered with a start-up company in this whole space called INUK.

And then the kind of third bunch of customers are essentially those enterprise customers who are doing essentially an internal software as a service, so what they’ve created is large, centralized services that they make available either to their internal branch offices or to sets of trading partners in a B-to-B style fashion. And I’ll talk about one of those examples, specifically JP Morgan, later on.

Okay, so before I jump into some of the details of the kind of lessons we’ve learned with SOA I just want to set the ground a bit. So we at Cape Clear produce a – we do one product, it’s called an enterprise service bus or an ESB, and our definition of an ESB as was done on this picture here, at the bottom we support all of the regular things that you’ll find inside an ESB, handling different transports, doing transformation, routing information, one site to the other, handling security and so on, all of those regular ESB things.

But in addition we have a lot of focus on orchestration and in particular on BPEL, and for those of you who don’t know, BPEL stands for business process execution language. It’s a standard service oriented way to describe business processes. And we also provide some BAM capability, which is business activity monitoring so it’s a way to look at what’s going on as an ESB. And then finally, we’ve got some unique service enabling technology which allows us to take existing applications, expose them as services, connect them into the ESB, orchestrate them together, and then build front ends that can be pushed out to the Web or a whole variety of different channel capabilities. So that’s a quick summary of our product, so now let’s jump in and talk about some case studies.

So the first case study is really a set of generic observations that we’ve made over a large number of our customers. I’d say this is over 20, 30 customers who last year rolled out some very large-scale SOA applications. I mean if you think of something like Channel 4 where they’re handling – you know, it’s all of the video-on-demand content for all of their millions of subscribers who are downloading very large files, the way you use Channel 4 is you go to their Web site and you log in and you buy the programs you want to watch and you can watch them on your PC. So they’re handling very large volumes, and it’s a very complex application because all of the content has got different rules. Some content can only be up on the Web site for two weeks and other content can be there forever, so it’s a very both complex and high volume application.

And so across the board what we’ve seen is that people are trying to build large SOA based systems but what they’ve run into again and again is issues around how do I make these systems very reliable and how do I make them very scaleable. And so to kind of just typify those, and in particular because most of our customers are writing their business processes using BPEL, so a lot of the scaleability issues they’re getting is that they sit down and they say BPEL is a really nice way to describe my business process so they write their applications in BPEL, and then they go and deploy them and they find that there’s issues that they run into.

So first of all, when they write these in the first place they find that if your BPEL engine, you know, the thing that’s executing your business processes, if that engine is not very well designed it’s going to make very inefficient use of server and memory resources and that limits the number of business processes you can process at any one time. And if you’ve got – when messages – you know, all of the time these BPEL processes, business processes, are waiting for external messages to happen, and when these messages arrive they need to be associated with the business process and make something happen, and associating a message with a business process is known as correlation, and if that’s done it’s very easy to do that very poorly so particularly when you scale up the number of business processes that you’re trying to simultaneously execute, this can be a big issue.

Then, one of the things that you get from BPEL is that it’s a very reliable transaction. A BPEL transaction can never be disrupted or broken or fail in an unknown manner. But in order to achieve that level of reliability, it’s obvious you’ve got to write a lot of database, so a lot of BPEL engines do a very poor job of writing to the database and they really limit what you can achieve.

And then finally, all of this is on the distributed architecture so it’s using network all the time, and if you’re doing a bad job you’re going to choke your network bandwidth very easily.

So the solution that ourselves and many other people offer to this is -- people really try and scale up these applications that they’ve written with BPEL – the solution is to do some horizontal clustering and to place all these things – to use cheap hardware and scale up horizontally and replicate your BPEL engine across a cluster and get increased performance and throughput.

However, there’s a number of – we here at Cape Clear have done a number of things to make this really scale up, and in particular we’ve done a lot around this thing called server affinity, and I’ll talk about that in a moment. But in addition to server affinity we’ve done a whole lot of work around caching in order to stop your BPEL engine talking to the database all the time. So, caching, using very flexible optimized caching algorithms we can reduce the amount of time you go to the database, and we’ve also done a lot of work on the algorithm to do the message correlation. So if you’ve got millions of BPEL processes running on a cluster, we guarantee that it will only take five milliseconds to associate an incoming message with the right BPEL process on whatever machine its running on and get that BPEL process reacting to that incoming message. So we’ve done a lot of work here.

But let me specifically – a lot of this really is built around this notion of server affinity. So I think that the best way to describe it is to look at how other people do kind of BPEL clustering or SOA clustering. What we would see our competitors normally doing is using replication algorithms because this is what we did when we were scaling up Web sites. So when you scaled up a Web server you replicated all the Web pages and you replicated sessions across a whole cluster and it worked pretty well. And people have tried exactly the same techniques with BPEL, they just did straightforward replication across all the members of a cluster. And the problem with that is that when you send a message to one BPEL instance, you have to send it to all members, and so as you scale up the number of BPEL instances to let’s say five million, then what’s going to happen is your cluster is going spend all the time chatting amongst itself and none of the time doing any work. So these basic replications are low balancing algorithms that have been adopted by some of our competitors, don’t really scale up. And the only architecture that really works is what’s known as server affinity.

And what server affinity means is that we associate a given BPEL instance with a given server in the cluster, so that BPEL instance isn’t replicated and it always stays there, but what we provide is a migration capability that if the server goes down, if one of the members in the cluster goes down, then we can migrate that BPEL instance and rehydrate it onto some other member of the cluster, and the whole system keeps running, and the user, the client, interacting with that BPEL process will see no down time or won’t see any transactional losses. So this server affinity architecture is unique to Cape Clear and it’s the only way that you can really scale up what you’re doing.

And, of course, scaling and reliability really go hand in hand, and this reliability is stuff that we’ve really seen tested by our customers. And in our new version, Cape Clear VII, based on what we’ve seen our customers trying to do, we’ve shown that Cape Clear is designed to cater for all of these type of failures. So you can system failures with the server going down or the database going down, you can have transport failures with the network going away or messages being lost, and your application can not do its job properly and you end up with lost messages, you can have a whole bunch of application errors where a poorly written application goes wrong and causes a whole range of errors, and then finally people have planned down time where they want the system to be available for upgrades and stuff like that. And across all of those scenarios our product has been tested and demonstrated and proven to work, so that not only can you get very high levels of scaleability going on but you can also use our product to build very reliable and highly available services.

And then I just wanted to just very briefly highlight on some of the things that this product really gives to you in terms of end-to-end reliability, and that is from the time some client interacts with this service, maybe using something like Web service reliable messaging, all the way through the full business process cycle, so as you kick off a business process and this process goes out and executes whatever it needs to get done, for that whole end-to-end chain our Cape Clear VII guarantees complete end-to-end transactionality, that nothing is going to get lost or fail, or not happen. So this is a very high-end set of guarantees that we’re offering.

But again, this is based on what we’ve seen our customers trying to do, so what we’re saying here is that as you – SOA is a fantastic way to build an architecture, but what’s even more important than SOA being a good architecture is that you have something like Cape Clear VII that really allows you to scale it up and to build the type of SOA applications that actually are going to be reliable and are not going to fall over as soon as you throw a bit of load on them, they’re not going to fall over as soon as you try and meet them scale.

So obviously it’s very easy for me to talk about all that, but what we wanted to do was try and really put some hard numbers on it. So in order to do that we worked with Intel and created a benchmark for BPEL processing for SOA applications. And so let me just talk very briefly about that. First of all, let me talk about the environment that we tested that we did all this benchmark in. So we had a set of servers with two four-CPU servers that generated the load, and then we had a load balancing layer that actually balanced the load out among the Cape Clear server [care] which was eight CPUs, and then this was all backed onto an Oracle database, and it was all done on a gigabyte Ethernet, isolated LAN. So a pretty high end environment.

And what’s really interesting is that – here’s some graphs on it – as we scaled up the number of processors in the cluster we went from handling 5,000 transactions per second up to handling 26,000 per minute. So these 26,000 transactions per minute is the equivalent of 37 million transactions per day. So this on an [eight way] machine – and bearing in mind that these are fully reliable, unbreakable transactions so you can kill the network, kill the database, and kill a server, and these whole transactions are going to keep on running. So these are very high-end numbers for those type of very reliable transactions.

And what’s even better is that as we scaled up the number of processors and scaled up the number of transactions we were pushing through the system, the response time for each individual transaction came down. So the system really had some nice scaleability characteristics. You get better throughput and you get better response time if you have more servers.

And in addition what we wanted to show was really show that this system could scale up to handle very large numbers of BPEL instances. So increasingly, in the type of business application set our customers are writing, they’re using a BPEL instance to represent a real business process. And for some of these very on-demand scenarios, and you’ve got very high volumes of concurrent business processes, and what we’ve shown here is that we can scale up to handle five million simultaneous BPEL processes. And what’s nice is that the time it takes to create the first BPEL process is the same as the time it takes to take the five millionth active instance, so again some very nice scaleability characteristics.

Quickly, just to talk about this whole – to show one of these high volume reliable applications in production is JP Morgan, but also what we wanted to do in discussing this example is to show that JP Morgan is essentially building a kind of – its own, if you like, mini-software to server application. So let me just talk a little bit about the application in the first instance.

So the part of JP Morgan that did this project is a group called – is the active management part of JP Morgan and they manage a bunch of assets on behalf of things like pension funds and hedge funds. And what they wanted to be able to do was offer a variety of ways in which those hedge funds and pension funds could send instructions to JP Morgan to buy some more assets or sell some of a portfolio, or in general do a wide range of transactions against the assets that JP Morgan are managing for them.

And all of these different entities, the pension funds and the hedge funds who wanted to access this service, have very different IT infrastructures. Some of the hedge funds are literally three people in a room, some of the pension funds are very large systems. So JP had to be able to build a service that could be accessed in a wide variety of different ways. And one of the simple answers to that, of course, is that JP Morgan could have written the service and given the API out to all the people who wanted to access it, and said here’s the API, go access the service any way you like. But that really didn’t meet many of the business requirements because what they want to do is make it easy for people to do trades so that they can increase the volume of trades but also make it easy to add new customers into their active management services.

So what they decided to do was do all the integration for those customers. So not only are they creating a service, but they’re also handling all of the integration for it so that as a new hedge fund comes on, if they want to send instructions in whatever Excel spreadsheet that they want to send it in, JP Morgan will do that work for them so that this hedge fund can just send them the spreadsheets in the format that the hedge fund wants to use, and the JP Morgan guys will do the transformation and handle the integration so that it can talk into their internal service.

So you end up with a little picture like this where on the right hand side you have JP Morgan using our ESB to build a service that talks into their internal infrastructure where the trades actually get executed, and to also build the integrations into all of the different formats that the customers want to be able to send the information to them on on the left hand side. So it takes JP Morgan a couple of days to set up a new customer, do the integration for them, so they can very quickly add new customers and new data formats that can access this service. And so it’s a very good example of what we’ve seen repeated among many of our customers where as they’re building a service-oriented architecture they’re not only building the services, but they’re also building the integrations that make it easy for people to consume that service, or to access that service. And this is a very good example of what we mean by on-demand integration. And we think that this pattern of building not only services but integrations is the way forward.

So I think that some of the results that they got from this is that they were able to very easily and quickly add new customers. The great thing for a lot of those customers is that they didn’t need to do anything on their side. They didn’t need to install any special software. They just send them the spreadsheets in whatever format they want. The whole thing is automated so all the error that would have been traditionally involved in these systems some of which were still done by faxing were all removed and so on. So it’s a very interesting architecture and a very nice business case.

As I said, this is JP Morgan. If I’d shown you the Workday example where Workday is a pure software service company, you’d see that it’s a very similar architecture. I could walk you through any number of our larger enterprise customers and you’ll see very similar architectures being used by them all.

So, with that, I think that it’s enough kind of blarney from me. I think it would be very interesting at this stage to just see the stuff in action and to that end we’ve got James Pasley on the line here and he’s going to hopefully, if it all works, give you a demo of the Cape Clear tools in action.

JAMES PASLEY:  I’m James Pasley, the CTO for Cape Clear software, and over the next few minutes I’d like to demonstrate for you just how quickly you can get started in the Cape Clear VII studio development environment. In preparation for this demonstration I’ve started a Cape Clear server and I’m now launching the tools. The first thing that’s displayed is the welcome page and this is a great [UNCLEAR] users. The overview section contains some background reading on the Cape Clear enterprise service bus and the development tools themselves. The first step section highlights some of the tutorials that we think you should run first, and allows you to choose to between them based on whether your interests lie predominantly with Java Web service development or with BPEL orchestration.

I want to start with one of these tutorials now. The first thing you need to do when you launch a development environment is to configure a server that you’re going to deploy and test your Web services on. And we can do this using the define-a- new Cape Clear server tutorial, or cheat sheets, as they are often referred. These provide step-by-step instructions to help you complete common tasks you’ll be doing as a developer. We configure a Cape Clear server using the new server wizard and I can launch this simply by clicking on a link within the cheat sheet itself. The cheat sheet then attaches itself to the wizard so that I can continue to use it as I progress through the panels in the wizard. The first thing I need to do is to select the type of server that I want to configure. And then I go on to select the installation directory for that server and finally the connection details. And when I’m happy with those I can click finish and a new server appears in the server’s view at the bottom of the development environment.

Now let’s go back to the welcome page and see what else we can do. There are other tutorials here that guide you end-to-end through the creation of a new project, writing the code, deploying, and testing the service. These are Hello World style tutorials for both Java and BPEL. In addition to these step-by-step tutorials there are quite a number of sample projects where you can simply import the projects, deploy, and test them, and these are very useful to return to as example code for your own Web services. There’s a payment gateway example for Java Web service development. I’m going to install the loan application BPEL sample. Installing the samples are very easy, just click on the link and the import wizard appears letting me know the project names that will appear, and I can click finish and those projects are now imported into my workspace. And you can see those here on the top left on the screen. You also get a panel here with links into the online documentation, which will explain the sample in further detail.

The loan approval process receives loan applications and then requests a risk assessment for them. Based on the amount requested and the risk assessment then the loan can either be approved automatically or the branch manager may need to be consulted before the loan application can be approved. And you can see that represented here in the flow of the business process.  The switch statement here [shows down] the left for automatic approval and [flowed in] the right for consulting the branch manager.

So let’s deploy these Web services to our Cape Clear server, and to do this I simply [mix it] on one of the projects and select the run-on server option. The wizard just asked me on the first panel to confirm which server I want to deploy to, and then the second panel shows me which projects I’ve got open and that allows me to specify which of these I want to deploy. In this case, I want to deploy all three together. I can click finish now and these are deployed to the Cape Clear server. And as each of the Web services is deployed they appear on the Web service browser panel within the development environment.

To test one of these Web services now I can right click on it and select test service and this opens up the Web service tester, which generates automatically an appropriate request message for this Web service. So I can modify the request message, type in a name and the amount that I wish to borrow, and send that message to the BPEL process that I just deployed. And I can view the response message that comes back and see that my response was automatically approved. Let’s send in a second request and this time request a much larger amount. This time the branch manager will also be consulted before the loan gets approved and I can view the response message and see that yes, my loan application for the second time was approved also.

The orchestration manager can be used to view the history of BPEL processors that have executed and I can log in to the orchestration manager now to see the history for the two loan applications. The first request sent by Joe, I can see the request was received, then the risk assessment was attained, and then immediately afterwards the reply message was sent back to approve the loan. The second request, sent in by Mary, following the risk assessment the branch manager was consulted and the notification came back from the branch manager, then the response was sent back to the client.

So you can see here that very quickly after getting started with the development environment I’ve installed a couple of Web service projects, deployed them to the server, tested them, viewed their history. And there’s lots more samples and tutorials that will get you productive immediately after you install the product.

So thank you for listening to the demonstration. I hope you’ve enjoyed it, and please do download and evaluate the product, and your time won’t be wasted. Thank you once again.

O’TOOLE:  Thanks very much for that, James. And so now I’d just like to end off with just a quick summary, and then I think we’ve got – I believe we’ve got some good questions coming in so we’ll take those, just in two minutes now. So just in summary, we believe that on-demand integration is being done today and, as I said earlier, that this is really the focus of where the SOA architectures are heading, and we believe that we’ve got the kind of horsepower and capability, and as you’ve seen from James there, the ease of use to really help people build those services, build those integrations and roll them out pretty quickly.

And so I think if there’s three pitfalls that we take away in terms of what you should be looking at as you think about your SOA architecture, first of all we think that clustering is key, that inevitably any SOA project you’re going to do you’re going to want to scale up and get it to handle reasonable amount of volumes and then give you high levels of reliability and availability. And so you need to look at your architecture pretty closely and make sure that it’s done properly.

Secondly, we’ve introduced briefly the whole concept of on-demand integration, and I think in summary what this is all about is not only building the right set of services in the first instance, but building the integration so that those services can be easily consumed, and I think that’s a pattern that we’ve seen a lot of and we strongly recommend you to think in those terms as you go about building your own SOA initiative.

And then finally, what I really say is the whole purpose behind the SOA architecture is to make life simpler, and so if you’re looking at products, or if you’re looking at architectures that aren’t making your life simpler then you have to ask yourself the question why you’re doing that and think about possibly some other options.

And so with that I’ll leave you with our final bit of marketing [unclear] and you can read that at your leisure, and then what I’d like to do is essentially hand back Sean here and we’ll field some questions. I’m obviously happy to answer some myself. I’m sure Sean’s got his own opinions as well. Thank you very much for your time.

RHODY:  Hi, this is Sean. I’ve got a few from the audience, I’m going to start with this. I’ve got one that says how is server affinity architecture different from the load balancing concept. Do you want to take a crack at that?

O’TOOLE:  Yes, so the main difference between, say, load balancing, what it is is for each individual request that comes in you’re going to load balances on to a different machine. And even if you change that to kind of make it sticky load balancing so that it’s always going back to the same machine, then the load balancing won’t give you – you know, what’s the load balancing going to do if that machine crashes? The load balancing itself isn’t going to figure out how to re-instantiate all your BPEL processes and all the data associated with them in some other server. So load balancing on its own isn’t going to give you the solution that you want, and that’s why server affinity, it’s to the same [portent], it not only attaches a BPEL process to a given machine, but it also has the capability to migrate all that stuff onto another server if that server crashes.

RHODY:  Okay. A second question that we have is can we compare the pros and cons of software based ESB such as Cape Clear with those of an application based ESB like a Cisco AON.

O’TOOLE:  Yes, that’s a very good question. Where to start? Well, I would start by saying that the Cisco AON thing hasn’t been an enormous success, I think is the first thing to do. I think, however, rather than taking little potshots like that let me answer it in a more meaningful manner. Before I do so let me just give a brief summary of what the Cisco AON is if people don’t know what it is.

So what Cisco announced a couple years back was an initiative to essentially create an ESB in hardware, to create an appliance, a software router that would be application aware, that would be able to do some of the tasks than an ESB do, and they announced this to much fanfare, and, as I say, I don’t think it’s necessarily gotten all that far. I think the overall difficulty with this is that when you create an appliance, a piece of hardware to do a task, that must be an extremely well defined task that can be done extremely well on hardware. So, for instance, load balancing, as I have proven, is something that can really be done well in hardware and there’s a whole bunch of handling storage that’s very well done on hardware.

When it comes to an ESB, the sets of tasks that you’re trying to put into hardware are very diverse, everything from simple confirmations to building pretty complex work-flows. And so there isn’t a good definition of what it is that we actually want to put into hardware and make it an appliance. And when you don’t have a very tight definition of what it is that you’re trying to make an appliance, then the thing tries to be all things to all people and fails, because you’ve got to remember that the reason people like and buy appliances is that they’re very simple; they’re boxes that they can switch on in the corner of a dark room and they don’t need to do anything more with them. When it’s something like what an ESB is doing, where it’s performing a pretty complex task, that isn’t a box that you’re just going to switch on in the corner and never look at again, it’s doing – you’re actually using it to implement a lot of your critical business processes.

So, to summarize all that hopefully somewhat coherently, I don’t think that an ESB is just ready to be plotted onto hardware any day soon because it’s doing too many diverse and different tasks. And maybe one day if we simplify it so that ESB is just doing one really simple thing then we can make it an appliance. But until we get to that day you’re still going to need a generalized software platform.

RHODY:  Another question that we have, Annrai, is how is ESB successful in practice? I have my opinion, too, after yours.

O’TOOLE:  So there’s many ways to answer that. Let me be just tangible and refer to one of the customers I spoke about there which is Channel 4. So Channel 4, they essentially wanted to launch a video-on-demand service, and their CEO stood up and said we’ll have it running by November 29^th and they got it live on that day, actually. But he said it in the middle of July, or something like that, so they had essentially three months to build it and a couple of months to test it. And they used an ESB because it enabled them to get it done very quickly. And I think that’s the real – and that’s repeated again and again over our customers, which is that if you’ve got to build a pretty complex, mission critical system and get it done in a short amount of time, then you’re going to look at something like an ESB from Cape Clear. If you’ve got lots of time and you can spend lots of money with IBM Global Services or someone like that who are going to roll in with a small army of people, money no object, and people and time no object, then you might look at different ways of doing this.

RHODY:  From my perspective, I do a lot of consulting work outside of the magazine work, and one of the things we see ESB being very successful at is helping SOA become enterprise integration without the point-to-point wiring that goes with just invoking Web services. So being able to take the actual intermediation of the Web services and not have to be involved in knowing where the endpoints are and wiring endpoint to endpoint is a huge plus for our service oriented architecture, so certainly that’s a place where ESB has been successful and we’ve seen some – my clients have been successful just doing that type of operation.

O’TOOLE:  Yes, and I would echo that. If you’re just one Web service calling another Web service you don’t need an ESB. When you’ve got complex multiple endpoints, different protocols, reliability concerns and it’s not just straight point to point then you need something like an ESB.

RHODY:  Yes. Any time you’re going beyond the simple, kick the tires Web service or a small divisional type of thing you need an enterprise service bus to make sure the routing and all the other types of information go well.

Another question we have, can you explain or define what exactly on-demand integration is?

O’TOOLE:  Yes. What I really believe it’s all about is this notion that when you build a service you’ve also got to build the integration to that service. So let’s say I’m building – let me take one example, I’m Workday and I’m building a new HR system, and I’m building that to be used in a software-on-demand manner so that people can come along and they’re not going to use me on premise, they’re going to use this HR management system over the Internet. Well, there’s two key integration points in order to make that useable by any customer. First of all, they’ve got to be able to get the information into Workday, so they’ve got to be able to take their HR information from whatever on-premise manner their using to store that information and get it to Workday. And then secondly, Workday has got to be able to call out to someone like ADP to actually do a payroll, okay? So here we have Workday offering software as a service; I’ve got a customer who wants to use it, and there’s this gap of how do I get the information from the customer into Workday in the first place and then how does Workday call out to ADP and get a payroll run done.

So, in order to make the services that Workday are providing, in order to make them usable, they’ve got to provide the on-demand integration to those services, and Workday need to host that integration on their site because obviously one of the big plusses about Workday is that they’ve got now no footprint on the customer side, you know, on-premise stuff. So Workday have got to build all those integrations and manage them so that you, as a customer, can come along, very easily get your information into Workday, and Workday can very easily get your specific information out to ADP. That’s what we mean by on-demand integration. And it’s not only applicable to pure software-as-a-service companies like Workday, but as I was trying to show on my sample with JP Morgan, it’s also very applicable to large enterprises where a large enterprise is essentially acting as a software as a service vendor. They’re creating meaningful business services and they want to make those available either to internal consumption or to business partners, such as in JP Morgan’s case, their hedge funds and pension funds. Hopefully that made a bit of sense.

RHODY:  We have a few more questions, Annrai. The first one is, [on] the 8-service system you used at Intel is high end, I guess I’d say I have a potential system of thousands of machines due to processing load by lower transaction volume. Have you considered scalability to, say, a thousand machines like a Google server forum type of operation?

O’TOOLE:  Well, we have, is the short answer. If we’d carried on that benchmarking we know exactly where those curves would have gone. They would have leveled off essentially in terms of database access. So you could scale up to thousands of machines but you’d need a whole different database configuration on the back end. Either you’d need a big replicated database to kind of plug in to that type of environment, or you’d logically split the services over multiple different back end databases, so maybe you’d have ten or 20 back end databases importing that number of machines. But yes, we have thought about that and it’s hard to give a short answer to such a complex topic on the phone, but if you want to contact us we’d be happy to talk about it.

RHODY:  Another question from the audience, is the [UNCLEAR] host process orchestrations in BPEL instant?

O’TOOLE:  Correct. Yes. So, a BPEL instance is an instance of a given business process.

RHODY:  Okay. And so each of the instances can be distributed among servers so it’s one. We’ve talked about server affinity so how different transactions during the life of that business process could take place, so they would all typically be bound to the same server, in most cases.

O’TOOLE:  They’d be bound to the same server, yes, and then those instances are evenly scattered over all the members of the cluster. Right.

RHODY:  A couple of the audience members have asked if the slides will be available?

O’TOOLE:  Oh, they certainly will. We’ll put them up on our Web site, and I’m sure this replay will be also available.

RHODY:  So the slides will be available and we are recording the whole presentation so this will [get up] as well. One last question was how can I go about getting details on the benchmarking results?

O’TOOLE:  Oh, there’s a white paper on the Web site. It describes it in far more detail than I did there and much better, I might add.

RHODY:  All right, one more question coming in; what are some of the specific scenes you would experience related to software development? I mean I can obviously see some myself so why don’t you go ahead and I’ll cover it [when you’re done – go ahead].

O’TOOLE:  Well obviously we run a variety of extreme programing here, we run a methodology called Scrum. So we break down all our accounts into four-week tasks, so we start these sprints that last every four weeks, so that’s a methodology we use. And then [tune-in wise], we’re all big Eclipse users.

RHODY:  I think, too – I’m sorry Annrai, are you done? I didn’t mean to interrupt.

O’TOOLE:  Yes, I am. Is there something else?

RHODY:  One of the changes I’ve seen recently is the shift from code-oriented development to design-oriented or model-driven development with BPEL being a good example of instead of writing hard coded, difficult to change monolithic applications, we would now write business processes in a design tool that allows us to design the business process and make changes dramatically and dynamically.

O’TOOLE:  Correct, yes. I think the real value of moving into a SOA architecture and using stuff like an ESP, you should be writing a lot less Java code, and you should be designing stuff more declaratively in modeling tools.

RHODY:  Yes, I’m not a big believer that we’ll ever get away from writing code at all, but I am a definite believer that some of things that we’re talking about minimize the amount of code, just as Java minimized the amount of code you wrote compared to C++, for example.

O’TOOLE:  Correct.

RHODY:  All right. We have a minute or two left, if they’re any other questions please send them in. If not, we’re pretty much done with the questions. Well, I’d like to thank everyone for coming again. Once again, these slides and the presentation have been recorded and they will be made available shortly. And I’ll turn it back over to Denise for any closing.

DENISE:  Thank you again, Annrai O’toole and Sean Rhody, for your presentation and thanks to all of our participants. We’d like to inform all participants that within the next couple of days you will receive a followup e-mail from today’s presentation with the on-demand URL and the presentation slides. We hope you found this Webcast presentation informative.

Have a good day!

• Scaling SOA
• Patterns for Building High Performance Applications