_______________________

INTRODUCTION TO OPENDOC
_______________________


This file contains the following sections:

      - WHAT IS OPENDOC
      - PLANNING FOR COMPONENT SOFTWARE
      - NOTICES


WHAT IS OPENDOC
_______________

OpenDoc is an architecture that provides a means for applications to
support compound documents.  Compound documents are documents that are
created and edited by several cooperating applications working within
the context of a single document.  OpenDoc enables users to integrate
and edit any kind of content, in place, in any kind of document.  An
example of this type of integration would be a chart from a graphics
application being embedded into a word processing document while still
being editable, within the word processing document, by the graphics
application.  OpenDoc delivers component-based software in an
industry-standard manner.

Industry analysts speak of OpenDoc as a "relaunching of software,"
and they are not exaggerating.  Not since the wide acceptance of third
generation languages like C, COBOL, and Fortran has there been such a
far reaching paradigm shift.  Every part of the software industry will
be deeply affected by OpenDoc.

For a more complete description of OpenDoc, see the documentation
files in the DOCS subdirectory.

For information on running the demonstration Document Shell, see the
file DEMO.TXT in the BIN directory.

For information on building part handlers see the README.TXT file in
the OPENDOC directory.


PLANNING FOR COMPONENT SOFTWARE
_______________________________

It is vital that you engage with this technology now.  There are many
open questions about how components fit with your business and software
directions -- but only you can answer these questions.  A small but
thoughtful investigation now will pay off handsomely over the next year.
Here are the questions you should investigate:

1. What parts make sense for your business?

Some parts may be included by end-users in compound documents.  These
parts are manipulated or tweaked by users and are embedded within
word processor, spreadsheet, drawing, or other kinds of horizontal
application documents.

Other parts do not have a visual incarnation, but instead provide
access to server data, or facilitate sharing between related
activities or users.  Typically such parts will be used by setting
parameters in a dialog box and then displaying the resulting data
with a more conventional visual part.  For example, a database access
part that provides tabular data targeted at a spreadsheet.  These
"back-end" parts probably represent real business objects: a customer,
problem report, invoice, etc.

2. How will existing applications be divided into parts?

Where are the value fault-lines in your applications? What are the
facilities and features of your applications that others would
desperately want to use if they could only pull them out separately?
Consider your user interface components -- are there look and feel
features that can be reused in new kinds of reports and documents?

Consider also the internal calculations and manipulations performed
by your application.  Are these reusable in other places? Where are
the places you have added information specific to your business or
application?

Finally consider any connectivity between different machines or
modules in your application.  Should this connectivity be made
available in a general purpose way?

Remember, in most cases componentized applications are still delivered
as large complete applications -- people still want solutions, not
technology.  Nonetheless, these complete applications will increasingly
be made out of components.  This allows more flexible delivery, faster
response to changing needs, and solutions better tailored to end-users.

3. What is scriptable in my components?

The OSA architecture in OpenDoc allows one part to direct or request
information from another.  Parts publish "event suites" that define
the available interfaces for such interactions.  Event suites are
like an API, but intended for users of the part, not implementers.

Suites consist of verbs -- the actions that can be performed on the
parts, and nouns -- the kinds of data stored within a part.  For
example, a Person part might define Name, Phone, and Address nouns.
A typical action on Person might be "Tell me the home phone number."
There are core and standard suites that most parts should support.
There are OpenDoc standardized suites for parts that manipulate text,
tables, and etc.

What suites should your parts support? You answer this question by
considering the nouns and verbs that users of the part would need.
Your parts should support standard suites where possible.  Where your
parts provide more function than standard suites, are there new
special vertical suites you should be defining?


_____________________________________________________________________

_______

NOTICES
_______

References in this publication to IBM products, programs, or services
do not imply that IBM intends to make these available in all countries
in which IBM operates.  Any reference to an IBM product, program or
service is not intended to state or imply that only IBM's product,
program, or service may be used.  Any functionally equivalent product,
program, or service that does not infringe any of IBM's intellectual
property rights or other legally protectable rights may be used
instead of the IBM product, program, or service.  Evaluation and
verification of operation in conjunction with other products,
programs, or services, except those expressly designated by IBM, are
the user's responsibility.

IBM may have patents or pending patent applications covering subject
matter in this document.  The furnishing of this document does not
give you any license to these patents.  You can send license
inquiries, in writing, to the IBM Director of Licensing, IBM
Corporation, 208 Harbor Drive, Stamford, Connecticut 06904-2501, USA.


TRADEMARKS
__________

The following terms, denoted by a single asterisk (*) in this
publication, are trademarks or service marks of the IBM Corporation in
the United States or other countries:

    IBM
    OS/2
    Presentation Manager
    Workplace Shell


The following terms, denoted by a double asterisk (**) in this
publication, are trademarks of other companies as follows:

    Apple           Apple Computer, Inc.
    C++             AT&T, Inc.
    CompuServe      CompuServe Incorporated
    CORBA           Object  Management Group, Inc.
    OpenDoc         Apple Computer, Inc.
    Macintosh       Apple Computer, Inc.
    PostScript      Adobe Systems Incorporated


IBM DISCLAIMS ALL WARRANTIES, WHETHER EXPRESSED OR IMPLIED, INCLUDING
WITHOUT LIMITATION, WARRANTIES OF FITNESS AND MERCHANTABILITY WITH
RESPECT TO THE INFORMATION IN THIS DOCUMENT.  BY FURNISHING THIS
DOCUMENT, IBM GRANTS NO LICENSES TO ANY RELATED PATENTS OR COPYRIGHTS.

Copyright International Business Machines Corporation, 1994.
All Rights Reserved.

__________________________________________________________________________

END OF OPENDOC.TXT
__________________________________________________________________________
