We intentionally avoided getting into the technical details of BP’s RTAP/Web Services solution in the first part of this article (OGJ, Jan. 2, 2006, p. 36).
At this point, it may be helpful to identify the key components and technologies involved as well as some of the potential barriers to more widespread adoption.
We will attempt to keep this discussion in plain English as well, to remain accessible both to E&P management and to non-IT professionals interested in exploring Web Services in the upstream industry.
Web Services are essentially web-based interfaces or connections built on established or emerging internet protocols and standards. As such, they are platform and operating system independent. Web Services enable any system within an IT infrastructure to send requests and receive responses from any other system.
At the risk of oversimplification, this type of interoperability is analogous to two people who speak the same language sending and receiving mail via a “standard” postal delivery service (Fig. 5). The two people are any two computers on a network.
A normal letter is written in, say, English or French or Italian. In Web Services, the language in which messages are generally written today is called XML (eXtensible Markup Language), a widely used standard developed by the World Wide Web Consortium.
XML is similar to HTML (HyperText Markup Language), the language used to create familiar Web pages read by any Web browser. HTML was highly successful because it was simple to use and could be understood by all end-use tools (browsers). The XML standard, which uses many of the same constructs as HTML but which can be extended to describe industry-specific concepts, has become the de facto standard for Web Service interfaces. In our analogy, therefore, the “letter” is written in XML. But every language also follows certain rules of grammar and syntax. The “grammar” for defining an XML-based interface is specified by a standard called WSDL (Web Services Definition Language), which also includes how and where to access a particular Web Service.
How, then, is this XML letter delivered? First, an “envelope” is required. In Web Services, SOAP (Simple Object Access Protocol) provides the envelope, which includes both routing and security information (like an address and a seal). SOAP, like any good envelope, is independent of either the content of the letter or the transport mechanism.
The second requirement for delivery of an XML message, of course, is an internet “courier service” or postal system. For Web Services, HTTP (HyperText Transport Protocol) is the usual internet transport mechanism, or HTTPS (a form of HTTP for secure transmission). Both of these are familiar to users of the World Wide Web, where they appear as the prefix on typical web site addresses.
The RTAP team utilizes these and other standards to build Web Service interfaces, enabling smooth interaction among data sources and applications. Technically, there are two ways of implementing Web Services within a particular oil and gas asset.
The first-used in most assets to date-is to write a simple piece of code that “wraps” a legacy system with a SOAP interface, automatically converting other data types to the XML standard. This “wrapper” is typically written either by in-house IT staff or a third-party consultant. It enables an E&P organization to leverage its existing investment in legacy systems for several more years, without any immediate need to alter or replace those systems.
The second way to implement a Web Service-which is much more exciting, in terms of simplifying future implementation and proliferating this approach across the industry-is for digital technology vendors to embed standard Web Service interfaces directly in their products, whether applications or database systems. In this scenario, a vendor’s product can read and/or write data in native XML format, eliminating the need for oil companies or third parties to build custom wrappers for data conversion.
Over time, it would be desirable for other application vendors to build Web Services natively into their systems, which would relieve BP from maintaining in-house software development teams to generate application-specific wrappers. It is BP’s view that this is a strategy that the majority of BP’s vendors are adopting.
One challenge involved in proliferating XML-based Web Service interfaces for real-time production/operations data transfer is the current lack of a production data exchange standard within the E&P industry. While XML is a generic standard that can apply without modification to any data type or industry, industry-specific XML vocabularies and specifications also must be developed and agreed on to facilitate the exchange of information (rather than just data).
Currently, for example, the Petrotechnical Open Software Corp. (POSC) manages a real-time drilling data standard based on XML known as WITSML (Wellsite Information Transfer Standard Markup Language). WITSML was originally developed by BP, Statoil, and several large oilfield service companies to enable seamless transfer of wellsite data from the rig to software systems in the office, regardless of brand.3
Evolving from a simple XML schema to a full Web Service solution for real-time drilling data,4 WITSML has demonstrated the value of industrywide collaboration in the development and deployment of standards.
BP is working with a group of operating companies and service providers to establish a similar XML standard for real-time production data under the proposed name of PRODML. The challenge here is greater than it was in developing WITSML, because there are considerably more data types involved in well, production and facilities operations than in drilling a well.
Another potential barrier to XML propagation is an existing range of standards for real-time data under the banner of the OPC Foundation, a nonprofit organization formed in the 1990s to foster interoperability among automation systems and applications in the process control industry. OPC-compliant interfaces are available in roughly 40% of the data stores deployed in BP today, and these deliver real-time information with somewhat better performance than XML.
Why not simply adopt OPC across the board?
Unfortunately, the OPC standard is based on a proprietary Microsoft protocol, which, in addition to being applicable only on Microsoft servers, does not work across a wide area network. As such, OPC prevents wider sharing and distribution of data throughout a global organization. Thus, OPC will never suffice as an enterprisewide standard.
Service Oriented Architecture
The SOA concept has been around for a number of years, but only recently has it begun gaining significant momentum and support in the IT world.
While SOAs are related to Web Services, the two concepts are distinct.
Consider the word “services.” In this context, the terminology can be a bit confusing. The term “Web Services” refers to standard internet technologies used to connect diverse IT components, just like RCA plugs connect components of an AV system.
In the term “Service Oriented Architecture,” “service” refers to the IT components themselves, not to the connectors. Typically, the services in an SOA today are connected via Web Services, but other technologies could be used instead.
In the preceding discussion of the RTAP initiative, the Web Service connected IT components have all been legacy data sources and applications, each of which was originally developed as a “monolithic” system combining all related capabilities within a single packaged and branded product. Technically speaking, these are not “services” in the current sense of the word.
While a “service” is, indeed, an IT component, it is a much more specific type of component, i.e., one that:
• Encapsulates a discrete business function, and performs a single, cohesive task-a well-defined “fragment” of a larger business process.
• Is “self-contained,” platform-independent, and does not depend on the current “state” of any other service to which it may be connected.
• Can be “reused” and “loosely coupled” in many different ways with other discrete services (either internal or external to the organization) to enable coordinated capabilities similar to, but far more flexible and cost-effective than, typical packaged applications.
To put this all together, consider the audio-video system analogy again.5 Analogous to an IT “service,” each AV component-VCR, CD player, DVD player, television-performs a single, discrete, well-defined function. Each component is “self-contained,” for example, the VCR is not required to use the CD player. The television is not even required to use the VCR; one could record a program without turning on the TV. Use of the VCR, therefore, does not depend on the “state” of the television (whether on or off). Also, each component is “loosely coupled” with the others, rather than hard-wired.
Unlike the “monolithic” stereo systems of the past, each AV component today can easily be reused and combined with new or existing components to create a whole new system. Just as the modern AV industry has standardized the capabilities of various components and connections, the IT industry is seeking to standardize around services and Web Services.
Given this understanding of services, therefore, a “Service Oriented Architecture” would define a coherent collection of discrete business functions-in the form of reusable services-that coordinate and communicate with each other via common internet standards and protocols.
Fundamental to the concept of an SOA is that, to the individual user, all services are “black boxes.” Users neither know nor care how a particular service is implemented, or where it resides. All a user needs to know is how to access and use the interface to that service.
An SOA, of course, is more than technology. It must incorporate policies, practices, and guiding principles that link IT components and their associated interfaces directly with strategic business processes, and ultimately with individual users (Fig. 6).
An SOA must be defined in such a way that when a particular business process needs to be reengineered, the underlying services can quickly be “rewired” without necessarily having to buy or build new technology. Or, when a particular service needs to be upgraded or replaced, that can be done without any noticeable impact on the current business process because the interface remains unaltered (Fig. 7).
What benefits would SOAs offer the upstream energy industry? A highly flexible SOA would enable E&P organizations to become more agile, able to respond efficiently to changes in the business and competitive landscape. What’s more, it would facilitate more effective integration beyond the firewall-allowing oil companies to collaborate with their partners in joint business processes, exploit high-quality services provided by external E&P or IT suppliers, and facilitate outsourcing of noncore activities.
An SOA would also dramatically lower technology development costs by leveraging functions already built into legacy systems, by reusing services developed for other processes, and by simplifying maintenance and support through elimination of redundant, siloed applications.
While true SOAs are not yet common either within the E&P industry or in other industries, most organizations appear to have some level of intent to move in this direction. New adopters of Web Services and SOA tend to go through similar stages,6 which has certainly been the case at BP:
1. First, experiment with Web Services on one or two short pilot projects that are not very complex to gain an initial understanding of the challenges, technologies, costs, and potential benefits.
2. Second, begin adapting legacy applications and data systems to use Web Services more widely based on what has been learned in pilot testing.
3. Establish a coherent internal SOA (this is where BP is today.)
4. Finally, expand the established SOA beyond the firewall to include external services from selected third parties, using appropriate security measures.
At present, the RTAP Web Services provide a common set of 29 functions-read, write, search, register, open, close, etc.-to enable applications to seamlessly access a large variety of real-time operations data sources.
We are now expanding the use of web services to go well beyond real-time operations data into production systems, financial and forecasting systems, and eventually to span the whole of upstream. RTAP is simply the first leg of an exciting new architectural road map leading, it is hoped, to a full-scale SOA in the years to come.
Summary
Web Services and SOAs offer E&P companies a number of compelling benefits, not least of which are an unprecedented flexibility in responding to changes in business process, preservation of legacy systems while enhancing integration, much lower software and IT costs, and accelerated realization of business value from technology investments.
BP’s RTAP initiative is a concrete, real-world example of how to investigate, implement, and institutionalize these new concepts in the upstream energy industry.
BP has developed an extensive capability to generate value from Web Services and have started the journey towards an E&P-wide realization of a full SOA. Nevertheless, much work remains before the full advantages of these new approaches to the deployment of information technology will be achieved.
Two strands of effort are required, at both an industry and organizational level, to reach the goal of a fully SOA-enabled enterprise. Service companies, technology suppliers, and industry standards organizations must begin to work together in order to achieve the following:
• Industrywide:
1. Support the definition of XML-based data standard covering a broad range of business functionality.
2. In the short term, encourage technology vendors to wrap their monolithic applications in Web Services to support simpler methods of integration.
3. In the longer term, encourage technology vendors to implement native Web Services in new application releases and to “deconstruct” their monolithic applications into discrete, reusable services-encouraging developers to focus where the real value lies: on innovation, quality and price rather than simply connectivity.
• BP Upstream:
1. Establish Web Services as the standard approach to integration.
2. Adopt the SOA concept as the IT architectural standard.
3. Wrap existing, legacy application to produce reusable services.
Acknowledgments
We thank Geoffrey Woodham for his willingness to support and encourage the use of this new technology in the North America Gas Business Unit. We also thank Jay E. Valusek, consultant, for assistance in preparing this article for publication. ✦
References
1. Barry, D.K., “Web Services and Service Oriented Architectures: The Savvy Manager’s Guide,” Morgan Kaufmann Publishers, San Francisco, 2003, p. 20.
2. We are indebted to D.K. Barry for this analogy. See Web Services and Service Oriented Architectures, pp. 17-18.
3. Holt, J., Haarstad, I., Shields, J.A., James, J.P., and Seiler, D., “WITSML: Technology-to-Business (T2B) for the Oilfield,” paper 74480 presented at the 2002 IADC/SPE Drilling Conference, Dallas.
4. Kirkman, M.A., Symmonds, M.E., Harbinson, S.W., Shields, J.A., Will, M., and Doniger, A., “Wellsite Information Transfer Standard Markup Language, WITSML, an Update,” paper 84066 presented at the 2003 SPE Annual Conference and Exhibition, Denver.
5. Barry, D.K., “Web Services and Service Oriented Architectures,” p. 19.
6. Barry, D.K., “Web Services and Service Oriented Architectures,” pp. 89-90, 96-97.