X
Business

ActiveGrid recipe: Soak in XML. Integrate. Scale.

For companies looking to speed up integration between new and legacy systems (or, just new and new systems), I've seen a lot of products out that there that use Web services standards (namely XML) to (1) give everything that needs to be integrated a common XML interface and (2) provide the graphical app dev environment for stringing everything together in rapid fashion. But what many of these XML soaking rapid app dev solutions have no concept of is scalability.
Written by David Berlind, Inactive

Play audio version

For companies looking to speed up integration between new and legacy systems (or, just new and new systems), I've seen a lot of products out that there that use Web services standards (namely XML) to (1) give everything that needs to be integrated a common XML interface and (2) provide the graphical app dev environment for stringing everything together in rapid fashion. But what many of these XML soaking rapid app dev solutions have no concept of is scalability. For example, if a single application draws upon three integrated sources to do it's job and one of those sources can't keep up with the others (maybe it's running on slow hardware or a platform that doesn't scale well), then the entire system will bog down. But what if that component's "return values" could be cached by the host of the integrated application? And what if the host could scale out to as a many as 1000 nodes? That's the secret sauce that Peter Yared says makes his company ActiveGrid different. 

Using the embedded player above, you can stream my interview of Yared to your desktop, you can manually download it, or if you're already subscribed to ZDNet's IT Matters series of podcasts, it should show up on your computer and/or portable audio player automatically.  Yared and I covered a lot of ground during the interview. If you're at an enterprise that needs to put together a highly scalable XML driven and integrated platform, you can decide for yourself whether ActiveGrid is the sort of recipe you've been looking for. If there's one potentially politically incorrect part to ActiveGrid's approach, it's that it focuses heavily on scaling out with commodity hardware (like 2P XEONs). This can obviously be a very cost effective solution to scaling (it's how Google does it).  But, relative to some of the energy efficient scale-up solutions that are coming onto the market today, scaling out with all those machines (and the power it takes to drive and cool them) could be an environmentally insensitive approach.

Nevertheless, scale out does have its advantages. Here's a sampling of what Yared had to say.

Yared on ActiveGrid's core message: "We let corporations very very quickly build Web 2.0 applications that are rich and that have the ability to integrate all their back ends to do these things, but they also have the ability to deploy scalably so to deploy on commodity machines in a way that you just keep adding machines instead of having to scale up."

Yared on what makes ActiveGrid different: "We have a development tool that will soon be based on Eclipse that lets you very very quickly build applications... what's different is underneath that, what you're editing [are] standard XML files. Virtually every single other high-level development environment to date has been one of two things: a glorified code generator, or it had very very proprietary metadata underneath. With the ActiveGrid Studio, what you're doing is you're editing XML files directly. So, when you're building a Web page flow, you're actually editing a Business Processes Execution Language File. When you build a UI, you're editing an XForm directly. When specifying user roles, you're editing an XACML file (the OASIS standard) directly.

The end result of building an ActiveGrid application is you have a set of very very standard XML files, you can then add logic (you know, those small logic you need) in a scripting language such as Python or PHP or Java. So you have ability to build apps very very quickly, you can use different skillsets of developers in different types of languages and you have completely standard applications that come out of it. And then, that's tied with the ability to scale horizontally up to 1000 nodes which nobody can do at this point except for us.

Inside your application, it's all natively XML.. so it can deal with any type of backend very very easily. A lot of things are being exposed as XML. XML is basically a glorified text file.  It's very very slow. So, when you're accessing databases, you still want to use native APIs. What's great about our technology is that once it's in the application, it looks to the developer like an XML data source so all the different backends to the developer look like an XML data source.  They have a WSDL-defined API. They return XML Schema-defined data set. But, whether you're talking to a DB2 stored procedure or just a standard database call or just an RSS call, you're using the same sort of hooks to get into it.

Yared is an ex-Sun CTO but ActiveGrid is echews Sun's techs for LAMP: Unix is a 25 year old technology, that is a commodity technology. Solaris does have some very exciting features. But not features  that you need on a dual processor XEON serving Web pages.... that's why pretty much the whole market..at least on front end stuff is running the LAMP stack. It's the Google message if you will.  Everybody knows what [Google does] and it works a lot better. 

And about that support for Eclipse (as opposed to NetBeans)? We wrote our own IDE. Neither Netbeans or Eclipse had strong dynamic language support....[that's] changing in a big way at Eclipse.  IBM came out in a big way in its support of dynamic languages -- especially PHP -- and did a lot of work on Eclipse to make it move beyond a Java-only development environment. It's a very nice environment, both socially and technically for our type of technology. We did [our own IDE originally] because we though we had to because there was no decent IDE for scripting languages. Now that there is, we don't like writing code editors and graphical canvases. We're moving all that stuff over to Eclipse. It looks better. It works better. People already know it. So, now we can target Eclipse developers; Hey just put in this plug-in and you can build apps a lot quicker. 

Disclosure: In the spirit of media transparency, I want to disclose that in addition to my day job at ZDNet, I’m also a principal of Mass Events Labs, Inc. Mass Events Labs is a producer of events such as Mashup Camp, Mashup University, and Startup Camp. Some of the events (past and planned) produced by Mass Events Labs have or will receive sponsorship from Sun Microsystems. Sun is mentioned in this story. For more information on my involvement with these events, see the special disclosure page that I’ve prepared and published here on ZDNet. 

Editorial standards