Interoperability and Business Objects Request for Technology Evaluation Report September 1998

1. Introduction

The focus of the POSC Interoperability and Business Object work effort is to develop specifications that facilitate and encourage software components to exhibit consistent operational characteristics, i.e., interoperability, to E&P professionals (the users of E&P software systems), even when software components are obtained from different suppliers. Achieving interoperability for end-users requires the development and use of an agreed upon architecture or description of how software components should be developed and how they are expected to inter-relate.

This objective complements the work that POSC has been doing over the last seven years. E&P data stores will continue to migrate toward the consistency, completeness, and integration supported by POSC's specifications for the Epicentre logical data model, DAE access API, and Epigramme/PEF exchange format. With the successful completion of the current work effort, application developers will have:

• A shared, industry-developed architecture to use
• Shared data definitions suitable for specific use by end-users and supporting applications
• Guidelines and techniques for integrating legacy applications and data sources into POSC-based computing environments.

1.1 Evaluation Team

The evaluation of the responses to the RFT was carried out by a joint team made up of representatives from the POSC member organizations and the POSC staff. The POSC Open Process depends on the active involvement of POSC member organizations not only to represent the best interests of the membership but also to reflect the requirements of the E&P industry. The valuable contribution of the members of the evaluation team is greatly appreciated.

The evaluation team members are:

The evaluation process began on May 26, 1998 and concluded on July 10, 1998. The team met for four week-long sessions supplemented by individual efforts in between. The members of the team have been invited to remain in place as a first-level review team to ensure the quality of the work that will be done between now and the publication of the POSC interoperability specifications.

1.2 Submissions Received

The RFT generated a lot of activity from many organizations. Fortunately, some of these organizations worked together to develop responses. This resulted in the integration and validation of their ideas and in higher quality submissions. In total, eight organizations participated in the four formal submissions.

The following list of submissions identifies the title of the submission, the area of coverage (Interpretation Domain or Architecture), and the names of the submitter organizations. For convenience, references to specific submissions will be made using the letter designations: A through D.

• Submission "A": Interpretation Object Representations
Submitters: CGG-Petrosystems, Chevron, PrismTech, Shell, Statoil
Type of submission: Domain
• Submission "B": OMEGA Business Objects Definitions
Submitter: Netherlands Institute of Applied Geoscience TNO - National Geological Survey
Type of submission: Architecture and Domain
• Submission "C": Interoperability and Business Objects Architecture Design
Submitters: CGG Petrosystems, Chevron, PrismTech, Schlumberger, Shell, Statoil
Type of submission: Architecture
• Submission "D": Subsurface Interpretation Business Objects
Submitters: CGG Petrosystems, Chevron, PrismTech, Shell, Statoil
Type of submission: Domain

This is the first time that POSC has issued an RFT that asked for draft specifications to be submitted. All earlier RFT's asked for relevant technology to be submitted; then POSC developed specifications based on the submitted technology through either staff work, e.g. Epicentre and DAE, or joint member-staff workgroup efforts, e.g. IAC. The intention of requesting draft specifications this time was that a total process of developing specifications would take less time and, more importantly, would produce specifications of high quality, i.e., ready to be used in commercial-grade products.

Reflecting on the manner in which the submissions were prepared and the results of the evaluation reported in this document, it appears that these intentions are being realized. The submissions are closely associated with the development of actual commercial products. Some of the submitting organizations are on record with commitments to align their commercial products with the POSC specifications as published. The results of the evaluation of the submissions have found limitations in the submissions that will require additional work before the POSC specifications are ready for use. In general, these limitations are believed to be the consequence of the evolving maturity of distributed object technology and the breadth of our requirements, which exceed what has been previously done in other industries.

POSC expresses its appreciation to all of the submitting organizations for their efforts. Other POSC member organizations are encouraged to support this project actively through the upcoming period of technical refinement, through the period of review of the specifications themselves, and through commercial acquisition and deployment of products based on these specifications.

1.3 Evaluation Objectives

The formation of a joint membership-staff evaluation team is also an innovation in POSC's Open Process. Previously, RFT submissions were evaluated by staff only. The broader evaluation process was enabled by requiring all submissions to be made openly and for the submitted materials to be licensed to POSC.

The principal objectives of the evaluation, as part of an overall fair and open specification development process, were:

• To examine each submission in the context of the RFT requirements
• To determine the optimal combination of ideas and technical material from the submissions

(The evaluation process could have resulted in two or more alternative combinations from the submissions, i.e. if there were any difficult technical or commercial issues that could not be resolved. In fact, the evaluation process defined one solution.)
• To define the remaining technical work items necessary to transform the submitted materials into a workable specification

The evaluation team members acted as neutral experts. They interacted with technical experts from the submission teams to ensure that their understanding of the submissions was accurate and complete. This report represents the analysis of what was found in the submissions and the team's recommendations. This report has been reviewed widely within the POSC organization as well as with the submitters.

1.4 Approach to Reaching Application Interoperability

The RFT expressed the belief that widespread application interoperability in the E&P industry will take a number of years to achieve. The RFT recognized that while considerable effort has already been expended towards reaching this goal, there is still much work to be completed. This work can be iterative, with useful results beginning early in the process. The current project is a first step along this path.

Prior to issuance of the RFT, the project produced a Request for Comments (RFC) document that proposed a baseline definition for application interoperability in the E&P industry and an evolutionary process to achieve its benefits. Six broadly defined levels of sophistication of application interoperability were introduced in the RFC (See table below.) as a guide for aligning this work. The more sophisticated interoperability capabilities will take longer to achieve. This approach allowed requirements to be prioritized by capability. The consensus of RFC responses from the membership indicated the target of achieving the capabilities of Level 3 within the next two to three years. Therefore, the RFT required submissions to define specifications sufficient to meet Level 3.

1.5 RFT Requirements Summary

The RFT requested that submissions address either or both architecture and domain requirements. The RFT used the terms as follows:

• Architecture refers to the definition of shared services and the structural basis for defining and using business objects.
• Domain refers to the definition of business objects (data, process, and/or presentation) in the E&P Domain called Subsurface Interpretation (or Interpretation, for short)

The RFT presents requirements in three sections:

