[This local archive copy mirrored from the canonical site: http://www.marimba.com/datasheets/osd-wp.html, text only; links may not have complete integrity, so use the canonical document at this URL if possible. See the database entry: Open Software Description Format (OSD).]
Contributors:
In August of 1997, Marimba and Microsoft jointly submitted a standards proposal called Open Software Description (OSD) to the World Wide Web Consortium (W3C). OSD is a compact software language for describing the contents and dependencies of software packages. Such a standard language is needed to realize the Internet's potential as a medium for delivering all types of software to any kinds of client platforms. The cooperation of Microsoft and Marimba in developing the OSD specification testifies to OSD's importance and its applicability to a broad spectrum of software distribution contexts.
This paper describes OSD and the motivation for its development. It shows how OSD can substantially improve the user experience of downloading software over the Internet. It explains how software developers can use OSD, and how OSD relates to other Internet standards. The paper concludes with perspectives on OSD written by Marimba, Microsoft, Tivoli, and Novell.
The Internet is increasingly used for distributing software. However, from a user's persective, obtaining software is often more difficult than it should. A common example: A user downloads one piece of software only to find it won't run because it requires another piece of software. Or a user clicks on a Web page to find that some page element (a movie, perhaps) can't run without a particular browser "helper."In both examples some software or Web page component has a dependency, a piece of software that it needs to operate as its developer intended. Today, the burden of locating, selecting,and acquiring dependencies falls on the user. The increasing trend toward component-based software will make these problems more common over time.
Learning that a dependency is needed is only the first challenge. Next comes finding the required software, a job that may be complicated by software permutations. Any given software package may come in multiple editions: for different platforms, for users who speak different languages, and sometimes in "lite"and "pro" versions. Each edition may have multiple release levels, such as 2.3.1 and 2.4. What the user needs is the right edition, but finding the right edition can be surprisingly complicated. Dependencies can also differ by platform; a software package may need a movie player on one platform but not on another because the appropriate player is built into the second platform's operating system.
Today's Internet users have been forced to grapple with the complexities of heterogeneous software configurations because there has been no standard way for clients (such as Web browsers) to know about and locate the right software. The OSD standard is the key element for creating "configuration-savvy"clients that can make the Internet a much more attractive medium for distributing software and a simpler medium for end-users. Recognizing its importance and applicability, the OSD standard proposal was immediately endorsed by CyberMedia Inc., InstallShield Software Corp., LANovation, Lotus Development Corp., and Netscape Communications Corp.
OSD is a language for describing the composition of software packages in a standard, platform-independent way. A software developer uses OSD to write a "bill of materials"describing the constituents and dependencies of a software package. An OSD file, which may be located anywhere on the Internet, lists the available implementations of a package and their attributes. For example, there may be one implementation for Windows platforms, another for the Macintosh platform, and others for Unix platforms. Each implementation can have a list of dependencies in the form of links to other OSD files, which can also be located anywhere on the Internet and have their own dependencies. Clients, such as Web browsers or Marimba Castanet Tuners, can use an OSD file to learn what files constitute a software package for a particular client platform and particular user preferences.
After determining which packages need to be installed the client can automatically select and download the right editions of the all right files, including dependencies.
Much as HTML is a language for describing the contents of a Web page, OSD is a language for describing the contents of a software package. The definition of "package"is open-ended and accommodates at least applications, applets, Web browser plug-ins, and Common Object Model (COM) or JavaBean components. Software packages are only described with OSD; their code can be written in any programming language. OSD is defined using XML, the extensible markup language; this emerging standard for representing Internet data is described later in this paper. Anyone familiar with HTML will see similarities in OSD.
As an HTML file can contain links to other HTML or media files, so an OSD file can contain links to other OSD files. These linked OSD files represent sub-packages or dependencies: related software that an implementation of the package requires. Each implementation listed in an OSD file can have its own set of dependencies, and the implementations of a dependency can, in turn, have their own dependencies. Because OSD links are World Wide Web URLs, the descriptions of a package's dependencies may reside anywhere on the World Wide Web. The most likely place for a dependency OSD file is a Web server associated with the package's provider.
An OSD file describes a software package. Some of the tags in an OSD file are global, such as the software package name, abstract, version, and licensing information. Most tags, however, apply to a particular implementation of the package, describing such things as:
An implementation is a distinct edition of the package that is downloadable as a unit. An OSD file lists an implementation for each platform it runs on. The platform orientation of implementations makes sense for a language that describes software, because much software is inherently platform-specific. The OSD definition of "platform"is very broad: it encompasses flavors of Unix, MacOS, the Windows operating systems, and emerging network computers. OSD implementation tags can also distinguish user languages: German and French editions of a package that run on the same platform, for example.
The following schematic depicts an OSD file for a hypothetical package called Solitaire. (An actual example OSD file is shown later in this paper.) It lists two implementations, one for Windows95 platforms and one for JavaTM platforms. The JavaTM implementation needs the package described in a second OSD file. If directed by a user to download Solitaire, a client would read solitaire.osd and download either solitaire.cab or solitaire.jar, depending on the user's computer and choice. If it downloaded the JavaTM implementation, the client would also download its dependency described in cards.osd-unless the user's computer already had acquired the package described in cards.osd in a previous download.
The Internet's success is in large measure due to its definition of platform-independent standards that combine simplicity with utility. Well-known examples include SMTP (email) and HTML. OSD follows in this tradition. Like HTML, OSD has been designed for easy implementation to encourage rapid and widespread adoption. Its designers have deliberately resisted the temptation to try to address every nuance of software package management. Like HTML and email, OSD can evolve as experience shows the way. For example, it may eventually make sense to add tags for device drivers and country codes. But meanwhile, implementing the initial version of OSD will substantially improve the software downloading experience for users. OSD can also be extended on a per-application basis, using the XML namespace facility; clients are free to ignore these specialized tags just as Web browsers are free to ignore HTML tags they don't understand.
OSD is an Internet standard that uses the Internet itself. The OSD tags that specify files, whether code files or other OSD files, use Universal Resource Locators (URLs). A web of OSD files, and the code files they refer to, can therefore be concentrated on a single server or dispersed worldwide. Adding a dependency on the product of another vendor requires nothing more than knowing the URL to that product's OSD file: It's just like adding a link to a Web page.
The complete description of all implementations of a software product is a web (technically a directed graph) of OSD files. An OSD file deliberately does not specify the means by which the software it describes is distributed. Regardless of delivery method, OSD can work as well with Marimba's Castanet application distribution and management platform as it can with Microsoft's Internet Explorer.
OSD can also be used for conventional CD-ROM distribution. OSD file references are URLs that can as easily name packages on a disk as packages served across the Internet. One can imagine, for example, a CD that contains multiple editions of a software package plus an OSD file that describes them. The CD can also contain a universal installer which ascertains the characteristics of the user's platform and then copies the relevant files from the CD. The installer can even connect to the Internet to resolve dependencies on packages not included on the disk.
OSD is based on the XML specification. This means an OSD file consists of a simple text file containing tags that describe the software dependencies in both a machine-readable and a human-readable format.
Using the XML namespace mechanism it is possible to add new functionality to OSD without causing incompatibilities. In that case new tags are introduced to the OSD file which are safely ignored by clients who are unaware of them. As a result OSD can be used in a variety of applications ranging from browsers to sophisticated software distribution systems. A browser can add tags it requires and these tags can be ignored by applications to which they don't apply.
An OSD file simplifies the distribution of multi-edition products by describing all editions in one place, in a standard notation, while preserving the freedom to locate the code files anywhere. For example, the Macintosh version of Solitaire can be served from Cupertino, while the Windows 95 edition is maintained in Redmond.
Download pages at Web sites can also be simplified. Instead of a separate link for every edition of the product, a single link to an OSD file enables all OSD-aware clients to select and download software editions. In particular, Web browsers that understand OSD can choose browser-specific software on their own, without requiring developers to create scripts that generate browser-specific software download pages on the fly. OSD provides developers with a uniform way to define a "menu"of the implementations that are available for a particular software package; the job of choosing from the menu is shifted to the browser or other client software.
OSD files simplify dependency management. There's no need to either:
Instead, vendors can maintain OSD files for their own products that link to the OSD files of dependency software provided by other vendors. Users of OSD-aware clients automatically get the dependency software they need-and no more. Developers are free to expand and modify their OSD files, without fear of affecting other OSD files that list them as dependencies. Clients that visit an OSD file as a result of following a dependency link always get the current list of implementations. Moving a code file listed in an implementation similarly has no effect on clients.
Users of OSD-aware clients get what they want and what they should always have had: precise, transparent software acquisition. There's no more wading through Web pages to find the edition of the software that matches the user's platform and language of choice. There's no subsequent discovery of missing dependencies, which must be located and downloaded to get the primary package working. Nor is any time wasted downloading superfluous dependency software that's either already installed or is not required for a particular platform.
Because OSD files describe application dependencies, it is advisable to use digital signature technologies such as SSL transport, RSA authentication, MS Authenticode, or the W3C's Digital Signature Initiative to ensure the authenticity of the OSD file. Alternatively the OSD file can be part of an archive of resources which is digitally signed.
The OSD standards proposal is an important step toward making the Internet a medium for automatic software distribution. It specifies how the attributes, especially platform attributes, and dependencies of a software package can be described by developers and understood by downloading client software. But OSD does not solve the entire problem of automating software distribution; for example, OSD is silent on the subject of transport. Other standards complement OSD by addressing other aspects of automatic software distribution.
Microsoft's Channel Definition Format (CDF) describes content channels as used in Internet Explorer. Although CDF channels are usually content-oriented, they may either contain software components or require them. For example, a channel containing a movie needs a movie player. CDF files can be augmented with OSD files that describe these software components so they can be downloaded automatically.
The HTTP Distribution and Replication Protocol (DRP) by Marimba, Netscape, Novell, Sun, and @Home defines an efficient way to transport and, especially, update software over the Internet. DRP does not address the question of what can be downloaded; that is OSD's province. The combination of OSD and DRP provide a powerful and efficient mechanism for software distribution.
The Resource Description Framework (RDF) is an emerging standard for describing Web resource meta-data based on XML. Because OSD is defined as an XML vocabulary, it is compatible with RDF. In the future RDF will be used in conjunction with OSD to form a web of meta-data which can be accessed in a variety of ways.
The Application Management Specification (AMS) developed by Tivoli Systems in 1995 expanded the original Desktop Management Forum (DMTF) work for managing software on desktops to cover the aspects of managing distributed applications in heterogeneous environments. Like OSD, AMS allows software developers to describe the details required to deploy software by describing the deployable packages of an application (referred to in AMS as "software components"), the bill of materials for these components, by describing the dependencies these components have on other components, and the depedencies components have on the systems they run on. Additionally, AMS can be used to improve the manageability of software in the application life cycle stages that occur after deployment. Specifically, AMS can capture the details required to configure software components by describing the steps required to properly install components, by describing how these components can be connected together, and by describing the tasks or commands used to configure components. For software components actually in use (executing), AMS provides ways to describe the details that can be monitored to understand the health of a component and the tasks/automation routines needed to maintain healthy states. Finally, software developers can describe the access rights security administrators need to establish to effectively control the actual use of the software components. This breadth of information makes it easy to automate the processes associated with deploying, configuring, monitoring and securing applications in full scale environments.
AMS captures information in a standards-based, platform independent way. Additionally, the information captured in AMS can be expressed in a variety of syntax so it is easy to use in a variety of environments. For example, AMS was originally expressed using DMTF's Management Information Format since this is a standard for describing desktop management information. Today, AMS 2.0 is based on the Common Information Model (CIM) initiative being lead by the DMTF. Thus, it is also expressed using the Management Object Format (MOF) prescribed for CIM. And the relevant pieces (for example, bill of material) can be easily expressed using XML for OSD.
The Desktop Management Task Force (DMTF) has developed a Common Information Model (CIM) to take advantage of object-based management tools and provide a common way to describe and share management information enterprise-wide.
Using HMMS as an input, the new model can be populated by DMI 2.0 and other management data suppliers, including SNMP and CMIP, and implemented in multiple object-based execution models such as JMAPI, CORBA and HMM. CIM will enable applications from different developers on different platforms to describe and share management data, so users have interoperable management tools that span applications, systems and networks, including the Internet. The documents can be found at http://www.dmtf.org/.
The CIM Application model was developed by the Desktop Management Task Force (DMTF) to describe Application Systems and associated elements using a Managed Object Format (MOF). This model is intended to record the details that various management tools need to know to effectively manage an application.
Both the CIM Application Model and OSD use an object-oriented approach to describing software. Although the scope of these models does overlap, the initial intended uses differ. Where OSD was designed to primarily address retrieving and installing software over Internets; the CIM Application model was designed to instrument large distributed applications. In order to handle the more complicated case, the CIM Application Model captures details about the software in one of four states( deployable, installable, executable, and running) and manages the transitions between these. The overlap with OSD is with the deployable state.
The actual formats of MOF and XML are not mutually exclusive. It is currently being discussed to describe a mapping between XML and MOF. XML is an SGML derivative that uses a tag structure to define classes and properties, where MOF is an IDL like format that also can define classes and properties but is designed to be compiled. The CIM model also has a set of rules defined within its meta-schema. These rules control a number of aspects of the model such as inheritance and references. Therefore it would be possible to express the CIM Application model in XML. It is the intent of the DMTF to unify these two models going forward.
Marimba is focused on providing products in the software category known as Application Distribution and Management (ADM). ADM is emerging to help companies distribute, manage, and maintain mission critical applications over the Internet, intranet, or extranet. Marimba's Castanet is the leading solution in this rapidly maturing category.
Castanet consists of client (Castanet Tuner) and server components (Castanet Transmitters) that work together to distribute, update, and manage applications, or channels. Castanet can distribute and manage any off the shelf or custom application, written in any language, such as Visual Basic®, JavaTM, C or C++. Castanet works over the corporate intranets, extranets, and the Internet.
OSD complements and extends the Castanet product family. The implementation of the OSD standard into Marimba's Castanet products will go further to reduce the complexity associated with the distribution of mission critical applications. This will simplify the software developer's job of neatly packaging and managing software deployment dependencies for distribution as well as make software deployment completely transparent to the end-user with Castanet. End-Users get automatic updates, when needed, to software applications and data and then have the differences transparently downloaded, installed, and launched on the desktop.
OSD fits very well with the Castanet family and Marimba is using OSD throughout its product line. Here are some examples of how OSD will enhance Castanet products:
An OSD ExampleHere is an example OSD file that describes the hypothetical application Solitaire. Two implementations are available, one that runs native on Win32 platforms, the other on JavaTM platforms. The JavaTM implementation has a dependency that is described in another OSD file. <SOFTPKG NAME="com.foobar.www.Solitaire" VERSION="1,0,0,0"> <TITLE>Solitaire</TITLE> <ABSTRACT>Solitaire by FooBar Corporation</ABSTRACT> <LICENSE HREF="http://www.foobar.com/solitaire/license.html" /> <!--FooBar Solitaire is implemented in native code for Win32, Java code for other platforms --> <IMPLEMENTATION> <OS VALUE="WinNT"><OSVERSION VALUE="4,0,0,0"/></OS> <OS VALUE="Win95"/> <PROCESSOR VALUE="x86" /> <LANGUAGE VALUE="en" /> <CODEBASE HREF="http://www.foobar.org/solitaire.cab" /> </IMPLEMENTATION> <IMPLEMENTATION> <IMPLTYPE VALUE="Java" /> <CODEBASE HREF="http://www.foobar.org/solitaire.jar" /> <!-- The Java implementation needs the DeckOfCards object --> <DEPENDENCY> <CODEBASE HREF="http://www.foobar.org/cards.osd" /> </DEPENDENCY> </IMPLEMENTATION> </SOFTPKG> |
Microsoft supports the OSD standard in Internet Explorer versions 4.01 and greater. Corporations and ISVs can utilize the support for OSD in three primary ways: To automatically notify users of new versions of software (also known as publishing the application) to update ActiveX controls when new versions become available and to extend Internet Explorer's Internet code download mechanism.
For the first two functions, which involve publishing applications, Microsoft's ZAW (Zero Administration Windows) initiative is the best solution for the corporation since it provides true administration for corporate deployment. For publishing through the Internet, though, Internet Explorer and OSD provide the optimal solution. By utilizing OSD vocabulary inside a Channel Definition Format (CDF) file to create a software update channel, software publishers can notify users of new releases of their software right at the launch of the application. In addition, the publisher can pre-cache the new bits through the channel so the user does not need to be connected to the Internet to upgrade.
For the third function, OSD provides an enhanced mechanism to describe software distribution units downloaded through the browser. With OSD, software packages can now describe JavaTM packages and classes, complex dependencies on other distribution units, and filtering criteria for distributing software based on the client's hardware. For example, using standard OSD vocabulary, an author can create a package which installs different software for Alpha and x86 systems within the corporation without requiring user intervention. In addition, if the software depends on the existence of other software on the system, Internet Explorer discovers this through the OSD vocabulary and automatically installs the required software dependency first.
Microsoft intends to continue enhancing OSD support in future versions of Internet Explorer. Further information about OSD in Internet Explorer can be found within the Microsoft Internet Client SDK, located at
http://www.microsoft.com/msdn/sdk/inetsdk/help/itt/osd/overview/overview.htm.
Tivoli Systems Inc. provides the industry's leading solution for end-to-end management of distributed computing environment, from mobile computers to mainframes. Thousands of companies around the globe use TME 10 and compatible third-party products to reduce the cost and complexity of managing networks, systems, databases, and applications.
Since Tivoli addresses management needs of heterogeneous IT systems, its product line blends with the various technologies native to the different environment (for example, SNMP for network management). Because OSD is XML based, it is a natural way to capture and record management information required to distribute software between IT organization controlled servers and desktops not control by the organization over the Internet. Just as the information captured in AMS can be used to generate MIF entries for the desktop, it can also be used to generate OSD documents. In this way, information that has been captured via AMS for managing software inside the enterprise can be used to solve the problems associated with managing the extended enterprise.
Tivoli provides a toolkit, the AMS Module Designer, that is capable of capturing the management information for applications and is capable of rendering this information in various formats like MIF, MOF, XML. This makes it easy for software developers to record the information without concern for the actual syntax. Because OSD, AMS, and CIM are expression of the same information it is simple to translate the information into the format that is most appropriate for a particular part of a heterogeneous environment.
Novell, Inc. is the world's leading provider of network software. The company offers a wide range of network solutions for distributed network, Internet/intranet and small-business markets. Novell's Z.E.N.works (Zero Effort Networks for users), the first directory services-based desktop management tool that reduces the cost of owning networked PCs and makes using networks easier. Z.E.N.works leverages Novell's industry-leading NDS (Novell Directory Services) functionality to make Windows-based desktops easier to use and manage.
Novell's Z.E.N.works provides policy-enabled software distribution, desktop management and workstation maintenance. This is facilitated by the use of Application Object stored within NDS. This information can be obtained via manual entry or through automated entry using Novell's snAppShot utility or by importing information provided by instrumented software components. The information provided in OSD files provides a standard way for software to describe themselves, their dependencies, and their deployment requirements. Z.E.N.works will support a number of formats to extract the information necessary to effectively manage software components and the applications they represent. OSD will be the format used for software that is deployed on the Internet as well as other media.
Novell will continue to enhance its support for OSD in future releases of their Z.E.N.works product. Additional information on Z.E.N.works can be found at
http://www.novell.com/products/nds/zenworks/
Here is an overview of the resources referenced in this paper, followed by contact information for each of the contributors.
Channel Definition Format (CDF) by Castedo Ellerman (Microsoft), March 1997.
http://www.w3.org/TR/NOTE-CDFsubmit.html
The Open Software Description Format (OSD) by Arthur van Hoff (Marimba), Hadi Partovi (Microsoft), Tom Thai (Microsoft). August 1997.
http://www.w3.org/TR/NOTE-OSD.html
The HTTP Distribution and Replication Protocol by Arthur van Hoff (Marimba), John Giannandrea (Netscape), Mark Hapner (Sun), Steve Carter (Novell), Milo Medin (@Home). August 1997.
http://www.w3.org/TR/NOTE-DRP.html
Resource Description Framework (RDF) by Eric Miller (Online Computer Libary Center), Bob Schloss (IBM), et al. October 1997.
http://www.w3.org/TR/WD-rdf-syntax/
Application Management Specification (AMS) by Tivoli Systems Inc., November 1997.
http://www.tivoli.com/o_partners/html/body_ams_spec.html
Extensible Markup Language (XML) by Tim Bray (Textuality and Netscape), Jean Paoli (Microsoft), C. M. Sperberg-McQueen (University of Illinois at Chicago), December 1997.
http://www.w3.org/TR/PR-xml/
The DMTF Common Information Model (CIM)
http://www.dmtf.org/work/cim.html
Marimba Inc., 440 Clyde Ave, Mountain View CA 94043
Arthur van Hoff, avh@marimba.com, (650) 9305282
Microsoft Inc., One Microsoft Way, Redmond, WA 98052-6399
Ray Sun, raysun@microsoft.com, (425) 882-8080
Tivoli Systems Inc., 442 Capital of Texas Highway North, Arboretum Plaza One, Suite 500, Austin, Texas 78759
John W. Sweitzer, john.sweitzer@tivoli.com, (512)-436-8918
Novell Inc., 122 East 1700 South, Provo, Utah 84606
Winston Bumpus, winston_bumpus@novell.com
Copyright © 1998 Marimba, Inc. All rights reserved. Marimba, Castanet, Bongo are trademarks of Marimba, Inc. All other trademarks or service marks mentioned herein are the property of their respective owners.