web services: been there, done that? - pku.edu.cn

Steffen StaabUniversity of [email protected]

T r e n d s & C o n t r o v e r s i e s

72 1094-7167/03/$17.00 © 2003 IEEE IEEE INTELLIGENT SYSTEMS

Don’t Go with the Flow: Web ServicesComposition Standards Exposed

Wil van der Aalst, Eindhoven University of Technology

The recently released BPEL4WS is said to combine thebest standards for Web services composition, such asIBM’s WSFL and Microsoft’s XLANG. (For an explana-tion of these and other acronyms, see the “Glossary” side-

bar.) BPEL4WS allows for a mixture of block- and graph-structured process models, thus making the languageexpressive at the price of being complex. AlthoughBPEL4WS is not such a bad proposal, it is remarkablehow much attention this standard has received, whilemore fundamental issues and problems such as semantics,expressiveness, and adequacy have not received the atten-tion they deserve.

Of course, having a standard is a good idea, but there aretoo many of them—and most die before they mature. Con-

Web Services: Been There, Done That?

What are Web services? The Stencil Group defines them as“loosely coupled, reusable software components that semanti-cally encapsulate discrete functionality and are distributed andprogrammatically accessible over standard Internet protocols”(see www.stencilgroup.com/ideas_scope_200106wsdefined.html). Does this sound familiar? Long ago, people learned howto send software components and RPCs over HTTP (for an expla-nation of RPC and other terms, see the “Glossary” sidebar). Mes-sage exchange is increasingly based on XML, but so what?

Do you recognize hype when you see it? Let us measure fameas a Google count of Web pages that include a specified term.For example, measure the Semantic Web—now the topic of anestablished department in IEEE Intelligent Systems—againstWeb services. (The Semantic Web department in this issuealso covers Web services.) The first Semantic Web languagedocument (a working draft on the Resource Description Frame-work) was issued as part of the World Wide Web Consortiummetadata activity in October 1997 (www.w3.org/2001/sw). UsingGoogle’s exact search, the term “Semantic Web” yields approxi-mately 136,000 Web pages.

Now consider “Web services.” The first UDDI document Icould find dates from 1999, and the first W3C XML ProtocolActivity preceding the Web Services Activity started in Septem-ber 2000 (see www.w3.org/2002/ws).1 The correspondingcount delivers a whopping 3,210,000 pages. Compare thesenumbers with “artificial intelligence,” whose count ranks at1,410,000, “Corba” (Common Object Request Broker Architec-ture) at 1,650,000, and “TCP” at 7,640,000.

Even given the inevitable fallacies of these numbers, theoverall result is clear: Web services have received a lot of hype,the reasons for which are not easily determined. Some of their

benefits might even seem to waste away, once we touch onthe nitty-gritty details, because Web services per se do notoffer a solution to underlying problems such as

• How can I effectively and efficiently distribute computa-tion efforts?

• How can I make a software component really reusable?• How can I control and monitor these processes?• How can I effortlessly integrate the components?

The following contributions delve into some of these issues.Wil van der Aalst describes the pitfalls of workflow issues, manyof which we’ve encountered before. V. Richard Benjamins pointsto the various research in the 1990s into structuring proceduralknowledge into problem-solving methods. Amit Sheth and JohnA. Miller discuss how a low initial entry barrier and simple tech-nology are balanced against the long-term goal of easy integra-tion. Christoph Bussler, Alexander Maedche, and Dieter Fenselstrongly support this idea—in particular, by including semanticsin their Web Service Modeling Framework. Finally, Dennis Gan-non argues that Web services should not follow the well-wornand unsuccessful paths of other distributed-object technology.Rather, they should build on new kinds of applications, such asgrid enterprises, which are only possible using technologies suchas Web services. Have we been there before? Let’s see.

—Steffen Staab

Reference1. A. Preece and S. Decker, “Intelligent Web Services,” IEEE Intelligent

Systems, vol. 17, no. 1, Jan./Feb. 2002, pp. 15–17.

Published by the IEEE Computer Society

sider the growing list of acronyms: PDL,XPDL, BPSS, EDOC, BPML, WSDL,WSCI, ebXML, BPEL4WS—and these arejust some of the acronyms referring to vari-ous standards in the domain. Another prob-lem is that these languages typically don’thave any clearly defined semantics. Theonly way to overcome these problems is tocritically evaluate the so-called standardsfor Web services composition. In otherwords, don’t just go with the flow.

Web services compositionTwo trends are coming together in e-busi-

ness that are creating both opportunities andpressures to automate business processesacross organizational boundaries. One isthe technology push created by enablingtechnologies taking XML-based standardsand the Internet as a starting point. Theother trend is improving the efficiency ofprocesses from a business perspective.

After the dotcom crash, there was apressing need to use Internet technology’spotential by automating business processesacross enterprise boundaries. Web servicesaim to exploit XML technology and theInternet by integrating applications than canbe published, located, and invoked over theWeb. A typical example of a Web servicesapplication is the Galileo system, whichconnects more that 42,000 travel agencylocations to 37 car rental companies, 47,000hotels, and 350 tour operators.

To truly integrate business processesacross enterprise boundaries, merely sup-porting simple interaction using standardmessages and protocols is insufficient.Business interactions require long-runninginteractions that are driven by an explicitprocess model. This raises the need for Webservices composition languages such asBPEL4WS,1 WSFL,2 XLANG,3 WSCI, andBPML. These languages are also known asWeb services flow languages, Web servicesexecution languages, Web services orches-tration languages, and Web-enabled work-flow languages. Before discussing such lan-guages, I focus on the typical technology onwhich they are building.

Figure 1 shows the relation between Webservices composition languages and otherstandards such as SOAP, WSDL, and UDDI.SOAP is a protocol for exchanging informa-tion in a decentralized, distributed environ-ment using typed message exchange andremote invocation. It is an XML-based pro-tocol that consists of

• An envelope that defines a frameworkfor describing what is in a message andhow to process it

• A set of encoding rules for expressinginstances of application-defined datatypes

• A convention for representing RPCs andresponses (SOAP can potentially be builton top of any transport layer, such as anHTTP-based infrastructure)

WSDL is an XML format for describingnetwork services based on a standard mes-

saging layer such as SOAP. A WSDL docu-ment defines services as collections of net-work endpoints, or ports. WSDL separatesthe abstract definition of endpoints andmessages from their concrete networkdeployment or data format bindings. Thislets us reuse abstract definitions, includingmessages, which are abstract descriptionsof the data being exchanged, and porttypes, which are abstract collections ofoperations. The concrete protocol and dataformat specifications for a particular porttype constitute a reusable binding. Associ-

JANUARY/FEBRUARY 2003 computer.org/intelligent 73

B2B Business to BusinessBPEL4WS Business Process Execution Language for Web Services BPMI Business Process Management Initiative BPML Business Process Modeling LanguageBPSS Business Process Schema Specification Corba Common Object Request Broker ArchitectureebXML Electronic Business Using Extensible Markup LanguageEDI Electronic Data InterchangeIBROW3 Intelligent Brokering Service for Knowledge-Component Reuse

on the World Wide WebIDL Interface definition languageOMG Object Management GroupPSM Problem-solving methodRPC Remote procedure call SOAP Simple Object Access ProtocolUDDI Universal Description Discovery and Integration WfMC Workflow Management CoalitionWSCI Web Service Choreography InterfaceWSDL Web Services Description Language WSFL Web Services Flow Language WSMF Web Services Modeling FrameworkXLANG Web services for business process designXPDL XML Process Definition Language

Glossary

Transport layer:HTTP, SMTP, FTP

XML messaging layer:Simple Object Access Protocol

Service description layer:Web Services Description Language

Web services composition:Business Process ExecutionLanguage for Web Services,

XLANG,Web Services Flow Languages

Publication and discovery:Universal Description Discovery

and Integration

Figure 1. Overview of Web services technology.

ating a network address with a reusablebinding defines a port, and a collection ofports defines a service.

UDDI defines a set of services supportingthe description and discovery of businesses,organizations, and other Web services pro-viders; the Web services they make available;and the technical interfaces we can use toaccess those services. Simply put, we can useUDDI to build “yellow pages” for Web ser-vices. Consensus currently seems to exist onthe use of SOAP, WSDL, and UDDI, so Iassume these standards will remain in place.

Web services composition languagesbuild directly on top of WSDL. A languagesuch as BPEL4WS both provides and usesone or more WSDL services. A WSDL service is composed of ports that provideoperations. Each operation receives a mes-sage (one way), receives and sends a mes-sage (request response), sends and receivesa message (solicit response), or sends a mes-sage (notification). WSDL services and thecorresponding operations are glued togetherto provide composed services. To glue suchservices together, a process model mustspecify the order in which the operationsexecute. A Web services composition lan-guage provides the means to specify such aprocess model.

