Information Technology Reference
In-Depth Information
Directory in order to let the service provid-
ers discovering them to later on register
their services as members in them.
the clouds will be provided via the cloud
provider system. For better understand-
ing of the abovementioned specifications,
Figure 2 depicts these components and the
relations between them in the proposed
model.
•
Cloud Provider: Will define the clouds
as instances of the cloud ontology by as-
signing values to its concepts. The cloud
providers can be normal service providers
or businesses that share common point of
interest (non-profit and in most cases profit
organizations).
system interactions
In this new model, the interactions can be detailed
as follows:
•
Semantic Mediator-based System: Has the
responsibility of solving the heterogene-
ity issues that might occur between the
semantic goals provided by WS consumer
system and the semantic descriptions of
the clouds' capabilities by performing the
matchmaking and filtering results pro-
cesses. The mediator-based system may be
embedded in a middleware as depicted in
the Figure 2, or it can be an external WS
that accomplishes the mediating scenarios
at run-time in a way that lessens the load
of mediation process. This loose coupling
promotes reusability and facilitates dy-
namic partner binding, especially at run-
time. These issues are to be considered in
our future work.
•
The cloud provider will define clouds as
instances of the cloud ontology and the
clouds then will be published in the cloud
directory so that the WS providers can dis-
cover them.
•
Via the validator's interfaces, service pro-
viders will identify the cloud of interest and
register their Web Services within it after
adding the semantic descriptions on them,
and during this stage the provider specifies
the cloud concepts that are inherited by its
WSs (only some of the generic operations)
and register them in the appropriate cloud
together with publishing them in the WS
directory after applying the proper valida-
tion (see next paragraph). In the case that
the service will be shared between multiple
clouds, the provider will register it in all of
them.
•
Validator: It is the interface that has the
responsibility of tunneling the communi-
cation between the WS capabilities and
concepts derived from the clouds in the se-
mantic WS system and also monitoring the
non-functional properties of WS.
•
The workflow system will execute a
workflow using an appropriate XML-
based workflow engine like Yet Another
Workflow Language (YAWL) (van der
Aalst, ter Hofstede, 2005) or any other dy-
namic workflow engines and will pass the
WS request to the WS consumer system.
•
Validation Repository: It has the function-
ality of calculating the values of the WS
non-functional properties in order to for-
ward it to the validator interface to make
the proper mapping decisions and it also
contains the relations between concepts
that are entailed from the existing domain
ontologies outside this model.
•
WS consumer system will have the respon-
sibility of searching for desired services,
and that is done by sending its request to
WS directory.
•
Cloud Directory: It is the directory of
clouds and it will store data about Web
Services to be used for the validation, all
•
At this stage, the request will be forwarded
to the semantic mediator-based framework
Search WWH ::
Custom Search