UPnP: Protocols vs APIs

Rohit Khare (rohit@uci.edu)
Sat, 30 Oct 1999 15:18:37 -0800

[A few more words on the bonfire of the debate between protocols and
apis, declarative vs. operational, text vs behavior, etc. Squirt some
partisan lighter fluid on the whole shebang: protocols vs API is by
no means isomorphic to open vs closed. RK]


Flexible Platform for APIs and Tools

Successful platforms enable developers. Universal Plug and Play's
focus on explicit open wire protocols means that it is language- and
operating system-neutral. The advantages of this approach to
developers are obvious - the choice of language and operating system
gives them the flexibility to choose the best platform for their
device and still be confident that their products will be able to
interact with other Universal Plug and Play devices, regardless of
platform. For example, it will be possible for a developer using
Windows to interact with services on non-Windows devices by invoking
Windows-based APIs, object models, or even XML-enabled data-driven
programming using familiar languages and tools, regardless of the
Universal Plug and Play implementation on the device providing the

The distinguishing feature between the Universal Plug and Play model
and architectures like Jini is the API strategy. Jini uses APIs as
the sole contract between vendors. Universal Plug and Play is built
around open protocols and data formats. These protocols and data
formats form the contract between vendors rather than the proprietary
APIs defined by Jini. From an API perspective, individual platforms
will implement APIs mapping to the protocols and data formats of
Universal Plug and Play. So, Windows-based Universal Plug and Play
implementations will provide device-specific and service-specific
sets of APIs to speed the development of Universal Plug and
Play-enabled applications on Windows. Similarly, vendors who want to
implement Universal Plug and Play on other operating systems or
devices will do so by adhering to the protocol standards, and may
provide their own APIs targeted at the features provided by their
operating system.

This balanced protocol / API architecture provides many advantages.
Device vendors are not locked into a one-size-fits-all single-vendor
operating environment, language or tools. Customers benefit from
devices that can seamlessly interoperate in a multiple-vendor
environment and with the Internet.

Universal Plug and Play achieves this flexibility without an
architecture that requires moving or downloading code. This is an
important point. Code download models like Jini introduce a
dependency on a single vendor's execution environment. More
problematic, however, is quality control. In the Jini code-download
model, one vendor moves code that uses a common API onto another
system where it can be called using local calling conventions. In
effect, device-to-device connectivity is achieved by creating, at run
time, a single application consisting of code written by different
vendors. Code download pushes the testing problem to every developer,
every device and every service vendor. Even today, different teams in
a common vendor environment have difficulty implementing against API
specs. It's hard to imagine how teams will manage the complexity of
the Jini environment.


The transition from a world of standalone devices to networked
devices, from appliance users to information users, will not happen
overnight. It will certainly not happen any time soon if a costly,
winner-take-all API battle is waged. Universal Plug and Play is an
open initiative to take existing standards, existing technologies and
existing knowledge, repurpose it, and deliver on the promise and
opportunity of the networked world. Standards-based, simple enough
for the smallest appliances to implement, powerful enough to scale to
the global Internet, and based on the proven approach of explicit
protocols, Universal Plug and Play is an incremental approach, but an
approach that has been proven to work.