An important difference between WSDLand a language such as BPEL4WS is re-vealed when we consider the states. WSDLis essentially stateless because the lan-guage is unaware of states between opera-tions. The only state notion supported is the state between sending and receiving amessage in a request-response or solicit-response operation. Any technology sup-porting a Web services composition lan-guage will have to record states for processesthat are more complex than a simple re-quest response. Only by recording the statecan we determine what should be done,thus enabling long-lived business transac-tions. This has triggered the developmentof languages such as BPEL4WS, WSFL,XLANG, WSCI, and BPML.

Overview of so-calledstandards

The BPEL4WS specification1 builds onWSFL2 and XLANG.3 XLANG is a block-structured language with basic control flowstructures such as sequence, switch (for condi-tional routing), while (for looping), all (for par-allel routing), and pick (for race conditionsbased on timing or external triggers).

Unlike XLANG, WSFL is not limited toblock structures and allows for directedgraphs. The graphs can be nested but mustbe acyclic. Iteration is only supportedthrough exit conditions—that is, an activityor subprocess iterates until its exit conditionis met. The control flow part of WSFL isalmost identical to the workflow languagethat IBM’s MQ Series Workflow uses. Thismight be surprising, given that this work-flow language is very different from mostlanguages. For example, the “Death-PathElimination” allows for the so-called “Syn-chronizing merge pattern.” This way, rout-ing is not restricted to explicit AND-joinsand XOR-joins, as in most workflow prod-ucts. This is a nice feature, but it is quiteexotic and most systems don’t support it.

Although the correspondence betweenthe WSFL standard and IBM’s workflowproduct might surprise people not involvedin the standardization process, we can easilyexplain it by the fact that the same set ofpeople (most notably, Frank Leymann) havedefined both languages. We can make simi-lar comments for XLANG and Microsoft’sBizTalk Orchestrator. XLANG is based onMicrosoft’s current middleware solution andtherefore hardly qualifies as a “standard.”

Unfortunately, BPEL4WS, WSFL, andXLANG are not the only recently proposedstandards. Sun, BEA, SAP, and Intalio haveintroduced another candidate for Web ser-vices composition: WSCI. Intalio also initi-ated the Business Process Management Initiative (BPMI.org), which developedBPML. OASIS and UN/CEFACT supportebXML. Part of ebXML is BPSS, which isyet another standard similar in scope toBPEL4WS, WSFL, XLANG, WSCI, andBPML. The abundance of overlapping stan-dards for Web services composition is over-whelming. Some people refer to these com-peting standards without clear added valueas WSAH—Web Services Acronym Hell.

Outside the Web services domain, otherinitiatives are attempting to standardize the specification of executable businessprocesses. Most notable is the initiative of the Workflow Management Coalition. Since1993, the WfMC has been active in standard-izing both a workflow process definition lan-guage and the interfaces between variousworkflow components. In August 2002,the WfMC released XPDL4 to support theexchange of workflow specifications betweendifferent workflow products. According toJon Pyke, WfMC Chair and CTO of Staff-

ware, XPDL is consistent with BPEL4WSbut goes far beyond the standards for Webservices composition. Clearly, many peopleworking on standards for Web services com-position did not benefit from the experiencesin the workflow domain. Therefore, “beenthere, done that” comments are justified.

However, workflow vendors clearly havenot adopted WfMC standards. Some systemscan export to XPDL, but none can importXPDL from another system and still producemeaningful results. This is partly becauseafter work on workflow standards for morethan a decade, still no consensus exists on theworkflow constructs that must be supportedand their semantics. It is remarkable howmany different interpretations of a join con-struct exist in contemporary workflow lan-guages: “Wait for all (AND-join),” “Wait forfirst and reset (XOR-join),” “Wait for firstand block until all have arrived,” “Wait for allto come,” and so forth.

Comparing BPEL4WS, XLANG,WSFL, XPDL, and WFMproducts

With respect to Web services compositionlanguages, software vendors such as IBM,Microsoft, Sun, BEA, SAP, and Intalio havebeen the main drivers of development. Thishas resulted in an abundance of standardshaving overlapping functionality. When youlook at the standards in more detail, you cansee clearly that they are often based on exist-ing products, just as WSFL is almost a copyof the MQ Series Workflow language. Stan-dards that involve multiple software vendorsare often a compromise between competingviewpoints. Consequently, such standardstend to be imprecise or unnecessarily com-plex. WfMC’s XPDL is an example of astandard that is imprecise, thereby lettingvendors have their own interpretation of it(and making it useless). BPEL4WS joinsviewpoints from both WSFL and XLANG,thus making the language complex.

Given these observations, looking forobjective measures for comparing Web ser-vices composition languages is useful. Forthe control-flow aspect of such languages, wecan use some of the results from workflowresearch.5 One way to compare standardssuch as BPEL4WS, XLANG, and WSFL isto use the set of workflow patterns availablefrom www.tm.tue.nl/it/research/patterns.6

Each of these patterns corresponds to a rout-ing construct often required during workflowdesign.7,8 The whole set of patterns has been

74 computer.org/intelligent IEEE INTELLIGENT SYSTEMS

used to evaluate and compare about 20 work-flow management systems.

Table 1 compares three Web services com-position languages, XPDL, and four concreteworkflow management systems.6 The firstfive patterns correspond to the basic routingconstructs you can find in any language. Theother patterns refer to more advanced con-structs that most standards and products don’tsupport. Every “+” refers to direct support—meaning the language has a construct thatdirectly supports the pattern. A “–” refers tono direct support. This does not mean thatrealizing the pattern through some work-around is impossible. (For example, any ofthe constructs can be realized using a stan-dard programming language, but this doesnot imply that there is direct support for allworkflow patterns.) Sometimes there is a feature that only partially supports a pattern,such as a construct that imposes certainrestrictions on the structure of the process.

Support for such features is rated “+/–”.Without going into details, we can make sev-eral observations.

First, BPEL4WS is indeed a combinationof XLANG and WSFL when it comes to sup-porting the patterns. Second, WSFL and MQSeries Workflow are indeed identical when itcomes to process specification. Third, XPDLseems less expressive than BPEL4WS. (In a way, we can view XPDL as the greatestcommon denominator of existing workflowlanguages rather than the least commonmultiple.) Finally, Web services composi-tion languages and workflow managementsystems have relevant differences when itcomes to supporting routing constructs. Ofthe four workflow management systemslisted, only FLOWer (a workflow and case-handling system) is block structured likeXLANG. The other three systems (Staffware,MQ Series, and eProcess) are graph-basedlike WSFL and XPDL.

The Web site of BPMI.org, one of theorganizations proposing a Web servicescomposition standard, states that

BPMI.org defines open specifications such asthe Business Process Modeling Language(BPML) and the Business Process Query Lan-guage (BPQL) that will enable the standards-based management of e-Business processeswith forthcoming Business Process Manage-ment Systems (BPMS), in much the same waySQL enabled the standards-based managementof business data with off-the-shelf DatabaseManagement Systems (DBMS).

The goal of obtaining standards similar toSQL for Web services is ambitious.

As history shows, such standards do notoriginate from vendors pushing their ownproducts. Recall that the Entity-Relationshipmodel by Peter Chen and the RelationalModel by Eduard Codd enabled languagessuch as SQL. Although there are well-estab-


Table 1. Comparison of BPEL4WS, XLANG, WSFL, XPDL, and four workflow products.

MQ Series PanagonPattern BPEL4WS XLANG WSFL XPDL Staffware Workflow eProcess FLOWer

1 Sequence + + + + + + + +

2 Parallel split + + + + + + + +

3 Synchronization + + + + + + + +

4 Exclusive choice + + + + + + + +

5 Simple merge + + + + + + + +

6 Multichoice + – + + – + + –

7 Synchronizing merge + – + – – + + –

8 Multimerge – – – – – – – +/–

9 Discriminator – – – – – – – +/–

10 Arbitrary cycles – – – + + – +/– –

11 Implicit termination + – + + + + + –

12 Multiple instances without + + + – – – + +synchronization

13 Multiple instances with + + + + + + + +a priori design time knowledge

14 Multiple instances with – – – – – – – +a priori runtime knowledge

15 Multiple instances without – – – – – – – +a priori runtime knowledge

16 Deferred choice + + – – – – – +/–

17 Interleaved parallel routing +/– – – – – – – +/–

18 Milestone – – – – – – – +/–

19 Cancel activity + + + – + – – +/–

20 Cancel case + + + – – – + +/–

lished process-modeling techniques combin-ing expressiveness, simplicity, and formalsemantics (such as Petri nets and processalgebras), the software industry has chosento ignore these techniques. So, the world isconfronted with too many standards, mainly driven by concrete products or commercialinterests. The only way to stop this is toignore standardization proposals that arenot using well-established process-modelingtechniques. This will force vendors to addressthe real problems rather than create new ones.

AcknowledgmentsI thank Arthur ter Hofstede, Bartek Kiepu-

