Enabling Open, Interoperable, and Smart Web Services
The Need for Shared Context

March 2001
Copyright © 2001 Sun Microsystems, Inc.
All Rights Reserved
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94303
Anne Thomas Manes, Sun Microsystems (atm@sun.com)


The Internet has had a profound impact on user expectations. Not too long ago, a computer user was a highly trained individual. Businesses trained their users to be experts in one or two specific applications. A Web user, though, is an entirely different breed. A business doesn't have the luxury of training its Web users. Web applications have to be intuitive. Or perhaps it's more appropriate to say that Web applications have to be invisible. A Web user simply uses the Web--to read email, find directions, pay bills, approve an expense request, and more. The user doesn't view these activities as executing applications. The user is simply using services that are available on the Web. The user wants to be able to access these services from a wide variety of client devices, such as desktop systems, PDAs, mobile phones, and in-car computers. Furthermore, the user wants these services to understand and act differently according to the context of the situation. Who am I? Where am I? What time is it? Am I acting as an employee or an individual?

These new user expectations are causing businesses to change the way they build application systems. Rather than building large, monolithic application systems or desktop-oriented client/server applications, businesses are starting to build applications using a service-oriented application design. Application software is being broken down into its constituent parts--into smaller, more modular application components or services. These application services make use of infrastructure software that has also been decomposed into discrete system services. All of these discrete services can be deployed across any number of physical machines that are connected to the Internet. This modular service approach gives businesses great flexibility in system design. By reassembling a few services into a new configuration, a business can create a new business service.


An application service represents some type of user or business activity, such as reading email, getting a stock quote, authorizing a credit purchase, and procuring materials. A system service represents system infrastructure and management functionality, such as storage, security, transactions, messaging, and fault recovery.

A service exhibits the following characteristics:

Service-oriented systems are not a new concept. Popular service-oriented systems include ONC RPC, DCE, COM, CORBA, JavaTM RMI, and JiniTM technologies. Although all of these systems have a lot going for them, they all require special protocols for communication. A COM client must use COM protocols to speak to a COM service. A Jini client must use Jini protocols to speak to a Jini service. Unfortunately, these special protocols aren't pervasive on the Web, and firewalls routinely block communication. So now, a new type of service-oriented system is evolving: Web services.

Web Services

A Web service represents a unit of business, application, or system functionality that can be accessed over the Web. Web services are applicable to any type of Web environment, be it Internet, intranet, or extranet, with a focus on business-to-consumer, business-to-business, department-to-department, or peer-to-peer communication. A Web service consumer can be a human user accessing the service through a desktop or wireless browser, it could be an application program, or it could be another Web service.

A Web service exhibits the following characteristics:

Perhaps what is most intriguing about Web services is that it doesn't matter what technologies are used to build Web services. Because Web services communicate over standard Web protocols using XML interfaces and XML messages, all Web services environments can interoperate--at least in theory.

What Businesses Want

Since the advent of the Web in 1994, businesses have been using the Internet to get closer to their stakeholders: shareholders, employees, customers, and partners. They have been using the Internet to automate supply chains and improve business process efficiency. Electronic business is no longer a future direction; it has become the norm. Now businesses are intrigued by the Web services approach to Internet computing. The Web services computing model promises even better cross-business integration, improved efficiency, and closer customer relationships.

But in order to make the Web services model palatable, businesses must be able to leverage existing application assets and expose them as Web services. Businesses want tools and technologies that will reduce the cost, risk, and complexity of moving to this new model.

[ Top of Page ]

Web Services Technologies

A variety of technologies that support Web services is starting to appear. The leading candidates include SOAP, SOAP Messages with Attachments, WSDL, UDDI, and ebXML. Currently, these technologies are not available as supported products, but they are maturing quickly.

Standardizing XML Messaging Protocols

Although SOAP appears to be establishing itself as the de facto standard for XML messaging protocols, interoperability problems among the various SOAP implementations continue to challenge developers. Formal standardization will certainly benefit the community. In September 2000, the W3C (World Wide Web Consortium) formed an XML Protocol Working Group to develop a standard XML messaging protocol. Ariba, Commerce One, Compaq, DevelopMentor, Hewlett Packard, IBM, IONA, Lotus, Microsoft, SAP, and UserLand submitted the SOAP 1.1 specification to the W3C, and the XML Protocol Working Group is using the specification as a starting point for the XML Protocol activity. Commerce One, Hewlett Packard, IBM, IONA, Microsoft, Oracle, and webMethods also submitted the SOAP Messages with Attachments specification to the W3C Activity. The W3C has not yet published the XML Protocol specification. Although SOAP 1.1 will certainly influence the future W3C XML Protocol recommendation, it may not be identical to the SOAP V1.1 specification.

[ Top of Page ]

The Developer's Dilemma

