As stated earlier, the environment of services can be referred to the correlations among services.
There are several types of correlations that can be detected during the build time and runtime.
Data flow relations: describe the correlations among services on the basis of the similarity of
services’ functionality, parameters, and QoS, which include equivalence, replacement, and flow
relations [12,18].
Service pattern relations: describe the correlations among services during the execution time on the
basis of the service-record mining, which include coopetition [19] and collaboration relations [20].
Provider relations: describe the social relations of service providers who offer the services for
SOBE [21].
• Service record
During dynamic selection and composition of services, services are combined together to create new
added-value services to respond to the consumer’s request. The environment creates the service
request. SOBE will translate it into abstract composition request that refers the service process and the
QoS of every service. How to decompose the global request into the local selection had been described
in [22] and is out of this paper’s scope. The discovery engine locates the services for each task in the
abstract composition request and forms the service instance to fulfill the user’s end-to-end request. We
suppose that it is possible to collect the information that services participate in collaboration. Actually,
each service will keep its interaction records with other services, and SOBE will keep the service
instance logs that consist of service records.
SerRecord ¼ CaseId; ServiceId; ActivityId; Ability; Status; Income; RequstServiceId
fg
(2)
where CaseId refers to a service instance that fulfills the consumer’s request; ServiceId refers to the
response service that participates in the service instance; ActivityId refers to the well-defined activity in
the service instance; Ability refers to the ability that the service offers to the user; Status refers to the
serve state of this record including success and failure; RequestServiceId refers to the services that
submit the serve request; and Income refers to the income for the response service and expense for the
request service.
Example:
Here, we could obtain a service record as follows:
SerRecord ¼ Case1; PrDy1; PrDy; 500; Success; 500$; Ironing1
fg
which means that the service PrDy1 successfully provides 500 ability for the activity Printing&Dyeing
in the service instance Case1 and owns PrDy1 500$ income, also this request is submitted by Ironing1.
• Service instance log
The service records will form the service log that will be used to mine the relations in the ecosystem.
Figure 2 is a fragment of th e service instance log that is created by the simulation. In the SOBE, if the
total request ability for one service is larger than one service’s ability, two or more services will be
selected; just as Case38, service Washing1 and Washing2 are selected at the same time. Also, if a
service fails to participate into compositions, the SOBE will choose another service to replace it. For
example, in Case114, the service ‘CutingOut3’ fails to participate into composition so that
‘CutingOut2’ is selected to replace it.
Until now, we have obtained the conceptual model of SOBE consisting of business service, service
population, service community, and service correlations. Then, we use service record and service
instance log to preserve the information during the execu tion of the ecosystem. In the following, we
will firstly discuss how to build the correlation network model and then show the implementation
and the added value of this model.
1864
K. HUANG ET AL.
Copyright © 2013 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. 2013; 25:1861–1878
DOI: 10.1002/cpe