• General Requirements ( RFT Section 5),
• Architecture Requirements ( RFT Section 6), and
• Subsurface Interpretation Domain Requirements ( RFT Section 7).

The General Requirements apply to all submissions and cover these topics:

The Architecture Requirements cover these topics:

The Domain Requirements cover these topics:

1.6 Evaluation Highlights

The evaluation focused on the following topics, discussed below:

Completeness

It was anticipated that although the initial interoperability specification would not be complete both in terms of the architecture and the Interpretation domain coverage, it would be sufficient to be used in commercial software development. The evaluation confirmed this expectation. The limitations on the completeness of the initial specifications result from several factors, including:

• Items required by the RFT but not included in any submissions, e.g. interpretation object definitions
• Items required by the RFT and provided in the submissions, but not in a usable form, e.g. the viewer server in Submission "D"
• Items not explicitly required by the RFT and not deemed necessary until a later revision of the specifications, e.g. a session object definition

Consistency and Workability

The evaluation process placed emphasis on these two important characteristics:

1. The specifications must be consistent with existing POSC specifications, e.g. Epicentre.

RFT Section 5, Requirement 5-1 states: "Proposals shall make use of existing POSC specifications and indicate the nature of the relationship between the existing specifications and the proposed specifications. Direct use of the material from existing POSC specifications may be appropriate in defining business object/Epicentre mappings and in implementations."

2. The specifications must be workable.

RFT Abstract states: "This Request for Technology (RFT) document states the goals and direction of this initiative and invites proposals of workable architecture and Subsurface Interpretation business object specifications suitable to become POSC SIP specifications."

The evaluation results included an elaboration on the definition of workability with the following points:

• The specifications must allow software developers (commercial or in-house) to implement services that will interoperate.
• The specifications must allow software developers (commercial or in-house) to design and implement (client) applications.
• The specifications must allow collections of object implementations to exhibit uniform behavior and cohesiveness (as described in the Levels of Interoperability).
• The specifications must be designed to facilitate the kinds of changes that can be anticipated to occur in the future.
• The specifications must be fit for their intended purpose.

The last two items are described in the following subsections.

Designed for change

Object technology offers a great deal of structural flexibility, even as compared with the best non-object-oriented software design techniques. Like earlier techniques, however, the benefits of flexibility can be realized only if there is an overall plan for the manner in which functionality is distributed among components. The definition of such design guidelines is an essential part of this project and, as such, is reflected in the RFT through the architecture portion as a whole and explicitly in domain Requirement 7-6, which asks for design guidelines to be proposed in the submissions.

The evaluation identified a number of useful design guidelines that can contribute to achieving a flexible environment in which changes can be introduced with minimal impact to previously definitions and implementations. This is a useful addition to the qualitative criteria defined in RFT Requirement 5-5. Some of these were derived from submissions, while others were recognized as by-products to the evaluation process itself. Most of the guidelines are analogous to well-known pre-object technology guidelines. Even for these, there are some unique aspects of object technology to consider.

Each guideline will now be explained briefly:

• Externalization of Object Relationships. There is a stated intention to develop E&P business object definitions incrementally. Therefore, it is important to be able to represent relationships between objects (classes) external to the definitions of the objects involved. Whether a relationship is represented internally or externally is a decision that should be made after considering the advantages and disadvantages of each alternative. The overall architecture should provide facilities for an object to use to determine and populate its external relationships. This will involve the definition and management of relationship definition meta-data, the definition of relationship-defining attributes in the Base Object, and the use of a generic Relationship Service. Internally defined relationships, even if mirrored through an external Relationship Service, can limit the flexibility of object implementations. This guideline is implicitly recommended in Submission "C" by a reference to the use of the CORBA Relationship Service at the end of Part 2, but the submission suggests not addressing this issue in the first version of the POSC interoperability specifications.
• Encapsulation of Data Representations. The POSC work to define Epicentre and the Data Access and Exchange (DAE) specifications set out the principal that the format and structure of data values, even very complex data values, should be encapsulated out of the logical data model. This allowed data store implementations to vary data value format and structure without making changes either to the data model or to any application program. This approach to adding flexibility and longevity to specifications should be applied to the definition of objects. Not only should the currently defined Epicentre/DAE data types be adapted for use with / in objects, but also additional complex E&P data values should be considered for similar treatment. This guideline is illustrated and recommended strongly in Submission "A".
• Factoring Out Common Methods. Flexibility can be enhanced by isolating common methods in a Service object rather than defining similar methods in multiple objects. This guideline (and the following two guidelines which are special cases of this one) is consistent with one of the specific points in RFT Requirement 5-4, which calls for the factoring out of common functions.
• Use of Object Instantiation Factories. Flexibility can be enhanced by defining factory objects exclusively for use to create object instances rather than including instance-creating methods in other objects.
• Parameterizing Computational Methods. Flexibility can be enhanced by generalizing computational methods, e.g. through parameterization rather than defining methods that handle very explicit formulas.

Fit for purpose

Early in the life of this project, it was realized that it is imperative that business objects be carefully defined in terms of a definitive purpose. The five-step process for defining a business object, first presented in the Request for Comments document, requires a Usage Scenario (also known as Use Case) as part of Step 1. This is reflected in RFT Requirement 7-3. Service definitions are also required to contain Usage Scenarios as stated in RFT Requirement 6-4.

In contrast to an integrated, enterprise-wide data model, like Epicentre, each business object is focused on a specific and limited purpose. Therefore, individual usage scenarios that clarify the purpose and intended scope of an object definition or service definition are appropriate.

The evaluation process also recognized the usefulness of defining Usage Scenarios at the level of each E&P Domain to be used as test cases to confirm the fitness for purpose of the entire set of service and object definitions. These usage scenarios should cover several levels if granularity, from E&-P oriented activity descriptions to explicit sequences of object and service method calls.

2. Overview of POSC Interoperability Specifications

This section describes the structure and content of the initial set of POSC interoperability specifications with reference to the RFT submissions and how each contributes to these specifications. This section covers both architecture and domain aspects of the RFT. A discussion of work items that should be addressed to complete the preparation of these specifications is in Section 4. Work Plan.

2.1 Overall Structure Within POSC SIP

