Request for Comments
DOCUMENT
|
Interoperability and Business Objects Request for Comments DOCUMENT |
Version 1.0a
May 9, 1997, revised May 14, 1997
Significant progress has been made by POSC on an integrated E&P logical data model and related specifications, but until recently the goal of delivering application interoperability to the business practitioner had not been explicitly addressed. Now, POSC is actively working to extend the POSC specifications to include higher-level business-oriented objects with agreed data attributes and operations for use as application components.
Use of such components will promote standard behavior in applications and facilitate sharing of information. The resulting application plug-and-play characteristics meet a long-stated requirement in the industry for application interoperability in an open vendor environment.
In addition to the business object components, both an overall architecture and supporting industry processes to support successful deployment will be specified. The architectural approach is intended to be consistent with cross-industry initiatives, such as those of the Object Management Group (OMG) and The Open Group (TOG).
This document states the goals and direction of this initiative and invites comment and wider participation.
Copyright © 1997 Petrotechnical Open Software Corporation. All rights reserved.
Notice: The information contained in this document is subject to change without notice.
POSC ®, Petrotechnical Open Software Corporation ®, and the POSC logo are registered trademarks, and Epicentre™ is a trademark of Petrotechnical Open Software Corporation.
Object Request Broker, OMG IDL, ORB, and CORBAare trademarks of the Object Management Group, Inc. Paradigm Plus is a trademark of Platinum Technologies, Inc. Rational Rose is a trademark of Rational Software Corporation. DCOM is a trademark of Microsoft Corporation.
Preface
1 Executive Summary
2 Problem Statement
3 Interoperability Requirements
4 Business Objects: The Key to Achieving Interoperability
5 Proposed Process
Appendices:
A. Glossary
B. Business Object Definition: Illustrative Sample
C. TNO's E&P Life Cycle
D. References
This document is a POSC Request for Comments (RFC) document. It is part of a process initiated in 1996 to pursue the aspect of the POSC mission that addresses interoperability. The RFC comment period closes on June 30, 1997. Comments received will be used to confirm and adjust the direction being taken in this work.
The primary audience for this RFC is the POSC membership, but comments are also sought from other organizations that have a strong interest in the subject matter addressed.
In order to maximize the value of the feedback, it is requested that comments from POSC member organizations be consolidated by each member organization's POSC Business Contact.
Because of the widespread impact that is anticipated to result from this POSC work effort, the RFC should be of interest to many E&P and IT disciplines, including:
The RFC presents material in four categories:
For the Problem Statement, please comment on whether you share the problems described. For the High-level Requirements, please comment on how important it is to you that the requirements be met; i.e. prioritize the requirements as vital, desirable, optional, undesirable. For the Technical Proposals, comment on whether each concept is clearly expressed. If so, comment on whether it is suitable to address the requirements. Even if a proposal is suitable to address a requirement, we welcome comments that propose a better solution approach. Your comments are also requested on the Process Proposals for developing the solution concepts into specifications and procedures that will lead to products and services that E&P companies can beneficially deploy.
POSC develops and maintains specifications that facilitate information sharing for use as standards for the benefit of the E&P industry. The current interoperability work effort is intended to result in additional components of the POSC Software Integration Platform (SIP) specifications. This RFC will be followed by a series of Requests for Technology (RFT's), that will result in published specifications and several POSC-managed procedures.
The planned RFT's include:
The proposed procedures include a process to manage a formal list of E&P domains, a process for business object registration and sharing, a specification change management process for E&P Domain Object Models and Business Objects, and a process for domain model extensions to be registered and shared.
We sincerely thank the POSC members who have participated in the workshops that led to this work effort and, especially, the POSC members listed here who have participated actively in the working meetings that began in November 1996:
The focus of the POSC Interoperability and Business Object work effort is to deliver consistent behavior among software components, 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 six years. Corporate and project 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. Application developers will have a shared industry-developed architecture to use. There will be shared data definitions more suitable for specific use by end-users and supporting applications. There will be guidelines and techniques for integrating legacy applications and data sources into POSC-based computing environments.
This Request for Comments (RFC) establishes a baseline of definition for interoperability and a process through which the E&P industry can achieve its benefits in an evolutionary manner. Widespread interoperability within the E&P community will take a number of years to achieve. Six broadly defined levels of sophistication of interoperability will be presented as a guide for aligning this work.
The maturation of object technology in general, and distributed object technology in particular, is noted. This is being followed closely by an effort to define and support independent software components -- objects -- that reflect aspects of business processes. These components are referred to as business objects. The work that has been done by POSC's members and staff over the past year leading up to this RFC has convinced us that business objects are key to achieving interoperability.
Section 4 of this document elaborates 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 is working concurrently with the RFC comment period to begin to define an architecture that supports business objects and facilitates interoperability.
The feedback from this RFC will be evaluated critically to ensure that this work effort is on the right track. Presuming positive feedback, a series of Requests for Technology (RFT's) are planned to follow. The first two RFT's will be issued in July for submission at the end of this year. One will request that the proposed architecture be completed, tested (through actual implementation), and refined to form a future POSC specification. The other will request an initial set of business object definitions for one of six proposed E&P domains -- subsurface interpretation. These RFT's, together with supporting POSC procedures, will allow business objects to be defined in the context of a workable software architecture. The illustration below identifies the timing for this RFC and the proposed timing for two follow-on RFT's. See Section 5 for more information about future plans. Following these RFT's, application suppliers will have the opportunity to develop and deliver interoperable products based on the resulting architecture and subsurface interpretation business objects.
Future RFT's will request business object definitions for other E&P domains and additional business object definitions for the subsurface interpretation domain. The architecture 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-maintained shared industry specifications.
As for all POSC initiatives, active support and participation from the member organizations is essential. This is certainly true for this initiative to achieve interoperability. Please encourage your organization -- whether you are a POSC member organization or not to review the RFC and to prepare constructive feedback. Please respond to these questions:
The ultimate challenge is to manage this work effort for the benefit of the POSC members and the benefit of the industry as a whole. This Request for Comments is a key element of POSC's open process, designed to meet that challenge. We look forward to your comments and your encouragement for this work.
Interoperability refers to the idea of cooperation among a group of application software components. This is a subjective characteristic of which different stakeholders may have different views. The primary stakeholder is the end-user of the applications and, in the final analysis, the end-user will decide whether a collection of applications work together well enough to meet the user's productivity requirements.
In many domains of interest an end-user (or a team of end-users) work in the context of a project and simultaneously use applications which are manipulating and displaying the very same data. These applications may have come from different vendors and may be sharing data in different ways. The applications are most often run interactively and are initiated directly by end-users. Without sufficient interoperability, end-users may have to ask support staff to run specialized data reformatting utilities to move data between the applications of different vendors. This burden adds great inefficiencies to the work processes.
The end-user will judge the adequacy of interoperability based on whether the collection of applications behaves as a single integrated application, a virtual application as it were. Specific aspects of the goal of interoperability are:
The importance of interoperability to end-users has been growing. Traditionally, most end-users were involved with essentially linear work flows and had need of perhaps one or maybe two workstation applications. The traditional interoperability requirement was framed in terms of the length of time required to reformat the data from a previous process so that it could be used in the next. Several things have changed that situation:
Each of these trends has changed the linear work process flows into a series of iterative and (partially) overlapping flows. In iterative flows, the effort to reformat data and to perform data exchange operations becomes significant. The situation can be further aggravated by the desire of end-users to choose application components from different vendors when customizing workflows to meet specific business needs. End-users desire a "plug and play" style of application purchase and use.
Thinking of the entire E&P application/development environment, there are clearly other stakeholders who have important views about interoperability. Corporate data administrators take an asset life cycle point of view. They want cooperation among software components that:
These requirements complement the end-user interoperability requirements. These requirements focus on data integrity and robustness.
One way to achieve these aspects of interoperability is the use of a single data model and, possibly, a single data store implementation, such as those based on current POSC specifications. This raises the question: is it feasible for all applications to use a single data model / data store directly? The answer appears to be negative. Consider some of the characteristics of a single data model / data store for the complete E&P asset life cycle:
In order to address the interoperability requirements of both end-users and data administrators, it will be necessary to provide more flexibility that can be achieved with the direct use of a single data model / data store. If it makes sense from an end-user point of view, then there must be the ability to incrementally change some components (either applications or data models / data stores) without wholesale replacement of other components. Such changes are inevitable because applications, data models, and data stores are all subject to upgrades to new versions.
The examination of the end-user and data administrator views of interoperability yields this important criterion of the ability for incremental, partial replacement.
From an end-user's perspective, the array of components he/she uses is more complex (Figure 1) than one might expect from a traditional two-box application / data base architecture diagram.
The end user has to cope with:
This complexity comes about because the end-user works in an environment whose infrastructure is continually changing. Fundamentally, this is true because each application or application suite and each data store come with their own infrastructure. The end-user's environment may never reach the theoretically desirable end-point of a single corporate data store, a single project data store and a set of applications which all work on the same project data store.
It is clear that most new E&P application software will be developed using object technology. Therefore, we can speak about the sharing of objects as a form of interoperability. Alternatively, we can speak about virtual applications as being made up of interoperable objects. The scope of sharable objects can be inferred from the requirements for interoperability presented above as including data (from data stores and other), viewers, cursor locations, and others. Figure 2 illustrates some fundamental types of objects. It also depicts the relationship between objects and persistent data from a data store.
Achieving overall interoperability, then, requires defining an architecture that supports the sharing of objects and supports a formal relationship between objects and data stores. Sharing through objects delivers interoperability within a user or group session, i.e. end-user interoperability as described in Section 2.1 over a narrow group of related business activities. Sharing through a data store delivers asset life cycle, data-related interoperability within a wider range of business activities, i.e. the scope of the data store that may be a project, an asset, or a larger business scope as described in Section 2.2.
The basic elements of the current situation regarding interoperability:
Widespread interoperability within the E&P community will take a number of years to achieve. Considerable effort has been expended in reaching this goal, e.g through the work of POSC, but there is still much work yet to be identified and completed in this area. This work can be iterative, with useful results beginning early in the process.
Given this, it is helpful to categorize interoperability into levels of capability that can be staged over time, i.e the more sophisticated interoperability capabilities may take longer to achieve. This allows requirements to be prioritized by capability and implicitly provides a time scale for their implementation.
This section defines levels of interoperability of applications according to their capabilities based on how many and how completely the characteristics identified in Section 2 are supported. The interpretation should be that increasing levels support more software plug-and-play, more data sharing, and more integrated virtual applications. Given the focus on concurrent interoperability of applications, a level characterizing linking applications via data exchange is not defined here.
These levels are tied to requirements. The definitions of capabilities and requirements are not intended to be rigorous. They are intended to refine the concepts of Section 2 and to provide a starting point for specifying an extensible architecture.
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:
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:
Capabilities: Application components can request to be notified when the contents of data objects encapsulated by servers change. From a users perspective, actions taken in one application can dynamically cause actions to take place in another. This is the beginning of realizing virtual applications.
Requirements:
Capabilities: Applications can share process or presentation objects/servers such as GUI's. Users can control aspects of multiple applications through a common interface. Because the interfaces are standard, users can expect plug-and-play for some process objects as well as data objects. Users get a standard look and feel from applications developed by different suppliers.
Requirements:
Capabilities: System integrators can create virtual applications which have components from different vendors and may be customized to end user work processes. Once created these virtual applications can be reused.
Requirements:
Capabilities: End-users can produce virtual applications as in Level 4 either directly or using composition tools.
Requirements:
The architecture should define standards to enable and promote
interoperability. Achieving the capabilities at all levels of interoperability
should not restrict the suppliers of E&P software to compete. In
particular:
A use case is a description of what a person does, uses, or sees in an existing or planned business role. Use cases allow one to describe, in natural language, the expected usage of an application and by so doing define many key requirements. It is proposed that use cases serve as the starting point for further refinement of the technical requirements of any proposed solution.
Thus far, we have examined various dimensions of application interoperability. We have recognized the likely use of object technology in future E&P software development and we have proposed that an architecture be defined to enable the broad realization of the requirements for interoperability. In this section, we will discuss the concept of business objects as defined by the work of the Object Management Group and we will propose to use business object concepts in addressing the interoperability requirements.
We propose that business objects can be an essential part of a solution to the interoperability requirements.
Having said that, the challenge is to complete the definition of an architecture based on defined, sharable business objects for application developers to use in products.
The architecture also must allow new applications that exploit business objects to co-exist and interoperate (at some level) with existing data stores and applications. A solution that requires a wholesale rewrite of all existing applications is unacceptable. The solution architecture must provide for incremental steps with results that are useful to end-users. The reasons for this are:
This section presents the key concepts used in the remainder of this document. Basic definitions for terms presented in bold can be found in the Glossary. Extended material that addresses the relevance of the concepts to the current work effort is presented here.
Of the four object characteristics (identification, encapsulation, polymorphism, and inheritance), the most relevant for this work effort are encapsulation and polymorphism. They allow objects to present a common interface for something (Well for example) and hide whether the data is stored in a POSC data store, a proprietary project data store, or flat files.
An object's behavior may be minimal if the object's internal data maps directly to its methods. An example might be attributes of a well. In other cases the object's primarily behavior may not make its internal data visible at all. An example of this is a property object that uses interpolation to present discretely sampled properties as a continuum. The internal representation may not be visible in the object's interface.
An important characteristic of distributed object technology for interoperability is support for late-binding interfaces.
For the rest of this document, the term object will refer to a distributed object as defined by the OMG. The differences between this definition and that used by Microsoft in their DCOM technology may be relevant in the implementation of a solution but not in the formulation of the requirements.
4.1.2 Business Object
We can think about a business object as being defined in a middle-level of an architecture between application components and data store components, for example. Business objects are typically defined with a scope that closely matches the applications that use them rather than at the level of underlying data store's logical data model entities, such as those of Epicentre. Business objects do embody similar building blocks to those found in the Epicentre and DAE specifications, such as data types, reference values, transaction behavior, and support for units of measure, coordinate systems, etc.
Business objects 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, etc. Business objects may be defined to address things that are not traditionally part of an underlying data store's logical data model, such as work environment elements, work project descriptions, catalogs of data, cursor locations, and specific presentations of data. No matter what their substance, business objects still obey the basic principles of encapsulation and polymorphism. As long as standard interfaces are defined for business objects, they can be shared and used in a plug-and-play manner.
Business objects participate in object models along with other kinds of objects.
More discussion can be found in Section 4.8 about business objects and their intended role in supporting interoperability.
4.1.3 E&P Domain
In this work, the term E&P domain has been introduced to represent one of a set of well-defined scopes within the E&P asset life cycle for which high levels of interoperability is desired. E&P domains correspond to collections of closely related business work processes. The work processes of an E&P domain determine the kinds of applications that are required. It is proposed that a set of related business objects be defined in the context of each E&P domain. Thus, an object model will be defined for each E&P domain. It will be called a domain object model. Interoperability between business objects can be assured only when business objects have defined behavior and relationships, e.g. in an object model.
The E&P domain approach to business object definition should allow an optimal trade-off between the goal of defining a small number of business objects in each domain object model and the goal of defining business objects that are not too complex and, therefore, difficult to use. The E&P domain approach should allow for a managed process of incremental growth of the domain object models and business object definitions over time.
The number of E&P domains must remain relatively small to achieve an efficient balance between the objective of closely matching individual business object semantics to its intended use and the objective of facilitated information sharing and application interoperability.
The following is the proposed list of E&P domains. This list (content and order to be addressed) is subject to change based on feedback to this RFC. Readers of this RFC are specifically requested to comment on their level of interest in participating in the development of domain object models and business object definitions for specific E&P domains.
Some business objects will be relevant to multiple E&P domains. Some may be relevant to all E&P domains.
Although information sharing and application interoperability within an E&P domain is well planned, it will be possible for applications to interoperate and share data across E&P domains. This may require some effort to verify whether cross-domain sets of business objects are compatible. In some cases, it may require sharing data through data stores or via data exchange.
It is end-user perception of requirements that drives the identification of appropriate candidate business objects. Furthermore, the end-user requirements for what is to be done with a business object, as reflected in application requirements (acting as an agent for the end-user) determines the appropriate business object interface definition. These interfaces may be subject to various constraints, such as: there must be way of implementing a business object over a source data store, e.g. a POSC data store based on Epicentre.
The role of the end-user in defining specific business objects leads to a distinct design approach. In the case of business objects, the process is essentially a moderated top-down approach in which requirements are gathered at a high-level of abstraction and then refined to define a set of high-level interfaces. Once this is done, implementers are then subject to the constraints in the business object definition.
Contrast this with the bottom-up approach used to develop integrated logical data models. Detailed relationships between data elements are defined and then abstracted up to low-level interfaces, such as DAE.
One difference between the two is that in the top-down approach, extra detail must be justified as useful to be included, whereas the goal for the bottom-up approach is to allow as much flexibility as possible. See Figure 3.
Note that there are data models associated with each level of abstraction, an internal data model for business objects and the explicit data model at the data store level.
There are no fundamental conflicts between these approaches so long as:
See Section 4.8 for a description of the proposed procedure for defining business objects.
For this discussion, the term corporate data store refers to a data store that manages data but does not provide direct access for end-users and technical applications. Data quality issues (completeness, non-redundancy, integrity, etc.) are very important for corporate data stores. Corporate data stores can be managed successfully without the same kind of architecture solution that will be developed to meet the requirements of application interoperability, i.e. without business objects.
Although not necessary, concepts like business objects and E&P domains may prove to be valuable in building corporate data management procedures, utilities, and applications because of the higher level of semantic content they provide. It already has been stated that it is necessary for business objects to have a semantically equivalent mapping with Epicentre. That will ensure that business objects and corporate data stores based on Epicentre will support both read and write operations properly. If this were not the case, then there could be problems with the integrity of data provided through business objects or with the integrity of corporate data stores updated from business objects.
The need for integrity-preserving mappings between business objects and data stores extends beyond Epicentre-based POSC data stores to situations where corporate data is managed in multiple data stores and/or files, e.g. separate data stores for different disciplines, separate data stores for bulk data types, etc. The successful use of both business objects and corporate data stores requires dependable, well-defined mappings.
The interoperability-oriented architecture may contribute to ways of addressing the problem of coordinating corporate data stores with project data stores. For this discussion, the term project data store refers to a data store that supports active, direct use by end-users and technical applications. The nature and extent of this problem depends on the data management architecture adopted by each E&P company. Some companies are moving to an asset data store approach in which there will not be separate corporate data stores and project data stores. Many companies advocate a dual data store approach, but the frequency of synchronization and the degree of duplicate storage vary from one company to another.
Figure 4 illustrates one possible situation in which a corporate data store is operating in a synchronized manner with several E&P domain focused project data stores.
.
Project data stores are an essential component in an architecture for application interoperability. The need for a semantically equivalent mapping between business objects and an Epicentre-based project data store has already been discussed. Clearly, semantic consistency would be needed between business objects and any project data store.
Figure 5 illustrates a situation in which three Well business object instances have been produced from three different project data stores / files. The applications shown use one interface to interact with all three instances even though the implementation of the business object knows how to apply the business object behavior to each of the project data stores, exhibiting polymorphism. This is an example of data store federation. That means the composition of the content of multiple data stores into a single, virtual data store.
Such federation is an important goal of an interoperability-supporting architecture. To achieve effective federation, however, will require policies to be defined and implemented to address gaps, overlaps, and inconsistencies between the individual project data stores. The formal definition of domain object models should provide a good foundation for defining and implementing federated mappings.
Figure 6 shows the relationship of business objects to existing applications that may access a project data store directly. The compliant, business object based application accesses data through the well business object interface. Whereas, the existing application accesses well alpha directly from the project data base.
This parallel access situation is not a problem if both accesses are read-only. If updates are involved, then mechanisms for synchronizing the applications in a way that meets end-user expectations must be used. Such a mechanism may be either transparent or under end-user control. The key point is that some forms of interoperability can be achieved with existing applications.
Figure 7 illustrates the generation of transient data as a result of the interaction of applications and business objects. Transient data is defined here to mean data that is generated and used within an active session but is not intended to be preserved permanently in a data store. Business object definitions will allow for transient data to be defined. Such data need not participate in data store mappings.
The introduction of an interoperability-oriented architecture that supports business objects offers a lot of flexibility in terms of accommodating existing applications and existing data stores. At the same time, the advantages to E&P companies and to the industry as a whole of migrating to a common logical data model and consistent data store implementations remain attractive. The flexible architecture and the common data model are, in fact, complementary goals. Each one helps the other.
The successful achievement of greater interoperability by using business objects depends on consistent and comprehensive business object definitions. The experience gained through the development of Epicentre and the related POSC specifications can contribute much to this goal. The principles of domain object models and semantically equivalent mappings with Epicentre are key to its success.
On the other hand, the flexibility that allows existing applications and data stores to participate in the interoperable architecture should accelerate migration to POSC specifications because migration can take place on a planned, incremental basis.
Some may wonder whether an asset life cycle logical data model, such as Epicentre, will still be relevant once a complete, interoperable architecture with business objects has been achieved. The answer is YES. The interoperability across E&P domains and among projects will require an asset life cycle data model and data stores. The proposals described in this RFC complement, but do not replace, the specifications already defined by POSC.
This section discusses preliminary ideas about how to define business objects in the context described earlier in the RFT. Fundamentally, a business object must be defined with a focus on what it is expected to do and an awareness of the environment in which it will live. This includes considerations, such as:
The proposed process is iterative and consists of two parts:
As introduced earlier, a domain object model is a representation of an E&P domain in terms of all of the object classes (service classes, business object classes, etc.) available for use by application components operating in that E&P domain. Each domain object model includes both object classes inherited from the overall architecture and object classes defined specifically for the domain.
It is intended that commercial products will implement domain object models and will be sold as infrastructure products to application developers and integrators.
The representation for a domain object model is proposed to be in the Unified Modeling Language (UML) as defined by Rational, Inc. and as submitted to the OMG Request for Proposal on Object Analysis and Design. UML is an interim recommendation, subject to final adoption by the OMG and pending the results of our work with UML. Comments are specifically requested on this technology recommendation.
Guidelines for the use of UML in defining domain object models will be developed as this work effort proceeds.
As discussed earlier, our definition of a business object is based on the definition of the OMG. We propose a five-step process to develop a business object definition:
During each step, information is placed in the corresponding portion of the business object definition template (See section 4.8.3 below.). The definition elements are refined through iteration.
Since the most important responsibility of a business object is to carry the data and operations needed to support business activities, this process begins by recognizing business need. This requires an understanding of the business activity, current and potential application components to link end-users, business objects, and other services with the required business logic, algorithm, etc. This step of the procedure should be focused on defining meaningful use-cases that characterize the intended purpose of the newly defined business object.
Although all of the required elements of the business object definition template (See section 4.8.3 below.) for Step 1 should be recorded at this step, it is expected that the definition elements will be refined and made more precise during the following steps.
In developing this proposed definition process and template, it is critically important to understand and express the intended use of the business object even at this first step in the process. There are many technical decisions to be made in the following steps. These decisions require a clear statement of the business-oriented requirements.
In the work done so far, we have found the E&P Life Cycle definition of TNO to be useful to qualify the scope of use of a business object. See the Appendix for a summary of the TNO E&P Life Cycle definition.
This step has been included to identify the relevant portions of Epicentre in preparation for Step 4 when formal mappings with Epicentre are defined. The suggested level of detail used in this step is the Epicentre diagram as published in the Epicentre specification and in the Browser.
The central step of business object definition is the definition of the external object interface, i.e. the attributes and operations that are visible and usable by application components and shared services. This step is accomplished with two activities:
Guided by the use case(s) defined in Step 1, it must be determined how the business object will serve application components. In general, objects can serve by delivering information defined as object attributes and/or by performing operations.
As this work effort continues, it is anticipated that many guidelines and design patterns will be determined to help in the definition of high quality business objects. Such guidelines must be tested and verified in actual use.
The decisions made about the attributes and operations provided by a business object are encoded in OMG CORBA IDL. This forms the specification used by application components when initiating interaction with any implementation of the business object. OMG has defined bindings for IDL in C, C++, and other programming languages. OMG is in the process of defining a Java binding as well.
At this point in the definition process, the business object should be recorded on the domain object model. If this is done using an object modeling technique, such as UML, and a comprehensive object modeling tool, such as Rational Rose or Platinum's Paradigm Plus, then the IDL definition for each business object can be generated from the domain object model documentation.
In general, implementation specifications for business objects can be left to implementers without compromising the ability of application components to run successfully on diverse implementations. To complete a business object definition, however, some implementation specifications are required to ensure that implementations over Epicentre-based POSC data stores are effective and consistent. The use of these specifications will help ensure interoperability at the POSC data store level, i.e. a consistent use of Epicentre in all implementations of a business object.
To ensure the effectiveness of using business objects together with POSC data stores, there must be a semantic equivalence between the business objects' internal data models and Epicentre. This means that mappings must preserve content and meaning as data is transferred in either direction.
The internal definition consists of three parts:
The internal data model defines the data required by an implementation to supply the attributes and operations defined in the interface. This specification is not specific to implementations using Epicentre-based POSC data stores.
The internal data model to Epicentre mappings define the specifications for populating business objects from Epicentre-based POSC data stores and for updating Epicentre-based POSC data stores from business object content. These mappings are defined at the attribute level. The mappings can consist of direct correspondence between attributes. They can contain complex, but well-defined, transformations as well.
The mappings will demonstrate the semantic equivalence between the business object definition and Epicentre, i.e. an identical expression using a common dictionary and an explicit formalism. Data can be alternately described in terms of either the business object definition or Epicentre. Therefore, data can be transferred back and forth without content loss. As described in Section 4 above, semantic equivalence does not exclude automatic processing defined as part of the mappings.
Semantic equivalence deals with data-related business objects, as opposed to process, presentation, or other kinds of objects. The use of such business objects is intended to result in simplifying an application's use of Epicentre to facilitate interoperability as compared with a direct application - Epicentre interface. Semantic equivalence ensures that the same business concepts are used in the business objects as in Epicentre, recognizing that business objects can be defined to overlap with each other.
The advantages of defining mappings between business objects and Epicentre can be summarized as:
It is proposed that definitions of the internal data model use the Epicentre-style of the EXPRESS information modeling language (ISO 10303.11). This will facilitate the definition of mappings with Epicentre using a (draft version) of the formal mapping language being developed for EXPRESS by ISO, EXPRESS-X. Developers of implementations to other data stores may find it useful to adopt EXPRESS-X for the mapping definition. To do so, a straightforward translation of the other data store's data model to EXPRESS must be made. (Note: EXPRESS-M and a similar mapping language called EXPRESS-V have both been used for EXPRESS mappings. Neither of these is recommended because work on them has been stopped in favor of completing work on the EXPRESS-X mapping language. Current tools that support EXPRESS-M are likely to be converted to EXPRESS-X.)
The number of mappings that must be defined depends on the breadth of functionality defined into the operations (methods) of the business object. It is anticipated that a single read mapping may be sufficient for all read behaviors, including supplying values for attributes. If the business object has update behavior to the underlying data store(s), then one mapping will be required for each distinct update behavior. EXPRESS-X appears to be suitable for mapping definition in both directions -- read and write.
As the business object definition illustration (See Appendix B.) shows, mappings to and from Epicentre will make use of a set of utility services. These services will take on many of the more common and more complex tasks of the mappings, such as searches conditioned by local preferences. As this work continues, many design patterns and utility services will be defined to make mappings more precise and easier to define. These utility services will also make implementation of the mappings more effective. Most of the mapping utility services defined for Epicentre will also be useful for defining and implementing mappings with other kinds of data stores.
It may be found useful to define the footprints in Epicentre corresponding to the mappings. Until now, the representation of an Epicentre footprint has most often been accomplished using EXPRESS-I, a formal language based on EXPRESS used to document actual data stored according to an EXPRESS-defined information model. Experience will show whether defining footprints separately is useful and whether the current EXPRESS-I technique is the best way to do so.
The final step in the business object definition process is to validate the definition by writing an illustration of how it will be used. This usage illustration should manifest the use case(s) defined in Step 1. Techniques for doing this could include writing pseudo-code for using application component(s) and sequence diagram(s), such as those of UML, to portray the details of the usage, including the use of shared services.
From Step 1:
From Step 2:
From Step 3:
From Step 4:
From Step 5:
Our conclusions are that:
Our strategy is to:
This section describes the proposed process to achieve the goal of application interoperability. The proposed process is a refinement of the POSC open processes used in the past. The key aspects of the proposed process are:
This RFC is the product of POSC member and staff efforts that began with a small workshop with oil company and application supplier members in February 1996. This was followed by a series of two one-day member workshops in July and September. These workshops led to a recommendation to form a continuing work effort to work approximately one week in five to clarify the intent and requirements for realizing interoperability and to propose follow-on steps. Four working meetings have been conducted - in November, December, February, and March.
The February meeting resulted in an agreement to produce and issue this Request for Comment (RFC) to be published in the second quarter of 1997. Between the February and March meetings, there was discussion about accelerating the work effort. At the March meeting, work progressed to draft this RFC and a dedicated sub-team was formed to develop a draft architecture. This will form the technical core of a follow-on POSC Architecture Request for Technology (RFT). The dedicated sub-team is due to deliver results by the end of May. Comments from this RFC will be used to validate the work performed by that time and to guide future work. The RFC comment period ends June 30, 1997.
The proposed forward plan is summarized here and explained greater detail in the remainder of this section:
Note that the dates stated here are subject to change depending on the nature of the feedback received on this RFC and on the availability of adequate resources to carry out each work activity.
The dedicated sub-team has recently presented a high-level preview of the interoperability-supporting architecture they are developing. In concert with parallel work going on in the Object Management Group, the set of services intended to support business objects is called a Business Object Facility (BOF). (See Figure 8.)
The purpose of the RFT on the POSC Architecture is to define how E&P software components (applications, shared services, business objects, infrastructure components, etc.) can facilitate information sharing and application interoperability. The architecture specifications will build on the results of this RFC and on the work of the current architecture sub-team. The architecture specification will link with all other POSC specifications. The architecture will address interoperability of newly written software components as well as opportunities to build-in some degree of interoperability with existing systems. Submissions that are based on actual implementation experience will be given strongest consideration. Submissions will be expected to complete and improve the draft specification as published in the RFT.
These are the key milestones for this RFT (See illustration.):
Submissions must be made so that POSC has the right to use the submitted material in formulating the architecture specifications. This will enable POSC to form a joint staff/membership evaluation team. Guidelines and procedures for the evaluation process will be published in October 1997 when the call for nominations to the evaluation team will go out. POSC will select the evaluation team from the staff and from the member nominees based on stated criteria for team composition and skill requirements. The evaluation team will be asked to make a unified recommendation to POSC. The recommendation could range from adopting one of the submissions, to combining the best aspects of several submissions, to augmenting the submissions with additional collaborative work, to rejecting the submissions and restarting a revised process. POSC will act on the recommendation of the evaluation team in the best interest of the membership.
All submissions will be made available to members for review during the evaluation process. In addition, POSC will conduct a submitter forum during which each submitter may make a presentation to the evaluation team and the membership at large.
The first in a series of RFT's for E&P Domain Object Models and Business Objects will be for the Subsurface Interpretation Domain. This E&P domain was chosen to be addressed first based on the high level of interest in this area expressed by the active members who have been contributing to the work effort.
This and each subsequent E&P domain RFT will seek a defined domain object model with a collection of business object definitions. It is anticipated that the results of this RFT will be sufficiently complete to enable meaningful applications to be developed. Additional RFT's for the same E&P domain may be issued in the future to expand the scope of defined business objects.
The procedures and key milestones for this RFT coincide with those of the RFT on POSC Architecture so that there can be assurance of compatibility between the architecture and the first E&P domain object model and business object definitions. There will be one coordinated evaluation team recommendation on both RFT's.
Presuming a positive recommendation from the evaluation team and acceptance of the recommendation by POSC, the specifications for the architecture and subsurface interpretation domain will be published in the second quarter of 1998. These specifications will then become part of the overall POSC SIP specifications and will be supported and enhanced based on member requirements.
At the same time, POSC will institute ongoing procedures to support the new specifications. It is anticipated that these will include:
POSC member organizations will be able to submit business object definitions. These definitions will be examined to ensure that they agree with the content template and usage guidelines contained here and in subsequently published POSC specifications and guidelines. Definitions that are accepted will be posted on the POSC Web Site for public access.
POSC will also manage an email discussion list concerning registered definitions. Members will be encouraged to share their business object definitions in the POSC registry. Business object definitions submitted in response to subsequent E&P Domain Object Model and Business Objects RFT's that have been registered and have received favorable comments from members will be considered strongly for standardization.
This process will be initiated in trial form beginning in the third quarter of 1997 to encourage members to begin to define and share business object definitions.
A similar process will be initiated to encourage members to share their own extensions to E&P domain object models. A domain object model extension will consist of a revised domain object model for one of the E&P domains defined by POSC along with additional or modified business object definitions.
Registered extensions will be considered for future versions of the domain object models.
Aside from the normal support and enhancement process on the architecture, subsurface interpretation domain specifications, and procedures, RFT's for other E&P domains will be conducted on the basis of a strong interest shown by the membership. These RFT's will follow a similar process to the first one.
A joint staff-member work effort will be initiated to draft the RFT. A joint staff-member evaluation team will be organized to recommend action on the submissions.
If not already done by the time of their publication, there should be an update to the POSC Base Computer Standards (BCS) to reflect and support the architecture and E&P domain/business object specifications.
The Glossary is organized in these four sections to help the reader understand the source of the terms and definitions.
"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).
As this work effort proceeds, the names and descriptions for various kinds of business objects will be refined and guidelines for their definition will be specified.
What follows is an example of a business object definition. It contains most of the required elements, including a read mapping and an update mapping with Epicentre. There is also an example of a parallel read mapping for the Geoshare Data Model (GDM). The Geoshare mapping is built on work that was done by the Geoshare Epicentre Mapping Special Interest Group (GEMSIG).
To illustrate the principle of semantic equivalence presented earlier in the RFC, the first sample mapping contains the following fragment:
(* Establish instance map using helper
function, GET_INSTANCE, and object-provided
preferences.* )
(* NOTE: This mapping has a semantic equivalence problem
illustrated below when the lack of a wellbore component in the
business object was handled by forcing the selection of the first
(value=0) wellbore for the selected well. *)
VIEW bw : target::basic_well;
FROM (w : source::well, wb : source::wellbore)
WHEN ((w IN GET_INSTANCE (preferences,
"WELL_BY_IDENTIFIER"))
AND (wb = w.wellbore [0]));
As shown, the mapping fails to be semantically equivalent with Epicentre because the business object does not contain the concept of wellbore. The mapping has attempted to deal with this by always choosing the first wellbore for a well. The proper correction of this problem would be to augment the business object definition with a wellbore attribute.
The second sample mapping illustrates rudimentary update behavior of a reference value in the Well entity.
From Step 1:
From Step 2:
From Step 3:
enum well_status_list {proposed, permitted, drilling, drilling_suspended,
active, suspended,
temorarily_abadoned, ... };
interface basic_well {
readonly attribute string identifier;
readonly attribute well_status_list status;
readonly attribute point2d surface_location;
readonly attribute point1d total_depth;
readonly attribute country well_country;
readonly attribute operator well_operator;
void update_well_status (in well_status_list new_status);
};
From Step 4:
SCHEMA basic_well;
ENTITY basic_well;
identifier : STRING (40);
status :
ref_well_status;
(* surface location elements *)
surface_coordinate_system : STRING(40);
x_coordinate : REAL;
y_coordinate : REAL;
x_units : ref_unit_of_measure;
y_units : ref_unit_of_measure;
(* total depth elements )
depth_coordinate_system : STRING(40);
z_coordinate : REAL;
z_units : ref_unit_of_measure;
country : ref_country;
operator : STRING (40);
new_status: ref_well_status;
END_ENTITY;
(* These TYPEs correspond to
Epicentre reference values. *)
TYPE ref_well_status
= STRING (40);
END_TYPE;
TYPE ref_country
= STRING (40);
END_TYPE;
TYPE ref_unit_of_measure
= STRING (40);
END_TYPE;
END_SCHEMA;
<This is not provided for this example.>
From Step 5:
<This is not provided for this example.>
<This is not provided for this example.>
For the example of the read behavior (for use case 1) of "Basic Well", the Epicentre mapping might be written in EXPRESS-X as follows:
(* This schema defines data used by the object implementation to
support this mapping )
SCHEMA basic_well_from_Epicentre;
USES basic_well FROM basic_well;
(* A rudimentary specification of preferences to apply to the mapping,
e.g. for selecting one from many, for resolving units / coordinates. *)
ENTITY preferences
preference_category : STRING (40);
preferred_thing : SET OF thing;
UNIQUE si : preference_category;
END_ENTITY;
(* For example, a preferences construct could be used to
specify the selection of one operator from many by choosing
the one with the largest production volume, one total depth from many by
choosing the deepest, etc. *)
TYPE thing =
SELECT (e_and_p_data, ref_data);
END_TYPE;
END_SCHEMA;
(* Mapping to load business object from Epicentre-based POSC data store.*)
SCHEMA_MAP basic_well_Epicentre_1;
GLOBAL
DECLARE source INSTANCE OF Epicentre;
DECLARE target INSTANCE OF basic_well;
END_GLOBAL;
(* Establish instance map using helper
function, GET_INSTANCE, and object-provided
preferences.* )
(* NOTE: This mapping has a semantic equivalence problem
illustrated below when the lack of a wellbore component in the
business object was handled by forcing the selection of the first
(value=0) wellbore for the selected well. *)
VIEW bw : target::basic_well;
FROM (w : source::well, wb : source::wellbore)
WHEN ((w IN GET_INSTANCE (preferences,
"WELL_BY_IDENTIFIER"))
AND (wb = w.wellbore [0]));
BEGIN_VIEW
bw.identifier := w.identifer;
bw.status := w.ref_well_status.name;
(* Filter surface locations using
helper function, GET_VALUE, and
object-provided preferences. )
FROM sp : source::well_surface_point,
pt : source::pty_location_2d
WHEN ((w.well_surface_point = sp)
AND (sp.data_value = pt)
AND (pt.data_value
IN GET_VALUE (preferences,
"WELL_LOCATION_2D")))
bw.surface_coordinate_system :=
pt.data_value.coordinate_system.identifier;
(* x is first coordinate in location_2d )
bw.x_coordinate :=
pt.data_value.coordinates[0].data_value;
(* y is second coordinate in location_2d )
bw.y_coordinate :=
pt.data_value.coordinates[1].data_value;
bw.x_units :=
pt.data_value.ref_unit_of_measure[0].acronym;
bw.y_units :=
pt.data_value.ref_unit_of_measure[1].acronym;
(* Filter wellbore points to find total depth
using helper function, GET_VALUE, and
object-provided preferences. )
FROM bp : source::general_wellbore_point,
pt : source::pty_location_1d
WHEN ((bp.ref_wellbore_point.name =
"bottomhole")
AND (bp.data_value = pt)
AND (pt.data_value
IN GET_VALUE (preferences,
"WELL_DEPTH")))
bw.depth_coordinate_system :=
pt.data_value.coordinate_system.identifier;
bw.z_coordinate :=
pt.data_value.coordinates[0].data_value;
bw.z_units :=
pt.data_value.ref_unit_of_measure[0].acronym;
(* Filter geopolitical features to find
country. One country assumed. *)
FROM cty : source::geopolitical_feature
WHEN ((cty.ref_geopolitical_area.name = "country")
AND (cty IN w.well_surface_feature_role.geopolitical_feature))
BEGIN
bw.country := cty[0].name;
(* take first instance *)
END;
(* Filter business associate to find
operator name using helper function,
GET_VALUE, and object-provided preferences. *)
FROM op : source::business_associate,
bar : source::business_associate_facility_role
WHEN ((bar.ref_business_associate_facility_role.name
= "operator")
AND (bar.business_associate = op)
AND (bar.facility = w)
AND (op IN GET_VALUE (preferences,
"WELL_OPERATOR")))
BEGIN
bw.operator := op.identifier;
END;
END_VIEW;
END_SCHEMA_MAP;
For the example of the update behavior (for use case 2) of "Basic Well", the Epicentre mapping might be written in EXPRESS-X as follows:
(* Mapping to load business object from Epicentre-based POSC data
store. *)
SCHEMA_MAP basic_well_Epicentre_2;
GLOBAL
DECLARE source INSTANCE OF basic_well;
DECLARE target INSTANCE OF Epicentre;
END_GLOBAL;
(* Establish instance map using helper
function, GET_INSTANCE, and object-provided
preferences.* )
VIEW (w : target::well, r : target::ref_well_status)
FROM bw : source::basic_well
WHEN ((w.identifier = bw.identifier))
AND (r.name = new_status));
BEGIN_VIEW
w.ref_well_status = r;
END_VIEW;
END_SCHEMA_MAP;
For this illustration of the mapping for the read behavior of "Basic Well", the direct translation of the Geoshare Data Model to EXPRESS is assumed.
The Geoshare Data Model mapping might be written in EXPRESS-X as follows:
(* This schema defines data used by the object implementation to
support this mapping *)
SCHEMA basic_well_to_Geoshare;
USES basic_well FROM basic_well;
(* A rudimentary specification of preferences to apply to the mapping,
e.g. for selecting one from many, for resolving units / coordinates. *)
ENTITY preferences
preference_category : STRING (40);
preferred_thing : SET OF thing;
UNIQUE si : preference_category;
END_ENTITY;
TYPE thing =
SELECT (<to-be-determined>);
END_TYPE;
END_SCHEMA;
(* Mapping to load business object from Geoshare Data Model data file.
*)
SCHEMA_MAP basic_well_Geoshare;
GLOBAL
DECLARE source INSTANCE OF Geoshare;
DECLARE target INSTANCE OF basic_well;
END_GLOBAL;
(* Establish instance map using helper
function, GET_INSTANCE, and object-provided
preferences. *)
(* Note: f is 217-FIELD parent of well w and
parent of coordinate system cs *)
VIEW bw : target::basic_well;
FROM (w : source::gdm_217-WELL-HEADER
f : source::gdm_217-FIELD,
cs : source::gdm_217-CARTOGRAPHIC-PROJECTION)
WHEN ((w IN GET_INSTANCE (preferences,
"WELL_BY_IDENTIFIER"))
AND (w = f.WELLS-IN-FIELD)
AND (cs = f.CARTO-PROJECTION));
BEGIN_VIEW
bw.identifier := w.UNIQUE-WELL-ID.value[0];
(* Convert GDM well status to POSC reference
value using helper function, REF_GDM_TO_POSC.
*)
bw.status := REF_GDM_TO_POSC
("WELL_STATUS", w.CURRENT-CLASS.value[0]);
(* Filter location using GET_VALUE and
convert units to POSC using
REF_GDM_TO_POSC. *)
FROM sp : source::gdm_217-MAP-LOCATION
WHEN ((w.TOP-LOCATION[0] = sp)
AND (sp IN GET_VALUE (preferences,
"WELL_LOCATION_2D")))
bw.surface_coordinate_system :=
REF_GDM_TO_POSC ("COORDINATE-SYSTEM-NAME",
cs.PROJECTION-NAME[0]);
bw.x_coordinate := sp.X-COORD.value[0];
bw.y_coordinate := sp.Y-COORD.value[0];
bw.x_units := REF_GDM_TO_POSC
("UNIT_OF_MEASURE", sp.X-COORD.units[0]);
bw.y_units := REF_GDM_TO_POSC
("UNIT_OF_MEASURE", sp.Y-COORD.units[0]);
(* Filter wellbore points to find total depth
using helper function, GET_VALUE, and
convert units to POSC using REF_GDM_TO_POSC.
*)
(* The following may be better done using
gdm_217-WELL-TOTAL-DEPTH for a borehole depth
measured from a working datum as opposed to a TVD
measured from a datum. A preference would be used
to select among the four kinds of total depth: generic, driller's, logger's,
and plugback. *)
FROM bp : source::gdm_217-MAP-LOCATION
WHEN ((w.BOTTOM-LOCATION[0] = bp)
AND (bp IN GET_VALUE (preferences,
"WELL_DEPTH")))
bw.depth_coordinate_system :=
sp.<to-be-determined>.value[0];
bw.z_coordinate :=
bp.Z-COORD.value[0];
bw.z_units := REF_GDM_TO_POSC
("UNIT_OF_MEASURE", bp.Z-COORD.units[0]);
(* Filter geopolitical features to find
country. One country assumed. *)
FROM cty : source::gdm_217-LEGAL-LOCATION
WHEN (w.BOTTOM-HOLE-LEGALS[0] = cty)
BEGIN
bw.country := REF_GDM_TO_POSC
("COUNTRY_NAME_FROM_CODE",
cty.COUNTRY-CODE.value[0]);
END;
bw.operator := w.OPERATOR.value[0];
END;
END_VIEW;
END_SCHEMA_MAP;
This definition of the E&P Life Cycle is based on material supplied by NITG-TNO. It consists of five phases. These correspond to the five phases usually described by POSC. The phases are exploration (discover), appraisal (define), development (develop), production (deplete), and abandonment (dispose). (Note: the terms in parentheses are the POSC phase names.)
Each phase is characterized in the bullet lists below by business processes, tools, and participants. Key decision points are shown.
The Exploration Phase consists of:
The Appraisal Phase consists of:
The Development Phase consists of:
The Production Phase consists of:
The Abandonment Phase consists of:
The Common Object Request Broker Architecture and Specification; Revision 2.0: Object Management Group, Inc. 1995
CORBAservices: Common Object Services Specification, Revision Edition: Object Management Group, Inc. 1995
EXPRESS Information Modeling Language (ISO 10303.11)
EXPRESS-I Specification (draft), ISO TC 184 SC4
EXPRESS-X Specification (draft), ISO TC 184 SC4
Khoshafian, Setrag, Razmik Abnous; Object Orientation: Concepts, Languages, Databases, User Interfaces, Wiley 1990
Mobray, Thomas and Ron Zahavi, The Essential CORBA, Wiley 1995
Orfali, Robert, Dan Harkey, and Jeri Edwards; The Essential Distributed Objects Survival Guide, Wiley 1995
Otte, Randy, Paul Patrick, Mark Roy; Understanding CORBA, Prentice-Hall 1996
POSC Base Computer Standards, Version 2.0, Prentice-Hall, 1994
POSC SIP Specifications Version 2.1 (2 CD-ROM set), 1996
Siegel, Jon; CORBA Fundamentals and Programming, Wiley 1996