Chevron Home Page Chevron Interest in Web Services Workshop

Roger Cutler
Chevron Information Technology Co.
Senior Staff Research Scientist

Abstract
Because we are a user rather than a generator of web technology, we are less concerned with exotic and high-end capabilities than we are with using the technology in practice. We have identified two gaps — administering user IDs and adapting CORBA functionality. Usage cases can help identify more. We also see a need to clarify the roles and boundaries of the organizations that develop standards, as well as to encourage the various standards bodies to cooperate in designing specifications that work together smoothly.

Background
Who We Are Chevron Corporation, one of the world's largest integrated petroleum companies, is involved in every aspect of the energy industry, from exploration and production to transportation, refining and retail marketing, chemicals manufacturing and sales. It is active in more than 100 countries and employs about 31,000 people worldwide.
Need for Standard Infrastructure From the point of view of "web services," Chevron is a user rather than a generator of technology. However, the environment in which we use technology is unusually complex and diverse. This has led Chevron to make a considerable corporate commitment to "net-enable" the company's core business processes and also to participate in the creation of e-marketplaces such as PetroCosm, an on-line marketplace for products and services used in the oil industry. The expectation is that Chevron will shift more and more of its core business to a digital infrastructure that is provided by web services.

Web Service Concerns
Gaps in the Infrastructure The overriding concern for Chevron in this situation is that web services work in a simple practical manner via a commonly accepted infrastructure. We are concerned that there may be gaps in the infrastructure required for purely commercial use of the web. In the context of the W3C, these issues appear to be lumped under the umbrellas of XML Protocol and "XML-based web service solutions." There are a number of extremely ambitious objectives in this area such as establishing distributed application environments and automated discovery of web services. However, the immediate issues for a company like Chevron that is trying to get practical benefit in a complex technical environment are more pedestrian. We need to make sure that there are simple, practical ways to deal with all the mechanics of simple transactions.
Usage Cases We would like to see an effort made in this workshop find simple gaps. The most obvious way of doing this would seem to be by looking at "usage cases." That is, how is one going to do something "right now" to implement a web service? Is each step of this process based on standards or are there necessary components or linkages that are proprietary? One might examine the tasks involved in building the web service and for each task ask if there are standards-based tools available that will do the job. If not, is one forced to write "one-offs" or use proprietary extensions? Is the problem that appropriate standards do not exist, or are there standards available that are not, in practice, being adopted?

W3C Key to Reaching Consensus
Roles and Boundaries The W3C plays a key role in defining and reaching consensus on such an infrastructure. It appears that OASIS also plays a key role in reaching consensus on the formats used in the web service infrastructure, particularly in cooperation with UN/CEFACT via the ebXML specifications. We do not understand what the boundaries are between the concerns of the W3C and those of OASIS, UN/CEFACT and ebXML. We would like to see these boundaries explored in this workshop.

Usage Case 1 — Administration of User IDs
We feel that there is a strong need for agreement on an infrastructure for handling user ID administration across B2B boundaries. This is a simple, straightforward requirement that at present seems to have no solution. We are, in practice, reduced to the extremely undesirable expedient of defining user ID/passwords locally and uniquely for each web service transaction. If we, for example, deal with PetroCosm, they must maintain some user IDs and passwords for our use in these transactions.
Information Protection The goal here is "single sign-on" for the Chevron end user. We regard this objective not just as a convenience for end users but as a key part of our information protection strategy. In "human practical" terms we do not think that it is reasonable to implement effective information protection policies in an environment where end users are maintaining multiple user IDs and passwords. We need to be able to exchange information with organizations providing web services. This information about users and roles needs to be exchanged in a standards-based manner which makes it possible for the process to be properly understood and controlled.
Competing Consortiums

There appear to be two competing industry consortiums in the XML security space — S2ML and AuthXML. (We are aware that there are other standards that touch on these issues, such as PKIX and X.509, but it is our impression that these specifications do not supply a complete solution for B2B transactions). According to a Giga analysis of S2ML and AuthXML (RIB-012001-00118, January 12, 2001) the functions addressed by these proposals, and thus the range of application scenarios addressed, is actually quite limited. For example, although in both proposals there are provisions for real-time exchange of basic information about principals (that is, a user or a process), there are no provisions in either for basic security administration functions.

Both groups have in the past talked about submitting to OASIS and/or the W3C, and it appears from archives of correspondence that at least AuthXML was actually submitted to a working group of the W3C. This issue appears to us, at least at first sight, as "technical infrastructure," and thus appropriate for the W3C domain. Nonetheless, we find that the Security Services Technical Committee of OASIS has received both submissions and is planning to publish a specification in this area in summer of 2001.
Define Roles So it appears that in practice everyone concerned agrees that this subject belongs in the OASIS domain. In this workshop, however, we would like to address the issue of how to define the appropriate roles or domains of the W3C and OASIS and how to recognize which subjects belong where.
Practical Solution

Whatever shop security administration belongs in, we feel that we have a stake in ensuring that a solution is defined that actually has teeth. That is, a "standard" which is so inclusive that it will accommodate incompatible implementations is not helpful. The fields need to be defined explitly enough so that seamless interoperability is guaranteed.
LCD Dependencies We would also like to see a standards-based solution for security administration which is, as much as possible, separable from other advanced or recent XML specifications. We feel that it might in practice hinder interoperability and ease of adoption to have a recommendation which depends for implementation on use of other recent recommendations. In other words, we would like to see dependencies on other recommendations be "lowest common denominator".

Usage Case 2 — Defining Common APIs
A considerable segment of upstream technical computing in the oil industry (e.g. well logging, geologic interpretation) has been moving in the past few years toward defining common APIs via CORBA objects. A "well object" would have methods that return or set in underlying data stores various types of data defined in that object's IDL (Interface Definition Language).
CORBA 80-20 This works well in a tightly coupled environment, but there is also interest in establishing a "high-value" subset of these functions in XML as web services, particularly for use across firewalls. Although it is almost certainly unreasonable to think about duplicating the entire CORBA environment in the infrastructure provided for web services, nonetheless we think that there is value in looking for the 80-20 of CORBA functionality that might usefully be incorporated into the XML infrastructure. One might examine high-value usage cases and ask what subset of CORBA functions they involve.
IDL, an ISO Standard It seems to us that the most obvious example of this involves the IDL itself. The interface's data definitions from the IDL should presumably end up in XML in DTDs or schemas. Early implementations of the SOAP submission to XML Protocol have required subsidiary interface definition information and this seems to have evolved into the WSDL (Web Services Description Language) proposal. We do not know whether this proposal has been submitted to any standards body at this time or whether WSDL covers any of the same ground as the IDL used by CORBA. If so, it might be worth noting that the OMG IDL used by CORBA has been accepted by ISO as a standard.

Conclusion
The W3C needs to look at practical usage cases to identify barriers to the implementation of web services. We also need to understand the roles and boundaries of the organizations that develop standards related to web services.

Roger Cutler
Last Update: February 27, 2001
Valid XHTML 1.0