Future of Search

The standardization part: several influential vendors, notably Microsoft and IBM, have attempted to take matters into their own hands by collaborating on the development and publication of specifications. However, this approach may lack sufficient adoption by other vendors and users to reach critical mass. 

The most successful and popular approach vendors are taking is to provide demos and case studies of what is possible. And, unanimously, vendors are keen to build "learning networks" not just about their own toolsets and technologies, but also about the potential of Web services and the loosely coupled architecture. 

Are we looking into the future? Yes, Web services promises to steer us through a world of opportunities and empower us with the ability to conquer the next e-business frontier. Capitalizing on web services in this new way of operating offers companies a good enough reason to join the web services revolution. 

Microsoft's .NET initiative is a platform for the tools and servers required in the Web services world to come together. The .NET platform promises to help build, own and operate the Web services of tomorrow easily. The future will be industry wide specialized web services that will emerge to provide reliable, fast and economical services that integrate together as a custom application to serve the needs of a particular client/organization. 

Despite the fact that there is already more support for the core Web services technologies—SOAP, WSDL, and UDDI—than there ever has been before for any set of comparable specifications, the killer applications for Web services haven't yet emerged; and no one can yet chart a clear path for their future evolution among the plethora of proposals, organizations, and vendors' initiatives in this space. 

Several influential vendors, notably Microsoft and IBM, have attempted to take matters into their own hands by collaborating on the development and publication of specifications. However, this approach may lack sufficient adoption by other vendors and users to reach critical mass.  

Many industry organizations have taken positions on or adopted various Web services-related specifications, including the World Wide Web Consortium (W3C); the Organization for the Advancement of Structured Information Standards (OASIS); the Object Management Group (OMG); the Internet Engineering Task Force (IETF); and the Electronic Business XML (ebXML) initiative, sponsored in part by The United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), UDDI.org, and now the Web Services Interoperability Organization (WS-I).  

An interesting and important side issue concerns what happens to UDDI. Despite the fact that WS-I includes UDDI, UDDI.org remains a vendor-controlled organization. UDDI.org has consistently stated that the UDDI project will be turned over to an independent standards body at an appropriate time, and that the future course of UDDI will be thereafter determined by that standards organization.  

This intention has been a consistent part of the proposition that UDDI.org has offered its members and the industry at large: Whatever the privately controlled organization produces will be placed under independent control at some point. The original timeline for the handover was following the completion of UDDI V3. However, the group has badly missed the original December 2001 deadline for V3, and no announcement has been made about which independent organization is to assume control.  

But beyond the core specifications—which give you interoperability (SOAP), service description (WSDL), and service discovery (UDDI)—there is even less consensus among vendors with regard to adoption of additional technologies.  

Sun has said that additional specifications for "enterprise quality" or industrial-strength Web services are not necessary because ebXML already provides them. The ebXML messaging service is based on SOAP with Attachments, so there are some grounds for viewing the remainder of ebXML as enterprise quality of service specifications on top of core Web services—but ebXML does not include WSDL or UDDI. Microsoft has said that it will never implement ebXML, and IBM seems to have ended up somewhere in the middle as a supporter of both (although I guess you could argue that IBM is big and divided enough to take a position both for and against ebXML, depending on whom you ask). Among Web services vendors, IONA and a few others remain more neutral, and support both initiatives.  

The initial push behind the SOAP specification was to get it adopted by W3C, and thereby place it under independent control and ensure the kind of widespread adoption necessary for standardization. Everyone could agree upon the standardization of SOAP because the real money to be made is not in the basic transport or fundamental communication unit, but in the added value services and features over which everyone is currently fighting. The danger, of course, is that the fighting will somehow spill over onto the foundational specifications, and that an effort such as WS-I will end up hurting rather than helping the effort, especially if it becomes exclusive rather than inclusive.

A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-process able format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. 

Four architectural models:

• Message Oriented Model
• Service Oriented Model
• Resource Oriented Model
• Policy Model

The Message Oriented Model

Addresses in the MOM and service references: 

• Protocol independent specification of delivery information
• Response delivery information
• Important concept that is lacking a standardized solution
• Proposals for a reference framework:
• WS-Addressing
• WS-MessageDelivery
• Gap that needs to be filled 

Semantics in the Service Oriented Model:

Setting expectations:

• Will make people's life easier
• Examples of use:
• Connect two services, ensuring that they speak the same language with same meaning
• Merge data from different sources
• Out of a list of 50 existing services, get only the 2 candidates that actually do what the user wants
• Automatic recovery from failure, etc.

Continuing building the infrastructure:

• In progress: service description, choreography, attachments for SOAP 1.2, internationalization issues
• Needs to be addressed:
• Delivery and service references
• Privacy
• Integration of semantics
• Constraints and capabilities
• Completing securing Web services

The truth is that Web services are usable today for many applications, just as the initial Web was. It's also true that no one really knows which direction Web services will evolve. It would be better for everyone if the user or consumer of Web services software became the force behind their evolution, rather than leaving it up to the vendors—who can't agree, anyway.

What a great day it will be when the users and customers finally stand up and speak for themselves, and start telling the vendors what they want and need—and what to do about standardization. Only users and customers can really judge the benefits, after all, and only they can truly force widespread adoption. Competing vendors by definition will find a way to disagree, and try to gain advantage over each other.