Capabilities: Applications in work processes must access the same data store to avoid data reformatting overhead. The variety of applications which can interoperate is limited because data stores typically have different formats.

Requirements:

• Common data model/access within sets of applications and data stores which work together.
• Public description of which applications work with which data stores.

Example: In the example above, applications 2 and 3 interoperate by sharing the same data store.

Level 1

Capabilities: End-users can run the same application against different data stores because servers act as intermediaries. Because the server interfaces are standardized, more applications within the work process can share the servers. The servers can achieve plug-and-play.

Requirements:

• Interfaces for servers (data objects) have to be standardized.
• Data Types (covering all data types used in Epicentre) must be standardized.
• Standard unit and coordinate transformations for data.
• Method(s) for locating servers and specific data objects.

Level 2

Level 3

Level 4

Level 5

2.4 Business Objects

The RFC elaborated on the concept of business objects, how they can contribute to interoperability, and how they relate to other aspects of software architecture and use. A vanguard technical team worked during RFC comment period to define a preliminary architecture that supports business objects and facilitates application interoperability. The preliminary architecture is presented as an Appendix.

Submissions to the architecture component of this RFT should be completed, workable architecture proposals building on the preliminary architecture presented in the Appendix. Submissions to the Subsurface Interpretation Domain component of this RFT should propose an initial domain object model and a set of business object definitions for this E&P domain. All submissions to this RFT will be evaluated critically to qualify and select the proposals that can be used to form the POSC SIP Architecture and Subsurface Interpretation Domain specifications.

The specifications that result from this RFT, together with supporting POSC procedures, will define business objects in the context of a workable software architecture. Thereafter, application suppliers will have the opportunity to develop and deliver interoperable products based on these specifications.

Future RFT's will request object models and business object definitions for other E&P domains. The architecture specification supporting business objects and interoperability and the E&P domain business object definitions will join Epicentre, DAE, PEF, Epigramme, BCS, User Style Guide, and CGM*PIP as a more complete set of POSC-defined specifications for the E&P industry.

2.5 Distributed Object Technology

This RFT is being issued in the context of the continued development and deployment of distributed object technology, notably driven by the work of the Object Management Group (OMG) as well as Microsoft's DCOM technology and the Java RMI technology. The preliminary architecture work has been guided primarily by the OMG work, i.e. the Object Management Architecture (OMA), Common Object Request Broker Architecture (CORBA), and concurrent work on a Business Object Facility (BOF) and business objects for industrial domains. Submissions should position themselves to enable use of environments and components from each of the main sources of distributed object technology development using emerging interoperable and/or interworking approaches for their integration.

The OMG defines four categories of object interfaces:

• general Object Services
• user-oriented Common Facilities
• shared Domain Interfaces
• specific Application Interfaces

The OMG Reference Model defines the concept of domain-specific Object Frameworks, i.e. collections 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. This RFT is essentially the beginning of an effort to define such a framework for the E&P industry with particular attention being paid to the requirements of this industry and to the ongoing work of POSC. Thus, this RFT seeks a solution that is sufficiently usable as specified to permit multiple, independent implementations of the framework components that are really interchangeable. The RFT also seeks a solution that defines an object models and object definitions that can be used by multiple, independent application products along with the framework to deliver a high-degree of interoperability to E&P users. This RFT addresses the Subsurface Interpretation domain. Future RFT's will address the other E&P domains.

