Position Paper Regarding Web Services

Ken Laskey, SAIC

Web services are often discussed in the context of B2B solutions supporting commerce over the Internet. Finding items of interest, negotiating price and delivery, and providing security for and certainty of the completion of transactions are among the many challenges which Web-based applications must execute. However, Internet commerce is not the only domain which has these types of challenges. Consider a collaborative design team distributed at work locations around the world. The design team must chose among a number of possible design alternatives, system budgets for resources such as power, weight, and heat load may be traded between teams with different allocations, and configuration control must be maintained for reference designs and modified baselines. Thus, the needs of a collaborative design team are analogous, if not in many cases identical, to their commerce brethren.

It is the contention of this paper that a Web service environment which supports the requirements for electronic commerce will also support technical collaboration among distributed teams. In the following, several conceptual elements are laid out describing how such an environment would function, and indicating the type of services which would be available from a Web service infrastructure.

Collaboration for a distributed design team would use a virtual repository to "store" all design data and design tools. The actual physical location of any such resource would be with the individual(s) or organization responsible for the resource's creation, maintenance, and update. Access to the resource would occur transparently, as discussed below. Metadata would characterize each resource through information which would act as discriminators to users. Search mechanisms would be available to support a user specifying target values for the metadata categories and relative importance in finding an optimum meeting of requirements. For example, a designer might need a motor which supplies torque in a given range, but a more important constraints is that the size must fit within a certain package allocation. Indeed, the search would be against the virtual repository and go across information gathered from multiple sources. The search utility used could also be discovered through a similar search which has culled through published search algorithms to identify the best utility for the user's needs.

In a collaborative environment, it would be valuable to know that you and other members of the team are using consistent information accessed from a single, if virtual, source. In addition, it would be important to know when information which led to a design decision changed so that the decision could be reevaluated. The collaborative environment could establish subscriptions when information is used from the virtual repository and the user would be automatically notified when the resource was changed. This would apply not only to data but to tools used for design as well.

Given that data could be stored anywhere in any format, the collaborative environment would also need to support transparent access from any data format. This could be negotiated by publishing the data format as an element of the resource metadata or by a metadata element providing the means to invoke a utility, i.e. a utility API, which could read, extract, or otherwise access information from a data store. The latter would be ideally suited for proprietary formats because the utility and the metadata describing the API could be created by the format's owner and data access could be enabled without the details of the format ever being published.

Security would obviously be of paramount importance. Design information is often proprietary and access would be restricted to the design team or other approved users. In addition, security must restrict change access to the party responsible for the resource, while allowing read access to all users who need the resource for their work. This again applies to both data and tools used by the team. In addition, for an approved change to become part of the design environment, several steps, including loading the change, updating documentation, and notifying subscribed users must all be accomplished for the "transaction" to be accepted.

Web services can be envisioned which support many of these functions. Discovering and invoking the services would be a function of the supporting infrastructure and the interoperability of the infrastructure components would depend on the standards and protocols on which these were built.