Recovered from the Wayback Machine.
If the Net is good for one thing, it’s the propagation of buzzwords and acronyms. In the case of P2P – Peer-to-Peer – you have a term that is both buzzword and acronym, and represents a group of technologies that is both very old (in Net terms) and very new.
Well, that’s all fine and dandy, but what the hell is P2P?
Well, some (such as Clay Shirky of The Accelerator Group) would say that P2P technologies encompass any technology that exists outside of DNS. Sounds impressive, but what does this mean?
This means that P2P services are accessed using some technique other than Domain Name Service (DNS) lookup. DNS is used to find specific IP addresses using well-known and human friendly aliases such as www.w3.org. P2P doesn’t rely on DNS and aliases such as these because much of the P2P resources and/or functionality may exist on IP addresses that change every time a participant connects to the Net through something such as a dial-up modem.
Tim O’Reilly broadens P2P to include any technology whereby peers share services and/or resources rather than these same resources being served up by a central server. In addition he also includes collaborative functionality and distributed computing, as well as instant messaging services such as AOL’s Instant Messenger and Jabber. In each of these, common points of intersection are features such as an assumption of no fixed IP address and no reliance on a common, centralized server.
Based on this, a standard Web application is not P2P because clients that access a site’s functionality all do so through one common server – the Web server – using a well-known DNS-supplied and supported name. Though the approach is Net-enabled, this way of serving functionality is a variation of the standard client/server application model that’s been around for years, with the browser acting as what is termed a very thin client (i.e. very little of the functionality is present on the client, most resides on the server).
So, if Web browsing isn’t P2P, how does P2P work?
As an example of P2P in action in its purest form, Gnutella is a P2P application that enables file and resource sharing among peers. To participate, you download the Gnutella client software, you pick an IP address among any that are currently connected to the system and connect to that IP, or connect to several IPs of friends and known associates who are also Gnutella clients.
Once connected to the Gnutella network, you have access to the peers each of your connected IPs are connected to, and through these secondary connections you have access to their connections, and so on. Sort of like a phone tree where the phone numbers change every day, but you’re guaranteed to have access to at least one of the numbers at any given time.
What happens once you’re connected? Well, in the case of another known P2P application, Freenet, you can issue a request for a specific file or resource, and any client that has access to that resource returns it via the request path…to you.
Gnutella and Freenet share the same common characteristics of P2P applications. Both use a naming system other than DNS to locate peers; both don’t require a common, centralized server. However, they differ in that with Freenet, each peer along the request path could keep a copy of the resource requested, basically increasing its availability. The more times a resource is accessed, the more peers have the resource on their own machines, the easier it is to access the resource.
With Gnutella, only the original resource and you since you’ve now accessed this resource have access to it. Because of this, you’re less likely to find the resource you’re requesting because it’s out of range of your request, or beyond the horizen. (Your request, unlike the ghost ships of yore isn’t going to float about the Internet, unsatisfied, forever. It will time out at a certain point.).
(Andy Oram has an excellent article on Gnutella and Freenet at http://www.oreillynet.com/pub/a/network/2000/05/12/magazine/gnutella.html.)
Okay, so that’s a quick look at some of the more well known P2P applications (other than Napster, and I’m sick of hearing about Napster). So now you might be asking yourself why you would care about this type of technology? Especially in a business context? After all, how can you charge for something when there’s no centralized server and no way of knowing which peer is accessing what resource?
Going back to Tim O’Reilly’s original list, let’s take a look at the concept of collaboration. In a collaborative P2P application, a group of peers work together on a specific project, such as a document or a presentation or using a virtual white board to brainstorm. In this type of environment, the services to work on the collaborative project are located on the peers, and the data is propagated to each of the clients at set intervals (based on the type of collaborative effort and the infrastructure supporting the peers). Again, there doesn’t have to be set IP addresses (though there isn’t a prohibition against fixed IP address), and there doesn’t have to be a central server (though again, a central server could be used to do such things as backup group data periodically – as long as it isn’t essential to the application process). In fact, a hybrid P2P application can be one that uses a centralized server for IP lookup, but all other services are performed on the peers.
It would be safe to say that this type of application does have commercial possibilities, and it is this type of technology that’s currently being implemented within the Groove architecture, a framework and toolset as well as application created by Ray Ozzie of Lotus Notes fame.
(You can download Groove at http://www.groove.net.)
How viable is something such as Groove? Viable enough to warrant 60 million dollars of Venture Capital money, and that’s big bucks to folks like you and I.
How Groove works is that a person wanting to be a peer downloads the Groove application/infrastructure and installs it on his or her machine. The architecture supports a user interface that provides a working area, known as a shared space, for the collaborative efforts supported by the application.
A shared space could contain something as simple as a discussion forum, a virtual white board, or a chess game; or it could contain functionality as complex as a piece of a sophisticated supply chain application.
The Groove architecture provides the infrastructure to support tools that can be used in the shared spaces, and vendors can provide Groove “connectors” for their existing applications, or can create new tools for Groove, through exposed interconnectivity accessed through the Groove Developer Kit (GDK).
So, if a major player such as Ariba wanted to publish their software services through Groove, they can by using the GDK to create a Groove tool that acts as a connector to the company’s services. By doing this, Ariba then gets the benefit of an architecture that supports safe, secure, efficient, and multi-peer access of its applications without having to write more than some XML files, and perhaps a COM/COM+ wrapper (if the Ariba service isn’t currently implemented as a COM service – Groove’s current service implementation).
How will Ray Ozzie make money with Groove? By licensing the Groove architecture to these third party service suppliers, who in turn, license their services to the peer – the customer wanting access to the services.
Making money. Sounds good.
(See an article “21 for 2001” from internet.com at http://boston.internet.com/views/article/0,1928,2011_552841,00.html that looks at 21 startup companies in Boston this publication believes will succeed in the year 2001. Features Groove)
A company can use P2P-friendly technologies, while still staying within more conservative, mainstream client-server types of implementation, such as browser-based access. For instance, speaking of Ariba earlier, this is a company that is using technologies that would enable this company to become P2P-abled fairly easily, if the company chooses.
As an example of P2P-friendly technologies, Ariba is partnered with webMethods, a leading integration application software company that provides a centralized “hub and spoke” technology to allow different companies’ heterogeneous applications to communicate.
(See more on webMethods at http://www.webmethods.com. More on the products at http://www.webmethods.com/content/1,1107,SolutionsIndex,FF.html.)
Ariba supports a dialog of XML (another buzzy acronym that turned everything upside down) called cXML – Commerce XML – within its Ariba Commerce Services Network (CNS) architecture. This architecture, in turn, supports many of the popular eMarket and B2B Ariba applications such as Ariba MarketPlace or Ariba Buyer.
To support integration with clients, all transactions within the CNS architecture are based in cXML, and webMethods has provided a cXML interface within its own set of integration applications. As webMethods supports interfaces to numerous other XML-based languages such as RosettaNet and numerous other technologies, clients can access the Ariba CNS services through the webMethods supplied cXML interface, using their own application-specific technology (and legacy systems – no major re-write required).
So a buyer can use Ariba CNS services to access a catalog item and purchase an item, and have the process connect seamlessly to the supplier applications created using something such as EJB (Enterprise Java Beans) through the webMethods integration interfaces.
Now, technically, all of this in dependent on a server being in place (the CNS services and the webMethods hub), but the infrastructure is such that it wouldn’t take a major re-engineering effort to lighten and split apart the services to form a P2P network. And Ariba and webMethods would still lease or sell their individual services – integrated licensing could prevent any individual from sending copies of these services out freely on the Net for anyone to use.
There’s that making money again.