There is a lot of discussion on what Web services can or cannot help business achieve [0]. Earlier simplistic views of Web services as silver bullet are being replaced by more temperate views, as exemplified by Andrew McAfee's recent article [1]. This posting is primarily focused on sharing some thoughts related to [1].

Prof. McAfee offers two insights: "Web services allow construction of modular and interchangeable building blocks software" is happening, but "how companies collaborate and compete" is not happening. He also observed that "the application-integration challenges that remain unaddressed by Web services are the really difficult ones and can only be overcome by the work of managers and leaders, not technologies and consortia".

Prof. McAfee is right on mark when he says "Web services, however, will not create this world," but I disagree when he says "nor will any technology on the horizon". My main argument is that if we add semantics to the mix, I think we will see more progress than what Prof. McAfee has seen so far. I will give a technical (computer scientist) view on these points that is validated by real-world deployments by the company I co-founded (Semagix), some collaborations in bioinformatics between the LSDIS lab and the biologists at UGA, and by some interactions with industry collaborators, mainly at IBM.

A different perspective inteoperability

Interoperability is the key to collaboration, integration and interoperability (between application and application, as well as human and application/system). It comes at four levels: infrastructure/system, syntax, structure/representation and semantics [2] [3]. I feel that this dimension is more meaningful when looking at technical issues compared to the three levels of transport, payload, and process used in [1].

XML and Web services deal with infrastructure, syntax and some representational issues. Concurrently, in several scientific and business domains (e.g., biology [OBO], health care [OpenClinical], risk & compliance [4], digital content applications on mobile networks and so on; also see- Why are we still pushing Semantic Web?), we are finding increasing success in developing and exploiting ontologies. These ontologies are the key enabler of semantic technologies, and embody human-agreement such that machines can interpret (mimic, reuse or in a rather limited form, "understand") this agreement to replace some of the human interactions (when such agreements exist). While I will spare the details, ontologies related semantic techniques and technologies (e.g., disambiguation with approximate/fuzzy matching, probabilistic relationships, etc.) enable semantic integration that can help deal with inconsistencies and other problems pointed out by Prof. McAfee. And while the difficulty in technological solution in Prof. McAfee's IBM case study was attributed to "Midrange systems were simply too complex", human bodies or biological description (e.g., pathways) are at least as complex, and yet it has been possible to develop very useful ontologies in these areas. Interestingly, parts of RosettaNet PIPs (the subject of the Case Study in [1]) has been represented as an ontology by us and others [RosettaNet ontology].

Using semantics to the mix

The need for painstaking work does not disappear when developing ontologies, but but many tools and techniques are available to build and maintain populated ontologies. Furthermore, ontologies defined in formal representation languages such as OWL are highly sharable and reusable form of knowledge representation. Ontologies, policies and rules provide a medium for capturing and reusing the knowledge and experience gained from prior integration efforts and negotiated agreements, thereby leading to greater level of automation at the semantic level,. This can enable companies such as IBM to reuse its experience for more efficient interactions and integration in the future.

To capture the breadth of issues necessary in modeling complex systems, our approach to semantics for Web services/processes consists of four components: functional (the capabilities of a business), data (how to talk to it), non-functional/QoS (policies, rules, ontologies capturing domain knowledge from previous experiences and business goals), and execution (issues of run time behavior, eg errors/exceptions) [5]. This gives a framework to deal with the complexity, capturing some of the semantic level inconsistencies, and dealing with run-time issues in application-application interactions (implemented as part of Web processes).

Commercial successes of Semantic Web Services/Processes are not evident because we are in a rather early technical and technological development process for this emerging technology. Nevertheless, evolutionary approaches to extend WSDL (the current standardard for Web service description) with semantics (e.g., WSDL-S) have been conceived, and I predict that we will be able to address the limitations identified by Prof. McAfee in next 3-5 years. I also expect good case studies from early adoption to be available within next 12 months.

[0] S. Staab, R. Benjamins, C. Bussler, D. Gannon, A. Sheth, W. van der Aalst. Web services: Been there, Done that? IEEE Intelligent Systems, Trends & Controversies, 18(1), Jan/Feb 2003.
[1] A. McAfee: Will Web Services Really Transform Collaboration http://sloanreview.mit.edu/smr/issue/2005/winter/16/
[2] A. Sheth: Focus on Interoperability in Information Systems: From System, Syntax, Structure to Semantics, 1998
[3] A. Sheth: Semantic Meta Data For Enterprise Information Integration
[4] A. Sheth, Enterprise Applications of Semantic Web: The Sweet Spot of Risk and Compliance
[5] A. Sheth, Semantic Web Proicess Lifecycle: Role of Semantics in Annotation, Discovery, Composition and Orchestraction, 2003 Abstract, Presentation