This month WSJ focuses on P2P architectures and grid computing, two topics that are gaining momentum in our industry. Over the past year or so I've read many excellent articles and books on these topics. However, getting a handle on what P2P and the grid are can be a challenge as implementations advance rapidly, major technologies are converging, and more people are applying these concepts to their particular disciplines.

I recently had the opportunity to interview Graham Glass, CEO and founder of The Mind Electric. We discussed the definitions of P2P and grid computing, the importance of service discovery, how TME's products relate to P2P/grid concepts, and the future of service-oriented computing. I've known Graham for some time and have always found his work and insight to be both solid and valuable. This article should give both developers and managers a better perspective on the state of the technology and how grid and P2P can help them solve problems.

Graham, tell us a little bit about yourself and The Mind Electric.
Graham: I'm the CEO and founder of The Mind Electric. TME builds software infrastructure for creating systems out of Web services, specifically moving our clients toward service-oriented architectures. Additionally, we believe that there will be a strong convergence between technologies like Web services and architectures like P2P.

What were you doing prior to starting The Mind Electric, and how did you get involved with distributed computing?
Graham: I've actually been in distributed computing for a long time. In a previous lifetime I founded a company called ObjectSpace, which had a good reputation for a product called Voyager. Voyager was in the days when object request brokers were kind of state of the art. The goal of Voyager was to make distributed computing based on object request brokers as simple and easy as possible. That theme of "making things as simple as possible" is something I've always held near and dear to my heart. The Mind Electric is doing the same kind of thing, but for much more sophisticated software infrastructure problems. We're in the business of making the construction of professional-quality enterprise systems out of Web services as simple and easy as possible.

We're hearing the term peer-to-peer, or P2P, frequently in the press. From your point of view, what is peer-to-peer computing?
Graham: I think from a technical perspective, when people talk about peer-to-peer they're really talking about highly decentralized architectures. For example, a client/server architecture is one where the server is generally a beefy machine with a whole bunch of mission-critical stuff and the clients are dumb. That's a setup that is clearly not a P2P system because the server is way more powerful and resilient than other nodes. I would say personally that peer-to-peer is more of a mind-set.

It's much like the days of object technology, where a lot of people didn't really know what an object was. They would ask for an example of objects in practice. I have an example that I've used quite successfully to show people what P2P is really all about; it has to do with cell phones.

If you look at how cell phones work right now, your phone is quite dumb. To set up a cellular network, you have to install base stations at a number of different points. This is quite like the client/server model - the phone is the client and the base station is a fairly extensive server. To extend the cellular network you have to put a bunch of base stations in place.

In a peer-to-peer cellular network, the cell phones would be both client and server. So if a cell phone were not being used as a way to communicate, then it would automatically switch into a kind of transmission mode and be able to route other people's cellular phone signals. Now, without needing base stations, you could basically air drop 100,000 cell phones into someplace and boom! - Instant cell network!

Another hot topic is "grid computing." Could you speak about that and its relation to peer-to-peer computing?
Graham: Grid computing is something that was initially about how to use free machine cycles to do high-speed scientific calculations. But as people get into Web services they're saying, "If I create a Web service, when I publish it for use by other services, what is the technology that will allow those services to connect together?" In other words, what will connect the producer and the consumer? And if a Web service fails, what will automatically route requests to a new server? The industry is realizing that a good architecture for doing this work is very similar to the architecture for managing services in the domain of electricity distribution. In the national power grid, if you're a producer - not of a Web service but of electricity - you can easily plug in a power generator somewhere. If some consumer wants to use electricity, they effectively plug into the national grid and it is responsible for connecting producer and consumer, billing, routing, and load balancing.

In the realm of electricity it's very clear what "the grid" does; people are now saying, "Hang on, we can do the same thing, but for Web services and for XML data." People are looking at grids as a general-purpose concept for linking together producers and consumers of services and data. It just so happens that when you start building large-scale grids, it's very natural to use P2P architectures to implement them because P2P architectures can usually scale much better than client/server architectures.

