The Web Service Modeling Framework WSMF
D. Fensel1 and C. Bussler2
spring framework是什么框架的1Vrije Universiteit Amsterdam (VU)
Faculty of Sciences, Division of Mathematics and Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
Fax: +31-(0)84-872 27 22, phone: +31-(0)6-51850619
E-mail: dieter@cs.vu.nl
2 Oracle Corporation
500 Oracle Parkway, Redwood Shores, 94065, CA, U. S. A.
Phone: +1-650-607-5684,
E-mail: chris.bussler@oracle
Abstract. Web Services will transform the web from a collection of information
into a distributed computational device. In order to employ their full potential,
appropriate description means for web services need to be developed. For this
purpose, we define a fully-fledged Web Service Modeling Framework (WSMF)
that provides the appropriate conceptual model for developing and describing web
services and their composition (complex web services). In a nutshell, its
philosophy is based on the following principle: maximal de-coupling
complemented by a scalable mediation service.
1Introduction
“Web services are a new breed of Web application. They are self-contained, self-
describing, modular applications that can be published, located, and invoked
across the Web. Web services perform functions, which can be anything from
simple requests to complicated business processes. ... Once a Web service is
deployed, other applications (and other Web services) can discover and invoke
the deployed service.”
IBM web service tutorial
The current web is mainly a collection of information but does not yet provide support in processing this information, i.e., in using the computer as a computational device. Recent efforts around UDDI1, WSDL2, and SOAP3 try to lift the web to a new level of service. Software programs can be accessed and executed via the web based on the idea of web services. A service can provide information, e.g. a weather forecast service, or it
1.  UDDI provides a mechanism for clients to find web services. Using a UDDI interface, businesses can dynamically lookup as well as discover services provided by external business partners. /
2.  WSDL defines services as collections of network endpoints or ports. In WSDL the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. /
3.  SOAP is a message layout specification that defines a uniform way of passing XML-encoded data. /
1
may have an effect in the real world, e.g. an online flight-booking service. Web services can significantly increase the Web architecture's potential, by providing a way of automated program communication, discovery of services, etc. Therefore, they are the focus of much interest from various software development companies.4
The ultimate vision is that a program tasked to achieve a result can use web services as support for its computation or processing. The program can discover web services and invoke them fully automated. Hence, it becomes a service requester. If the web services have a cost attached, the program knows when to search for a cheaper service and knows all the possible payment methods. Furthermore, the program might be able to mediate any differences between its specific needs and a web service that al
most fits.
In a business environment this translates into automatic cooperation between enterprises. Any enterprise requiring a business interaction with another enterprise can automatically discover and select the appropriate optimal web services relying on selection policies. They can be invoked automatically and payment processes can be initiated. Any necessary mediation is applied based on data and process ontologies and the automatic translation of their concepts into each other. An example would be supply chain relationships where an enterprise manufacturing short-lived goods has to frequently seek suppliers as well as buyers dynamically. Instead of employees constantly searching for suppliers and buyers, the web service infrastructure does it automatically within the defined constraints.
Still, more work needs to be done before the web service infrastructure can make this vision come true. Current technology around UDDI, WSDL, and SOAP provide limited support in mechanizing service recognition, service configuration and combination (i.e., realizing complex workflows and business logics with web services), service comparison and automated negotiation. Therefore, there are proposals such as WSFL [Leymann, 2001] that develops a language for describing complex web services or DAML-S [Ankolenkar et al., 2001] that employs semantic web technology ([Berneers-Lee e
t al., 2001], [Fensel & Musen, 2001], and [Fensel et al., 2002]) for service description. The Web Service Modeling Framework (WSMF) follows this line of research. It is a fully-fledged modeling framework for describing the various aspects related to web services. Fully enabled ecommerce based on workable web services requires a modeling framework that is centered around two complementary principles:•Strong de-coupling of the various components that realize an e-commerce application.
•Strong mediation service enabling anybody to speak with everybody in a scalable manner.
These principles are rolled out in a number of specification elements and an architecture describing their relationships.
The contents of the paper are organized as follows. In Section 2, we provide a motivation for web services, an analysis of the state of the art of this technology, we identify eight layers as being necessary to achieve automatic web service discovery, selection, mediation and composition into complex services, and introduce the main 4.  /2001/01/WSWS/
2
principles of WSMF. Section 3, provides the architecture and the main modeling primitives of WSMF. S
ection 4 discusses related work and Section 5 puts web services in the context of the semantic web. Conclusions are provided in Section 6.
2Web Services
This section briefly recalls the vision of web services. Then we analyze the current infrastructure with which web services are realized and indicate the future steps to take to make the vision workable.
2.1The Vision
Web Services connect computers and devices with each other using the Internet to exchange data and combine data in new ways. Web Services can be defined as software objects that can be assembled over the Internet using standard protocols to perform functions or execute business processes. The key to Web Services is on-the-fly software creation through the use of loosely coupled, reusable software components. This has fundamental implications in both technical and business terms.5 Software can be delivered and paid for as fluid streams of services as opposed to packaged products. It is possible to achieve automatic, ad hoc interoperability between systems to accomplish business tasks. Business services can be completely decentralized and distributed over the Internet and accessed by a wide variety of communications devices. Businesses can be released from the burden
of complex, slow and expensive software integration and focus instead on the value of their offerings and mission critical tasks. Then the Internet will become a global common platform where organizations and individuals communicate with each other to carry out various commercial activities and to provide value-added services. The barriers to providing new offerings and entering new markets will be lowered to enable access for small and medium-sized enterprises. The dynamic enterprise and dynamic value chains become achievable and may be even mandatory for competitive advantage.
2.2State of the Art
The web is organized around URIs, HTML, and HTTP. URIs provide defined IDs to refer to elements on the web, HTML provides a standardized way to describe document structures (allowing browsers to render information comprehensible to the human reader), and HTTP defines a protocol for retrieving information from the web. Not surprisingly, web services require a similar infrastructure around UDDI, WSDL, and SOAP.
UDDI provides a mechanism for clients to find web services. Using a UDDI interface, businesses can dynamically look up as well as discover services provided by external business partners. A UDDI registry is similar to a CORBA trader, or it can be thought of as a DNS service for business application
s. A UDDI registry has two kinds of clients: businesses that want to publish a service description (and its usage interfaces), and clients who want to obtain services descriptions of a certain kind and bind 5.  See /WebServices.html.
3
programmatically to them (using SOAP). UDDI itself is layered over SOAP and assumes that requests and responses are UDDI objects sent around as SOAP messages. The UDDI information contains four levels: the top level element is the Business entity, which provides general data about a company such as its address, a short description, contact information and other general identifiers. This information can be seen as the white pages of UDDI. Associated with each business entity is a list of Business services. These contain a description of the service and a list of categories that describe the service, e.g. purchasing, shipping etc. This can be considered as the yellow pages of UDDI. Within a business service, one or more Binding templates define the green pages: they provide the more technical information about a web service (cf. [Lemahieu, 2001]).
WSDL defines services as collections of network endpoints or ports. In WSDL the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings.
This allows the reuse of abstract definitions of messages, which are abstract descriptions of the data being exchanged, and port types, which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitute a binding. A port is defined by associating a network address with a binding; a collection of ports defines a service. SOAP is a message layout specification that defines a uniform way of passing XML-encoded data. It also defines a way to bind to HTTP as the underlying communication protocol for passing SOAP messages between two endpoints. Instead of being document-based, automated B2B interaction requires integration of processes. However, although techniques such as DCOM, RMI and CORBA are successful on the local network, they largely fail when transposed to a web environment. They are rather unwieldy, entail too tight a coupling between components and above all conflict with existing firewall technology. Replacing this by a simple, lightweight RPC-like mechanism is the aim of SOAP. SOAP uses XML messaging over plain HTTP, thus avoiding firewall problems (asynchronous communication can also be accomplished via SMTP). Hence SOAP is basically a technology that allows for “RPC over the web”providing a very simple one-way as well as request/reply mechanism.
2.3Functionalities required for successful web services
UDDI, WSDL, and SOAP are important steps in the direction of a web populated by services. However,
they only address part of the overall stack that needs to be available in order to eventually achieve the above vision. [Bussler, 2001c] identifies the following elements as being necessary to achieve scalable web service discovery, selection, mediation and composition:
•Document types. Document types describe the content of business documents like purchase orders or invoices. The content is defined in terms of elements like an order number or a line item price. Document types are instantiated with actual business data when a service requester and a service provider exchange data. The payload of the messages sent back and forth is structured according to the document types defined.
•Semantics. The elements of document types must be populated with correct values so that they are semantically correct and are interpreted correctly by the service 4
requesters and providers. This requires that vocabulary is defined that enumerates or describes valid element values. For example, a list of product names or products that can be ordered from a manufacturer. Further examples are units of measure as well as country codes. Ontologies provide a means for defining the concepts of the data exchanged. If ontologies are available document types refer to the ontology concepts. This ensures consistency of the textual representation of the concepts
exchanged and allows the same interpretation of the concepts by all trading partners involved. Finally, the intent of an exchanged document must be defined.
For example, if a purchase order is sent, it is not clear if this means that a purchase order needs to be created, deleted or updated. The intent needs to make semantically clear how to interpret the sent document.
•Transport binding. Several transport mechanisms are available like HTTP/S, S/ MIME, FTP or EDIINT. A service requester as well as a service provider has to agree on the transport mechanism to be used when service requests are executed.
For each available transport mechanism the layout of the message must be agreed upon and how the document sent shall be represented in the message sent. SOAP for example defines the message layout and the position within the message layout where the document is to be found. In addition, header data are defined, a requirement for SOAP message processing.
•Exchange sequence definition. Communication over networks is currently inherently unreliable. It is therefore required that service requester and service provider make sure themselves through protocols that messages are transmitted exactly once. The exchange sequence definition achieves this by defini
ng a sequence of acknowledgment messages in addition to time-outs, retry logic and upper retry limits.
•Process definition. Based on the assumption that messages can be exchanged exactly once between service requester and service provider the business logic has to be defined in terms of the business message exchange sequence. For example, a purchase order might have to be confirmed with a purchase order acknowledgment. Or, a request for quotation can be responded to by one or more quotes. These processes define the required business message logic in order to derive to a consistent business state. For example, when goods are ordered by a purchase order and confirmed by a purchase order acknowledgment they have to be shipped and paid for, too.
•Security. Fundamentally, each message exchange should be private and unmodified between the service requester and service provider as well as non-reputable. Encryption, as well as signing, ensures the unmodified privacy whereby non-repudiation services ensure that neither service requester nor service provider can claim not to have sent a message or to have sent a different one.
•Syntax. Documents can be represented in different syntaxes available. XML is a popular syntax, although non-XML syntax is used, too (e.g. EDI6).
•Trading partner specific configuration. Service requesters or service providers 6.  /
5

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。