szewski, Marlon Dumas, and Petia Wohed forcontributing to the results mentioned in this essay.

References

1. F. Curbera et al., Business Process ExecutionLanguage for Web Services (Version 1.0), IBM, July 2002, www-106.ibm.com/developerworks/webservices/library/ws-bpel.

2. F. Leymann, Web Services Flow Language(WSFL 1.0), IBM, May 2001, www-3.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

3. S. Thatte, XLANG: Web Services for BusinessProcess Design, Microsoft, Redmond, Wash.,2001, www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm.

4. Workflow Process Definition Interface—XMLProcess Definition Language (XPDL),WFMC-TC-1025, Version 1.0 Beta, Work-flow Management Coalition, 2002, www.wfmc.org/s tandards/docs/TC-1025_10_xpdl_102502.pdf.

5. W.M.P. van der Aalst and K.M. van Hee,Workflow Management: Models, Methods,and Systems, MIT Press, Cambridge, Mass.,2002.

6. W.M.P. van der Aalst et al., Workflow Pat-terns, QUT tech. report FIT-TR-2002-02,Queensland Univ. of Technology, Brisbane,Australia, 2002; www.tm.tue.nl/it/research/patterns (also to appear in Distributed andParallel Databses).

7. W.M.P van der Aalst et al., Pattern-BasedAnalysis of BPML (and WSCI), QUT tech.report FIT-TR-2002-05, Queensland Univ. ofTechnology, Brisbane, Australia, 2002.

8. P. Wohed et al., Pattern-Based Analysis ofBPEL4WS, QUT tech. report FIT-TR-2002-04, Queensland Univ. of Technology, Bris-bane, Australia, 2002.

Web Services Solve Problems,and Problem-Solving MethodsProvide Services

V. Richard Benjamins, Intelligent SoftwareComponents, S.A.

In the fall of 1996, on a flight home fromthe Knowledge Acquisition Workshop, somecolleagues and I were outlining a new re-search project (an FP4 Esprit project) thataimed to link knowledge technology to theWeb. The Web was gaining importance, andknowledge technology was looking to jointhe bandwagon. We were talking about theIBROW3 project, an Intelligent BrokeringService for Knowledge-Component Reuseon the World Wide Web (see www.swi.psy.uva.nl/projects/IBROW3/home.html).

The project envisioned reusable heteroge-neous components located at repositories onthe Web, which a broker (or software agent)would configure into a distributed programto solve a particular problem. The brokertherefore had to know about the problemand the individual components’ capabilities.The brokering process’s result would be adistributed system that could, for example,classify edible and poisonous mushroomsusing a public mushroom database and aclassifier, both available on the Web.

The components that the IBROW projectconsidered were problem-solving methodsand ontologies. A PSM is a generic descrip-tion of a reasoning process, independent ofthe domain to which it is applied. A PSMmight solve classification tasks, for exam-ple, by classifying mushrooms, diseases, orfinancial transactions. Before we can applya PSM to a particular domain, we have tocheck its assumptions, which describe thedomain model’s required characteristics.

For example, the establish-and-refinePSM, which B. Chandrasekaran introducedin the late 1980s, requires hierarchically orga-nizing the domain knowledge. The PSM’sassumptions capture the interaction betweenthe PSM and domain knowledge explicitlysuch that reusing each of them in different sit-uations becomes less troublesome. One mainmotivation behind research on PSMs andontologies in the 1990s was to increasinglyreuse and share code rather than develop codefrom scratch for each new problem.

Web servicesWe also see this motivation in Web

services—pieces of software available on

the Web that people can access through astandard protocol and execute remotely.Furthermore, when used together, Web ser-vices can deliver a complex functionality.

The three major ingredients for Web ser-vices are a description of the service, whichuses the WSDL; the XML protocol SOAP,through which users access the services; anda UDDI directory, where you can find whatWeb services are offered and where. (For anexplanation of these and other acronyms, seethe “Glossary” sidebar.) With those ingredi-ents in place, anybody can use a Web service,regardless of the programming language inwhich the service was originally defined.

Web services thus tackle the problem of heterogeneous sources and make them interoperable. Technologies such as Corba,RPC, and EDI had the same objectives, but those solutions needed their proper (that is,specific or dedicated) infrastructure, withthe corresponding costs and implementationefforts. We can thus explain the success ofWeb services by viewing them as a technol-ogy based on maximal decoupling (and thusmaximal reusability) available over an exist-ing economic infrastructure (the Internet).Their power is not so much in their technol-ogy (the idea of RPC is nothing new) butrather that they offer a Web-native XML-based solution. So, we can rapidly design,implement, and deploy Web services.

These characteristics make Web servicesan interesting candidate for integrating het-erogeneous enterprise applications. Organi-zations spend a lot of money making theirinternal systems interoperate with theirpartners’ and providers’ enterprise applica-tions—and sometimes even with their inter-nal applications. Web services offer an inter-esting alternative because they wrap existing(legacy) systems and let them communicatethrough SOAP over existing infrastructures(extranet or intranet). This is probably whyresearch analysts at companies such as theGartner Group and McKinsey are monitor-ing developments in this area.

The Semantic WebHaving said all these nice words, I must

admit that current Web services technologysolves only part of the problem. Distributedsystems developers now have a commonplatform for rapidly developing or integrat-ing complex software by configuring exist-ing services. Through UDDI, they can lookup the basic services they need expressedin WSDL, which they then can access by


programming SOAP. However, a personmust do all this work, and without muchsupport. As more Web services becomeavailable, information overload will makefinding the service you need difficult.

To overcome these problems, we mustfirst recognize that current Web servicestechnology is basically a syntactical solu-tion and that the semantic part is still lack-ing. A Web service is described in WSDL,outlining what input the service expectsand what output it returns. To exploit theirpotential (beyond enterprise applicationintegration), Web services must be able toorchestrate themselves into more complexservices. Thus, we need ways to combineindividual Web services into a distributed,higher-level service.

The Web Service Flow Language, whichcan express the sequencing of individualservices, is taking the first steps. WSFL letsthe user decide which Web services tocombine and in what order. However, westill need a framework that semanticallydescribes services, such that softwareagents can locate, identify, and combinethe services.

This is where the Semantic Web comesin. It semantically describes (annotates)content available on the Web such that soft-ware agents can understand and process theinformation. In this manner, Web servicesshould form part of the Semantic Web (www.

semanticweb.org). They would need asemantic characterization of the servicesthey offer as well as a middleware for servicediscovery and orchestration, to hide complextechnology from users. A user can thus con-sume a high-level functionality withoutnoticing that a complex process is going onunder the hood. This is a main objective ofthe Semantic Enabled Web Services project(SWWS, swws.semanticweb.org)—todevelop such intelligent middleware alongwith a language to semantically expressWeb services capabilities.

If we look back at the original IBROWproject (www.ibrow.org), we see that itresembles the SWWS project in particularand the Semantic Web in general. Table 2illustrates this, showing some phrases andterms from the IBROW project and the cor-responding terms used in current SemanticWeb research projects.

We are now entering FP6, the SixthEuropean Research Framework Program.In addition, the IBROW projects (one inFP4 in 1998 and the current one in FP5from 2000–2003) are about to finish. Sincethese projects began, many things havechanged. The Web has drastically changedhow we communicate, do business, andobtain information (where Google is theruling champion). A revolution of newtechnologies has overtaken the IBROWproject, such as Semantic Web technology

and Web services. However, IBROW hasplayed a crucial role in identifying relevantissues and major challenges and in bring-ing together the key people and groups thatnowadays lead the European effort inSemantic Web services research.

The notion underlying Web services isnothing new. In this sense, it is “been there,done that.” However, the infrastructure wecurrently count on is much more advancedthan several years ago. In IBROW, we spentmuch effort making the underlying infra-structure work and creating the (heteroge-neous) content. This hampered us fromfocusing completely on the real issues, suchas semantic interoperability. In the currenttechnological situation, coupled with a strongbusiness pull (PSMs were more of a tech-nology push from the knowledge-engineer-ing community), we soon will have Web-accessible methods that solve real businessproblems through knowledge-intensive orintelligent Web services.

AcknowledgmentsI would like to acknowledge the IST projects

IBROW (IST-1999-19005), Esperonto (IST-2001-34373), and SWWS (IST-2001-37134).


Table 2. Resemblance between IBROW, on the one hand, and the Semantic Enabled Web Services project and the Semantic Web in general, on the other hand.

IBROW3 (Esprit FP4); IBROW (IST, FP5) The SWWS project, Semantic Web Comments

The Web is changing the nature of software Web services are orchestrated into In IBROW, problem-solving methods development to a distributive plug-and-play process. complex services. (PSMs) and ontologies were the The components concerned are problem-solving components being configured, versusmethods (generic algorithms) and ontologies. Web services today.

