1.txt

来自「Java实现传统算法加密解密」· 文本 代码 · 共 78 行 · 第 1/2 页

Web services connect computers and devices with each other using the standard Web-based protocols to exchange data and combine data in new ways. Their distribution over the Web confers on them the advantage of platform independence. Each Web service represents an atomic piece of functionality that can be reused to build more complex ones. In order to allow their discovery, invocation, composition, execution, monitoring, mediation, and compensation, Web services are described in WSMO from three different points of view: non-functional properties, functionality and behavior. Thus, a Web service is defined by its non-functional properties, its imported ontologies, its used mediators, its capability and its interfaces. A Web service can be described by multiple interfaces, but has one and only one capability. The capability of a Web service encapsulates its functionality and an interface of a Web Service describes the behavior of the Web Service from two perspectives: communication and collaboration. For more detailed information about how to model Web services within WSMO please refer to Section 4.2.

Goals describe aspects related to user desires with respect to the requested functionality as opposed to the provided functionality described in the Web service capability. In WSMO a goal is characterized by a set of non-functional properties, imported ontologies, used mediators, the requested capability and the requested interface. Goals are described in Section 4.3. 

Mediators describe elements that aim to overcome structural, semantic or conceptual mismatches that appear between the different components that build up a WSMO description. Currently the specification covers four different types of mediators:

OOMediators - import the target ontology into the source ontology by resolving all the representation mismatches between the source and the target; 
GGMediators - connect goals that are in a relation of refinement and resolve mismatches between those; 
WGMediators - link Web services to goals and resolve mismatches; 
WWMediators - connect several Web services for collaboration. 
More details about the particular use of mediators and the role they play in WSMO are provided in Section 4.4. 

3. Use case description
In order to introduce the basic concepts and model, a use case from the domain of e-tourism is used throughout the Primer. In this use case, an agent wants to buy a ticket to travel from Innsbruck (Austria) to Venice (Italy) on a certain date. The goal that specifies the intent of buying a ticket for a trip from Innsbruck to Venice is abstracted from this agent desire. A hypothetical Book Ticket Web service, offered by a "Virtual Travel Agency "(VTA), is considered for achieving the goal. This Web service allows the service requester to search and buy tickets for itineraries starting in Austria. The only accepted payment method is credit card. For the execution of the transaction, the credit card must be a valid PlasticBuy or GoldCard (two fictitious credit card brands). 

4. WSMO Modeling Elements 
This section explains the WSMO modeling elements, describing their purpose and illustrating how they can be specified. This section is divided into four subsections: Section 4.1 describes ontologies and all the essential components used to define them, Section 4.2 presents Web services, Section 4.3 presents goals and how they are used to specify the functionality required from Web services, and finally Section 4.4 exemplifies the use of mediators which provide the means to bypass interoperability problems among the rest of the elements. The examples presented throughout this section are based on the previously presented use case.

4.1 Ontologies
A widespread definition of ontology is given in [Gruber, 1993] where an ontology is defined as "a formal explicit specification of a shared conceptualization" . In WSMO, ontologies provide machine-readable semantics for the information used by all actors implied in the process of Web services usage, either providers or requesters, allowing interoperability and information interchange among components. As an example, we present the definition of an ontology used for specifying the "Book Ticket Web Service" described in the use case and for defining a goal that can be solved by this Web service. This ontology is called "Trip Reservation Ontology", since it defines the necessary terminology for describing trip and reservation related information. 

A namespace declaration can appear at the beginning of each WSML file. Such a declaration may comprise the default namespace and abbreviations for other used namespaces. Listing 1 starts with the namespace declaration at the top of the WSML file where the "Trip Reservation Ontology" is specified. 

Any ontology declaration starts with the keyword ontology optionally followed by the ontology identifier. A set of non-functional properties may follow this statement. Non-functional properties can be specified for almost any WSMO element and they describe information that does not affect the functionality of the element like title, authorship, copyrights, etc. For each different WSMO element, there is a recommended set of non-functional properties, but this set is extensible. The "Trip Reservation Ontology" is characterized by the non-functional properties that appear in Listing 1.

Note that, the majority of the recommended non-functional properties are properties defined in the Dublin Core Metadata Element Set. However, their values have types according to the WSMO recommendation:

the property dc#title has as value the name of the element, in this case the "Trip Reservation Ontology" . 
the property dc#identifier has been defined following the WSMO recommendation to use an IRI for identifying the element. In the case of the "Trip Reservation Ontology", the identifier was already declared, but here is repeated in order to allow Dublin Core metadata aware applications to process this information. 
the property dc#creator has been defined following the WSMO recommendation to use an instance of the class foaf#agent defined in the FOAF ontology [FOAF] to indicate unambigously the entity responsible for creating the content of the element. 
the property dc#description has been defined following the WSMO recommendation, as a free-text description of the content of the element. 
the property dc#publisher has been defined following the WSMO recommendation to use an instance of the class foaf#agent defined in the FOAF ontology [FOAF] to indicate unambigously the entity responsible for publishing the content of the element. 
the property dc#contributor has as value an instance of the class foaf#agent defined in the FOAF ontology [FOAF] in order to indicate unambigously the entity responsible for making contributions to the content of the element, as WSMO recommends. 
the property dc#date has been defined following the WSMO recommendation to encode date values as defined in the ISO standard 8601:2000 [ISO8601]. 
the property dc#format has been defined following the WSMO recommendation to use types defined in the list of Internet Media Types by the Internet Assigned Numbers Authority. 
the property dc#language has as value a language tag defined in the ISO standard 639 [ISO639].
the property dc#rights reference a document that contains a rights management statement for the element.