URGENT- Response to RFI from OMG

Sankar <sankar@fcrao1.phast.umass.edu>
Date: Mon, 18 Jul 1994 22:54:47 -0400
From: Sankar <sankar@fcrao1.phast.umass.edu>
Message-id: <199407190254.WAA28333@fcrao1.phast.umass.edu>
To: kqml@cs.umbc.edu
Subject: URGENT- Response to RFI from OMG
Sender: owner-kqml@cs.umbc.edu
Precedence: bulk
Hear, Hear, everyone!

This note is being sent to recruit a working group of volunteers to
prepare a response to an RFI from OMG. The RFI is about "Common

The OMG's common facilities are supposed to be user level layer. One
of the sub-topics of interest in this RFI is agent facilities.

For your information, I have included the text of the RFI and a more
detailed response from the Chairman of the committe handling this RFI.

Those of you interested - would you please contact me through email
asap. We have gotten approval for a late submission, however, I would
like to turn in the response asap.



                     Object Management Group
                   Framingham Corporate Center
                    492 Old Connecticut Path
                   Framingham, MA  01701-4568

                   Telephone: +1-508-820 4300
                   Facsimile: +1-508-820 4303
                    Internet: request@omg.org

                        Common Facilities
                     Request for Information
                     OMG TC Document 94.2.11

1.0   Introduction

This OMG Request For Information (RFI) solicits documentation of
object-oriented technologies and guidance for the purpose of
surveying available products, projects, and requirements. This
input will be used to create the Common Facilities Architecture
and Road Map necessary to affect the technical direction of the
Object Management Group and to guide future Request for Proposal
(RFP) documents.

Common Facilities are defined by the OMG as those interfaces and
uniform sequencing semantics that are shared across applications,
making OMA-compliant applications easier to create.  This RFI
solicits those Common Facility categories which are most
fundamental to integrating these applications using the OMG
Object Request  Broker, Object Services and Object Model.  Common
Facilities will comprise both generic facilities and domain
specific specifications.  Example categories of Common Facilities
include inter-application services such as linking objects,
launch management, object rendering, cataloging and  browsing,
help facilities, printing and spooling, object query and agent

OMG intends to issue a series of RFPs for Common Facilities. In
addition, the OMG has recently adopted a fast track request for
comment (RFC) process, which accelerates the process for areas
where industry consensus already exists. The information provided
by your response will be used to produce an Architecture and Road
Map for Common Facilities which determine the order in which
these RFPs and RFCs will be issued.

As outlined in Section 4, your response to this RFI can describe
the requirements on and desirable characteristics of Common
Facilities, approaches, categorizations, priorities, and

                              - 1 -

architectures used to provide them. Examples of Common Facilities
are outlined in Section 5.

Your response may address as many categories as you wish.
Responses to this RFI should consist primarily of information and
documents that are readily available to you. We feel that
responses should be no longer than approximately 25 pages and
should not consume more than approximately 2-3 staff days of

This RFI provides the following information:
o Section 1 -- Introduction to the RFI.
o Section 2 -- The context of Common Facilities within the OMG
o Section 3 -- The OMG process for evaluating and selecting
o Section 4 -- The scope, objectives and requirements of this
o Section 5 -- An example categorization.
o Section 6 -- Instructions for responding to this RFI.
o Section 7 -- The review process and schedule for this RFI.

2.0  Context
OMG is dedicated to producing a framework and specifications for
commercially available object-oriented environments. The Object
Management Architecture (OMA) Guide, published in 1990 (revised
September, 1992), provides an architecture with terms and
definitions upon which all supporting interface specifications
are to be based. Part of this architecture is the Reference Model
which identifies and characterizes the components, interfaces,
and protocols that compose the OMA.

Figure 2.1 shows the four major parts of the OMA Reference Model.
The solid boxes represent software with application programming
interfaces. The dotted boxes represent groupings of objects that
can make and receive requests.

  The Object Request Broker (ORB) enables objects to make and
  receive requests and responses.
  Object Services is a collection of services with object
  interfaces that provide basic functions for realizing and
  maintaining objects.
  Common Facilities is a collection of interfaces and objects
  that provide general purpose capabilities useful in many
  Application Objects are specific to particular end-user

         [Figure omitted from ASCII version of document]

                Figure 2-1:  OMA Reference Model