The Mind Electric's two products are GLUE and GAIA. GLUE is a core Web services platform. Can you describe GLUE and then tell us a little about GAIA and how it is a P2P and grid-computing enabler?
Graham: Our product line is designed to help enterprises go through the adoption curve of Web services from beginning to end. The beginning is, "How do I build my first Web service?" Developers then progress towards the mental evolution of "How do I now build systems comprised of a large number of services hosted in a variety of different platforms?" So the first phase of adoption is what GLUE is targeted at. For Java developers it's all about how do I rapidly create and then deploy Web services. The very early versions of GLUE simply focused on the early parts of the puzzle, but the latest versions include advanced features like a high-speed Web server, servlet engine, JSP implementation, and all the standard J2EE application stuff. The main reason GLUE is so successful is because it makes this very simple and that's what we think Java developers really want.

We think that once people start building Web services, some of which will be built using Java, some built using .NET, then in order to connect these services together reliably you're going to need something that is the equivalent of the national electricity grid. GAIA is targeted at tackling this second stage of evolution. If you imagine having a bunch of different services created in a vendor-neutral way, then GAIA is designed so you can plug something into it and, just like the national electricity grid, it will connect the producers and consumers to perform fail-over, load balancing, discovery, etc. But most importantly, GAIA does this all in a way that's independent of the service implementations themselves.

Service discovery has been an issue for a couple of platforms, JINI and UDDI being two of the most prominent. Please speak about them and GAIA's service discovery.
Graham: Let's look at JINI to begin with. JINI, at least so far, hasn't been particularly successful and one of the reasons was because it was so Java-centric. In a world that is so heterogeneous, with services written in C, Perl, and C#, having a discovery mechanism that's based purely in Java is never going to be successful.

However, one of the things that people liked about JINI, especially in the Java world, is that it was relatively transparent in the way that you used it. So if there was a Java interface for a currency exchange service, it was very easy to say, "Find me a service that implements this interface" and you would get back a proxy and invoke the service transparently.

Java developers using GAIA will find it even easier than any code examples you might have seen in JINI to discover and use services. With one line of code in GAIA you can say, "Find me a service that has a certain interface," and it will find that service if it's compatible, regardless of whether the actual service is an EJB, C#, or VB component - it makes no difference to GAIA. So the first difference is basically ease of use, which we've got a great reputation for.

As far as UDDI goes, it's really just an API to perform a search using XML. UDDI doesn't actually enforce any particular architecture for doing that. One of the things we're looking at is providing a UDDI skin over GAIA. In other words, if you want to access GAIA as if it was a UDDI server, then you can do it through the standard UDDI API. Under the hood GAIA would be using a P2P architecture to actually broker services and the publications.

You said that one of the weaknesses of JINI was that it was Java only. Do you think the JINI team at Sun has learned that lesson and is applying it to JXTA?
Graham: Good question. The lesson they learned most clearly shows up in JXTA just because it's now completely focused on protocols not implementations. I think that JXTA has definitely learned a lot from the JINI experience. It's tricky to understand right now where JXTA is going. It seems to be absorbing more things and becoming less and less JXTA-like over time. Additionally, I think when people look at the architecture in GAIA they'll find it to be insightful.

Do you have any plans for implementing GAIA in languages other than Java? Is there a need to do that?
Graham: It's funny you should ask that. A lot of people who are familiar with The Mind Electric and GLUE would pigeonhole us as a Java-centric company. That's certainly our roots, and we really love Java as a language, but the reality is that there are going to be a lot of other technologies out there, specifically Microsoft's .NET. We wanted to make GAIA as efficient as possible for the platforms that it's actually installed on. Also, we want GAIA to run reliably and quickly on small devices like PDAs, and a lot of PDAs look like they're going to start shipping with the .NET Compact Framework. Later on this year we're going to be porting GAIA to the C# language so it will be a native .NET implementation of the same technology. There will be a .NET version for .NET developers and a Java version for Java developers. They will all completely interoperate. So if you want to build a grid composed of services using .NET it's completely transparent as far as GAIA goes. It uses XML for all of its communications; there's nothing language-specific about the architecture at all.

Back to the grid. When UDDI came out there was a lot of talk about big public UDDI registries. The reality has been that that model has not taken off and it is being downplayed, often at the expense of private UDDI registries. Right now the talk is about 'the grid'; do you see a single grid emerging or do you see many grids?
Graham: I think there'll be a global grid that will share general information and services, but companies will also have their own internal grids. Your company, even within projects, might have mini-grids. The mini-grids are almost like next-generation app servers, and they might be connecting 10 or so different computers. A small grid will presumably be able to access some of the power of the large grid that it's plugged into and so on. Public services will be used by private grids but not the other way around. That's my prediction.

We have it on record. Thank you and best of luck with the upcoming releases of GLUE and GAIA.