Introducing Jockey

Two powerful, yet separate topics in computing have emerged recently: Peer-to-Peer Computing and Service Frameworks (like those implementing Web Service protocols).

Jockey is an open API for peer-to-peer and service oriented frameworks.

Why is there a need for Jockey?

As new technologies emerge, it is common for them to begin to overlap with existing technologies. It is also natural for some of the features to creep between technical domains; unfortunately this often leaves the application programmer confused. Jockey attempts to draw the line between Service Provider Frameworks and Peer Frameworks and unites the two powerful services under a single umbrella.

Jockey also acknowledges that multiple versions of peer and service frameworks exist and the number will only increase in number over time. In this vein, Jockey provides a standard interface into these services and also provides a bridging mechanism between them as well.


The Jockey API is divided into two components:

Jockey Goals

Target Device

Jockey does not prescribe to the "one-size-fits-all" mentality of computing. The Jockey API is designed for desktop computers and servers. It is not intended to work on limited configuration devices. We do not believe that the Jockey is overly heavy, but the design goal remains desktop computers.

Calls made from Jockey to lightweight devices will use well-known protocols (like JXTA and SOAP) as a communication mechanism. There is NO requirement that Jockey be used on both sides of the communication link. Jockey should be used as a convenience layer on devices that have the luxury of using a convenience layer.

Initial Verification

Only time will tell if Jockey fulfills the goals that we have set out to achieve. To help prove these goals, our intent is to use the following tests as verification:

The Big Picture

"Corporate Web Services" represents the set of web services that a business makes available to their trading partners. Typically, these services concentrate on performing business-to-business transactions.

"Personal Web Services" represents the set of web services that reside and execute on an individuals local desktop. These services can be simple information providers like those found in Hailstorm (myWallet, myCalendar, myContacts, etc.). In addition, personal web services are a repository of business logic for rich-client applications. In this context, personal web services provide an abstraction between the application UI and the business logic.

Note that bi-directional communication between personal web services and corporate web services is now possible through Jockey. This allows for corporate web services to aggregate data housed at the employee's desktop as well as allowing the desktop user to query pre-aggregated information at the corporate level.

Another benefit of Jockey is the abstraction between the application and the network. Once can anticipate that several peer-networking standards will evolve from consortiums like the Peer-to-Peer Working Group, as well as from companies like Sun, IBM and Microsoft. Regardless of the network, peer applications will still need to communicate.

Some basic assumptions were built into the design of Jockey:

  1. People will work on different operating systems.
  2. People will work in different computer languages.
  3. People will work on different peer networks.
  4. People will have preferred providers of service managers and peer networking technology.
  5. People will have applications written in different languages using one or more peer networks.
  6. People will have applications which reference services where each service could be written in a different language.

With these assumptions in place, our design goal was to develop a simple application programmers API to enable ad hoc, distributed computing regardless of the aforementioned challenges.

Applications should not need to be re-written if the underlying networks change. Imagine if all applications had to be significantly modified when a company changed their network from Novell to a Microsoft network. The history of computing has told us that these types of changes will occur. The answer has been simple; provide an abstraction layer. Just as sockets provided abstraction to TCP implementations or ODBC provided abstraction to databases, we are now finding it necessary to provide abstraction from our peer networks and service invocation providers.

Time and market forces will flush out the survivors in this fast changing market. Jockey provides common semantics that preserves time and money investments in distributed application development by abstracting the developer from the Darwinian process that is unfolding in peer and service technologies.

Next: What is a P2P Framework?