The specifications that will result from this project have been described in a number of ways over the life of the project. With the completion of the RFT process, the following structure for the specifications has been determined:

• Define a new major category of POSC specification called Interoperability Specifications, joining Epicentre, Data Access and Exchange, Exchange Format, and CGM*PIP.
• Place the following existing POSC specifications in the Interoperability Specification category: Base Computer Services (renamed from Base Computer Standards), E&P User Interface Style Guide, and Interapplication Communication.
• Define the results of this project in these new and revised POSC specifications in the Interoperability Specification category:
• Base Computer Services (updated and enhanced to add Distributed Object Technology services)
• Distributed Object Services (new)
• E&P Object Model (new)
• Interpretation Object Model (new)

(This paves the way for additional E&P Domain Object Model specifications in the future, e.g. Acquisition & Processing Object Model, Drilling Object Model, etc.)

It is often helpful to relate the name of a specification to the name of the class of products that implement the specification, e.g. the UNIX specification is implemented by UNIX operating system products, the DAE specification is implemented by DAEF products, etc. In this case, we have:

• The Distributed Object Services specification is implemented by specific CORBAservice or equivalent Microsoft distributed object service implementation products.
• The E&P Object Model specification is implemented by a new class of E&P <name> Object or Service products (e.g. an E&P Collection Service product).
• The Interpretation Object Model specification is implemented by a new class of E&P Interpretation <name> Object products (e.g. an Interpretation Well Object product).

The full set of Interoperability Specifications can be represented in terms of architectural layers, as follows:

USER INTERFACE STYLE GUIDE
<application components>
INTERPRETATION OBJECT MODEL SPECIFICATION	INTERAPPLICATION COMMUNICATION SPECIFICATION
E&P OBJECT MODEL SPECIFICATION
DISTRIBUTED OBJECT SERVICES SPECIFCATION
BASE COMPUTER SERVICES SPECIFICATION (includes references to other layers)

Another representation of the structure of the POSC specifications with the addition of the new interoperability specifications is the following enhanced version of the POSC Software Integration Platform diagram. Note that the new specifications address functionality previously resident in a portion of the Technical Applications box. (Note that Domain Object Model is a generic reference to the set of E&P Domain Object Models of which Interpretation Object Model is the first to be defined.)

2.2 Summary of Contents of the Specification

The recommended contents for the initial POSC interoperability specification are presented according to the architectural layers introduced above and illustrated in the following figure.

2.2.1 General Recommendations

The evaluation resulted in a number of recommendations for elements that should be included in the specifications and for items to be worked in conjunction with the specification development (Base Computer Services). These recommendations are discussed below.

General Discussion

The specifications should include a general discussion of interoperability and business, including specifically:

• Architectural layering diagram, as shown above.
• Identification of stakeholders that make use of each of the categories of services. Types of stakeholders include: business object implementation developers, virtual application developers/integrators, distributed object service capabilities extenders, system administrators, etc.
• Pertinent information from the RFT, e.g. the description of the levels of interoperability.

Representation

The concepts illustrated in Submission "A" should be adopted, refined, and applied to the material taken from other submissions. This is important because Representation objects are basic building blocks for most of the other object definitions being defined now as well as most E&P Business Objects to be specified in the future.

Design Patterns

The following design patterns, implicitly described in the various submissions, should be explicitly described in the specifications:

Draft descriptions of those four design patterns, as developed during the evaluation process, are presented in Appendix A.

Additional design patterns may be included in the specifications, such as: (1) a History/Versioning Pattern that creates an audit trail for objects derived from existing objects; (2) a Life Cycle Pattern that manages the creation, saving, restoring, and deletion of objects; and (3) a Data Type Conversion Pattern that addresses problems related to data formats.

Criteria for Inclusion

The following are criteria used during the evaluation to help support the decision to recommend that specific objects and services be included in the initial release of the POSC interoperability specifications for the E&P Object Model (summarized in Section 2.2.3) and Interpretation (Domain) Object Model (summarized in Section 2.2.4):

• necessary, if not sufficient, to perform subsurface interpretation
• most completely defined in the submissions
• known to be in the process of implementation

Object Roles

The objects to be defined in the interoperability specifications generally play one of several roles as defined in the RFT Section C.3.2, i.e. entity (or data) objects, process objects, presentation objects. For clarity, the specifications should employ commonly used descriptors of these roles as the final word in the names of the objects. Specifically, object for entity objects, service for process objects, and viewer for presentation object. Common usage suggests using a small number of specialized descriptors, e.g. factory as a special kind of service.

Templates

Templates, as illustrated in Appendix B, should be used in the specification to define objects, services, and design patterns.

• Object Interface definitions should include a complete description of the public interface, the mappings with Epicentre, references to usage scenarios, identified dependencies, etc.
• Object families should be defined to describe the usage and behavior associated with related objects/interfaces, inter-object relationships, life cycle patterns and policies.
• Design pattern descriptions, i.e. common patterns of usage that are expected to be repeated over many different types of business objects, should be explicitly defined for inclusion in the specifications.

Capabilities Description

There are basic capabilities of objects that need to be defined in the specification. The capabilities described here are based on several sources: the submissions, supplemented by material in the RFT; related work on interoperability; and concepts discussed during the evaluation. Each object is described by the following items of information:

Object Design Guidelines

Determine how to define and manage business object subtypes, e.g. subtypes of the EPIO Horizon Object. Consider the OMG BOCA submission concept of a BOF Type manager. Consider simply providing enumerated lists within an EPIO Horizon Factory.

Microsoft Distributed Object Technology

Document the equivalent Microsoft Services, e.g. from COM+, along with the references to CORBA services where possible. Provide links to MIDL descriptions that are equivalent to the CORBA IDL descriptions, preferably generated with the same CASE tool. See the OMG / Microsoft correlations documented in RFT Section C.2.5.

OpenGIS Consortium

Coordinate relevant specifications, e.g. Units and Coordinates, with the OpenGIS Consortium and the OMG CORBA GIS Special Interest Group.

Base Computer Services

Work on the Base Computer Services component of the Interoperability Specifications should include the following:

