Information Technology Reference
In-Depth Information
•
Ease of use.
IRS interfaces are designed such that much of the complexity
surrounding the creation of Semantic-Web-service-based applications is
hidden. One-click-publishing is a corollary of the above design principle.
•
Agnostic to service implementation platform.
Within the design of IRS,
there is no strong assumption about the underlying service implementation
platform.
•
Connected to the external environment.
To support this, functions and
relations can be defined in order to make calls to external systems, for
example, invoking a Web service.
•
Inspectability.
In many parts of the life cycle of a software system, it is
important that the developers are able to understand the design and be-
havior of the software being constructed. This principle is concerned with
making the semantic descriptions accessible in a human-readable format.
The key is that the content and form are easily understandable by the
builders of Semantic Web service applications.
Many of the direct principles of IRS are application-focused, but from
the first design principles, we can say that they largely follow the WSMO
approach described in this topic. The IRS-III ontology is based on the WSMO
conceptual model; however, it has a number of differences. To achieve the goal
of capability-based invocation, Web services are required to have input and
output roles, and goals linked to Web services via mediators. Web services are
linked to goals inherit the input and output roles of the goals. In WSMO, the
mediation service slot of a mediator may point to a goal that declaratively
describes the mapping. Goals in the context of a mediation service play a
slightly different role in IRS-III. Rather than describing a mapping, goals are
considered to have associated Web services and are therefore simply invoked.
IRS clients are assumed to be able to formulate their request as a goal
instance. This means that it is only choreographies between IRS and the
deployed Web services that are required. Choreography execution in IRS-III
thus occurs from a client's perspective. That is to say, to carry out a Web
service invocation, IRS executes a Web service client choreography, which
sends the appropriate messages to the Web service deployed. In contrast, the
current WSMO choreography describes all of the possible interactions that a
Web service can have.
At the heart of the server of IRS-III is the WSMO library, where the
WSMO definitions are stored using the representation language OCML [96].
The library is structured into knowledge models of WSMO goals, Web ser-
vices, and mediators. The structures of each knowledge model are similar, but
typically the applications consist of mediator models importing from relevant
goal and Web service models. Following our design principle of inspectability,
all information relevant to a Web service is stored explicitly within the library.
Within WSMO, a Web service is associated with an interface that contains a
separate orchestration and choreography. Orchestration specifies the control
and dataflow of a Web service, which invokes other Web services (a composite
Search WWH ::
Custom Search