<<Starting with the Ajax Messaging Service you just announced, what's the difference between it and having General Interface with your ESB? Kevin Hakman: The synergy between SOA and Ajax as we see it is kind of the perfect storm. These two things kind of evolved independently but they leverage one another really well. Typically Ajax applications talk to HTTP services and just deliver pure information -- HTML markup or just data -- and then transform it on the user side. In contrast the ESB is JMS-based or Rendezvous-based or MQ-based from a variety of vendors that move data around in real time. What the Ajax Message Service does is bridge those two worlds.
The other issue with the ESB is that typically it's a fire hose that a human can't drink from. You're going to have to take all that fast-moving real-time large amount of data and filter it down to something a human being's eyeballs and fingers can absorb. So that's the other thing that Ajax Message Service does. It's a server that bridges the server side to the client side building a real-time HTTP connection, but then multiplexing, filtering messages, throttling bandwidth for human consumption. The Ajax Message Service is optimizing that real-time streaming information from the server side into human consumable forms. Does it work with any type of messaging, for example JMS Hakman: The Ajax Message Services server ships with a server side SDK and a client side SDK. It also ships with an example of that SDK being used to tap into JMS. So you can use that server side SDK to tap into pretty much anything you want including Plain Old Java Objects or pretty much anything. You might need an adapter if you had to tap into a mainframe but short of that you're probably in good shape. On the client side similarly there's an SDK, a JavaScript SDK, there's a Java client SDK. It ships with an example of the JavaScript working. So you can use Tibco General Interface Ajax kit as a client to it, or you can just use an HTML page, or someone else's Ajax kit. It's very, very open, modular and extensible, and not dependent on other Tibco products. So JMS is not a problem? Hakman: Not a problem. How does it handle issues such as, scalability, virtualization and multi-threading? Hakman: The Ajax Message Service is a stand-alone Java server because one of the problems with scaling these kinds of solutions when you do it inside of a servlet is that the servlet has one thread, one connection specification. With the app servers, the reason you can't scale to the long-lived persistent HTTP connection is you'd use up all the threads and the servlet spec disallows multi-threading that you're talking about. So to get around that you're still using port 80, port 443 is a standalone processor running on the JVM where shared threads and connection pooling can be used. That's one of the ways in addition to other features like multiplexing of messages that allows the Tibco Ajax Message Service to support many, many, many concurrent users. Can you give us an example of a business use of Ajax Message Service? Hakman: The customer cases for example would be a financial services company seeking to deliver real time stock quotes to it's own trading environment. Distributed desktops to their high net-worth individuals or consumer traders on the Internet. Or it might be used for real time operational views, dashboards. For example, intelligence or operational monitoring types of applications in the energy industry, keeping tabs on the performance of the overall electricity grid and all the substations and component parts of the grid, where real time information is really critical. Then that scales to the other model. Instead of constantly streaming information where a large number of users are predominantly idle until a message comes through, for example, notification applications. So these are the two typical types of applications. Our vision has been to displace Visual Basic-, PowerBuilder-installed client applications. When you look at the Ajax Message Service as a core capability, you can use that as a primary architecture for an application. For example, when you do that you no longer draw diagrams where the Web page is separated from the server via a stateless connection across the cloud. Instead what you've got is the client and server effectively in the same event cloud simultaneously so an event that happens on the client is roughly equivalent to a simultaneous event on the server and vice versa. Therefore your state management is much more closely knit and your primary application event model is publish and subscribe. One of the things we did recently to further that obviously publish and subscribe is the core architecture for these enterprise service buses we created a JavaScript service bus that runs in the browser. We call it the page bus. We donated the core of the page bus to the Open Ajax alliance. Ajax Message Service implements this. So when it takes a message from the server and publishes it to the client, it actually puts it on this message bus to which your Ajax or JavaScript functions can listen and handle that incoming data accordingly. In the world of Ajax, we all remember back in 2005 where if you just said the word "Ajax" people would hover around you and say, "Tell me about that." But it's fair to say we're in the Gartner trough of disillusionment. What is it that you think people need to know about the potential of Ajax to help the business that they probably didn't get initially? Hakman: I'm one of the co-founders of General Interface. We developed this particular product line and brought the General Interface to market in 2001 with the vision to frankly displace thick client software. We see a lot of Ajax today with that cool factor, being cute, but valuable enhancements to HTML pages, making the HTML page richer. What we focused on is different. It is how do you deliver the feature, functionality, performance of GUI software, things that otherwise would have been written in Visual Basic or Java Swing or PowerBuilder, but do that with all the low cost benefits of flex deployment and rapid application development. So I think our enterprise customers who embraced General Interface have been doing so and getting rid of their Visual Basic applications. The advent of the Web displaced a lot of client server technology early on, but there's still a bulk of rich categories of desktop software that has to be installed an maintained. You see a lot of these applications now in Google Docs and Google Spreadsheets. They're the equivalent of Word and Excel from Microsoft. These are business productivity applications, not e-commerce or e-marketing Web site with fancy HTML graphics. They're focused on enabling you to work faster. That's the kind of problem we've focused on in General Interface. Frankly, a 4GL for SOA that happens to be executed in a data browser way is the Ajax technology stack.>> You can read this at: http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1254525,00.html?track=NL-110&ad=588625&asrc=EM_NLN_1419031&uid=5532089 Gervas