These Web services technologies are rapidly maturing, but the nascent Web services developer is pretty much left to his own devices to figure out how to make Web services work. There are no guidelines to help put all of these technologies and standards into perspective. He can use a context-sensitive XML editor to manually define the Web service interfaces, or he can generate them using a SOAP or WSDL toolkit. But how does the developer associate these new Web service interfaces with existing applications and services? And how does he assemble multiple discrete Web services into a composite business service? Interoperability between vendor implementations is still quite challenging. The vision of seamless assembly and integration of distributed, heterogeneous Web services is still a distant dream.

Shared Context

The issue is a matter of shared context. Context refers to the things that a Web service needs to know about the service consumer to provide a customized, personalized experience, such as the identity of the consumer, the location of the consumer, and any privacy constraints associated with the consumer information. If you aggregate a number of services to create a composite business service, these services somehow need to share this context.

Take for example shared user identity. A Web service that offers a personalized experience maintains information about the identity of each user. When an individual uses that service, she identifies herself to that service. Sometimes the service determines her identity automatically from a cookie maintained on her system. Sometimes she has to enter a userid and password. Consider for a moment how many userids and passwords you have to remember for all of the Web sites you visit. Consider how many more cookies you have stored on your system. Consider how many businesses maintain their own database of private information about you.

This discussion has no doubt raised your hackles about privacy and security issues. It also points out a significant challenge facing Web services technology. There are no standards that allow Web sites to share something as simple as user identity. There are in fact, no standards to represent the multiple facets that make up the user's identity. There are no standards that allow an individual to manage and maintain her personal information or to control access to that personal information. How can we achieve the seamless integration of Web services if these services can't share identity as well as other situational context?

Before the vision of transparent, dynamic interaction of widely distributed, heterogeneous Web services can become a reality, this issue of shared context must be solved. Shared context raises some fairly sensitive issues. The solution can't come from a single vendor. It cannot be proprietary. The solution must be open and interoperable. It must work with any Web service. And the solution must ensure the security and privacy of individual information.

Once we define standards for identity, privacy, and context, we will have the basic infrastructure in place to support "smart" Web services.

[ Top of Page ]

Smart Web Services

A smart Web service is a Web service that can understand situational context and can share that context with other services. It produces dynamic results based on who, what, when, where, and why it was called. A smart Web service can be aware of a number of situational circumstances, such as:

Smart Service Examples

For example, let's say you invoke a smart restaurant finder service to help you select a restaurant. The smart restaurant finder wants to make a recommendation based on where you are, what you like, where you ate last night, and whom you're with. It makes a big difference if you're going out with your children or with an important prospective client. So the smart restaurant finder considers your identity, your preferences, your history, and your role.

As another example, let's imagine that there's a power emergency in California. The electric company broadcasts a Stage III emergency electrical supply shortage alert to all power consumers. This notification would launch an energy conservation service, if available, at all consumer sites. In a business facility, the energy conservation service would automatically reduce power utilization by adjusting thermostats and switching off lights according to predefined policies based on parameters such as time of day and day of the week. Some of these predefined policies might be superseded by situational parameters such as a temporary service level agreement that's in effect during a particular production run. In a home, the energy conservation service could adjust the thermostat, switch off lights, and impose a volume governor on your teenager's stereo. But the smart service also considers who is physically present in the home. For example, the smart service knows that the baby is sleeping upstairs and therefore doesn't adjust the thermostat for the upstairs heating zone.

As a final example, let's consider an order fulfillment process. Imagine that a customer has ordered six different items. At the time of the order, you promised the customer that the goods would be shipped within two days, but as your procurement service places the order with your contract suppliers, it determines that there is a supply constraint on one of the items that will prevent you from shipping the entire order as promised. Your standard policy in a situation like this is to send partial shipments, but this policy eats away at your profit line. What's most irritating is that even if you send multiple shipments, many times they all arrive on the same day, and the customer may not care if the goods arrive today or tomorrow. You're looking for an alternative that saves you money and yet still keeps the customer happy.

Rather than automatically sending the goods in multiple shipments, a smart service would determine a course of action by considering the customer profile and past history, and by weighing the profit impact of expediting the missing components or reshuffling factory work orders. The service may also take into consideration other parameters such as cost of inventory, cost of space, estimated shipping charges, and expected delivery times. The service might send an inquiry to the customer--by email, SMS message, automated voice response message, return fax, or some other delivery mechanism as defined in the customer profile--requesting a decision:

  1. Please accept this coupon for your inconvenience; the goods will be shipped when the order is complete, which is currently estimated to take five days.

  2. Ship the order in pieces as they become available.

Making Web Services Smarter

Anyone can build context-sensitive Web services. Certainly there are many Web sites today that offer highly customized content based on who you are and your past history with the site. But context-sensitivity is only one half of the problem. A smart service must also be able to share context with other services. Unfortunately, there are no standards or conventions for representing this context. Every site that provides a personalized experience maintains identity and history information in a proprietary format.

[ Top of Page ]

The Road Ahead

What's needed is a new set of standard vocabularies to represent all the components of identity, and to define open, vendor-neutral web services to support identity infrastructure. Sun wants to work with the community, in whatever forum is deemed the most appropriate, to foster new vocabularies, standards, and technologies that will enhance and enable the web services model. Initial topics to be considered include:

Page last updated 12 March 2001