PSMs and ontologies Web services PSMs and ontologies, when connectedto the Web, deliver services. PSMs deliverreasoning services, while ontologies enableintelligent query answering.

IBROW integrates research on heterogeneous Semantics and enterprise application Web services can wrap heterogeneous sourcesdatabases, interoperability, and Web technology integration to make them interoperable.with knowledge-system technology and ontologies. Semantic agreement is currently hard coded

in the wrapper.

The project aims at providing intelligent From information overload to task The current paradigm of information retrieval reasoning services on the Web as opposed delegation causes much information overload. to the more common information services. We need to delegate tasks to agents such that

people focus on the interesting information.

The broker needs to reason about Annotation of services, WSMF, UPML is used to characterize ontologies and characteristics of PSMs, for example about DAML-S PSMs in terms of their competence (capabilities) their competence: Unified Problem-Solving and requirements.Method Description Language (UPML)

Web Services: TechnicalEvolution yet PracticalRevolution?

Amit Sheth and John A. Miller,University of Georgia

Web services are here to stay. Both busi-ness and technical considerations will pro-vide them with the staying power and tail-wind to survive the hype. Despite their lackof a major technical breakthrough, Webservices will initially succeed owing to theright confluence of evolutionary tech-nological choices, low barriers and entrycosts, and their strong standards-basedapproach. In the long run, however, theymust be empowered by semantics and cou-pled with Semantic Web technologies tofulfill broader, longer-term promises.

Evolution in the rightdirection: Reasons for likelysuccess

Progress in software componentry hasbeen ongoing. The Web is becoming morethan just a collection of documents; appli-cations and services are coming to the fore-front. History shows that incremental tech-nological progress can produce dramaticeffects, such as the advancement from FTPto Archie to Veronica to the Web. Web ser-vices might have a similar fate.

Several technical and technology-drivenbusiness advantages present themselves,boding well for a quicker and more success-ful adoption of Web services.

Low initial complexityThe first consideration is the low initial

complexity (although the complexity offully mature technology might be substan-tially higher), with low entry barriers andcosts. Although the Web now consists ofmany components and technologies—sev-eral of which were added as the Web gainedwider acceptance and matured—it indeedstarted with a remarkably small, simplecore technology. That simple core—freeavailability and low- or no-cost initial adop-tion—played an important role in its growthand acceptance.

Unlike the Web, the Corba architecturewas complex from the start (considering itsvarious services and facilities) and requiredseasoned developers to use it. Also, mostbusinesses had to rely on object requestbrokers that were not free, which made

starting pilot projects—something largebusinesses always do before adopting anynew technologies—difficult.

However, like the Web, the basic compo-nents of Web services are relatively simple,and the learning curve is low. XML isalready known to the likely adopters andaccepted as the data exchange standard byenterprises. Standards such as SOAP andWSDL are simple to use and learn. (For anexplanation of these and other acronyms,see the “Glossary” sidebar.) AlthoughUDDI as a whole (with all the details ofwhite, yellow, and green pages) is not sim-ple, the basic parts needed to get started arerelatively easy to learn and use. Also, Webservices can be developed with essentiallyno initial technology cost. Furthermore,just as the Web is used not only for publish-ing or sharing data but also as an applica-tion infrastructure, the complexity of Webservices can be incrementally increased asmore functionality is added.

The hypeThe second consideration is the hype sur-

rounding Web services, and the industry’sability to sustain interest over time. ConsiderXML. Although it has been significantlyhyped—for example, it only addresses thesyntactic interoperability issues, not seman-tic ones—it has succeeded. This is becauseit solves a limited yet important and well-understood business problem, and there is agroundswell of commercialization effortsaround the use of XML technology. Someenterprise software such as EnterpriseResource Planning quickly adopted XML,broadening its adoption by businesses. Incomparison, corresponding commercialactivities did not support the hype of expertsystems and other artificial intelligencetechnologies.

In the case of Web services, various soft-ware segments, including application serversand Enterprise Content Management,1 havefound them worthy enough to adopt. Thisgives the hype of Web services an ability tosustain with follow-through developmentand adoption.

StandardsThe third consideration is the use of more

widely accepted standards. XML alreadyenjoys wide adoption in enterprises. Stan-dardization efforts are well aligned and arestructured to act much faster than what hap-pened with Corba. Some in industry also

see Web services as a natural follow-up toElectronic Data Interchange and ebXML,which already have significant commercialsuccess.2

Loosely coupled architecturesThe fourth consideration is that Web ser-

vices are a good choice for loosely coupledarchitectures.3 This means not allowingobject references or requiring statefulness.Although the Corba architecture was moresuitable for intra-enterprise environments,the technical features and choices of Webservices make them more reusable and thusmore appropriate for interenterprise andglobal environments.

LanguagesFinally, Web services do not use languages

that look like programming languages (thatis, there’s no interface definition language).This is what the industry is trying to accom-plish with Web services.

Incremental advances insoftware componentary

The introduction of the object-orientedprogramming paradigm in the 1980spromised to make reusable software compo-nents a reality. Although there were certainlysome gains in software reuse and program-ming productivity, the change was not sub-stantial. The 1990s saw further attempts toincrease software reuse, focused on the ideaof software components and extended to dis-tributed components. A notable effort in thisarea was Corba. It let components on differ-ent machines, using different operating sys-tems and even different languages, commu-nicate. From one viewpoint, Web servicesrepresent an evolution of Corba. We contendthat Web services are more convenient thanCorba and that eventually incrementalimprovement will lead to widespread use.

One difficulty in using distributed tech-nology such as Corba is dealing with lan-guages. Corba tried to eliminate this problemby moving the language into the back-ground by defining an IDL. Although this isa good idea, an IDL looks much like C++,and developers must also understand lan-guage bindings to use Corba. If there was away to replace language-like IDLs withhigher-level specification, surely communi-cation could be simplified using meaning-ful messages. Fortunately, Web services,defined as “self contained, self-describingmodular applications that can be published,


located, and invoked across the Web,”4

automatically get the Web-wide scoperather than primarily the enterprise-widescope (at least initially) for Corba. In thenear term, we see the use of a few well-tar-geted Web services within and across enter-prises for well-targeted B2B applicationsand as integration points between enterprisesoftware. Examples include integrating adocument management system and portalmanagement system within an enterprise, orinterenterprise interfaces between differentparts of a supply chain or ERP solution,which already uses XML for data exchange.

Intermediate to long term:Processes, QoS, security, andsemantics

For the intermediate term, we predictdistinct advances in

• Web processes • Technical support for quality of service • Technical support for security

Although we expect researchers to addressQoS and security in the intermediate term, weexpect support for Web processes to takelonger, because initial research is just startingon these topics.5 Because Web services arecomponents, if individual services are limitedin their capability, we can compose existingWeb services to create new functionality inthe form of Web processes. Web service com-position is the ability to take existing services(or building blocks) and combine them toform new services.6 In carrying out this com-position task, we should be concerned aboutthe efficiency and the QoS that the composedprocess will exhibit when it executes. Thistask of composing services to create efficientWeb processes is analogous to designing aworkflow.

Web service composition is an active areaof research, with academic and industrialresearch groups proposing many languages.IBM’s WSFL7 and Microsoft’s XLANG8

were two of the earliest languages to definestandards for Web services composition.Both extended WSDL, W3C’s standard lan-guage used to describe the syntactic aspectsof a Web service. BPEL4WS9 is a recentlyproposed specification that represents themerging of WSFL and XLANG. It combinesWSFL’s graph-oriented process representa-tion and XLANG’s structural construct-based processes into a unified standard forWeb services composition. Another effort in

this area is ebXML, which lets enterprisesconduct business over the Internet using anopen XML-based infrastructure.

In contrast to these commercial XML-based standards, researchers are developing aunique Web service markup language calledDAML-S.10 According to the group of re-searchers working on DAML-S, it suppliesWeb service providers with a core set ofmarkup language constructs for describingthe properties and capabilities of their Webservices in unambiguous, computer-inter-pretable form. DAML-S markup of Web ser-vices will facilitate the automation of Webservice tasks including automated Web ser-vice discovery, execution, interoperation,composition and execution monitoring.10

If Web services are to provide not onlyan enterprise-wide but also a global archi-tecture for application interoperability andintegration, we will need to enhance Webservices and processes with semantics.Many applications will require a Webprocess created from composing severalWeb services. In the intermediate term, wecan create enterprise-scale Web processes(or service compositions) by adoptingworkflow management technology. How-ever, to achieve Web services’ full Web-wide and global potential, semantics holdsthe trump card. Using semantics involvesdescribing resources with formal, machine-readable description. Resources in this caseare Web services, and given that they wrapapplications, they must be described bothfunctionally and operationally.

As already recognized by DAML-S,10

