The promise of easy access to multiple quality sources of oil and gas data, regardless of location, remains an elusive goal for interpreters, data managers and commercial data providers. Even with the advent of the Internet, e-commerce and technologies such as Web services, the industry as a whole still spends an inordinate amount of time mired in manual processes gathering, checking and moving data into environments where it can actually be used for its intended purpose: finding and procuring hydrocarbons.

The process of accessing data stores, both commercial and proprietary, is relatively easy today. Although an end-user in this industry can still not easily "comparison-shop" between different commercial data offerings, most major data service companies offer a way to access and often download their product through a Web-based interface. The challenge to an integrated system of procurement and storage is what to do with this data - is it of good quality, where should it go and how do I know what I have? There is the additional challenge of balancing the needs of the data manager whose first priority is managing all of the data and tracking procurement charges and the end-user who is often most concerned with optimizing the time it takes to get the data in his or her hands for analysis.

Well log data is an example of a common, and critical, data component within the exploration and production industry, and data managers frequently restrict or delay end-user access to well log data in the hopes of controlling the flow of new vendor data into the organization. This is an unfortunate side effect of the data manager's need to enforce corporate data standards, validate data quality and store well log data within a corporate repository.

Some organizations funnel data procurement through a single source (either an individual or team), creating a data delivery bottleneck. Others require (usually with limited enforcement capability) end-users to send copies of acquired well log data to a central administrator, who in turn loads the data to a central data store. A few have developed elaborate internal integration systems to ensure that newly acquired data is routed to project data stores as well as a corporate repository.

Still others have no centralized well log management strategy in place, in which case well logs are acquired, stored and managed by individual users. This results in an inefficient data retrieval process and redundant data purchases of the same well log data since colleagues are not aware of specific well log data that has already been purchased and archived within their data enterprise. Each system has advantages and disadvantages, but there is general agreement that some type of consistent and standardized storage would be preferable for the following reasons:

• Cost-savings are realized through reduced repurchasing of data;
• Standardized file naming conventions and/or data access reduces the time required to determine what logs are available;
• Pre-qualified data increases end-user confidence that data has been quality controlled;
• End user project data can be considered "disposable;" end users do not have to maintain legacy local data stores if they know that their corporation (or data host) has permanent copy of data;
• Centralized data repository facilitates integration, auto-loading and synchronization with application environments; and
• Vendor invoice reconciliation easier and candidate for automation.

The adoption of e-commerce and Web services in the oil and gas industry has developed at a slower pace than in the general marketplace and, with only a few exceptions, is just now becoming commonplace. Today's stages of well log data procurement can be thought of as follows: access to a company's data catalog - common; online, e-commerce purchase and download of data - rare but available; access of multiple sources, purchase and targeted storage to different data stores - very rare.
How, then, do we provide access to different data sources, both proprietary and commercial, and allow for real-time purchase of data and delivery of the products to the appropriate data stores - all the time keeping data managers and end-users alike happy?

Developing a service-oriented architecture (SOA) using Web services makes it possible to implement an "order once, route anywhere" model which is an optimal solution for the end-user's need for timely delivery of data and the guaranteed delivery of data to designated targets for the data manager. This model has the following benefits:

• More accurate data procurement, as end-user directly initiates the order;
• "Hands-free" delivery for the end-user to an interpretive environment;
• Guaranteed delivery and completion notification;
• All acquired data routed to "clean room" staging area and/or archive;
• Automation of business rule validation; and
• Utilization of existing data; "sourceless" metadata.

A service-oriented architecture is essentially a collection of services that communicate with each other. The communication can involve either simple data passing, or it could involve two or more services coordinating some activity. Some means of connecting the services to each other is needed. In this example software services were developed to support the necessary data retrieval, data validation (LAS Certify), data transformation (e.g., LAS to WellLogML) and data delivery, facilitated by the development of software adapters to common data applications such as Baker Atlas's RECALL and Halliburton's OpenWorks environments. Developing these services in an SOA paradigm provides the following advantages:

• Individual services can be orchestrated in specific combination to meet a customer's business process;
• Services can be leveraged by any middleware or integration platform that can speak Web services or http; and
• There is minimized impact on the corporate infrastructure since the services are very lightweight and self-contained.

Location-independent procurement

This process facilitates the user simply requesting well log data without regards to its specific location, and the router solution retrieves and delivers a prioritized version of the requested log data. This enables an organization to impose custom business rules and logic on the log data delivery process, affording them a competitive advantage in terms of timely delivery of high-quality data to their geoscientists and engineers. An example of the procurement process is as follows:
1. User identifies the specific log data to be retrieved and the project destination(s) for the data using a text or spatially enabled front-end application.
2. This request is processed and, based on the company's defined business logic, specific data sources are queried for the appropriate well log products as described below:
a. Retrieve metadata from the company's internal master or project data store if it is available;
b. Retrieve the equivalent metadata from the commercial source(s);
c. If log data exists in multiple locations, use a parameter such as total depth to compare the log products from the different sources; and
d. Based on the custom business logic, choose the "best fit" well log from the appropriate source
i. Deliver that well log data to the company's master data store; and
ii. Notify data administrator of delivered log data.
3. Deliver the log data to the user's project and notify the user of the data delivery.
Technical architecture
The Router solution as described above and illustrated in Figure 1 involves the utilization of the following system components:
• Commercial Data Source Adapter;
• SOA Routing Engine;
• Target Resource Adapters (OpenWorks, RECALL, Other); and
• Transformation and Validation Services.

Both source and target are exposed as Web services and leverage native applications interfaces (APIs), which minimizes the amount of future maintenance required as vendor data schemas evolve over time.
The Source adaptor provides the functionality necessary to perform authorized and secure retrieval of the log data order file from the commercial site, unpack the order into discrete datasets and prepare the individual log files for delivery.

The Log Data Services package provides a set of individual services that can be utilized and combined as required to support specific business processes. These services offer such functionality as certification of LAS files (per the CWLS LAS Certify spec) and data transformation of log data files (e.g., LAS to WellLogML, SIF to RasterML) in preparation for delivery to the target systems.

The Routing Engine is responsible for interrogating the specific well log data files in order to provide the necessary content-based routing to individual destinations, such as TIF image files to an image repository, LAS files to RECALL and WellLogML files to OpenWorks. Additionally, the routing engine provides a guaranteed, once-and-only-once delivery mechanism to ensure data delivery or to handle delivery exceptions in a predictable manner. The Routing Engine also provides a user notification mechanism to inform the user when the data delivery has been completed. The Routing Engine is provided through both a commercial integration platform, such as WebMethods or Microsoft's BizTalk, or through a more custom "fit-for-purpose" routing solution.

The Target Adapter is responsible for accepting well log data files, in LAS or WellLogML formats, along with the necessary user authentication and routing information, and providing the appropriate data insertion into the target database. Each adapter provides appropriate transaction status information back to the routing engine for the purposes of informing the user of the status of the delivery.

Conclusions

Extending an existing e-commerce application with middleware-based routing and notification capabilities strikes the best compromise between satisfying the end-user's desire for immediacy of data and the data manager's quest for a standardized, quality-controlled data repository.

The advantages of using an SOA approach with Web services is the inherent scalability and flexibility to implement a similar but conforming model at multiple sites as well as the ability for the middleware to scale vertically within a given organization. Leveraging this modern "services" model allows for the system to evolve over time with a minimum of maintenance time and cost for both consumer and provider. Although this particular solution focused on a comprehensive order, compare and storage of well logs, it is flexible enough to be used as a core platform to extend to additional data types such as general well, engineering and seismic information.

Comments