In a similar and parallel manner, the OMG continues to issue Requests for Proposal (RFP's) to populate the first three categories of object interfaces above. Submissions to this RFT should build on available products that implement OMG object interfaces and should be positioned to evolve forward as OMG-based specifications and products become available. Submissions should not be dependent on the availability of approved specifications or workable products that will not exist by the submission closing date.

Although POSC and OMG have had reciprocal memberships for several years, POSC has chosen to work outside the OMG specification development processes. Even so, submissions to this RFT should be suitable as OMG specifications to the extent possible. The specification resulting from this RFT may be submitted to the OMG in some form at a future time. POSC may sponsor the formation of an OMG Domain Task Force for the Energy Industry in the future.

3.1 Introduction

POSC develops and publishes specifications intended to realize POSC's mission of delivering value to the industry through information sharing throughout the E&P asset life cycle. POSC specifications are directed toward areas in which there is sufficient industry interest as determined by POSC's ongoing interaction with the POSC member organizations and by formal open processes, such as the Request for Comments process which preceded this RFT.  Soon after development and initial availability to POSC member organizations, POSC publishes its specifications to be used by both member and non-member organizations.

3.2 Role of the Board of Directors

The POSC Board of Directors defines the mission and vision for POSC, approves the budget, and appoints the officers. The Board has no direct role in the development of specifications, and, therefore, no direct role in the evaluation of RFT submissions.

3.3 Role of the POSC Staff

The role of the POSC staff is to conduct the business of the company, including the development of specifications. In doing so, the POSC staff use various processes open to either the public or to POSC members, e.g. periodic member meetings, public conferences and exhibitions, technical workshops, Requests for Comments, and Requests for Technology.

This RFT is the direct result of a series of member technical workshops that began in 1996 and culminated with the issuing of a Request for Comments in May 1997 and the preparation of the preliminary architecture in March through June 1997.

As part of the Request for Technology process, the POSC staff will organize a joint membership / staff evaluation team to review and examine RFT submissions according to established criteria. The evaluation team will make a recommendation concerning the submissions for consideration by POSC in deciding the outcome of the RFT process.

3.4 Role of the RFT Evaluation Team

The role of an RFT Evaluation Team will be to technically evaluate submissions, determine which submission or combination of submissions satisfy which of the RFT requirements, and recommend how one or more submissions could satisfy the goal of defining  workable POSC specifications. For this RFT, the evaluation process will include these steps:

• Member-Participant Selection Criteria: POSC will publish the criteria by which individuals nominated to participate in the evaluation team will be selected at least six weeks prior to the due date for nominations. The criteria will include: skills and experience requirements, material required to accompany a nomination (e.g. statement of skills and experience), willingness to function as an independent-thinking technical expert, exercising his/her best technical judgment in recommending a best solution to the problem at hand, and the criteria for setting the minimum and maximum number of member participants. There will be two sets of criteria for this RFT's evaluation team -- one focused on the architecture submission part and one focused on the Subsurface Interpretation Domain submission part.
• Member-Participant Nominations: Interested POSC members may nominate individuals as member participants in the evaluation process for this RFT. Nominations are due on a specified date which coincides with the date on which Letters of Intent (LOI's) to submit are also due. [Letters of Intent are explained in Section 4.3.] POSC members may nominate individuals for the evaluation team whether or not the organization makes a submission to this RFT.
• Member-Participant Announcement: The individuals selected to be member participants in the evaluation team will be announced approximately 30 days prior to the submission due date.
• Submissions: RFT submissions are due by a specified date. Submitters will be asked to present their proposals at the POSC membership Submitters Forum to be scheduled soon after the submission due date. Submissions are expected to be full and complete proposals. The existence of working implementations of the proposed specifications at the time of submission is highly desirable and should be clearly described in the submission material.
• Evaluation Period: A period of approximately 90 days follows during which the evaluation team works with the submissions. The team's work will be facilitated by POSC staff members. Interim decisions and the recommendation of the team will be based on consensus. POSC will provide logistical and technical assistance to the evaluation team. The evaluation team may invite and/or contract with external experts from industry or other standards bodies to contribute to the evaluation process in specific ways.
• Recommendation: The deliverable product from the evaluation team is a recommendation on how workable POSC specifications that address the stated requirements could be achieved based on the submissions. The recommendation will be one of the following:
• A Positive Recommendation: A set of one or more groups of submissions that individually or when combined in a specified manner should be a suitable basis for POSC specifications that address the goals of the RFT. The recommendation should include a comparative analysis of the benefits and drawbacks of each such group.
• A Negative Recommendation: A statement that the submissions are not adequate to use as the basis for workable specifications. The recommendation should include an analysis of the major short-comings and a proposed set of criteria for issuing a revised RFT requesting refined submissions.

3.5 Evaluation Team Member Participant Nomination Letters

Here is a suggested template for Member Participant Nomination:

This letter confirms the nomination by POSC member organization <___ organization required ___> (the organization) of <____ nominee name and details required ____> to the Evaluation Team for the POSC Interoperability and Business Objects RFT. Should this nominee be accepted to serve on the Evaluation Team, we will make the nominee available for service on the Evaluation Team for the duration and under the terms indicated in the Call for Nominees letter from POSC, dated <____ actual date to be filled in ____>, including  a commitment to function as an independent-thinking technical expert, exercising his/her best technical judgment in recommending a best solution to the problem at hand.   <____ contact name and details required ____> will be responsible for liaison with POSC regarding this nominee's service on the Evaluation Team.

The signatory below is an officer of the organization and has the approval and authority to make this commitment on behalf of the organization.

<___ signature required ____>

3.6 Summary of Evaluation Goals

• Contribute to a fair and open specification development process
• Achieve a critical review of the submissions and discussion by a qualified, representative cross-section of POSC
• Give feedback to allow submitters to address concerns in their revised submissions
• Build consensus on recommendations for acceptable paths forward to workable specifications
• Enable POSC to make an informed decision on either composing the specifications or re-starting the process with revised criteria

Submitters are expected to actively contribute to the evaluation process, including making qualified personnel available to respond to requests for assistance from the evaluation team.

4.1 Submission Effort

An RFT submission may require significant effort in terms of preparation of submission material, presentations to the POSC membership, participation in response to requests from the evaluation team, and related technical development, testing, etc. POSC is unable to reimburse submitters for any costs in conjunction with their submissions to this RFT.

4.2 Co-Submission Opportunities

4.3 Letter of Intent

A Letter of Intent (LOI) must be submitted to POSC signed by an officer of your organization signifying your intent to respond to the RFT and confirming your organization’s willingness to comply with POSC's terms and conditions. These terms, conditions, and requirements are presented below. Note that each organization that intends to co-submit a submission is required to file an LOI. There is no requirement to identify an organization's intended co-submitters in the LOI.

The LOI should designate a single contact point within your organization for receipt of all subsequent information regarding this RFT and your submission. The name of this contact will be made available to all POSC members. The LOI is due sixty days before the deadline for submissions. LOI's must be sent by fax or paper mail to the “POSC, Attention: Interoperability RFT” at the Houston POSC address: 10777 Westheimer Road, Suite 275, Houston, Texas 77042-3453 USA.

Here is a suggested template for the Letter of Intent:

This letter confirms the intent of <___ organization required ___> (the organization) to submit a response to the POSC Interoperability and Business Objects RFT. We will grant POSC and its members the right to copy our response for review purposes as specified in section 4 of the RFT. Should our response be adopted by POSC we will comply with the Terms and Conditions set out in section 4 of the RFT.

<____ contact name and details required ____> will be responsible for liaison with POSC regarding this RFT response.

The signatory below is an officer of the organization and has the approval and authority to make this commitment on behalf of the organization.

<___ signature required ____>

4.4 Terms and Conditions

The business factors that POSC will consider to qualify an RFT submission for use by POSC in defining specifications are outlined below:

• Assurance that the duplication of the “look and feel” of any aspects of a submitter's implementations from the resulting specifications will not result in infringement or obligation to pay royalties.
• Agreement to grant to POSC, a non-exclusive, royalty-free, paid-up, worldwide license to copy and distribute the submission and to incorporate the submission (in whole or in part) in a POSC specification and distribute copies of the resulting specification. (Products that implement the submission or the resulting specifications are owned by the product developer.)

4.5 Responding to RFT items

Separate proposals

Independent proposals are solicited for each of the two items in the RFT. Each item is considered a separate entity for which a proposal may be made. A submitter may respond to one or both items. Each item in a submission that covers both items may be evaluated independently, i.e. with complementary items from other submissions. Submissions that address both items should identify dependencies between the items clearly to avoid being at a disadvantage.

Complete proposals

Proposals for each separate RFT 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 RFT.

Additional specifications

Submissions may include additional specifications for items not covered by the RFT 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 inclusion in POSC specifications.

Alternative approaches

Submitters may provide alternative RFT item definitions, categorizations, and groupings so long as the rationale for doing so is clearly stated.

Confidential and Proprietary Information

The POSC specification development process is an open process. Responses to this RFT become public documents of POSC 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 RFT.

Copyright Waiver

If a submitted document is copyrighted, a waiver of copyright for unlimited duplication by POSC is required to be stated in the document. In addition, a limited waiver of copyright is required that allows each POSC member to make up to fifty (50) copies of the document for review purposes only.

Proof of Concept

Submitters are encouraged to include a “proof of concept” statement in submissions, explaining how the submission has been demonstrated to be workable. Workability 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:

• “The content of this submission has completed the design phase and is the process of being prototyped.”
• “An implementation of this submission has been in beta-test for 4 months.”
• “A named product (with a specified customer base) is a realization of this submission.”

It is incumbent upon submitters to demonstrate the workability of their proposal. POSC will favor submissions for which sufficient relevant experience has been gained.

4.6 Format of RFT Submissions

General

• 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 RFT. If this is not practical, submitters must make clear what portion of the documentation pertains directly to the RFT and what portion does not.

• Where relevant, the models and terminology in current POSC specifications and referenced documentation, e.g. the OMG Object Management Architecture Guide, should be used in the submission. If this is not appropriate, describe and provide a rationale for the alternative models and terminology used.

• The preliminary architecture in Appendix C should be incorporated in the submission or the submission should describe and provide a rationale for the alternative used.

Suggested Outline

A three part structure for submissions is suggested for each item addressed in a submission:

PART I

• Copyright Waiver (see above)
• Submission contact point (see above)
• Overview or guide to the material in the submission
• Overall design rationale (if appropriate)
• Statement of proof of concept (see above)
• Resolution of RFT mandatory and optional requirements
  • Explain how the submission satisfies the mandatory and (if applicable) optional requirements stated in Section 5. References to supporting material in Part II should be given.
  • In addition, if any of the general requirements stated in Section 5 are not satisfied by the submission, provide a detailed rationale.
• Responses to RFT issues to be discussed
  • Discuss each of the Issues To Be Discussed identified in Section 5.

PART II

• Proposed specification

PART III

• Submissions must clearly distinguish interfaces that all implementations must support from those that may be optionally supported.
• Submissions should propose appropriate compliance points for implementations.
• Submissions must include a full specification of any changes or extensions required to any existing POSC specifications, i.e. with respect to Version 2.1 or Version 2.2. This should be in a form that enables direct revision of existing specifications.
• 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 as specifications.

4.7 How to Submit

Submitters should send an electronic version of their submission via email to interop-rft-submissions@POSC.org by 5:00 PM U.S. Central Standard Time (23:00 GMT) on the day of the submission deadline. Acceptable formats are Postscript, ASCII, Acrobat PDF, 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 hard copy version of their submission to the attention of the “Interoperability RFT” at the Houston POSC address shown near the beginning of this RFT.

In addition, submitters are responsible for making available 50 paper copies to attendees of the submitter forum held soon after the submission due date.

5.1 Mandatory Requirements for Object Interfaces

• 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.

• Proposals shall justify and fully specify any changes or extensions required to existing POSC specifications. (Modifications are anticipated, for example, to the Base Computer Standards to address the distributed object environment and the object framework required in this proposal. Change proposals to other specifications may arise in the course of defining object models and business objects, in defining business object mappings with Epicentre, in defining adaptations for complex data types, units, coordinates, reference values, etc., or in defining user interface elements of proposed services.)

• Proposals shall express interfaces in OMG IDL. Proposals should follow accepted OMG IDL and CORBA programming style. The correctness of the IDL shall be verified using at least one IDL compiler (and preferably more then one). In addition to IDL quoted in the text of the submission, all the IDL associated with the proposal shall be included as part of the submission in compiler-readable form.

• Proposals shall define object models using UML Version 1.1. Proposals shall recommend guidelines and conventions for the use of UML in the context of these requirements and shall illustrate said guidelines and conventions in the submission itself.

• Proposals shall define internal object data models using the EXPRESS information modeling language in the context and with the extensions used for defining Epicentre.

• Proposals shall define mappings between internal object data models and Epicentre using an EXPRESS-based mapping language, e.g. EXPRESS-X, and shall document any extensions or conventions needed.  POSC will endeavor to provide assistance to submitters in preparing internal data models and mappings on a consulting basis. Submitters are encouraged to formally request such assistance as early in the submission preparation process as possible.

• Proposals shall meet General Requirements set by the OMG for their Requests for Proposals (See OMG Document ab/97-06-01: Generic RFP Template), as appropriate, including:
  • Proposals shall specify object operation behavior, sequencing, and side-effects (if any).

  • 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 object interface specifications.

  • Proposals shall clearly distinguish mandatory interfaces and other specification elements that all implementations must support from those that may be optionally supported.

  • Proposals shall reuse existing (approved and published) OMG specifications including CORBA, CORBAservices, and CORBAfacilities in preference to defining new interfaces to perform similar functions. Note: Submissions shall define required behavior in any case, but submitters are asked not to presume the availability of specific components as commercial products.

  • 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.

  • 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.

  • Proposals shall specify object interfaces that are compatible and can be used with existing (approved and published) OMG specifications. Separate functions doing separate jobs should be capable of being used together where it makes sense for them to do so.

  • 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 object interface semantics.

  • 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.

  • Proposals shall be compatible with the architecture for system distribution defined in ISO/IEC 10746, Reference Model of Open Distributed Processing (ODP). Where such compatibility is not achieved, the response to the RFT must include reasons why compatibility is not appropriate and an outline of any plans to achieve such compatibility in the future.

  • In order to demonstrate that the service or facility proposed in response to this RFT, can be made secure in environments requiring security, answers to the following questions shall be provided:
    • What, if any, are the security sensitive objects that are introduced by the proposal?
    • Which accesses to security-sensitive objects must be subject to security policy control?
    • Does the proposed service or facility need to be security aware?
    • What CORBAsecurity level and options are required to protect an implementation of the proposal? In answer to this question, a reasonably complete description of how the facilities provided by the level and options (e.g. authentication, audit, authorization, message protection etc.) are used to protect access to the sensitive objects introduced by the proposal shall be provided.
    • What default policies should be applied to the security sensitive objects introduced by the proposal?
    • Of what security considerations must the implementers of the proposal be aware?

5.2 Relationship to Existing POSC Specifications

Proposals may be related to existing POSC specifications. Among others, here are some possible relationships that apply to any RFT submission:

• The POSC Base Computer Standards (BCS), Version 2.0 1994, state endorsements for software standards related to operating systems, graphics, programming languages, etc. Proposals should follow BCS and/or state proposed extensions appropriate to the scope of this RFT.

5.3 Evaluation criteria

Although POSC develops and publishes specifications, the workability of implementations is taken into account during the evaluation of submissions. The following criteria will be used:

• Performance: Potential implementation trade-offs for performance will be considered. Benchmark tests for relevant use cases should be included with submissions to establish expectations on the achievable performance levels using the specifications.

• Portability: The ability to develop object implementations on a variety of computing and underlying software platforms, operating systems, etc. will be considered.

• Compliance: The adequacy of proposed specifications for the purposes of compliance inspection and testing of object implementations 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.

• Ease of Use: Potential implementation trade-offs for ease of use by client applications will be considered. A range of relevant client application usage scenarios should be included with submissions to demonstrate the level of difficulty that can be expected from client application developers.

• Transition: Potential transitional use in conjunction with existing (legacy) software components, e.g. data bases / data files, application systems, and proprietary integration environments, will be considered. A range of illustrations of such use should be included with submissions to demonstrate opportunities and how they relate to the proposed object interfaces. The level of change or conformity required from existing software components should be described.

• Microsoft and Java: Potential use together with distributed object and related components from Microsoft (i.e. COM, DCOM, ActiveX) and/or associated with Java will be considered. A range of illustrations of such use should be included with submissions. The role played by specific interface, inter-working, or interoperability products should be clearly identified.

6 Specific Requirements for the Workable Architecture Specification Item

7 Specific Requirements for the Workable Subsurface Interpretation Domain Object Model and Business Object Definitions Item

8 RFT Timetable

The current timetable for this RFT is given below. It is possible that changes will be made by POSC. The latest timetable can always be found in the Interoperability and Business Objects section of POSC's Web Site (http://www.posc.org/)

Appendices

A. Glossary

The Glossary is organized in these four sections to help the reader understand the source of the terms and definitions.

• Basics - general terms, from a variety of sources
• Key Concepts - definitions of the key terms used in or defined for this document.
• POSC Specifications - terms defined in and for the current POSC specifications
• Stakeholders - terms used in this document to describe constituencies and their roles

RFC Section 2. Problem Statement.

• The need for interoperability among asset team members should be addressed in addition to those for a single end-user. This emphasizes further the requirement for the architecture to include provisions for data integration through underlying data stores across the entire E&P life cycle. It also suggests the requirement for the architecture to address multi-user transactions and work-flow capabilities.

• During the process of writing and editing the RFC document, there was an effort to determine how (or whether) to state a requirement on the architecture related to performance. The RFC did not contain such a requirement in its published form. Some comments encouraged the inclusion of a performance requirement, i.e. at least to state that the architecture should be able to support good performance. Some suggested that the architecture specification, when written, include specific performance benchmarks.

• The requirement that the architecture should not preclude the use of Microsoft technology should be emphasized.

RFC Section 4. Business Objects as the Key to Interoperability

• The idea of requiring the definition of a layer of data objects close to Epicentre to be used by higher level object implementations over Epicentre / POSC data stores was raised in the RFC comments. If defined, this layer of objects would not, in general, be visible to application components. This proposal can not be addressed properly in isolation of the broader question of implementation architecture. POSC will make a study leading to one or more suitable implementation architectures for object implementations over Epicentre / POSC data stores. This study will be done in parallel with the RFT submission preparation period. The results of this study will be published on the POSC Web Site. The study will consider issues, such as alternative implementation approaches, the role of an E&P asset life-cycle object model, opportunities for multiple data store federation, and transition strategies.

• The parallel idea of requiring the definition of a layer of data objects close to the POSC / CAESAR product model to be used by higher level object implementations over POSC / CAESAR repositories / warehouses was also raised. This proposal is being examined jointly by the POSC and POSC / CAESAR technical staffs together with consideration for the issuing of a Facility Domain Object Model and Business Objects RFT.

• In the description of E&P Domain in the RFC, it must be clarified that: (1) The E&P Domain concept does not take anything away from the need for inter-domain interoperability through shared use of an asset life cycle data model (Epicentre) and (POSC) data stores. (2) The E&P Domain concept does not take anything away from the need to drive business object definition from use cases related to E&P business processes. Therefore, a focus on the combination of inter-domain (life cycle), domain, and use case requirements must be maintained.

• In the description of project data store in the RFC, it must be clarified that a project data store can be used to hold all data for an E&P asset across the full E&P life cycle, while supporting real-time, concurrent applications.

• For the description of the use of transient data and objects, an additional example was requested and is presented here:

  Typically, transient data is summary or status data, such as data representing what is plotted in a user interface window, where it is located, histograms for color table building, etc. This is the kind of example that is suggested in section 4.6 of the RFC.

  Transient data can also be summary data, such as number of wells of interest, their total production over a six month period, number of seismic lines in this area, their total length, who are the owners, etc. Such derived data is often not retained permanently.

• In the description of domain object models, it must be clarified that there will be an E&P (base) object model from which each domain object model will inherit. Objects defined in the architecture and business objects that apply to multiple domains will be defined in the E&P (base) object model. All RFT submissions will be required to propose an E&P (base) object model, i.e. whether the submission is for an architecture, the Subsurface Interpretation domain or both.

• In the description of the requirement for mappings between business object internal data models and Epicentre, it must be clarified that mappings are needed for object behaviors which are relevant to retrieval and/or updating of persistent data in one or more source data stores.

• In the description of the need for mappings between business object internal data models and other (non-Epicentre) data models, it must be clarified that: (1) Such mappings should follow similar requirements as are stated for mappings with Epicentre, e.g. use the same internal data model, be comprehensive, etc. (2) Such mappings will not be published as POSC specifications since they involve technology that belongs to other organizations.

• Regarding POSC compliance, it must be clarified that the compliance of object implementations to the architecture, E&P and domain object models, and business objects specifications does not require the use of the DAE, Epicentre, and/or PEF specifications. Compliance of object implementations to the DAE, Epicentre, and/or PEF specifications is a separate issue. These components have the same requirements for compliance with these specifications as any software component.

• Regarding the relationship between business objects and application components, it must be clarified that business objects are intended to be defined at a high-enough level so that they can be used easily by application components, i.e. there is a close semantic match and the application component does not have to apply complex logic to compose the data it needs. This idea works both ways in that application components should be conceived in ways that allow business objects to be used easily.

RFC Section 5. Proposed Process

• Regarding the RFT evaluation process, one possible outcome will be to recommend a second round of submissions. This may be appropriate as the alternative to a complex integration and/or modification of the  submissions.

  Regarding the RFT evaluation process, there will be one evaluation team with two skills-based sub-teams that will operate separately most of the time but coordinate as needed to ensure overall consistency.

• The RFT should include some preliminary guidelines for combining business objects into virtual applications (Level 4). The requested preliminary guidelines follow:

  How to create a virtual application in the context of Interoperability Level 4

  Virtual applications are composed of component objects which may be processing objects, presentation objects or data entity objects.  There can be two approaches:

  Simple:

  The component objects exist and are known to the systems integrator as interfaces within existing server processes which are registered in an Implementation Repository. The components can be found through the Naming Service, the Trading Service or through “bind” methods. The system integrator creates an application process, which may itself be a CORBA object. This process connects via client stubs to the required objects. Note that some of the objects may be chosen at run-time by having components which are “selector” objects.  Thus not only data entity objects can be chosen at run-time but also processing and presentation objects as well. The application process is compiled and linked with client stubs for the required component objects.

  More Difficult:

  The system integrator creates new server processes which are customized by selecting which component objects reside in which server processes. The purpose for doing this is to enhance performance by guaranteeing that appropriate objects are collocated together in the same process address space. This may sacrifice some runtime flexibility but will be necessary for some applications. Component objects that are configured this way must be implemented for the same vendor ORB (until the OMG Portable Object Adapter is implemented by vendors) and should be completely encapsulated. Having done this, the system integrator proceeds with the steps outlined in the simple case.

• Regarding the object model and business object registration process, it must be clarified that submissions will go through a compliance verification process, including checking for compatibility with the architecture and semantic equivalence with Epicentre as demonstrated by mappings.

• Regarding future steps, it must be clarified that first RFT is the beginning of a series of RFT's / collaborative work team efforts that will progressively reach higher levels of interoperability and more complete coverage of the E&P life cycle.

C.1 Introduction

This section outlines a preliminary, high-level architectural context or business object framework to be used by the E&P industry to achieve application interoperability through the use of business objects. Implementation of a completed form of the architecture is intended to facilitate the use of E&P business objects to achieve interoperability between applications components. In a parallel sense to the usage of the term Business Object Facility (BOF) by the Object Management Group, the resulting architecture / framework will be referred to as an E&P BOF.

Note: All OMG IDL code is represented in Courier New font style, e.g. " typedef string InterfaceID;". The OMG IDL for all preliminary objects and services is found in Section C.8. Relevant portions of the IDL are also shown in the corresponding descriptive subsections.

C.2 Background

The E&P BOF preliminary architecture is the product of a special POSC member / staff team which was established in March 1997 as an adjunct to the ongoing POSC initiative in the area of Interoperability and Business Objects. The team consisted of individuals from Elf, Chevron, POSC, Prism and Schlumberger. The team met for a total of five weeks and three days during the period March through May.  Meetings were scheduled for continuous one or two week sessions, and were held at participant sites in Austin and Houston, Texas and Pau, France.

The team focused on validating the requirements stated in the RFC by employing use cases derived from previous real work experiences and developing new use cases based on expected need. CORBA-based architecture characteristics were then developed based on the requirements and demonstrated use cases.

The preliminary architecture is intended to provide initial baseline for use by submitters to the architecture component of this RFT.

The short time available for the team to prepare the preliminary architecture resulted in a high-level architecture specification, not a detailed one. The team has attempted to illuminate the important features that an E&P BOF needs to support. Submitters may find it necessary to modify the preliminary architecture specification in whole or in part. Submission(s) chosen through the RFT process will be seen as the completion of the detailed architecture specification, which when combined with the high-level specification (modified as necessary), will form a complete architecture specification.

The following work products were delivered by the team:

• Identification of the required E&P business object services with:
  • Descriptions of their capabilities.
  • A mapping to existing CORBA services, if any.

• Examples of usage showing how the services are intended to satisfy interoperability requirements.

• Selected example OMG IDL service interfaces.

• A preliminary set of OMG IDL representations of the POSC Epicentre data types.

Because of time constraints, the team did not provide a comprehensive set of OMG IDL interfaces for all specified services. Submitters to the RFT have significant design flexibility in responding to the preliminary, high-level architecture specifications.

Additionally, RFT submitters should use the OMG IDL representation of Epicentre data types in their proposed IDL interface definitions where possible. Since these representations of the Epicentre data types are neither complete nor finalized, POSC will continue refining the OMG IDL representations of data types during the RFT submission period. In cases where the preliminary Epicentre data types are not appropriate or sufficient, submitters may supply their rationale for employing exceptions.

C.2.1 Architecture Context

The architecture provided to support E&P business objects must necessarily exist in the context of current geoscience software systems. An example of this architecture context is presented in the figure below.

Various elements presented in this figure are identified as follows:

• Stakeholder Views of Services - These views are presented to the different types of stakeholders on the desktop to work with in their domains.

• - A data transmission which need not be launched from the desktop (e.g., a remote acquisition operation) and which may require quality control operations prior to integration into a project data store.

• Data Transfer - A data transfer launched from the desktop that does not use E&P business objects and which may require reprocessing before integration into a project data store.

• Legacy Applications - Applications that were constructed with an existing API and data store. These applications are unaware of E&P business objects.

• Application 1, Application 2, Application 3 - Examples of application components that make use of the E&P Business Object Facility; these can be composites of business objects (e.g., virtual applications)

• Scrubbers / Mappers - Processes for extracting, transforming, enhancing, etc. data before these data are moved into shared storage. Note that mapping information between a POSC project data store and a POSC data warehouse is presumed to be a lighter weight operation than mapping to the warehouse from a legacy data store.

• Operational Data Store - A large, possibly volatile (end-user modifiable) data store containing data from or indices into registered data sources.

C.2.2 Architecture Scope

The objective of this RFT is to define an architectural layer for business objects and how they must be used to allow interoperability between applications.

The use of POSC Data Stores and Epicentre remains the preferred solution for permanent data storage. Nevertheless, having a common data model to share permanent project data is not sufficient to provide application interoperability. Moreover, legacy supplier application platforms must be accessible at the business object level. The objective is to standardize business objects and the architecture that will enable applications to interoperate by handling them. The E&P Business Object Facility (BOF) software layer will offer a set of services supporting real cooperation between applications. The E&P BOF will be defined formally as an E&P Life Cycle Object Model which will contain definitions of all services, i.e. object interfaces, and all universally available business objects (data, process, and presentation).

The figures below indicate a possible evolutionary path for using the E&P BOF. The first figure indicates how legacy systems could use the E&P BOF in the near term, with increased use of the E&P BOF and improved interoperability shown in the second figure for the longer term.

In the longer term, the legacy applications will migrate to use the BOF facility directly, with the legacy programming interfaces and data stores at the project level replaced by fully POSC-compliant products. The legacy data will still be present, but treated for the most part as data sources.

C.2.3 E&P Domains

Business objects reflect the structure and semantics of specific E&P business activities. In general, business objects are close in semantics to the needs of end-users and application software.

If the E&P industry is to receive the benefits of reusing business object definitions and sharing business object data, then it will be most efficient if fairly large groups of business activities can share well-defined sets of business objects. Therefore, the concept of E&P Domains is introduced.

An E&P Domain is defined to a subset of closely related business activities from the overall E&P life cycle. For each E&P Domain there will be a domain object model with a set of well-defined POSC business objects that can deliver a very high-level of information sharing and application interoperability.

The number of such E&P Domains should remain small to achieve an efficient balance between the objective of closely matching an individual business object's semantics to its intended use and the objective of facilitating information sharing and application interoperability.

The following is the initial list of E&P Domains:

• land and lease
• geophysical acquisition and processing
• subsurface (earth model) interpretation
• drilling
• facilities
• reservoir management

Some POSC business objects will be relevant to multiple E&P Domains. Some may be relevant to all of them. Business objects that pertain to multiple E&P Domains will be defined in the overall E&P Life Cycle Object Model and inherited into relevant E&P Domain object models.

Although information sharing and application interoperability within an E&P Domain will be closely coordinated, it will be still be possible for applications to interoperate and share data across them. This may require some effort to verify whether cross-domain compatibility.

C.2.4 Relationship to Proprietary Vendor Systems

Existing E&P application platform products are part of the context for this RFT. Most of them offer programming interfaces that allows data access and message communication. These interfaces are not standardized. In addition, the client code is closely related to the platform and must respect the highly exacting implementation constraints from its design.

The following restrictions to application communication exist in current E&P platforms:

• Industry applications are often considered client code.
• The functionality of the platform cannot be controlled.
• Most of the time, a programming interface is available only for data access and the data interface is not standardized.
• The programming interfaces have to be linked statically with client code.
• There is no standard inter-process communication layer supported.
• Most do not support threads.
• Most programming interfaces are non object-oriented.
• Data must be duplicated between the platform and an application. You cannot reference a single, shared data structure in the platform.
• The basic services are duplicated in each platform and do not provide common interfaces.

The objectives of this RFT is to standardize an interface for data access and service invocations based on distributed object technologies. The resulting specifications will enable vendors to build an object-oriented interface layer compliant with this architecture on top of their proprietary platforms. This layer will be accessible to applications through a standardized inter-process protocol.

C.2.5 Industry Standards

Submitters are expected to conform to standards appropriate to the E&P industry where possible. The following sections discuss important standards considered in developing this architecture.

Current POSC Standards

POSC's mission is to develop and maintain specifications for the integration of upstream petroleum data and applications. The specifications define requirements for POSC-compliant applications.

POSC has already published specifications for the following:

• Base Computer Standards: identifies systems environments that promote portability, interoperability and scalability of software across multiple computing environments, based on POSC specifications and existing industry standards.

• Epicentre data model: integrates elements from selected data models in industry into a single logical data model. Epicentre covers a broad spectrum of E&P disciplines. This specification defines the data models using an extended EXPRESS language and meta-model. The Epicentre data model is the basis for other POSC specifications

• Data Access and Exchange: defines the interface between applications and data management software, and how an application creates, queries, updates and deletes data that complies with the Epicentre Logical Data Model.

• E&P User Interface Style Guide: addresses issues of user interfaces needed by applications used by the E&P industry so that applications are consistent in appearance and behavior.

• POSC Exchange Format: defines a general data exchange format, for the transfer of information.

• Inter-Application Communication (IAC): addresses the need to establish standards for high-speed inter-application communication between applications developed by different vendors.

• CGM*PIP: defines extensions to the ISO Computer Graphic Metafile specifications specific to E&P requirements.

OMG Object Management Architecture

The chief mission of the Object Management Group (OMG) is to determine architecture and define a set of specifications, based on commercially available technology, to produce distributed integrated applications. Primary goals include the reusability, portability and interoperability of object-based software components in distributed heterogeneous environments. To achieve these goals, OMG adopts interface and protocol specifications that define an Object Management Architecture (OMA) that will support applications based on distributed interoperating objects.

The OMA architecture is based on a cooperative paradigm that allows applications to cooperate dynamically across the network. Current client server technologies separate the data storage from the application. They do not, however, separate the business logic from the application, user interface, and underlying technology. Also, they do not provide the appropriate architecture to support the multi-tier reality of business systems.

The objective of the OMG is to create an open infrastructure based on distributed objects to ensure application interoperability. The distributed object technology is well suited to creating cooperative systems because the data and the business logic are encapsulated within objects. This architecture allows the distributed objects to be located anywhere in the system. Thus, the granularity of distribution is improved allowing:

• software plug and play
• interoperability across the network
• portability on different platforms
• integration of legacy applications

The components of this architecture are the following:

• The object request broker (ORB) which defines the communication bus between the objects. It enables a program to launch queries to objects and receive the corresponding response transparently, irrespective of the objects’ locations. The program that issues the request may be procedure code or an object itself calling on the service. An ORB will link objects both statically (their interface is known at compilation) and dynamically (the objects discover the interfaces with which they collaborate at execution). It is consequently a far more advanced communication infrastructure than remote procedure calls for instance. Its chief advantages are as follows:
  • Invocation of static and dynamic methods: an ORB can therefore take advantage of both strong typing and the flexibility of late binding (capacity of invoking methods on different types of objects at execution).

  • Implementation with existing languages: IDL describes only the interface of objects. IDL mapping exists towards the main object development languages (C++, Java, Smalltalk, etc.) allowing the distributed objects to be implemented in the language of your choice.

  • Self-descriptive system: the object interface is stored in an interface repository that allows CORBA objects to determine the relevant interface for the objects they which to access. It is possible to record in the repository all the interfaces of the CORBA objects.

  • Transparency of location: the objects may be present in the process or spread over different processes. The ORB renders their location transparent.

  • Object design support: an ORB supports the object mechanisms such as heritage, polymorphism (capacity of a method to be invoked on different types of objects by accomplishing functionality suited to their semantics).

• The common object services which extend the object buses by framework objects: life cycle management (creation, deletion of objects), persistence (disk storage of objects), naming, events, relations between objects, … All these services are described in a specific chapter.

• The common facilities which define the application frameworks which can be directly used by the business objects:

• Horizontal facilities: user interface, composite documents, management of tasks and of the system, ...

• Vertical facilities: provide standard IDL interfaces in specific domains such as telecommunications, management, finance, exploration-production, and so on.

• Application objects, which are the business objects, are the final consumers of this infrastructure.

Submissions should reuse the OMG specifications as much as possible. The OMG architecture as the basis of the preliminary architecture. This RFT seeks to achieve specifications for an architecture that may be supported by E&P suppliers in the short term. This assumption means that the specifications of this architecture must be realistic in relation to existing technologies. The implementation of CORBA, as well as the IDL language, can be considered as workable today. OMG IDL is a good way for describing the interface of the services required to achieve E&P software interoperability.

CORBA Services

The OMG object services are collections of system-level services packaged as objects with an IDL interface. The OMG has recently published the CORBA Object Services Specifications. Most of them are now stable. The purpose of the services is to provide a set of standard interfaces in order to implement generic object services (persistence, life cycle, events, etc.). Many of these services are still not supported in CORBA implementation products.

It will probably adapt some of these services to ensure concrete, short-term solutions.

To date, the OMG has approved specifications for the following services:

• Naming
• Event
• Transaction: providing two-phase commit coordination among recoverable objects using either flat or nested transactions.
• Relationship: providing a way to create dynamic associations between objects and also mechanisms for traversing the links that group those objects.
• Concurrency: providing a lock manager that can obtain locks on behalf of either transactions or threads.
• LifeCycle: defining operations for creating, copying moving, and deleting objects.
• Persistence: providing interfaces for storing objects.
• Trader: providing a way to register a service with the related information (location, methods, parameters, etc.).
• Security: providing interfaces to manage security for distributed objects.
• Externalization: providing a standard way for getting data into and out of an object using a stream-like mechanism.
• Query: providing query operations for objects.
• Property: providing operations that let you associate dynamically named values to an object.
• Time
• Licensing
• Collection

Business Object Facility

Recently, the OMG published an Request for Proposal (RFP) for the specification of a Business Object Facility (BOF) and Common Business Objects (CBO). The RFP solicits proposals for the following:

• Business Object facilities: a dedicated infrastructure (application architecture, services, etc.) to support business objects operating as cooperative components in a distributed object environment.

• Common Business Objects: a set of business objects common throughout different kinds of businesses (E&P, Telecommunications, Manufacturing, etc.).

The OMG Business Object Facility will provide the interoperable infrastructure to support business objects as application components. The infrastructure will have the semantics to support business objects concepts. It will provide interfaces and patterns to ensure collaboration between business objects and the infrastructure to support plug and play. It includes:

• Interface and protocol between application components.
• Interface and protocol between application and any non-application components (user interface, web, etc.).
• Interface and protocol between the business object facilities and the existing CORBA specifications.

Initial submissions to the OMG BOF / CBO RFP were made in early 1997 by:

• Joint Business Object Facility: Data Access Technologies, Sematech, Prism Technologies, IONA Technologies
• IBM, Oracle
• EDS
• Genesis, Visigenic
• Technical Resource Connection
• SSA

Second submissions are due in November 1997. POSC is proceeding with this RFT process, but POSC is monitoring the progress of the OMG effort and will consider adopting some or all of the eventual OMG BOF specification at a future time. For now, POSC is focused on specifications for pragmatic solutions to ensure short-term implementations.

Microsoft Distributed Object Architecture

Microsoft has developed a de facto standard to manage distributed objects: OLE / COM / DCOM - ActiveX. The following discussion shows that this standard can be used in conjunction with OMG specifications. There are clearly identifiable equivalencies between the OMG concepts and those introduced by Microsoft. Consequently, there should be no major difficulty in implementing the resulting POSC E&P Business Object Facility specification using either of these technology approaches. Nevertheless, the OMG interface definition language and the CORBA services will be the basis of the POSC specifications.

COM is a binary object model with an interface definition language. It is language-independent, but tightly integrated with Microsoft's development tools. The objects expose their interfaces in a well-defined binary form. The reusability of these objects is based on aggregation and containment/delegation patterns. The QueryInterface method can be used to determine which interfaces an object supports. COM supports a reference counting mechanism for resource management. COM also allows clients and objects to ignore packaging and locality.

COM uses globally unique, 128-bit integer identifiers (GUID's) to identify object classes and their interfaces. These identifiers are The Open Group's DCE UUID's. A CLSID is a GUID that identifies a COM class to avoid name collisions. In the Windows Registry, COM maintains a mapping between each CLSID and the location of the DLL or EXE that implements the server for that CLSID. An OLE Control or OCX is a COM object that implements OLE Control interfaces.

ActiveX is Microsoft’s answer to Web interactive applications. It defines a set of interfaces to manage, among other things, distributed Web objects. ActiveX objects can be used on both the client and server. Client-side objects can execute in the context of an ActiveX aware Web browser, either as automation objects or controls. The Active Template Library (ATL) is a set of template classes for building lightweight COM objects and controls in C++. The improvements made by Microsoft to COM with COM+ will make it even easier for developers to produce distributed Web objects.

DCOM, which provides cross platform interoperability, is the distributed version of COM. DCOM is currently only available on Windows NT and Windows 95 platforms.

The following is a loose mapping between CORBA and COM based on work done by the OMG:

• The CORBA dynamic method invocation corresponds to the IDispatch interface.
• The interface repository and the meta-data defined in CORBA correspond to the type library.
• The CORBA interface definition language (IDL) corresponds to the MIDL Microsoft language.
• The implementation repository corresponds to the Implementation Registry defined by Microsoft.

  The following is the correspondence between CORBA services and Microsoft interfaces:

  • CORBA Event Service - Connections interface
  • CORBA LifeCycle Service - IClassFactory interfaces
  • CORBA Naming Service - monikers/repository
  • CORBA Persistence Service - IPersistStorage, IPersistStream
  • CORBA Versioning Service - versioning of Interfaces via GUID's
  • CORBA Transaction Service - Microsoft Transaction Server (MTS)
  • CORBA Concurrency Service - MTS
  • CORBA Security Service - DCOM Implementation may support any level of DCE remote procedure calls (MTS)
  • garbage collection - reference counting

C.2.6 Business Objects

Because the term Business Object has been used by different groups to refer to similar concepts which mean quite different things when examined in detail, its definition has become confused. This RFT document assumes the definition developed by the OMG, which is a specialization of their definition of an object. The OMG definition states:

"A business object is 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" [OMG, Business Object Management Special Interest Group (October, 1994)]

An important characteristic of Business Objects is that they represent things that an end user works with directly. End users select and access wells, create interpreted horizons and faults, cause velocity models to be built and applied. The ultimate goal is to provide medium-grained object components that behave more like “the real world does.”

Business Objects in the E&P Domain

The following work process illustrates the interaction of an end-users, a few potential business objects and some simple applications. In this example, the user has the objective: establish the well-seismic tie for a given well as input to the interpretation of seismic data in the vicinity.

The left column of the table enumerates the steps in the process as perceived by the user. The right column identifies the business objects and business object services which could correspond to the process steps. Potential business objects such as Well are underlined, business object services such as Trader Service are tagged with a bold font. The example is intended for illustrative purposes and should not be construed as a specification of either the business objects, the business object services or exactly how they will be used.

The current state is that the user has created a session and asserted a default coordinate system and units in which he wishes to work. In the first phase of the scenario the user identifies an area of interest and refines his selection based on geographic locality.

Work Process Illustration

Process Steps (User actions)		Possible Implementation
(1)Asserts geographical region and identifies required data types (wells, logs, seismic, cultural, velocity)		A DataSelector converts the region to appropriate coordinates, maps user data types to ServiceType’s and goes to Trader Service to find some objects such as seismic Volumes or QueryableCollections of objects such as Wells and WellLogs that satisfy both the geographical constraints and can return collections of the required data types.
(2) User narrows search based on advertised properties (some ad hoc), formulates a more specific query and requests results to be displayed on basemap.		DataSelector:  a) Finds Basemap presentation object in Naming Service (site default)  b) Issues query against corresponding QueryableCollection for Wells and cultural data and gets Collection's returned. The SeismicLines and VelocityModel returned by previous step are accessed directly  c) Accesses elements of Collection's and causes them to be plotted on Basemap. Coordinates are automatically converted to users preferred coordinate system using Coordinate Service.  d) Because some Well's may appear in multiple Collection's, use Identity to eliminate redundant Well's
(3) Identify specific well, seismic subset, and existing velocity model. A Line-of-section is created corresponding to the projection of well bore geometry.		DataSelector receives notification from Event Service that Well has been selected on Basemap. Uses Relationship to find associated WellLog's and present them to user with identifier attributes. Similarly selected SeismicSubset is retrieved.
(4)  User selects an appropriate display application for all of the relevant data:		Trader Service is used to find display applications which can be used in “plug and play” mode. If only one found, use it, otherwise allow user to select.
	a) seismic trace wiggles whose locations fall on or close to the identified line of section.	Get traces based on users coordinates (transformed using Coordinate Service)
	b) projected well path  c) selected logs  d) markers from projected well bore  e) dipmeter and azimuth data for well bore	Find Projection object (processing) from Naming Service. Use for (c), (d) and (e).
	f) seismic picks  g) intersecting surfaces for previously interpreted horizons.  h)