Web Service Modeling Framework ini-tiatives,11 the Work Group on Web Servicesat a recent Semantic Web workshop,12 andothers, semantics can play a critical role indeveloping Semantic Web services. This canlead to better discovery of Web services forreuse in a global, Web-scale environmentthat is not limited to one enterprise or a staticcollection of enterprises and where currentsyntax-based techniques do not work. Strongsupport for Web services discovery is also aprerequisite to developing Web processes13,14

and addressing various issues of composi-tion, interoperability, and execution.15,16

There is demonstrable progress in develop-ing semantics-based solutions when dealingwith data, such as to achieve better interoper-ability and integration of information re-sources. However, the challenges of dealingwith applications that are enabled by Webservices are even more difficult. They will

involve substantial further research and engi-neering that consider both functional andoperational perspectives. The Large ScaleDistributed Information Systems Lab’sMeteor project is one of the projects lookingat developing semantics-based solutions toQoS, discovery, and composition issues inthe context of Web processes (see http://lsdis.cs.uga.edu/proj/meteor/SWP.htm).

References1. R. Perry and R. Lancaster, Enterprise Con-

tent Management: Expected Revolution orVendor Positioning, The Yankee Group,Boston, 2002.

2. A. Kotok, “ The E-Business Continuum: WebServices, ebXML and EDI,” WebServices.Org, June 2002, www.webservices.org/index.php/article/articleview/479/1/24.

3. D. Austin et al., “Web Services ArchitectureRequirements,” World Wide Web Consor-tium, 2002, www.w3c.org/TR/wsa-reqs.

4. D. Tidwell, “Web Services—The Web’s NextRevolution,” IBM tutorial, 29 Nov. 2000,www-105. ibm.com/developerworks/education.nsf/webservices-onlinecourse-bytitle/BA84142372686CFB862569A400601C18?OpenDocument.

5. J. Cardoso and A. Sheth, Semantic e-Work-flow Composition, tech. report, Large ScaleDistributed Information Systems Lab, Dept.of Computer Science, Univ. of Georgia,Athens, Ga., 2002.

6. G. Piccinelli, Service Provision and Composi-tion in Virtual Business Communities, tech.report HPL-1999-84, Hewlett-Packard, PaloAlto, Calif., 1999; www.hpl.hp.com/techreports/1999/HPL-1999-84.html.

7. F. Leymann, “Web Service Flow Language(WSFL) 1.0,” IBM,Armonk, N.Y., 2001, www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.

8. S. Thatte, “XLANG: Web Services for Busi-ness Process Design,” 2001, www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm.

9. F. Curbera et al., “Business Process Execu-tion Language for Web Services,” 2002, www-106.ibm.com/developerworks/webservices/library/ws-bpel.

10. A. Ankolekar et al., “DAML-S: Web ServiceDescription for the Semantic Web,” Proc. Int’lSemantic Web Conf., Springer-Verlag, Berlin/Heidelberg, 2002, pp. 348–363.

11. D. Fensel and C. Bussler, “The Web ServiceModeling Framework WSMF,” 2002, http://informatik.uibk.ac.at/users/c70385/wese.


12. A. Sheth and R. Meersman, “AmicalolaReport: Database and Information SystemsResearch Challenges and Opportunities inSemantic Web and Enterprises,” ACM SIG-MOD Record, vol. 31, no. 4, Dec. 2002.

13. S. Narayanan and S. Mcllraith, “Simulation,Verification and Automated Composition ofWeb Services,” Proc. 11th Int’l World WideWeb Conf., W3C, 2002, pp. 77–88.

14. J. Cardoso et al., Modeling Quality of Servicefor Workflows and Web Service Processes,tech. report, Large Scale Distributed Infor-mation Systems Lab, Dept. of Computer Sci-ence, Univ. of Georgia, Athens, Ga., 2002.

15. J. Cardoso et al., “Semantic Web Services andProcesses: Semantic Composition and Qual-ity of Service,” tutorial at Federated Confer-ences (CooPIS, DOA, ODBASE), 2002; http://lsdis.cs.uga.edu/lib/presentations/SWSP-tutorial-resource.htm.

16. S. Chadrasekaran et al., Composition Perfor-mance Analysis and Simulation of Web Ser-vices, tech. report, Large Scale DistributedInformation Systems Lab, Dept. of ComputerScience, Univ. of Georgia, Athens, Ga., 2002.

Web Services: Quo Vadis?

Christoph Bussler, Oracle CorporationAlexander Maedche, FZI Research Center for Information Technologies at the University of KarlsruheDieter Fensel, Leopold Franzens Universität Innsbruck

Web services have been touted for sometime now as the technology-based silverbullet solution for many significant integra-tion problems in information technology.These integration problems are of so differ-ent a nature due to the specific requiredfunctionality that we can’t avoid askingright now, “Web services: Quo vadis?”

Here, we illustrate the immense discrep-ancy between the magnitude of the integra-tion problems and the simplistic functional-ity that Web services provide. We proposethe WSMF as the future direction of Webservices so that they can cope even with themost real complex integration problems.(For an explanation of this and otheracronyms, see the “Glossary” sidebar.)

Web services at the crossroadsLet’s spotlight the state of the art of

Web services and the situation of the“movement” (or “hype,” as some might be

more than happy to state). For the follow-ing reasons, we see Web services as beingat the crossroads:

• They have been touted as the silver bul-let for a (too) wide array of integrationproblems, currently being addressed bycomplex integration solutions such asB2B integration technology1 as well assimple technology such as Java forremote server invocation.

• Many competing, conflicting, andoverlapping standards exist that addressWeb service functionality (see www.oasis-open.org/cover/sgml-xml.html).

• Many research projects are repackagingexisting work as Web services work.

• Many start-up companies, including CapeClear (www.capeclear.com), Actional(www.actional.com), and Intalio (www.intalio.com), provide technology imple-menting Web services technology.

• Major infrastructure companies (such as BEA, IBM, Microsoft, and Oracle)already provide implementations of Webservice technology.

• Broad journalistic coverage of Web ser-vices exists in the trade press, such aseAI Journal (www.eaijournal.com) andebizQ (www.ebizq.net).

• Web services have no underlying realconceptual integration model and areonly defined as an implementation tech-nology, such as SOAP (see www.w3.org/TR/soap12-part1/ and www.w3.org/TR/soap12-part2).

• No one has analyzed available and provensolutions such as EDI translation technol-ogy2 or reported on lessons learned fromdeployments that could advance Web ser-vices technology functionality (morethan 300,000 Electronic Data Interchangedeployments exist worldwide—see www.disa.org/x12org/about/faqs.cfm).

This situation cannot continue indefinitely.We must consolidate the Web services space,focusing Web services technology on awell-defined and well-manageable set ofintegration problems. This includes theconsolidation of the multitude of Web ser-vice standard proposals. Current Web ser-vices expectations are too high and too var-ied for one technology to solve all thegiven integration problems.

The silver bullet problemsHere we discuss some of the silver bullet

problems, clearly showing the vast spectrumthat Web services are said to solve.

First, SOAP was originally the acronymfor the Simple Object Access Protocol.Nomen est omen (the term reveals its intent):the underlying paradigm follows the client-server model. The SOAP specification inconjunction with WSDL (see www.w3.org/TR/wsdl) clearly enables the definition of theexternal interface of a server in a particularway but not of its clients, violating the gen-eral peer-to-peer approach that most integra-tion solutions require. The only pattern thissupports is the one-way invocation with andwithout results between the defined roles ofclient and server.

In this sense, SOAP, in conjunction withWSDL, clearly implements yet anotherRPC model. This is also explicitly calledout in the SOAP specification. Because itis based on the ubiquitous HTTP protocolin conjunction with XML as the messagesyntax, computer system boundaries areeasy to overcome and the notion of the“better RPC” or even “better distributed-object-management technology” was born,leading to the wide awareness of Web ser-vices in the developer community.

Second, because SOAP messages can betransported over HTTP to implement theruntime invocation, bridging computer sys-tem boundaries is clearly easy owing to thecommodity of the HTTP protocol. If onlypackaged applications like EnterpriseResource Management systems, such asOracle or SAP (www.sap.com), were toexpose WSDL interfaces, then integratingthem with Web services would be easy,fast, cheap, manageable, and so on (betteralong all possible dimensions).

In such a scenario, Web services wouldbe the “better Enterprise Application Inte-gration solution,” overcoming the currentcostly integration technology deployments.This is because the whole integration worldwould be a nice homogeneous sea of SOAPmessages implementing WSDL operationinvocations.

Finally, because we can easily exchangeSOAP messages over the Internet, the pro-posal of using Web services as the only andsuperior way to implement B2B interactionsbetween companies (interenterprise B2Bcommunication) is not far off. The vision inthis case is to very rapidly replace EDI,SWIFT (Society for Worldwide InterbankFinancial Telecommuication, www.swift.com), and other existing B2B standards


(some of which have existed for over 30years).

These three example integration problemsalone span an impressive array of seriousrequirements for an integration solution thatWeb services would have to address:

• Efficiency: To scale on an industrialbasis, Web services execution must bevery efficient.

• Expressiveness: B2B interactions in sup-ply chain scenarios are complex, requir-ing an expressive set of supported inte-gration concepts.

• Security: Interactions within as well asacross enterprises must be secured toprevent security attacks of all types, andnonrepudiation must be provided forreliable record keeping.

• Reliability: Remote and distributed com-munication must be reliable, and mes-sages must be sent exactly once to ensuredependable interactions.

• Manageability: Interenterprise commu-nication changes frequently, requiringeasily manageable technology.

These requirements pose a high demand on a technology that addresses their implementation.

On the other side, we have the currentstate of Web services technology. Thefollowing standards currently define Webservices: SOAP, WSDL, and UDDI (seewww.uddi.org). This standards triple, even iffully implemented, is far from addressingeven a subset of the requirements we’velisted, because it is based on the primitivenotion of synchronous remote invocationfollowing a simple client-server model.Complex integration problems, such as B2Bintegration problems based on a peer-to-peerparadigm, are not at all in the scope of thestandards triple owing to missing integrationconcepts, missing reliability protocol defini-tions, or missing security concepts.

Because Web services have caught onvery impressively across the developer andbusiness community, it is worthwhile explor-ing potential future developments to capital-ize on the state Web services have reached.

Directions leading from thecrossroads

We can only ask where to go from here ifthere are alternative paths going forward.Possible directions for Web services includeit being

• The better RPC• The better plumbing for application-

to-application or B2B integration• The better intelligent agent platform• All of the above

There seems to be the implicit agreementin the community that Web services shouldbe “the” new and “the” better technology forintegration (especially for B2B integration).For instance, together, the vast array ofindustrial-standard proposals appears to pro-vide an almost complete set of conceptsrequired for implementing complex B2Bintegration. Examples of such integrationinclude supply chain management, healthcare organization integration, or financialtransaction processing.

Zapthink (www.zapthink.com/reports/poster.html#) has a poster that shows 135 ofthe 450 (at its time of publication) industrialstandards and standards proposals classifiedand related to each other. They define busi-ness documents, security services, transportprotocols, packaging, trading partner man-agement, and many other relevant standards.

However, it’s not just industry that isworking on a complete set of standardsaddressing the complete integration space.Academic research is also tackling the vastarray of problems in interenterprise integra-tion, as we’ve seen at workshops such asTechnologies for E-Services (TES 2002) orthe Workshop on Web Services, E-Business, and the Semantic Web (WES2002), or in certain research papers.3–5

Even more important, the big “however”is that the need for 135 (or 450) standardsindicates a broken conceptual model,because the standards conflict, contradict,

overlap, compete, or disagree with eachother significantly. Another big “however”is that these efforts haven’t really consideredsemantic unification at all. Only a few con-tributions (standards and research) highlightthe need to solve the semantic mismatchproblem that inherently exists in interenter-prise integration and that no real integrationsolution can do without.

So, we need a comprehensive conceptual-integration model that combines all aspectsof a solution for the interenterprise as wellas intra-enterprise integration problem.From that we can derive a comprehensivemodeling and execution framework that canaddress even the most complex integrationproblems completely.

Such a framework must provide a holis-tic and general conceptual-integrationmodel that characterizes all integrationproblems. From that we can derive a set ofexpressive modeling constructs that modelWeb services, their invocation, and otherrequirements such as composition andsecurity, addressing even the most complexintegration scenarios. Furthermore, such aframework must provide an expressive andscalable mediation approach that can tacklethe semantic unification problem throughpowerful mediation.

The future of Web services:WSMF

Web services that can address complexintegration problems require conceptualmodeling based on a well-defined set ofintegration concepts. This set of conceptsmust be able to represent all relevant aspectsof integration, including document formats,processes, security, trading partner manage-ment, mediation, and discovery.

Because integration always occurs be-tween two or more parties that are exposingservices, any integration solution is “inbetween” the parties. This calls for an inte-gration framework that clearly identifiessystem boundaries and modes of interactionbetween all elements. Furthermore, it mustdefine the execution model for the concep-tual model so that the application of conceptsis uniform.

Last but not least, we need a methodol-ogy that suggests best practices for themodeling task when integrating services ofseveral parties. The methodology suggestsappropriately using integration concepts.

The WSMF is an important step towardsuch a conceptual model in conjunction


Web services that can address

complex integration problems

require conceptual modeling

based on a well-defined set of

integration concepts.

with an integration framework and method-ology.6 It provides all the integration conceptsnecessary for modeling even the most com-plex integration scenarios. It also provides aframework that defines the meaning of theconcepts and suggests a methodology.

The major aspect of WSMF is, besides themere definition of complex Web services, astrong support for mediating data as well asinteraction behavior (message exchange pat-terns). In general, different services exposebusiness data following different schemasand expect different message exchange pat-terns. For two or more services to interact,the differences in data structure and meaningas well as in message exchange behaviormust be mediated. WSMF recognizes a sig-nificant set of mismatch patterns and providesmediation support. Only after the mediationproblem is solved does integration becomepossible.

For Web service integration and Webservices mediation to scale, the integra-tion concepts must be represented as aformal language so that particular Webservices definitions are self describing,machine interpretable, and machine exe-cutable. Ontologies are a suitable tech-nology for this purpose, owing to theirability to represent semantics in the formof concepts.

The formal representation of services, theirdata, and their behavior are a precondition forautomatic Web services registry, discovery,and composition. Only a strictly formalapproach allows automatic and meaningfulWeb services composition. UDDI is far fromproviding such a formal mechanism today,and WSMF can serve as an important inputto this necessary development.

With WSMF as a foundation, service-oriented architectures and computing be-come possible where all elements thatrequire integration are represented as ser-vices. Once a service is formally defined,it is registered and can be discovered andcomposed to achieve its integration forbusiness goals such as supply-chain auto-mation. WSMF provides the formal foun-dation that allows service-oriented archi-tectures to be executable in a complexbusiness world.

We therefore strongly suggest that Webservices will choose the path toward anintegrated, complete conceptual-integrationmodel supported by a framework definingthe execution semantics and a methodologyfor successful definition of integration.

References1. C. Bussler, “The Role of B2B Engines in B2B

Integration Architectures,” ACM SIGMODRecord, vol. 31, no. 1, Mar. 2002.

2. M. Sherif, Protocols for Secure ElectronicCommerce, CRC Press, Boca Raton, Fla.,2000.

3. F. Casati, M. Sayal, and M.-C. Shan, “Devel-oping E-Services for Composing E-Services,”Proc. 13th Int’l Conf. Advanced InformationSystems Eng. (CAISE 01), Lecture Notes inComputer Science, no. 2068, Springer-Ver-lag, Berlin, 2001, pp. 171–186.

4. C. Bussler, “The Application of WorkflowTechnology in Semantic B2B Integration,”Distributed and Parallel Databases, vol. 12,nos. 2–3, Sept.–Nov. 2002, pp. 163–191.

5. A. Maedche and S. Staab, “Services on theMove: Towards P2P-Enabled Semantic WebServices,” to be published in Proc. 10th Int’lConf. Information Technology and Travel &Tourism (ENTER 2003), Springer-Verlag,Berlin, 2003.

6. D. Fensel and C. Bussler, “The Web ServiceModeling Framework WSMF,” ElectronicCommerce Research and Applications, vol.1, no. 2, 2002.

From Web Services to Grid ServicesDennis Gannon, Indiana University

There are two common criticisms of theWeb services model. The first is that Webservices define a mechanism for doing RPCson an implementation of some XML-speci-fied interface, using a slow protocol calledSOAP. (For an explanation of these and otheracronyms, see the “Glossary” sidebar.) Thisconcept appears to be a second-rate reinven-tion of OMG’s Corba or Java remote methodinvocation.

The second criticism is that the WorldWide Web works, and Corba and the otherdistributed-object technologies are all hope-less failures. Web services are just trying todrive the Web down the same path to doomas these other RPC disasters.

As is the case with most folk wisdom(and other less benign forms of oversimplifi-cation), these statements contain some truth.In fact, attempting to use the Web servicesframework as a replacement for Corba ortrying to use it to redo what Web technolo-gies already do well is folly. What the Webservices architecture brings to the table is a

highly extensible, message-oriented middle-ware for building distributed, composableservices. To illustrate this point, I look athow it is being used to build a componentarchitecture for applications and services thatmakes ubiquitous grid computing a reality.

Grid computingThe concept of grid computing grew out

of attempts to build large-scale distributedapplications that group remote super-computers, databases, and online instru-ments into tools used by groups of collabo-rators. Examples include the Particle PhysicsData Grid and GriPhyn (www.griphyn.org),which involves a widely distributed team ofphysicists working to analyze the datastreaming out of large international particlephysics projects. Another example is theNetwork for Earthquake Engineering Simu-lation Grid (www.neesgrid.org), which is anational virtual collaboratory for earth-quake engineering. A third example beingorganized is the Linked Environment forAtmospheric Discovery, which will providethe tools to do “better than real-time” de-tailed prediction of severe storms, such astornadoes, based on the adaptive coupling ofinstruments, databases, and massive super-computer simulations. Disciplines such asastrophysics, genomics and proteomics, andchemical engineering are building manyother grid applications and testbeds.

To enable a distributed team of collabora-tors to build these applications, grids needan infrastructure of ubiquitous services thatmanage the resources provided to them.These services include

• Security services: Grid users need a wayto authenticate themselves, and servicesare needed that reveal what the user isauthorized to do. Privacy is also a seriousconcern for many grid collaborations.

• Scheduling services and resource brokers:If a grid application needs to use a dis-tributed set of resources (such as advancedinstruments, supercomputers, and data-bases) in a linked computation, the usermust schedule these resources for con-current use.

• Information and data services: Manylarge scientific applications requirenumerous data archives that are distrib-uted around the world. These must becataloged, indexed, and provided to the user to make information accesstransparent and ubiquitous.


• Workflow services: Grid applicationsusually require a complex set of interac-tions between many services and re-sources. For example, data must beextracted from instruments and thenfarmed out to data mining services orused as input to numerous simulationswhose output is correlated to other sen-sor data. Orchestrating these tasks is theworkflow engine’s job.

• Monitoring, messaging, and logging ser-vices: Grids are complex and dynamic.At any given time, some component willbe down or temporarily unavailable.Hence their applications must rely onautonomic services that keep track ofalternate resources, redundant computa-tions, and better network routes.

Many more standard grid services exist.The research community defining thesestandards is called the Global Grid Forum(see www.gridforum.org). Consisting ofabout 30 working groups and researchgroups and about 600 individuals, GGFmeets three times a year. It occupies a placein the grid-computing world similar to thatof the IETF for the Internet and W3C forWeb standards. GGF depends on both theIETF and W3C because it builds onstandards both groups are developing.

In GCF’s early days, the standards wereconsidered in isolation and often imple-mented in very different ways by differentorganizations. However, the emergence ofWeb service standards has changed that. IanFoster, Carl Kesselman, Jeffrey M. Nick, andSteven Tuecke proposed the Open Grid Ser-vice Architecture as an extension of Web ser-vices to build a true component frameworkfor the Grid.1 By looking at OGSA, we cansee where many of us believe Web servicesstandards will evolve.

Web servicesA conventional Web service consists of

• A set of types, which are usually describedwith XML schema documents

• Messages, which are XML elementsconsisting of a set of typed and namedparts

• Operations, which can have an inputmessage, a response output message,and possibly a fault message

An operation with an input and outputmessage is called a solicit response operation,

and an operation with only an input messageis a one way message. Web services also con-tain port types, which group together a set ofoperations; bindings, which are associationsbetween port types and transport and encod-ing protocols; and ports, which associate aname, binding, and network location.

WSDL provides an extensible schemafor encoding all these elements to define aspecific Web service (see www.w3.org/TR/wsdl). A complete WSDL document of aservice is usually enough to generate thecode needed to access that service—that is,it is a service reference. The standard pro-tocol most services use is SOAP overHTTP; however, that is not a requirement.Because operations can be one-way and

messages can be almost arbitrary docu-ments, it is possible to implement a serviceover just about any transport protocol suchas email, Corba Internet InterOperabilityProtocol, or a peer-to-peer protocol such asSun’s JXTA.

Another advantage of Web services is thatthe specification says little about the wayservices are actually implemented. Open-source and commercial toolkits exist forbuilding Web services from standard Java,Enterprise JavaBeans, C/C++, Python, andC# using .NET.

The GGF Open Grid Service Infrastruc-ture working group, led by Steve Tueckeand David Snelling, has taken advantage ofWSDL’s extensibility to define a grid ser-vice component model. OGSI defines astandard set of port types that grid servicessupport and that applications can expect.One port type that every grid service mustsupport is called the grid service, whichprovides a basic, essential introspectionmechanism for services. Each grid service

supports a set of Service Data Elements,XML documents that describe the servicemetadata and its state. The grid service portprovides every grid service with two typesof operations. One operation lets clientssearch the service’s SDEs to answer ques-tions such as

• What other port types do you support?• What other SDEs do you support? • What status and state information can

you provide?

The other operation involves servicelifetime management.

In his PhD dissertation, Roy Fieldingdescribed the Representational StateTransfer model, based on the principlesthat have helped the Web achieve success.2

REST emphasizes a few verbs applied tomany nouns. The verbs in the Web are theHTTP operations, such as GET. The nounsconsist of the network of URLs that consti-tute the Web. The REST model assignsmost of an operation’s semantics to thedata, rather than to the operation’s name.The grid service specification uses themessage and document delivery model ofWeb services framework to achieve a simi-lar goal. The grid service port provides asimple mechanism to convey informationthrough service data elements rather thanthrough complex interfaces of methodsand parameters.

Every grid service is represented by aGrid Service Handle, which is a universalresource identifier that can be resolved intoa specific Grid Service Reference, whichmight be the WSDL for the service instance.Using a separate URI handle lets services beeasily replicated or maintained and still havea globally unique identity.

The other standard grid service porttypes include

• HandleMap: This service provides themapping between the Grid Services Han-dle and a current Grid Service Reference.

• Registry: This service binds service instancemetadata to a registry.

• Factory: This can create instances ofother services and generate stateful, tran-sient instances of grid applications froma stateless, persistent service.

• Notification: Several standard ports areprovided to allow asynchronous, publish-and-subscribe notification between ser-vices and clients.


The Web Services Definition

Language provides an extensible

schema for encoding all these

elements to define a specific

Web service.

In addition to OGSI, there is a GGFOpen Grid Service Architecture workinggroup, which is exploring grid uses casesand defining the specific standard ser-

vices that are needed for a new generationof grid applications. Other working groupsare looking at specific topics such as secu-rity. Another important advantage of Web

service messaging’s document model isthat security can be end-to-end ratherthan link level. In other words, we canencrypt and sign a message that might


Wil van der Aalst is a full professor of infor-mation systems and head of the Information andTechnology section of the Department of Tech-nology Management at the Technische Univer-siteit Eindhoven. He is also a part-time full pro-fessor at the Computing Science faculty at theDepartment of Mathematics and Computer Sci-ence at the same university. His research inter-ests include information systems, simulation,

Petri nets, process models, workflow management systems, mining, ver-ification techniques, enterprise resource planning systems, computer-supported cooperative work, and interorganizational business processes.He holds an MSc in computing science and a PhD in mathematics, bothfrom the Technische Universiteit Eindhoven. He is a fellow and manage-ment team member of the research institute BETA. Contact him at Eind-hoven Univ. of Technology, P.O. Box 513, NL-5600 MB Eindhoven,Netherlands; [email protected].

V. Richard Benjamins is the director of R&Dat Intelligent Software Components (iSOCO) inMadrid, Spain. His research interests includeareas such as knowledge technologies, artificialintelligence, knowledge management, the Seman-tic Web, and ontologies. He received his MS andPhD in cognitive science from the University ofAmsterdam. He serves on many internationalprogram committees and has been co-chair of

many international workshops (including at IJCAI and ECAI) and con-ferences (EKAW). He is member of the IEEE Intelligent Systems editor-ial board. Contact him at [email protected].

Amit Sheth is a professor of computer scienceand the director of the Large Scale DistributedInformation Systems (LSDIS) Lab, at the Uni-versity of Georgia. He also founded Taalee, anenterprise software and Semantic Web technol-ogy startup based on the research at the LSDISlab. He received his BE from B.I.T.S., Pilani,India, and his MS and PhD from Ohio State Uni-versity. He is on the editorial board of six jour-

nals, has served on over 70 program and organization committees, andhas chaired or cochaired six international conferences or workshops inthe areas of the Semantic Web, digital libraries, multidatabase systems,and parallel and distributed information systems. Contact him at theDept. of Computer Science, 415 Graduate Studies Research Center,Univ. of Georgia, Athens, GA 30602-7404; [email protected]; lsdis.cs.uga.edu/~amit.

John A. Miller is a professor of computer sci-ence at the University of Georgia and is also theGraduate Coordinator for the Computer Sciencedepartment. His research interests include data-base systems, simulation and workflow, andparallel and distributed systems. He receivedhis BS in applied mathematics from Northwest-ern University and his MS and PhD in informa-tion and computer science from the Georgia

Institute of Technology. He is an associate editor for ACM Transactionson Modeling and Computer Simulation and IEEE Transactions on Sys-tems. Contact him at the Dept. of Computer Science, 415 Graduate Stud-ies Research Center, Univ. of Georgia, Athens, GA 30602-7404; [email protected].

Christoph Bussler is a principal member of thetechnical staff at the Oracle Corporation’s Inte-gration Platform Architecture Group, based inRedwood Shores, Calif. He is responsible forthe overall architecture of Oracle’s next-genera-tion integration platform technology addressingB2B, A2A, and ASP integration. He received hisBA and MS in computer science from the Tech-nical University of Munich, Germany, and a PhD

in workflow management from the University of Erlangen-Nuremberg,Germany. He is a member of the IEEE Computer Society and ACM.Contact him at [email protected]; http://hometown.aol.com/chbussler/index.html.

Alexander Maedche is the head of the Knowl-edge Management research department at theFZI Research Center for Information Technolo-gies at the University of Karlsruhe. His researchinterests include knowledge discovery in dataand text, ontology engineering, learning andapplication of ontologies, and the SemanticWeb. He has taught courses at the University ofKarlsruhe in the areas of knowledge discovery

in databases, data and text mining, ontology engineering, and appliedcomputer science and has given several tutorials on ontologies. Hereceived a diploma in industrial engineering and his PhD in appliedinformatics, both from the University of Karlsruhe. He is a member ofthe IEEE and German Society of Computer Science. Contact him at FZI,Univ. of Karlsruhe, 76131 Karlsruhe, Germany; [email protected]; www.fzi.de/wim.

Dieter Fensel works at the University of Inns-bruck, Austria. His research interests includeontologies, the Semantic Web, Web services,knowledge management, enterprise applicationintegration, and electronic commerce. He is aneditor of Knowledge and Information Systems:An International Journal (KAIS), IEEE Intelli-gent Systems, the Electronic Transactions onArtificial Intelligence (ETAI), and Web Intelli-

gence and Agent Systems (WIAS). He has been involved in severalnational and internal research projects—for example, the IST projectsCOG, Esperonto, H-Techsight, IBROW, Multiple, Ontoknowledge,Ontoweb, SWAP, SWWS, and Wonderweb. He has been the projectcoordinator of Ontoknowledge, Ontoweb, and SWWS. Contact him [email protected].

Dennis Gannon is a professor in and chairs theComputer Science Dept. at Indiana University.His current work is on designing software com-ponent architectures for distributed scientificapplications and studying the architecture of gridsystems. He received a BS from the Univerisityof California, Davis, a PhD in computer sciencefrom the University of Illinois, and a PhD inmathematics from the University of California,

Davis. He is one of the cofounders of the Common Component Archi-tecture project (now supported by the DOE Center for Component Tech-nology for Terascale Simulation Software), the Java Grande Forum, andthe Global Grid Forum. He is also the Science Director for the new Indi-ana Pervasive Technologies Labs and the Chief Computer Scientist forthe NCSA Alliance. Contact him at [email protected].

pass through several intermediaries beforereaching its destination. In standard RPCmodels, the security is often at the levelof the supporting stream protocols, andthe contents of method arguments areexposed at any intermediate steps in theprocessing.

Any component architecture must have aconcept of component composition. The Webservices community has produced a newdraft standard, called the BPEL4WS, whichis one candidate.3 A BPEL4WS processdefines a composite Web service describedthe way you might build a flowchart for analgorithm. It is composed of a set of activitiesthat include invoking its composite services,waiting for input messages, copying data, andthrowing exceptions.

Like any programming language,BPEL4WS has a rich control structure tosequence operations. While it is not yetknown if BPEL4WS will also prove tobe the appropriate composition tool forgrid services, it does seem to be a strongcandidate.

A final area of concern might be the rela-tion of Web services and grid services tothe Semantic Web. Others have observedthat Semantic Web markup languages canplay an important role in allowing agenttechnology to automatically use Web ser-vices.4 Within the Grid Forum, there is aresearch group arising out of the SemanticGrid of David De Roure and his colleagues(see www.sematnicgrid.org) that is activelyconsidering this question.

References

1. I. Foster et al., “The Physiology of the Grid:An Open Grid Services Architecture for Dis-tributed Systems Integration,” Grid Comput-ing: Making the Global Infrastructure a Real-ity, F. Berman, A.J.G. Hey, and G. Fox, eds.,John Wiley, New York, 2003.

2. R.T. Fielding, Architectural Styles and theDesign of Network-Based Software Architec-tures, PhD dissertation, Dept. of Computer Sci-ence, Univ. of California, Irvine, Calif., 2000.

3. F. Curbera et al., “Business Process ExecutionLanguage for Web Services,Version 1.0,” IBMdeveloperWorks, 13 July 2002, www.ibm.com/developerworks/library/ws-bpel.

4. S.A. McIlraith, T.C. Son, and H. Zeng, “Seman-tic Web Services,” IEEE Intelligent Systems,vol. 16, no. 2, Mar./Apr. 2001, pp. 46–53.


EXECUTIVE STAFFExecutive Director: DAVID W.HENNAGEAssoc. Executive Director:ANNE MARIE KELLYPublisher: ANGELA BURGESSAssistant Publisher: DICK PRICEDirector, Finance & Administration: VIOLET S.DOANDirector, Information Technology & Services:ROBERT CAREManager, Research & Planning: JOHN C.KEATON

COMPUTER SOCIETY OFFICESHeadquarters Office1730 Massachusetts Ave. NW

Washington, DC 20036-1992

Phone: +1 202 371 0101 • Fax: +1 202 728 9614

E-mail: [email protected]

Publications Office10662 Los Vaqueros Cir., PO Box 3014

Los Alamitos, CA 90720-1314

Phone:+1 714 8218380


Membership and Publication Orders:

Phone: +1 800 272 6657 Fax: +1 714 821 4641


Asia/Pacific OfficeWatanabe Building

1-4-2 Minami-Aoyama,Minato-ku,

Tokyo107-0062, Japan

Phone: +81 3 3408 3118 • Fax: +81 3 3408 3553


PURPOSE The IEEE Computer Society isthe world’s largest association of computingprofessionals, and is the leading provider oftechnical information in the field.MEMBERSHIP Members receive themonthly magazine COMPUTER, discounts,and opportunities to serve (all activities areled by volunteer members). Membership isopen to all IEEE members, affiliate societymembers, and others interested in the com-puter field.

BOARD OF GOVERNORSTerm Expiring 2003: Fiorenza C. Albert-Howard, Manfred Broy, Alan Clements, Richard A.Kemmerer, Susan A. Mengel, James W. Moore,Christina M. SchoberTerm Expiring 2004: Jean M. Bacon, RicardoBaeza-Yates, Deborah M. Cooper, George V. Cybenko,Haruhisha Ichikawa, Lowell G. Johnson, Thomas W.WilliamsTerm Expiring 2005: Oscar N. Garcia, Mark AGrant, Michel Israel, Stephen B. Seidman, KathleenM. Swigger, Makoto Takizawa, Michael R. Williams

Next Board Meeting: 22 Feb. 2003, San Diego, CA

IEEE OFFICERSPresident: MICHAEL S. ADLERPresident-Elect: ARTHUR W. WINSTONPast President: RAYMOND D. FINDLAYExecutive Director: DANIEL J. SENESESecretary: LEVENT ONURALTreasurer: PEDRO A. RAYVP, Educational Activities: JAMES M. TIENVP, Publications Activities:MICHAEL R. LIGHTNERVP, Regional Activities: W. CLEON ANDERSONVP, Standards Association: GERALD H. PETERSONVP, Technical Activities: RALPH W. WYNDRUM JR.IEEE Division VIII Director JAMES D. ISAAKPresident, IEEE-USA: JAMES V. LEONARD

EXECUTIVE COMMITTEEPresident:STEPHEN L. DIAMOND* Picosoft, Inc.P.O.Box 5032San Mateo, CA 94402Phone: +1 650 570 6060Fax: +1 650 345 [email protected]

President-Elect: CARL K. CHANG*Past President: WILLIS. K. KING*VP, Educational Activities: DEBORAH K. SCHERRER(1ST VP)*VP, Conferences and Tutorials: CHRISTINASCHOBER*VP, Chapters Activities: MURALI VARANASI†VP, Publications: RANGACHAR KASTURI †VP, Standards Activities: JAMES W. MOORE†VP, Technical Activities: YERVANT ZORIAN†Secretary: OSCAR N. GARCIA*Treasurer:WOLFGANG K. GILOI* (2ND VP)2002–2003 IEEE Division VIII Director: JAMES D.ISAAK†2003–2004 IEEE Division V Director: GUYLAINE M.POLLOCK†Computer Editor in Chief:DORIS L. CARVER†Executive Director: DAVID W. HENNAGE†

* voting member of the Board of Governors† nonvoting member of the Board of Governors

COMPUTER SOCIETY WEB SITEThe IEEE Computer Society’s Web site, athttp://computer.org, offers informationand samples from the society’s publicationsand conferences, as well as a broad range ofinformation about technical committees,standards, student activities, and more.

web services: been there, done that? - pku.edu.cn

Documents