Through a series of RFPs, OMG is populating the OMA Reference
Model with detailed specifications for each of its components and
interfaces. The OMA's Object Model describes what an object is
and what constructs are generally available for defining OMG
objects. The Common Object Request Broker Architecture (CORBA)
specification defines the OMG ORB - a mechanism which allows
clients to issue requests to, and receive responses from
conforming objects (Figure 2.2).

         [Figure omitted from ASCII version of document]

  Figure 2-2:  Common ORB Architecture (see pg. 28 of the CORBA

Using the ORB, requests for an object's services are made without
regard to the location or implementation of the object providing

                              - 3 -

the service, i.e., without regard for the mechanisms used to
represent, store, manage, invoke or communicate with the object.
Objects made available through the ORB publish their interfaces
using the Interface Definition Language (IDL) as defined in
Chapter 4 of the CORBA specification. The IDL provides a
language-independent way of specifying an object's operations and

 To construct inter-working, portable clients and object
   implementations, there must exist a set of basic Object
   Services which provide functions for realizing and
   maintaining objects. Object Services provide the basic
   operations for logical modeling, naming, lifecycle,
   managing and physically storing objects. For example,
   Object Services define the operations used to create, find,
   move and delete objects, as well as the operations used to
   define an object and its implementations.

 Object Management Architecture Guide, Revision 2.0,
   September 1, 1992. OMG TC Document 92.11.1.
 The Common Object Request Broker: Architecture and
   Specification, Revision 1.1, December 1, 1991. OMG TC
   Document 91.12.1.
 The Common Object Services Specification (COSS), Volume I,
   October 29, 1993.  OMG TC Document #'s 93.7.1, 93.5.2,
   93.7.3, 93.7.4
 The OMG Object Model.  Chapter 4 of the Object Management
   Architecture Guide.

3.0    Process
OMG adopts specifications for interfaces, based on existing
technology, by explicit vote on a technology-by-technology basis.
The specifications selected each fill in a portion of the OMA
Reference Model. OMG bases its decisions on both business and
technical merit. The OMG Technical Committee (TC) provides
technical guidance to the OMG in making decisions about
specifications. The TC is composed of representatives of all OMG
member companies. The TC is operated by a Vice President of
Technology, working full-time for the OMG itself (as opposed to
being an employee of a member company).

The TC operates in a Request for Proposal mode, requesting
technology to fill open portions of the Reference Model from
international industry. The responses to such a proposal, taken
within the specific RFP response period, are evaluated by a Task
Force of the TC with the full TC then voting on a recommendation
to the Board for approval of a specific addition to the set of

                              - 4 -

OMA specifications. Once a specification (a technology, not
source or product) has been adopted by the OMG Board, it is
promulgated to the industry through a variety of distribution

Responses to this RFI will be reviewed by the Common Facilities
Task Force (CFTF). Our intent is to survey the industry to obtain
information about object oriented technologies and guidance which
will be used in the preparation of Common Facilities Architecture
and Road Map documents to govern a forthcoming series of Common
Facilities RFPs.

The OMG's  fast track process allows for faster adoption of
technology in the case where an existing OMG compliant
specification exists and there is likely to be no competition.

4.0  RFI Scope, Objectives and Requirements
The goal of this RFI is to canvas the industry for technologies,
guidance, available products, projects, and requirements for
providing Common Facilities in the context of OMG's Object
Management Architecture (see Chapter 5, Reference Model Section

4.1  Mission of the Common Facilities Task Force
The mission of this  task force is to populate the OMA "Common
Facilities" components:
(1) To endorse ORB-conformant IDL code and definitions of
  semantics and sequencing to facilitate application
(2) To enable application interoperability in vertical market
  specialized areas: e.g., compound documents, electronic mail,
  database access.
(3) To layer above and conform with the CORBA specification as
  well as adopted Object Services.
(4) To maximize leverage of existing international and national
  standard as well as existing de facto interfaces in specific
  vertical market areas.

4.2  Scope of the RFI
This RFI focuses on Common Facilities that are useful in many
applications.  These may be specific to some particular
application domain, or generally useful for applications across
domains. Unlike Object Services which have universal
applicability, all Common Facilities are not present in every
computing environment, but it should be possible for developers
and ISV's to instantiate Common Facilities on any ORB platform
conformant with the specifications. Common Facilities reduces the

                              - 5 -

effort required to build OMA-compliant applications.  Application
developers may also define and supply subtypes to enrich or
customize the functionality of Common Facilities for specific

Note that while Common Facilities will need to provide and use
OMA-compliant interfaces (e.g., ORB-compliant interfaces) and
support the OMG Object Model, the facilities themselves need not
be constructed using the object-oriented paradigm. Furthermore,
responses to the RFI do not need to have completed compliance to
the OMG ORB and Object Model.

4.3    Objectives of the RFI
This RFI solicits responses to any or all of the following:

Requirements The requirements  on basic Common Facilities; the
          desirable characteristics of them.
          Your response to the RFI should supply the rationale
          as to why a specific set of Common Facilities is
          essential, and describe the required characteristics
          of these and the benefits which accrue from using
          To illustrate this point, you could reference the
          requirements of a set of particular application
          domains (e.g., hot-linked applications and CAD

Approach  The approach used to provide basic Common Facilities
          in the context of OMG's OMA; more specifically for
          systems based on the OMG ORB and Object Model, and
          Object Services.
          Your response should describe how the Common
          Facilities identified below are modeled and
          efficiently supported, the nature of their interfaces
          and how they relate to each other. The rationale
          behind specific approaches is of particular interest.
          In describing your approach to Common Facilities you
          could provide examples, comparisons and critiques of
          existing facilities.

CategoriesYour suggested groupings  and priorities of Common
          Facilities that are most likely to result in
          submissions of practical technology in response to
          future RFPs; the inter-relationships between Common
          Facilities and Object Services and the priorities you
          assign to each of them. For example, Object Services
          may provide transaction management that spans objects,

                              - 6 -

          implementations and machines.  Certain aspects of a
          function can more easily be provided by software that
          is intrinsically concerned with controlling an object
          while the more generalized, abstract, or multi-object
          implementation of a function can be better provided by
          Common Facilities.

Architecture     The architecture  used to provide Common
          Facilities. Your response should summarize which
          interfaces in your architecture provide or support the
          provision of Common Facilities. In order to support
          Common Facilities, additional interfaces (i.e., non-
          IDL interfaces) may need to be identified, defined and
          specified as part of the Object Management

Standards Existing standards as well as current or prospective
          standardization activities in closely related areas.
          Your input should rank the relevance and significance
          of each with respect to the proposed OMG work.

4.4  Dependencies and Relationships
Chapter 3 of OMG's OMA Guide lays out the general objectives of
the OMA. Responses to this RFI should be presented in this
context. Where appropriate, responses should include information

  Technology Dependencies - what software is presumed to exist
  to support a Common Facility for example, the provision of
  document interchange may presume the existence of a document
  interchange formatter.

  Extensions/Changes to OMG Specifications - what extensions or
  modifications to OMG specifications the service presumes or
  implies. For example, the provision of launch management may
  require extensions to IDL.

  Relationships with Object Services - how do your facilities
  overlap or relate to Object Services, as described in the
  adopted object service specifications and the Object Services
  Architecture and Road Map (OMG Documents 92.8.4 and 92.8.5).

  Utilization/Compliance with other standards - what standards
  are applicable to the provision of a service. For example,
  compliance with SGML may be appropriate for a compound
  document facility.

                              - 7 -

  Limitations - what limitations does the facility have or
  imply. For example, object rendering may not apply to objects
  maintained on floppy diskettes.
                           -- NOTE --
   Responses to this RFI are not required to include IDL
   interface definitions. A response may provide
   information on currently defined interfaces and
   available supporting technology. However a response must
   indicate the relevance to OMG's OMA and the feasibility
   of recasting the interfaces and technology for use in
   ORB-based systems. Approaches must also be able to
   conform to OMG's Object Model.

     Categories of Common  Facilities5.0
OMG is primarily soliciting information about the general
approach and architecture for Common Facilities. The information
you provide should primarily be a summary  of how the objectives
outlined in Section 4 are met.

The table below shows examples of categories of Common
Facilities.  You may provide alternative organizations of Common

 Service            Function

 Object linking     Provides for linkage of objects
                    together to form compound objects.

 Embedded objects   Allows embedded objects to be used.

 Object             Supports the negotiation of protocols
 Interchange        used for the interchange of data
                    between objects.

 Clipboard          Allows for the cutting, pasting,
                    copying of objects between objects.

 Cataloging and      A mechanism for browsing and
 browsing           discovering objects and interfaces for
                    application linking and integration.

 Object Rendering   Mechanism for scaling the dimensions of
                    objects to a specific display or

                              - 8 -

 Document           Supports standard formats for documents
 Interchange        (e.g. SGML, etc).

 Help Facilities    Mechanism for storing and presenting
                    application help information.

 Printing and       Support for hardcopy output.

 Agents             Support for user-delegated tasks
                    controlling applications.

           Table 5-1: Categories of Common Facilities

6.0    Instructions for Responding to this RFI

6.1    General

Companies responding to this RFI shall designate a single contact
within that company for receipt of all subsequent information
regarding this RFI, RFI responses and the forthcoming series of
RFPs. The name of this contact will be made available to all OMG

Responses to this RFI must be received at OMG no later than 5:00
PM EST (22:00 GMT) Friday, 3 June 1994.

Documentation submitted in response to this RFI will be
distributed to all of the members of the Common Facilities Task
Force (CFTF).

6.2   Format of RFI Responses

The following outline is offered to assist in the development of
your response. You should include:

1.A cover letter -- the cover letter must include a brief
  summary of your response and a check-list similar to Table 5-1
  that lists the Common Facilities for which you are providing

  Your response to any or all of the RFI objectives and2.
  requirements listed in Section 4.

3.If necessary, please include a glossary which maps your
  terminology to OMG standard terminology. (See the Appendices

                               - 9 -

  to the OMA Guide and the CORBA Specification for OMG's
  standard terminology.)

Although the OMG does not limit the size of responses, you are
asked to consider that the OMG will rely upon volunteer resources
with limited availability to review these responses. In order to
assure that your response receives the attention it deserves, you
are asked to consider limiting the size of your response (not
counting any supporting documentation) to approximately 25 pages.

If you consider supporting documentation to be necessary, please
provide one copy to the Common Facilities Technology Desk at OMG.
Please indicate which portions of this supporting documentation
are relevant to this RFI.
                             NOTE --
   According to the Policies and Procedures of the OMG Technical
   Committee, proprietary and confidential material may not be
   included in any response to the OMG. Responses become public
   documents of the OMG. If copyrighted, a statement waiving
   that copyright for use by the OMG is required and a limited
   waiver of copyright that allows OMG members to make up to at
   least twenty-five copies for review purposes is required.

6.3    How to Submit
OMG requests that 50 copies of the response plus a copy in IBM PC
machine readable format (typically ASCII, Word or WordPerfect
format) be sent to the Common Facilities Technology Desk at OMG.
If you are submitting supporting documentation, one copy of the
supporting documentation must be sent to the Technology Desk at

Responses to this RFI (and other communication regarding this
RFI) should be addressed to:

  Common Facilities Technology Desk
  Object Management Group Inc.
  Framingham Corporate Center
  492 Old Connecticut Path
  Framingham, MA 01701-4568

Responses to this RFI must be received at OMG no later than 5:00
PM EST (22:00 GMT) Friday, 3 June 1994.

The outside of packages/envelopes containing submissions or any
other communication regarding this RFI should be clearly marked

                           -- NOTE --
   Your organization should be prepared to handle requests
   for additional copies of your response and should be
   prepared to handle requests for additional copies of
   supporting documentation.

                             - 10 -

6.4    Reimbursements
The OMG will not reimburse submitters for any costs in
conjunction with their responses to this RFI.

7.0    Response Review Process and Schedule
As noted in Section 3, responses to this RFI are to be reviewed
by the Common Facilities Task Force (CFTF) for the express intent
of surveying the industry and providing OMG with technological
information and guidance in writing the forthcoming series of

7.1    Process
Copies of your response will be delivered to the CFTF membership
for review. Based on the responses to the RFI, the CFTF will
construct an Architecture and Road Map that outlines the model
which will be used in issuing RFPs for Common Facilities
technology. The Road Map will contain the list of Facilities for
which RFPs will be issued and the timetable for issuing this
series of RFPs. The Road Map will identify which RFP or RFPs will
be issued first, and which (if any) RFPs will be issued in

Upon completion of the Architecture, Road Map and drafts of the
initial RFP (or RFPs) by the CFTF, the Architecture, Road Map,
and the initial RFP(s) will be presented to the entire OMG TC for
vote on acceptance. The TC will evaluate these documents based
upon member input. Upon TC approval, the Architecture, Road Map,
and the initial RFP(s) will be issued to the public.

As a forewarning to organizations who intend to respond the
initial Common Facilities RFP(s) when they are issued, please
note that responding to an RFP requires:

o A Letter of Intent signed by an officer of your organization
  signifying your intent to respond to the RFP and a statement
  of your organization's willingness to comply with the OMG's
  requirements (e.g., your willingness to license the proposed
  technology openly).

                             - 11 -

o The technology submission described in accordance to the RFP.
  Any technology adopted by the OMG must be commercially
  available from a Corporate Member. A statement describing how
  the submission meets this commercial availability requirement
  is required with the submission.

Section 7.3 provides a timetable listing the tentative dates when
these documents will be due for the first RFP(s). Please consult
the OMA Guide for a complete description of the OMG's
requirements, policies and procedures for technology submissions.

7.2    Clarification of Responses
To fully comprehend the information contained within a response
to this RFI, the CFTF may seek further clarification on that
response. This clarification may come in the form of verbal
communication over the telephone; written communication;
electronic; or a request to make a presentation of the response
to the Common Facilities Task Force.

7.3    Schedule
The schedule for responding to this RFI is as follows. Please
note that early responses are encouraged.

  TF recommends issuing the RFI         2 Feb. 94
  RFI issued                            6 Apr. 94
  RFI responses due                     3 Jun. 94

The tentative schedule for the RFI evaluation process and
subsequent RFPs is:

  Review of RFI responses meeting       28 Jun. 94
  Common Facilities Architecture and Road Map issued   19 Oct. 94
  First RFP issued                      6 Dec. 94
  Letters of Intent to Respond to first RFP due   6 Feb. 95
  First RFP submissions due             6 Apr. 95
  Revised submissions due               6 Jul. 95
  TF Recommendation of adoption for first RFP     6 Oct. 95
  TC Recommendation of adoption for first RFP     8 Nov. 95

Note that this schedule is subject to change based on the number
of RFI responses received.

7.4    Questions and Further Information

                             - 12 -

Questions concerning the Common Facilities RFI should be directed

  Common Facilities Technology Desk
  Object Management Group Inc.
  Telephone: +1-508-820 4300
  Facsimile: +1-508-820 4303
  Internet: request@omg.org

                 [End of Common Facilities RFI]

Thanks for your interest, and yes, I'd really like you to submit input to
the OMG Commmon Facilities Task Force.

Please use the attached template.  I'd like you to try to observe a page
limit of about 6 pages... Submission via ASCII email would be most
convenient (or RTF as a 2nd choice).  If you have any other materials to
submit, I'll have to work with your to arrange to have them posted on the
OMG server.


(Adapted from the OS Arch 92.8.4)

As for Object Services, Common Facilities descriptions are typically 2 to 4
pages each, divided into four sections.

1. Service Description and Requirements

Prescriptively describes a common facility; delimits the scope of the
facility. The description is written in the form of a collection of
requirements and goals.

2. Related Standards and References

References that should be useful to submitters in understanding the problem
space.  Submitters should describe whether and how their proposals relate
to existing, relevant standards.

This section typically contains a bulletized list.

3. Relationship to other Object Services, CORBA, and the OMG Object Model

Possible interactions with (or relationship to) other Common Facilities,
Object Services, CORBA, and the OMG Object Model.  In particular:
* Other Common Facilities: How the facility depends on the existence of
other facilities,
* Object Services: How the service may use and/or specialize the Common
Object Service Specifications and other services identified in the Object
Services Architecture and Roadmap,
* CORBA: How the service may use CORBA features,
* OMG Object Model - How the service may conform to the OMG Object Model
and/or what new components or profiles may be needed.

4. Technical Issues
A log of additional technical issues for this facilities area that the
OMG's architectures do not address.

Send mail to majordomo@cs.umbc.edu to subscribe/unsubscribe to the kqml
mailing list.  Send a message with the body "help" for more information.
Archives are at http://www.cs.umbc.edu/kqml/mail/