|
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:
- A service provides an interface that can be called from another program.
- A service is registered and can be located through a service registry.
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.
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:
- A Web service is accessible over the Web.
- A Web service exposes an XML interface.
- A Web service is registered and can be located through a Web service registry.
- Web services communicate using XML messages over standard Web protocols.
- Web services support loosely-coupled connections between systems.
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.
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 ]
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.
SOAP -- SOAP (Simple Object Access Protocol) is technology developed by DevelopMentor, IBM, Lotus, Microsoft, and UserLand. SOAP provides an extensible XML messaging protocol, and it provides an RPC programming model application layer. At this time, more than 30 SOAP implementations are available. The two most popular implementations are an open source Java implementation from the Apache Software Foundation and a Microsoft implementation within the .Net SDK.
SOAP Messages with Attachments -- SOAP Messages with Attachments, developed by Hewlett Packard and Microsoft, defines a binding for a SOAP 1.1 message to be carried within a MIME multipart/related message, enabling a SOAP message to carry multiple XML documents and non-XML attachments. Microsoft BizTalk Server uses SOAP Messages with Attachments, so this technology is included in a supported product.
WSDL -- WSDL (Web Services Description Language) is technology developed by Ariba, IBM, and Microsoft. It specifies a common XML framework for describing the technical specifications of a Web service. At this time, IBM has released a WSDL developer toolkit for Java through IBM alphaWorks, which can automatically generate SOAP interfaces from a WSDL description.
UDDI -- The UDDI (Universal Description Discovery and Integration) initiative is an industry consortium lead by Accenture, Ariba, Commerce One, Compaq, Edifax, Fujitsu, HP, I2, IBM, Intel, Microsoft, Oracle, SAP, Sun Microsystems, and VeriSign. More than 200 companies have joined the UDDI initiative. The group is developing specifications for a universal Web-based business directory called the UDDI Business Registry. At this time, the UDDI V1 specifications have been published, and beta implementations of the UDDI Business Registry are available from Ariba, IBM, and Microsoft. The UDDI Business Registry is a Web service that exposes an API invoked through SOAP messages. IBM has released an open source UDDI developer toolkit for Java through the IBM developerWorks Open Source Zone.
ebXML -- ebXML (Electronic Business XML) is a B2B XML framework being developed by the ebXML Initiative. The ebXML Initiative is a joint project of UN/CEFACT (the United Nations body for Trade Facilitation and Electronic Business) and OASIS (Organization for the Advancement of Structured Information Standards). The ebXML membership includes representatives from more than 2000 business, governments, institutions, standards bodies, and individuals from around the world. ebXML is a complete B2B framework that enables business collaboration through the sharing of Web-based business services.
The framework supports the definition and execution of B2B business processes expressed as choreographed sequences of business service exchanges. The framework includes specifications for a Message Service, Collaboration Protocol Profile and Agreements, Core Components, Business Process Methodology, and Registry and Repository. The ebXML Message Service provides a quality of service framework layered on SOAP Messages with Attachments. A proof-of-concept interoperability demonstration was presented in October 2000. Participants included Ajuba Solutions, Cisco, Extol, Fujitsu, IBM, IPNet, Netfish, NTT, Savvion, Sterling Commerce, Sun Microsystems, TIE, Viquity, webMethods, XML Global, and XML Solutions. The ebXML specifications are scheduled to be published in May 2001.
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 ]
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.
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 ]
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:
- The service consumer's identity, whether it be an individual, a business, or another Web service
- The role that the consumer is using at the time it invokes the service
- Preferences that the consumer may have defined for this type of service
- The security policies associated with the consumer of this service
- The privacy policies associated with the consumer of this service
- The business policies associated with the consumer of this service
- The physical location of the consumer
- The type of client device being used to invoke the service
- Any past history associated with the consumer of this service or related services
- Any service level agreements that exist between the consumer and this service provider
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:
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.
Ship the order in pieces as they become available.
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 ]
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:
A standard XML vocabulary to represent personal, corporate, and service identity components.
A standard XML framework that enables consumers to specify privacy policies that govern access to and control of personal or corporate information.
A standard XML vocabulary for context descriptions.