• Consider endorsing the Enterprise JavaBeans (EJB) specifications (at least for preliminary use). This recommendation would be strengthened if EJB is adopted as an open specification.
• Consider endorsing the OMG UML
• In spite of the recent withdrawal of the OMG RFP on Business Object Facility, consider adapting some of the work submitted, e.g. the Business Object Component Architecture and Interoperability Specification submissions, for use pending future OMG work in this area. POSC should continue to participate in relevant OMG work.
• The current OMG Workflow submission supports a workflow object that will interoperate with existing (non-OMG) work flows. Consider endorsing this OMG work, which also represents the work of the Workflow Management Coalition (WfMC). This capability may address some level 4 and level 5 interoperability requirements.
• The OMG Composition interface submissions seem to be going towards extending IDL to allow one interface being dependent on multiple interfaces. Consider endorsing this OMG work when ORB vendors begin adopting these extensions. This may address some level 4 and level 5 requirements.
• Consider tracking OMG's work with XML (Extended Markup Language). A proposal has been submitted recently for an interchange service based on XML.

2.2.2 Distributed Object Services

The Distributed Object Services specification will define services which provide capabilities that are: (1) described in the submissions in response to the requirements of the RFT, and (2) supplemented as proposed in the recommendations resulting from the evaluation.

The RFT asked for submissions to recommend how Microsoft distributed object technology can be used with the POSC specifications. This information was not received in the submissions, but it should be included in the POSC specifications. Reflecting the current status, the following services are described only in terms of the OMG CORBA Object Services, prefixed by COS.

The Distributed Object Services specification will define the following object services:

These services are summarized below.

2.2.3 EPO Objects and Services

Object Families

The E&P Object Model specification will define the following object families:

These objects are summarized below.

EPO Services

The E&P Object Model specification will define the following services. They are presented in three groups:

• EPO Services that will be in the POSC specifications and are refinements (constraints and/or extensions) to CORBA Services

Concurrency	Notification	Relationship
Identity	Property
Life Cycle	Query

• Other EPO Services that are to be included in the specification:

Authorization	POSC Data Type
Base Factory	Reference Value
Coordinate	Units

• Future EPO Services: EPO Services discussed in the RFT and/or submissions that may be included in future versions of the specification

Collection	Scripting	Versioning
History	Session	Workflow
Meta-data Management	Transaction

These services are summarized in the following subsections.

2.2.4 EPIO Objects and Services

The (E&P) Interpretation (Domain) Object Model will define the following object families:

During the preparation of the specifications, any object that is applicable to multiple E&P domains should be defined in the E&P Object Model specification.

There are some issues that apply generally to all of the EPIO Objects and Services summarized in this section:

• Although these objects are now being defined to satisfy usage scenarios in the Interpretation Domain, there may be opportunities in the future to consider adapting some of these object definitions to apply to multiple E&P Domains.
• Submissions did not satisfy the requirement to ensure consistency and mapability with Epicentre.
• The recommended policy regarding relationships must be applied.
• The representation encapsulation policy must be applied.

The following object families will be defined:

EPIO Well Objects with interfaces for:

EPIO Well Object

• Purpose: Serves as the organizational tool for gathering and storing well information; provides descriptive information about a well.
• RFT Reference: 7.2
• Level of Interoperability: 1
• Submission: "D"
• Satisfaction: 1.5
• Issues:
• The life cycle and usage material (Well Query Manager, et. al.) used in the presentation of Submission "D" should be considered.

EPIO Wellbore Object

• Purpose: Provides well bore header information and the geometry information of the well path.
• RFT Reference: 7.2
• Level of Interoperability: 1
• Submission: D, but factored as specified in Submission A
• Satisfaction: 1.5

EPIO LogTrace Object

• Purpose: Provides log trace data values and one or more indexes for a digital well log trace.
• RFT Reference: 7.2
• Level of Interoperability: 1
• Submission: D, but modified to include Submission A.
• Satisfaction: 1.5
• Issues:
• The effect of representation encapsulation on conversions associated with indices must be considered.

EPIO Wellpick Object

• Purpose: Provides data about identified features (dipmeter picks, well markers, etc.) found in a well bore along with the feature's location in a specified coordinate system. The well picks are associated with geologic features.
• RFT Reference: 7.2
• Level of Interoperability: 1
• Submission: D
• Satisfaction: 1.5
• Issues:
• The relationship of picks to geologic features, as described in the submission, should be reviewed.

EPIO Velocity Function Object

• Purpose: Provides parametric descriptions of velocity functions, e.g. as sets of time/depth pairs; used to convert time to depth or depth to time.
• RFT Reference: 7.2
• Level of Interoperability: 1
• Submission: D, but factored to reflect Submission A.
• Satisfaction: 1.5
• Issues:
• Processing interfaces for time-depth conversions should be included.
• The methods for time-depth conversion may be significantly altered by the representation encapsulation.

EPIO Seismic Objects, including interface definitions for:

EPIO Seismic Volume Object

• Purpose: Provides post-stack seismic 3D Volume: 3D traceset, 3D header
• RFT Reference: 7.2
• Level of Interoperability: 1
• Submission: Partially addressed by submission D
• Satisfaction: 1.5

EPIO Seismic Panel Object

• Purpose: Provide post-stack seismic 2D Line: 2D traceset, 2D header
• RFT Reference: 7.2
• Level of Interoperability: 1
• Submission: Partially addressed by submission D
• Satisfaction: 1.5

EPIO Seismic Trace Object

• Purpose: Provides post-stack seismic trace data and header.
• RFT Reference: 7.2
• Level of Interoperability: 1
• Submission: Partially addressed by submission D
• Satisfaction: 1.5

EPIO Interpretation Objects, including Interface definitions for:

EPIO Geologic Feature Object

• Purpose: This object includes Horizons, Faults, Surfaces, etc.. These are the features to which geometries will be assigned and the features to which well picks and seismic picks will be associated. Life cycle models are critical since these objects are the end product of interpretation and need to be saved.
• RFT Reference: 7.2
• Level of Interoperability: 1
• Submission: "D"
• Satisfaction: 1.5

EPIO Seismic Pick Object

• Purpose: Similar to Well Pick, this object provides the seismic features that are related to the geologic features.
• RFT Reference: 7.2
• Level of Interoperability: 1
• Submission: "D"
• Satisfaction: 1.5

3. RFT Requirements Satisfaction

