This RFP solicits proposals for the following:
Chapters 1 through 5 provide background information on OMG, the Object Management Architecture, the OMG technology adoption process, general instructions to submitters, and general requirements on proposals. Chapter 6 of this document provides specific information on the Rules Facility.
The Object Management Group (OMG) is the world's largest software consortium with a membership of over 600 vendors, developers, and end users. Established in 1989, its mission is to promote the theory and practice of Object Technology (OT) for the development of distributed computing systems.
A key goal of OMG is create a standardized object-oriented architectural framework for distributed applications based on specifications that enable and support distributed objects. Objectives include the reusability, portability, and interoperability of object-oriented software components in heterogeneous environments. To this end, the OMG adopts interface and protocol specifications, based on commercially available object technology, that together define an Object Management Architecture (OMA).
The remainder of this document is organized as follows:
The following documents are referenced in this document:
These documents can be obtained by contacting OMG at request@omg.org. Many OMG documents, including this document, are available electronically from OMG's document server. Send a message containing the single line "help" to server@omg.org for more information.
For more information about OMG visit OMG's Web page (URL http://www.omg.org/). If you have general questions about this RFP send email to rfp@omg.org.
The Object Management Architecture Guide (OMAG) describes OMG's technical objectives and terminology and provides the conceptual infrastructure upon which supporting specifications are based. The guide includes the OMG Object Model, which defines common semantics for specifying the externally visible characteristics of objects in a standard implementation-independent way, and the OMA Reference Model.
The Reference Model identifies and characterizes the components, interfaces, and protocols that compose the OMA. This includes the Object Request Broker (ORB) component that enables clients and objects to communicate in a distributed environment, and four categories of object interfaces:
A second part of the Reference Model introduces the notion of domain-specific Object Frameworks. An Object Framework component is a collection of cooperating objects that provide an integrated solution within an application or technology domain and which is intended for customization by the developer or user.
Through a series of RFPs, OMG is populating the OMA with detailed specifications for each component and interface category in the Reference Model. Adopted specifications include the Common Object Request Broker Architecture (CORBA), CORBAservices, and CORBAfacilities.
The wide-scale industry adoption of OMG's OMA provides application developers and users with the means to build interoperable software systems distributed across all major hardware, operating system, and programming language environments.
The Common Object Request Broker Architecture defines the programming interfaces to the OMA ORB component. An ORB is the basic mechanism by which objects transparently make requests to - and receive responses from - each other on the same machine or across a network. A client need not be aware of the mechanisms used to communicate with or activate an object, how the object is implemented, nor where the object is located. The ORB thus forms the foundation for building applications constructed from distributed objects and for interoperability between applications in both homogeneous and heterogeneous environments.
The OMG Interface Definition Language (IDL) provides a standardized
way to define the interfaces to CORBA objects. The IDL definition
is the contract between the implementor of an object and the client.
IDL is a strongly typed declarative language that is programming
language-independent. Language mappings enable objects to be implemented
and sent requests in the developer's programming language of choice
in a style that is natural to that language.
CORBA 2.0 is an extension and restructuring of the earlier CORBA 1.2 specification. CORBA 2.0 is a family of specifications consisting of the following components:
Each component is a separate compliance point. The minimum required for a CORBA-compliant implementation is adherence to the core and one language mapping.
Interoperability between CORBA-compliant ORBs is provided by OMG's Internet Inter-ORB Protocol (IIOP). Adopted in December 1994 as the mandatory CORBA 2.0 protocol for "out of the box" interoperability, IIOP is the TCP/IP transport mapping of a General Inter-ORB Protocol (GIOP). IIOP enables requests to be sent to networked objects managed by other ORBs in other domains.
The OMG interoperability architecture also accommodates communication using optional Environment-Specific IOPs (ESIOPs), the first of which is the DCE-CIOP.
Object Services are general purpose services that are either fundamental for developing useful CORBA-based applications composed of distributed objects, or that provide a universal - application domain-independent - basis for application interoperability.
Object Services are the basic building blocks for distributed object applications. Compliant objects can be combined in many different ways and put to many different uses in applications. They can be used to construct higher level facilities and object frameworks that can interoperate across multiple platform environments.
Adopted OMG Object Services are collectively called CORBAservices and include Naming, Events, LifeCycle, Persistent Object, Relationships, Externalization, Transactions, Concurrency Control, Licensing, Query, Properties, Security, Time, Collections, and Trading Services.
Common Facilities are interfaces for horizontal end-user-oriented facilities applicable to most domains. Adopted OMG Common Facilities are collectively called CORBAfacilities and include an OpenDoc-based Distributed Document Component Facility.
A specification of a Common Facility or Object Service typically includes the set of interface definitions - expressed in OMG IDL - that objects in various roles must support in order to provide, use, or participate in the facility or service. As with all specifications adopted by OMG, facilities and services are defined in terms of interfaces and their semantics, and not a particular implementation.
Unlike the interfaces to individual parts of the OMA "plumbing" infrastructure, Object Frameworks are complete higher level components that provide functionality of direct interest to end-users in particular application or technology domains. They are vertical slices down the OMG "interface stack".
Object Frameworks are collections of cooperating objects categorized into Application, Domain, Facility, and Service Objects. Each object in a framework supports (through interface inheritance) or makes use of (via client requests) some combination of Application, Domain, CORBAfacilities, and CORBAservices interfaces.
A specification of an Object Framework defines such things as the structure, interfaces, types, operation sequencing, and qualities of service of the objects that make up the framework. This includes requirements on implementations in order to guarantee application portability and interoperability across different platforms.
Domain Task Force RFPs are likely to focus on Object Framework specifications that include new Domain Interfaces for application domains such as Finance, Healthcare, Manufacturing, Telecom, Electronic Commerce, and Transportation.
OMG adopts specifications for interfaces and protocols 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 considerations. Once a specification is adopted by OMG, it is made available for use by both OMG members and non-members.
For more detailed information on the adoption process see the Policies and Procedures of the OMG Technical Process.
The OMG Board of Directors votes to formally adopt specifications on behalf of OMG. The OMG Technology Committees (Domain and Platform TCs) and Architecture Board (AB) provide technical guidance to the Board of Directors. In addition, the Business Committee of the Board provides guidance to ensure that implementations of adopted specifications are made commercially available.
Submissions to RFPs are evaluated by the TC Task Force (TF) that initiated the RFP. Selected specifications are recommended to the parent TC after being reviewed by the Architecture Board for consistency with the OMA. The full TC then votes to recommend adoption to the OMG Board.
The role of the initiating TF is to technically evaluate submissions and select one or more specifications that satisfy the requirements of the RFP. The process typically takes the following form:
Voter Registration
Interested TF members may register to participate in specification selection votes for an RFP. Registration ends on a specified date 6 or more weeks after the announcement of the registration period. The registration closure date is typically around the time of initial submissions. Companies who have submitted an LOI are automatically registered to vote.
Initial Submissions
Initial submissions are due by a specified deadline. Submitters normally present their proposals at the next following meeting of the TF. Initial submissions are expected to be full and complete proposals and working implementations of the proposed specifications are expected to exist at the time of submission.
Evaluation Phase
A period of approximately 120 days follows during which the TF evaluates the submissions. During this time submitting companies have the opportunity to revise and/or merge their initial submissions, if they so choose.
Revised Submissions
Final revised submissions are due by a specified deadline. Submitters again normally present their proposals at the next following meeting of the TF. Finalists may be requested to demonstrate implementations of their proposal.
Selection Vote
When the registered voters of the TF believe that they sufficiently understand the relative merits of the revised submissions, a specification selection vote is taken.
The primary goals of the TF evaluation process are to:
Submitters are expected to actively contribute to the evaluation process.
Unlike a submission to an OMG Request For Information (RFI), an RFP submission may require significant effort in terms of document preparation, presentations to the initiating TF, and participation in the TF evaluation process. Several staff months of effort might be necessary. OMG is unable to reimburse submitters for any costs in conjunction with their submissions to this RFP.
A Letter of Intent (LOI) must be submitted to the OMG Business Committee signed by an officer of your organization signifying your intent to respond to the RFP and confirming your organization's willingness to comply with OMG's terms and conditions, and commercial availability requirements. These terms, conditions, and requirements are defined in the Business Committee RFP Attachment and are reproduced verbatim in section 4.3 below.
The LOI should designate a single contact point within your organization for receipt of all subsequent information regarding this RFP and your submission. The name of this contact will be made available to all OMG members. The LOI is typically due 60 days before the deadline for initial submissions. LOIs should be sent to the attention of the "RFP Submissions Desk" at the main OMG address shown on the first page of this RFP.
The OMG Business Committee has produced a document entitled "OMG Policy on Adoption of Specifications". When reviewing submissions to each RFP, the specific items that the OMG Business Committee will be considering during the selection process are outlined below:
For technology to be accepted and adopted by the OMG Board Of Directors (reference OMG document tilted "OMG Policy on Adoption of Specifications - 2/12/90") it must be commercially available within twelve (12) months or less from when the OMG Task Force (prior to the Technical Committee and Board vote) adopted the specification(s). This is required for proof of concept and expedient implementation of actual product and licensing procedures. Commercial availability is delineated as:
A statement of commercial availability must be accompanied by a letter of authorization by an officer of the company proposing the technology.
Separate proposals
Unless otherwise indicated in Chapter 6, independent proposals are solicited for each separate item in the RFP. Each item is considered a separate architectural entity for which a proposal may be made. A submitter may respond to any or all items. Each item will be evaluated independently by the initiating TF. Submissions that do not present clearly separable proposals for multiple items may therefore be at a disadvantage.
It should be noted that a given technology (e.g. software product) may support two or more RFP items. So long as the interfaces for each item are separable, this is not precluded.
Complete proposals
Proposals for each separate RFP item must be complete. A submission must propose full specifications for each item and address all the relevant general and specific requirements detailed in this RFP.
Additional specifications
Submissions may include additional specifications for items not covered by the RFP which they believe to be necessary and integral to their proposal. Information on these additional items should be clearly distinguished.
Submitters must give a detailed rationale as to why these specifications should also be considered for adoption. However submitters should note that a TF is unlikely to consider additional items that are already on the roadmap of an OMG TF, since this would preempt the normal adoption process.
Alternative approaches
Submitters may provide alternative RFP item definitions, categorizations, and groupings so long as the rationale for doing so is clearly stated. Equally, submitters may provide alternative models for how items are provided within the OMA if there are compelling technological reasons for a different approach.
The OMG specification adoption process is an open process. Responses to this RFP become public documents of the OMG and are available to members and non-members alike for perusal. No confidentiality or proprietary information of any kind will be accepted in a submission to this RFP.
If a submitted document is copyrighted, a waiver of copyright for unlimited duplication by the OMG is required to be stated in the document. In addition, a limited waiver of copyright is required that allows OMG members to make up to fifty (50) copies of the document for review purposes only.
Submissions must include a "proof of concept" statement, explaining how the submitted specifications have been demonstrated to be technically viable. The technical viability has to do with the state of development and maturity of the technology on which a submission is based. This is not the same as commercial availability. Proof of concept statements can contain any information deemed relevant by the submitter, for example:
It is incumbent upon submitters to demonstrate to the satisfaction of the TF the technical viability of their proposal. OMG will favor proposals based on technology for which sufficient relevant experience has been gained in CORBA-based or comparable environments.
This section provides guidance on how to structure your RFP submission.
Submissions that are concise and easy to read will inevitably receive more consideration.
Submitted documentation should be confined to that directly relevant to the items requested in the RFP. If this is not practical, submitters must make clear what portion of the documentation pertains directly to the RFP and what portion does not.
The models and terminology in the Object Management Architecture Guide and CORBA should be used in your submission. Where you believe this is not appropriate, describe and provide a rationale for the models and terminology you believe OMG should use.
A three part structure for submissions is suggested:
Copyright Waiver (see 4.5)
Submission contact point (see 4.2)
Overview or guide to the material in the submission
Overall design rationale (if appropriate)
Statement of proof of concept (see 4.6)
Resolution of RFP mandatory and optional requirements
Explain how your proposal satisfies the mandatory and (if applicable) optional requirements stated in Chapter 6. References to supporting material in Part II should be given.
In addition, if your proposal does not satisfy any of the general requirements stated in Chapter 5, provide a detailed rationale.
Responses to RFP issues to be discussed
Discuss each of the "Issues To Be Discussed" identified in Chapter 6.
Proposed specification
Summary of optional versus mandatory interfaces
Submissions must clearly distinguish interfaces that all implementations must support from those that may be optionally supported.
Proposed compliance points
Submissions should propose appropriate compliance points for implementations.
Changes or extensions required to adopted OMG specifications
Submissions must include a full specification of any changes or extensions required to existing OMG specifications. This should be in a form that enables "mechanical" section-by-section revision of the existing specification.
Complete IDL definitions
For reference purposes and to facilitate electronic usage, submissions should reproduce in one place a complete listing in compilable form of the IDL definitions proposed for standardization.
Submitters should send an electronic version of their submission to the RFP Submissions Desk (rfp@omg.org) at OMG by 5:00 PM U.S. Eastern Standard Time (22:00 UTC) on the day of the submission deadline. Acceptable formats are Postscript, ASCII, FrameMaker, Word, and WordPerfect. Submitters should make sure they receive electronic or voice confirmation of the successful receipt of their submission.
Submitters should also send, within three (3) working days after the submission deadline, a single hardcopy version of their submission to the attention of the "RFP Submissions Desk" at the main OMG address shown on the first page of this RFP.
In addition, submitters are responsible for making available 100 paper copies to attendees of the TF meeting immediately following a submission deadline. There are normally two such presentation meetings, one for the initial and one for the revised submissions.
5.1.1 Proposals shall express interfaces in OMG IDL. Proposals should follow accepted OMG IDL and CORBA programming style.
5.1.2 Proposals shall specify operation behavior, sequencing, and side-effects (if any).
5.1.3 Proposals shall be precise and functionally complete. There should be no implied or hidden interfaces, operations, or functions required to enable an implementation of the proposed specification.
5.1.4 Proposals shall clearly distinguish mandatory interfaces and other specification elements that all implementations must support from those that may be optionally supported.
5.1.5 Proposals shall reuse existing OMG specifications including CORBA, CORBAservices, and CORBAfacilities in preference to defining new interfaces to perform similar functions.
5.1.6 Proposals shall justify and fully specify any changes or extensions required to existing OMG specifications. This includes changes and extensions to CORBA inter-ORB protocols necessary to support interoperability. In general, OMG favors upwards compatible proposals that minimize changes and extensions to existing OMG specifications.
5.1.7 Proposals shall factor out functions that could be used in different contexts and specify their interfaces separately. Such minimality fosters re-use and avoids functional duplication.
5.1.8 Proposals shall use or depend on other interface specifications only where it is actually necessary. While re-use of existing interfaces to avoid duplication will be encouraged, proposals should avoid gratuitous use.
5.1.9 Proposals shall specify interfaces that are compatible and can be used with existing OMG specifications. Separate functions doing separate jobs should be capable of being used together where it makes sense for them to do so.
5.1.10 Proposals shall preserve maximum implementation flexibility. Implementation descriptions should not be included, however proposals may specify constraints on object behavior that implementations need to take into account over and above those defined by the interface semantics.
5.1.11 Proposals shall allow independent implementations that are substitutable and interoperable. An implementation should be replaceable by an alternative implementation without requiring changes to any client.
Although the OMG adopts interface specifications, the technical viability of implementations will be taken into account during the evaluation process. The following criteria will be used:
5.2.1 Performance
Potential implementation trade-offs for performance will be considered.
5.2.2 Portability
The ease of implementation on a variety of ORB systems and software platforms will be considered.
5.2.3 Compliance: Inspectability and Testability
The adequacy of proposed specifications for the purposes of compliance inspection and testing will be considered. Specifications should provide sufficient constraints on interfaces and implementation characteristics to ensure that compliance can be unambiguously assessed through both manual inspection and automated testing.
Chapter 6 contains all information specific to this RFP.
OMG IDL provides a means for specifying interfaces to objects. The OMG Relationships Service adds a means of specifying relationships among objects. Many object modeling systems have been further augmented with rules systems to allow the specification of integrity constraints, triggers, demons, before-and-after methods, condition-action rules, and various control strategies like forward and backward chaining. Augmenting OMG IDL with a declarative rules management facility will increase its representational power and provide a general means of managing and enforcing rules. Others inside OMG should find a general rules management system useful (e.g., for modeling business rules, workflow, security and integrity constraints, constraints in product data, and rules for implementing active DBMS and KBMS).
The Rule Management Facility provides for declarative event-condition-action rule specification and processing within CORBA. Rule management involves the acquisition, management, and execution of rules.
The rules management facility depends on:
The rules management facility may depend on:
Mandatory (minimum) requirements are requirements that proposals must satisfy, i.e., for which proposals must specify an implementable solution and which do not unnecessarily constrain viable solutions or implementation approaches.
Proposals shall provide:
Optional requirements are requirements that proposals may satisfy. While the satisfaction of optional requirements is desirable (and will be taken into account in evaluating the submissions), proposals are not required to satisfy them, i.e., specify an implementable solution.
Proposals may provide:
Proposals should describe:
No additional criteria.
A mapping of rules management service's rules to one or more of the programming languages C, C++, Java, Smalltalk, or Ada should be provided if the mapping requires extensions of the existing IDL mappings.
The timetable for this RFP is given below. Note that the TF may, in certain circumstances, extend deadlines while the RFP is running, or may elect to have more than one revised submission step. The latest timetable can always be found in the Member Services section of OMG's Web page (URL http://www.omg.org/)
|
| |
| Preparation of RFP by TF | ||
| Approval of RFP by Architecture Board
Review by TC ("Three week rule") | ||
| 0 | TC votes to issue RFP | |
| 60 | LOI to submit to RFP due | |
| 120 | Initial submissions due | |
| 134 | Voter registration closes | |
| 141 | Initial submission presentations | |
| Preliminary evaluation by TF | ||
| 240 | Revised submissions due | |
| 261 | Revised submission presentations | |
| Final evaluation and selection by TF
Recommendation to AB and TC | ||
| Approval by Architecture Board
Review by TC ("Three week rule") | ||
| 330 | TC votes to recommend specifications | |
| 360 | BOD votes to adopt specifications |