Starting with the Ajax Messaging Service you just announced, what's the difference between it and having General Interface with your ESB?
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?
Not a problem. How does it handle issues such as, scalability, virtualization and multi-threading?
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?
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.
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.