The RFT stated what was required in submissions for both architectural components (services) and domain components (business objects). These were stringent expectations if strictly interpreted and none of the submissions met them entirely. The evaluation team took these submissions, identified those parts which addressed RFT requirements, and identified additional work that must be done to fulfill the RFT requirements. Nevertheless, as stated in Section 1.6, the initial specification will not cover all of the RFT requirements.

The following is a summary of the level of satisfaction of the RFT mandatory requirements from the selected portions of the submissions. The requirements are grouped and identified as listed in Section 1.5. The quantitative scores range from 0 (means not addressed) to 3 (means fully satisfied).

Satisfaction of RFT Mandatory Requirements

Requirement Group		Score	Comments
GENERAL
5-1	POSC Specifications: use and proposed refinements	1.5	References to existing specifications not complete Some additions to BCS proposed
5-2	OMG Specifications: use of IDL and UML	2.0	IDL not complete UML not complete No UML guidelines provided
5-3	Object Definition Techniques	1.5	Internal object models not complete Mappings not complete
5-4	OMG Interface Requirements	2.0	Good integration of current and in-progress OMG services Factoring out common functions partially address, e.g. Submission A, Factories, etc. Not Addressed: ISO/IEC 10746, Reference Model of Open Distributed Processing (ODP) Not Fully Addressed: Security
5-5	Qualitative Criteria	1.5	Most topics addressed in limited ways Microsoft technology usage not adequately addressed
ARCHITECTURE
6-1	Use the RFT's Preliminary Architecture as a Baseline	3.0
6-2	Shared Service Interfaces	2.0	See details in Section 2.2
6-3	E&P Object Model	2.0	Substantial definitions for required services Object model diagrams not complete Definitions and relationships not complete Not Included: E&P process and presentation objects/interfaces
6-4	Service (Object) Definitions	2.0	See details in Section 2.2
6-5	Relationship to Existing POSC Specifications	2.0	Epicentre usage and mappings not complete Association with data types not complete
DOMAIN
7-1	Relate the domain submission to a specific Architecture submission	3.0
7-2	Interpretation Domain Object Model and E&P Object Model	1.5	Object model diagrams not complete Definitions and relationships not complete
7-3	Business Object Definitions	1.5	In spite of the high-quality work reflected in the submissions, the required object definition process and detailed definition content was not included in full.
7-4	Scope: target subset	2.0	Coverage within the target subset was fairly good In spite of the high-quality work reflected in the submissions, the required scope of objects was not addressed in full.
7-5	Relationship to Existing POSC Specifications	1.5	Epicentre usage and mappings not complete Association with data types not complete
7-6	Business Object Definition Guidelines	1.5	For the most part, object definition guidelines were not addressed The encapsulation of data types/representation was addressed in Submission "A"

4. Work Plan

A detailed work plan for completing the work on the POSC interoperability specifications has been developed. The following is a summary of the work plan.

Phasing and Estimated Timing

The work is organized in four phases labeled 0 through 3. Major reviews are planned at the end of Phases 1 and 2. An Alpha/Beta release is planned in Phase 3.

Resource Roles and Estimates

A number of roles have been identified to address the tasks and phases as shown. The current estimated total is 22 man-months. The plan will be refined and roles re-assigned as the planning and resource assignments proceed. The resource roles of "Contracted Subject Expert", "IT/Object Contractor", and "E&P/Object Contractor" will be contracted from outside of the POSC staff. Other roles may be contracted from outside as well. The First-Line Member Reviewers are currently designated to be the member representatives on the evaluation team. The First-Line Reviewers will be included in task reviews and will primarily be invited to participate in the Phase End reviews.

Current resource roles defined are:

Tasks

The following list identifies the details of the tasks to be performed during development of the specifications:

All Phases
	Project Management
Phase 0
	Define Usage Scenarios covering requirements for Interoperability Levels through "3" and Interpretation coverage across the target RFT scope, limited as recommended in the evaluation. This will produce deliverables including E&P activity descriptions and correlated object/service sequence diagrams. Detailed applications of these Usage Scenarios will be made as the objects and services are defined resulting in correlated object/service-level sequence diagrams.	Identify and Define Geological Scenarios Identify and Define Geophysical Scenarios Review
	Prepare Tools and Techniques, including templates (from the evaluation work checked against OMG style requirements, POSC specification production techniques, UML tools, IDL tools, naming conventions (define and publish), software engineering and data management requriements, mapping language (EXPRESSIVE) techniques and tools, utilities, etc.	Installations Administration and Usage Guidelines Mapping Language and Tools Review
	Draft Specification Overview, using material taken from the Request for Technology, submissions, evaluation report, etc.	Microsoft / OMG Guidelines, investigate and document alignment and options to use Microsoft distributed object technology with the specifications Design Guidelines, using material from the submissions and evaluation report supplemented by the ongoing work to complete the specifications Assemble and Edit the Specification Overview Material Review
	Draft Base Computer Services (BCS) and Distributed Object Services (DOS)	Issue BCS Business Driver Survey, to validate and/or enhance the 1994 survey Determine Future BCS Profile Strategy, including the disposition of the Version 2.0 profiles and the definitions of new profiles suitable for Version 2.2. specifications and for the interoperability specifications Draft Extended / Updated BCS Specifications Draft DOS Specifications Review
	Representation Encapsulation (RE)	Continue the work presented in Submission "A", including determination of base objects and derived objects, definitions of all objects and supporting services, correlation with POSC specifications, mappings, and interface with early SEM work Ensure Thorough Understanding from Submitters Associate with Data Type Definitions Consult with Subject Expert(s) Define Objects/Services and Interfaces Review
	Prioritize objects and services to be defined in Phases 1 & 2, guided by the Usage Scenarios.	Prioritize Phase 1 & 2 objects and services
	End Phase 0 Milestone
Phase 1
	Define E&P Objects and Services Specifications, including for this and the following tasks the preparation of full object / service definitions per the RFT and the templates; this will include object models, object family definitions, object definitions, design pattern recognition and definitions, internal data models, Epicentre mappings, and illustrative sequence diagrams	Objects: Base, Representation, Project (plus Base Factory, Classification, and Authorization Services) Workshop Drafting A Interim Workshop Drafting B Review Services: CORBA Service Refinements Workshop Drafting A Interim Workshop Drafting B Review Services: New Services Drafting A Interim Workshop Drafting B Review
	Define Interpretation Objects and Services Specifications	Objects: Well, Log, Geologic Feature Workshop Drafting A Interim Workshop Drafting B Review Objects: Seismic, including Pick Workshop Drafting A Interim Workshop Drafting B Review
	Phase 1 Review
	End Phase 1 Milestone
Phase 2
	Refine Specification Overview
	Refine Base Computer Services (BCS) and Distributed Object Services (DOS) Specifications	Assess and Document BCS Survey Results Refine BCS Profile Description Revise/Edit BCS and DOS Specifications Review
	Refine E&P Objects and Services Specifications	Refine E&P Object Specifications Refine E&P Service Specifications Review
	Refine Interpretation Objects Specifications	Refine Interpretation Objects Specifications Review
	Phase 2 Review
	End Phase 2 Milestone
Phase 3
	Prepare Alpha/Beta Release
	Alpha/Beta Release and Member Acceptance Feedback
	Prepare Production Release
	Production Release

Appendix A. Design Patterns

A.1 Sample Design Patterns

A.1.1 Coordinates

• Name: Coordinates
• Problem: Eliminate the need for software developers to address coordinate transformation details
• Context: All geometric data with object representations is references to a coordinate system. This system may not be the system required by an application. Standard coordinate systems are defined by Epicentre reference values and must be used by applications.
• Forces:
• - performance is an issue
• -/+ complexity
• + correctness (transformation needs to be right and the same everywhere)
• completeness for coordinate system descriptions
• extensibility (add more coordinate systems and transformations)
• Solution:
1. All transformation algorithms will be encapsulated in a coordinate service
2. Encapsulate all coordinate systems in a coordinate service
3. (CORBA) client asserts required coordinate system to an EPO, the EPO applies coordinate transformations with respect to its native coordinate system
• Examples: Display a well on a seismic section.
• Resulting Context: Performance may be sacrificed for correctness.

A.1.2 Representation

• Name: representation
• Problem: eliminate redundant and inconsistent handling of representations of geometry and measurements by E&P subject-matter objects in a well-defined and consistent way.
• Context: Multiple E&P subject-matter objects have similar forms of representation and single objects have multiple representations. Ease of use requires consistency of the interfaces to representations.
• Forces:
• - cohesion, i.e. a complete interface on a business object versus its components
• - complexity
• +/- performance (good and bad)
• + granularity of polymorphism (can use other representation implementations)
• Solution:
1. Separate E&P subject-matter objects from representation (data type) objects by letting subject-matter objects have a non-inheritance relationship with representation.
2. Each kind of object has an independent inheritance hierarchy.
• Examples:
• Triangulation of a Surface (representation) serves Horizon and Fault (both subject-matter).
• A Horizon has a Surface that may be represented as a 2D Grid or a Tri-mesh.
• Resulting Context: Visualization and processing can be applied to multiple objects that share the same representation. More factories will be required because there will be more types of objects.

A.1.3 Query and Create

• Name: query
• Problem: Client seeks to discover and access objects based on attributes which have been identified as queryable; data may or may not be persistently stored as objects.

Remarks: Client seeks to find and select a well either from a data store or from the existing transient wells. Object definitions must identify the queryable attributes. Factories will define the process in which objects will be instantiated.
• Context:
1. There may be a large number of objects.
2. Objects may not always exist as persistent objects
3. Data store for objects may be shared with applications that do not use object interfaces.
4. Objects may be in multiple data stores (? multiple or federated?)
5. Objects that have already been instantiated (perhaps by another client) should not be instantiated again.
• Forces:
• Efficiency / Performance:
1. Do not want to instantiate objects during the query/selection process.
2. Want to control in what process the object resides: what defines 'sameness' or 'is equal' of an object?
• Key identifiers for objects must be known and standard.
• Flexibility
• Extensibility (to new data stores)
• Solution: Use a CORBA Query Service to discover objects that result in a queryable collection. Allow client to assert a Factory for object instantiation. The Factory registers the objects with the Trader Service.
• Examples: The Submission "D" Query plus queryable collection.
• Resulting Context: Well objects known by the Trader Service. This pattern needs work with respect to copy and unique identity.
• Related Patterns: Lifecycle

A.1.4 Relationship

• Name: relationship
• Problem: Establish ad-hoc relationships between objects, i.e. establish relationships between objects without changing their interfaces. This allows reuse of the objects.
• Context:
• A reusable set of objects
• Set of existing persistent objects
• The need to replace end-members of a relationship: object plug-and-play (granularity)
• Someone creates new kinds of objects with new IDL interface requiring two-way relationships with existing objects
• Objects will be aggregates of other objects, e.g. representation, in which the aggregate is defined at run time
• Forces:
• ++ Flexibility, complexity
• Performance: can traverse relationships without touching the objects (which is needed when the relationship is hard-coded in the interface)
• Solution: Needs work; consider the OMG BOCA submission's approach
• Examples:
• Assigned unassigned Fault segments
• Representation and subject-matter objects are separate
• Resulting Context:
• Related Patterns: representation

A.2 Design Pattern Guidelines

1. Design patterns defined for the specifications should be mapped to basic patterns (e.g., the singleton pattern) used to determine which one of a group of instances retrieved from the CORBA Trader Service is to be used). This is a low priority, but would be helpful in legitimizing the design patterns used in the specifications.
2. Consider defining guidelines for exception handling.

Appendix B. Templates

B.1 Object Families

• Summary: describe scope of objects included in terms of types of data and usage scenarios addressed
• IDL Module/Interface Enumeration: list the modules and interfaces
• Class Diagram: UML, illustrate relationships and inheritance within the set of objects
• Relationships: describe the relationships; possibly from a categorized list; clearly identify ownership; may be redundant with Object / Interface template
• Description: reference design patterns and services used, if appropriate. Explicitly not relevant Factory objects.
• Supported event types: For objects that provide data, identify the supported event types and provide introspective methods.
• Usage Scenarios: reference the POSC-defined usage scenarios which establish the requirements for the objects
• Sequence Diagrams: UML, supply two categories of diagrams:
• Creation Diagrams: illustrating how objects are found / created emphasizing use of Factories; illustrate use of Naming Service or Trader Service where appropriate
• Use Diagrams: illustrating how clients typically use the objects to address business needs, e.g. from the identified usage scenarios
• IDL: OMG IDL listings for all objects / interfaces using OMG style guidelines. Include links to IDL definitions defined in external specifications, e.g. OMG CORBA Services

B.2 Object / Interface Definitions

• Name: fully qualified name of the IDL interface in the format module_name::interface_name
• Domains: list the E&P domains in which this object is being defined; indicates the names of the object model(s) in which this object is defined or into which it is inherited
• Definition: succinct definition in user terminology; identify responsibility
• Categorize: indicate one or more of the enumerated list of descriptors
• Description: use idldoc style, including structs, typedef constants, methods, and attributes
• Class Diagram: UML, showing inheritance hierarchy
• Inherited Functionality: enumerate and justify; include dependencies on base classes, services, and other objects
• Relationship Enumeration: list relationships with roles (usually selected from an enumerated list); indicate whether it is visible as an attribute, visible through a method, or hidden
• Queryable Attributes: for queryable object classes, identify the attributes which can be used to qualify a query
• For objects that can link data with a persistent data store:
• Epicentre Version
• List of Relevant Epicentre ER Diagram Names
• Internal Data Model - EXPRESS
• Mappings with Epicentre - EXPRESSIVE (From Submission "D"), bi-directional mappings illustrating all behaviors for retrieving and for updating data
• Natural Identifier: define the criteria by which an object instance answers the is_equal method; presumably an enumeration of attributes
• Design Patterns: identify specific design patterns in which the object participates, e.g. a Factory object may participate in a Query and Create Pattern
• For objects that encapsulate data types / representations:
• Lattice Types: identify the appropriate lattice types
• Usage Scenarios: identify the usage scenarios which are addressed by this object

• Most of the above are natural products of a reasonable design process. The standardization of the template minimizes the effort required to create and validate definitions
• The template includes reference to defined object and relationship role categories, usage scenarios, design patterns, etc.
• The template should serve to produce a minimal but fully workable definition suitable for OMG RFP submissions.

B.3 Design Patterns

• Name: qualified name for the design pattern
• Problem: explanation of the business problem described by the design pattern
• Context: enumeration of constraints and external conditions that bear on the problem
• Forces: enumeration of quality factors that bear on choosing a good solution; desirable factors are marked (+), undesirable factors are marked (-), factors with positive and negative aspects are marked (+/-)
• Solution: description of the approach to address the problem
• Examples: illustration of a small number of business usage scenarios that involve the design pattern
• Resulting Context: characterization of the qualitative and quantitative consequences of the solution in terms of the context and forces.
• Related Patterns: enumeration of related design patterns

• The design patterns should follow the format used by Erich Gamma, et al (Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional Computing Series, 1995, ISBN 0-201-63361-2)

Glossary

API

(1) American Petroleum Institute. (2) Application Programming Interface.

application component

A component that is initiated by and/or interacts with end-users to accomplish business tasks.

application interoperability

The characteristic demonstrated by two independent application components of exhibiting predefined behaviors in a consistent manner, e.g. user interface interoperability, data instance sharing interoperability, etc.

architecture

Defines how components operate and cooperate to achieve an overall purpose. The architecture under development here is intended to define how E&P software components can facilitate information sharing and interoperability.

Base Computer Standards

POSC definition of a set of specifications that can be used to define an E&P computing environment. It is an assembly of pointers to existing standards and other POSC specifications.

BCS

Base Computer Standards.

BOCA

Business Object Component Architecture.

BOF

Business Object Facility.

BODTF

Business Object Domain Task Force.

business object

A representation of a thing active in the business domain, including at least its business name and definition, attributes, behavior, relationship and constraints. A business object may represent, for example, a person, place or concept.

business object facility (BOF)

A collection of services that facilitate the definition and use of business objects.

CBO

Common Business Object. A term defined by the OMG to denote objects that are defined with business-oriented content and which are applicable across all industries.

CBOF

Common Business Object Facility. The name given to a submission to the OMG Business Object Facility RFP (now withdrawn).

CBOF I/S

Common Business Object Facility Interface Specification.

CGM*PIP

Computer Graphics Metafile - Petroleum Industry Profile. CGM*PIP is a set of POSC specifications containing E&P-specific extensions to the ISO Computer Graphic Metafile standards.

COM+

Component Object Model Plus (Microsoft).

component

A discrete piece of a software system or application. See application component and software component.

COS

CORBA Object Service; the OMG-defined prefix for naming services defined by the OMG.

CORBA

Common Object Request Broker Architecture.

CORBAservice

The general name used by OMG to refer to broadly applicable services defined by the OMG are used together with the CORBA specification (i.e. with Object Request Brokers).

DAE

Data Access and Exchange. POSC interface specification for logical data model access to data stores.

DAEF

Data Access and Exchange Facility; any product that implements the POSC DAE. DAEF products manage data populations called POSC Data Stores in much the same way that traditional DBMS products manage data bases, except that access to POSC Data Stores use versions, extensions, or subsets of Epicentre as their schema and DAE as their interface.

data object

An object that is primarily a representation of an E&P business entity in terms of its data. Examples are seismic section, well log curve, etc.

data store

Application accessible, organized collection of data managed in a controlled manner and accessed through a defined interface; may be supported either by a commercial Data Base Management System with a defined physical data base schema or by a middle-ware layer that offers similar services at a logical data model level, e.g. POSC Data Stores accessed via the Data Access and Exchange (DAE) interface.

data type

A "building block" of data values defined in Epicentre. Data types are the basic data formats and ranges, such as integer, character, location, date, quantity, and surface.

DCE

Distributed Computing Environment

design pattern

Repeated fragment of information processing that can serve as a guide to software design and as a test of the completeness and correctness of the definitions of shared services and objects.

developer

A person with programming skills whom creates tools to be used by other developers or by end-users.

distributed object technology

Object technology with the ability to distribute objects across heterogeneous computing environments. With distributed object technology, the servers and clients can be in different address spaces or in different processors that may be distributed across a network (e.g. an Intranet or the Internet).

domain

General idea of the scope of relevance of a definition or set of definitions. In this report, domain is a POSC-defined subdivision of the E&P industry's business processes intended for use in defining coherent object models; one of the following: Interpretation, Acquisition and Processing, Drilling, Facility, Operations, Land/Lease, Management/Economics, Accounting/Financial.

E&P

Exploration and Production sector of the Oil and Gas industry

E&P BOF

Term introduced in the Request for Technology document intended to encompass the services layered above the OMG CORBA services specifically designed to support business object usage; this term has been dropped in light of the withdrawal of the OMG Request for Proposal upon which it was based.

E&P User Interface Style Guide

POSC specifications that defines guidelines for E&P industry oriented user interface constructs that are intended to encourage consistency in the appearance and behavior of E&P applications. Also referred to as POSC Style Guide.

EJB

Enterprise JavaBeans.

encapsulation

Concept that the internal content of an object is hidden and may not be accessed or examined from outside the object. One interacts with an object through its public interface, which exposes selected attributes and methods.

end-user

An E&P professional (geologist, petrophysicist, etc.) who uses the software products. Synonym: business practitioner.

Epicentre

POSC E&P logical data model specification, i.e. a data model for the exploration and production industry that is expressed in a form meaningful to the way E&P professionals and application developers define and use data.

Epigramme

A POSC PEF encoded data file.

EPIO

E&P Interpretation Object; POSC-defined prefix for naming objects and services specific to the Interpretation Domain.

EPO

"E&P Object"; POSC-defined prefix for naming objects and services applicable across all E&P Domains.

EXPRESS

The name for the information modeling language defined in ISO 10303-11 intended to be used to define exchange data models related to manufactured products and processing plants. EXPRESS has object-oriented capabilities, including inheritance. EXPRESS, with several enhancements, is used by POSC to define the Epicentre logical data model.

EXPRESS-X

The working name for a information model mapping language being defined to complement EXPRESS, i.e. to define mappings between pairs of EXPRESS information models.

factory

A specialized object service that primarily instantiates object instances.

GIS

Geographical Information System.

IAC

Interapplication Communication; a POSC specification for a non-object shared service Interoperability, the characteristic demonstrated by two independent components of exhibiting predefined behaviors in a consistent manner.

IDL

Interface Definition Language. IDL defines the interfaces of the objects in a rigorous programming language independent manner that can be compiled for a specific programming language.

idldoc

A utility that generates documentation from OMG IDL definitions.

Interoperability Specifications

A new major category of POSC specification.

interpretation

One of the POSC-defined E&P Domains; includes the full range of subsurface interpretation disciplines corresponding to the Definition or Appraisal phase of the E&P life cycle.

levels of interoperability

The six POSC-defined stages of interoperable behavior for applications.

levels of sophistication of application interoperability

See levels of interoperability.

MIDL

Microsoft Interface Definition Language. The name used by Microsoft for its interface definition language.

MTS

Microsoft Transaction Service.

MOF

Meta-data Object Facility. The name used by OMG for a specification of a service to define and manage meta-data, e.g. meta-data to support software engineering tools.

natural identifier

For an object, the set of attribute values which together link an object instance to the real-world "thing" that it characterizes.

object

As used in the software engineering discipline of object technology, an object is a discrete software component that can contain data and can perform operations. Objects often model real-world things. The operations that an object can perform are called the object's behavior. In the context of this report, object refers specifically to an entity object.

object families

A working term representing a group of object defined together because of close affinity in content and/or use.

object model

A representation of a set objects and their relationships.

object role

Defined characteristics in the functionality of an object, e.g. entity or data for objects carrying and providing data, process for objects that carry out algorithms, and presentation for objects that cause information to be displayed for users.

object technology

The set of techniques and tools based on the concept of object.

OMEGA

Object Oriented Methods Environment for Geoscience Applications. The name of an Esprit project.

OMG

Object Management Group.

OpenGIS Consortium

A consortium of organizations dedicated to the definition of open specifications in support of Geographic Information System products and their users.

Open Process

A set of activities through which POSC member organizations and others contribute comments related to requirements for POSC specifications.

ORB

Object Request Broker.

PEF

POSC Exchange Format. PEF is the POSC generic linear encoding of logical data model defined data content. A PEF file that uses Epicentre as its data model is called an Epigramme.

ODP

Open Distributed Processing.

POA

Portable Object Adapter.

POSC

Petrotechnical Open Software Corporation. A not-for-profit membership organization formed to help realize the benefits of information sharing in the E&P industry through collaborative development of specifications for use as standards.

POSC data store

A data store based on the POSC Epicentre data model.

presentation object

An object that is primarily intended to display information to end-users.

process object

An object that is primarily intended to perform algorithmic or interactive operations.

PSS2

Persistent State Service V2.

reference values

Standard values in Epicentre defined by POSC or other organizations.

representation

The structure and format of the pure values of a measurement as contrasted to the business context and meaning of the measurement values.

representation object

An object that primarily serves to define and manage potentially complex value structures and content without regard to the business context of said values.

RFC

Request for Comments. In this report, RFC refers to the Interoperability and Business Objects RFC that was issued by POSC in May 1997.

RFP

Request for Proposal.

RFT

Request for Technology.

service

A process object.

SIP

Software Integration Platform; the set of all POSC specifications. The specifications, taken together, support improved information sharing through the use of computer software (applications, infrastructure, etc.), through integration of previously diverse definitions and usages, and by facilitating the building of common platforms on which end-users can work effectively.

software component

Discrete piece of software. Software systems are composed of components.

SSL3

Socket Security Layer, version 3.

stakeholders

A synonym for "interested parties", i.e. those who have a vested interest in something.

Style Guide

POSC E&P User Interface Style Guide.

Subsurface Interpretation

The name given to the E&P Domain which covers the appraisal or definition phase of the E&P Life Cycle and covers the re-appraisal studies that occur during the Production phase. Subsurface Interpretation covers a set of related geophyiscal and geological disciplines.

template

Annotated outline of information suitable for the content of a type of definition.

UML

Universal Modeling Language

UNIX

The name of a computer operating system implemented on many hardware platforms and based on an open specification standard managed by The Open Group.

usage scenario</