G ENERAL DESCRIPTION AND BASIC SCENARIO

The proposed approach is illustrated in the system throughout the study. It can be applied in any specific domain where service composition is made based on the users' feedback which represent the quality rate of the service content. The proposed approaches are helpful to form the values objectively based on the consensus, and it can be iteratively applied for reaching a consensus to interactive environment. To answer questions concerning interaction between the services and users, the number of services and number of users might be cause the limitations. One large source of inefficiency in SOAP is the use of multiple system calls to send one logical message.

Another source of inefficiency in SOAP is the XML parsing and formatting time. ESB can bind the proper service from different web server. Hence, it can reduce the effort on one server. Furthermore, SCA is designed for the XML parsing and formatting on SOAP. ESB and SCA can offer a good scalability in our proposed approach.

However, this prototype system architecture has its own constrains. First, the proposed method is based on pre-defined criteria such as convenience, comfortable, and power saving to evaluate a service. Therefore, dynamically evaluation to each service is supported in order to get better users' interaction between human with environment. Second, we only use one embedded board to simulate the hardware as services. Arduino offers multiple transmission interface such as wired and wireless to communicate each other. The hardware and software used to implement the prototype system are listed in following. (See Table 7)

Table 7 Implementation suggestion

Hardware CPU Xeon 2.33 GHz

L2 cache 2MB

RAM 8GB

Arduino Duemilano (connect with USB cable)

LED Matrix 8 * 8 LED

Operation System Windows 2008

UDDI Server jUDDI v0.9 rc4

HTTP Server Tomcat 5.5 with Axis2 1.5

ESB Server Synapse 1.1

Database System MySQL 5.5

Main Program Language J2SDK 1.6

In this study, we assume that there is only one consensus formation method in these services. This TOPSIS evaluation service was located on a AXIS web service container which could be triggered by data adapter service. The evaluation process can be perform iterative by each user, and user can evaluate each service in each time.

On

rs understand how services are activated and adjusted to meet users’ requirements. The basic scenario for this architecture is divided into 7 steps which are illustrated as follows:

ce any user get into the space, user can express their opinions according to their preferences. The evaluation process can be also trigger by the other service. For example, if there is another service for timekeeping, the collection service can get the correct time given by the timekeeping service. The service execution engine can also automatically turn on the lighting in the evening. Any other better inference result by a novel algorithm than TOPSIS can bind the proper services by service execution engine.

We use a sequence diagram to help reade

Figure 17 Sequence Diagram of service support the consensus-adjusting between ESB and users

Step 1:

Users pr functional re and their QoS preferences. Users use linguistic variables to rate all possible alternatives and give a weight to each criterion based on their importance.

Ste

The

ugh a graded mean integration method by equation (4) and equation (5). The TOPSIS is able to reason over the values relating to QoS criteria and alternatives to identify the possible group

escribe their quirements

p 2:

Collection service gathers the users’ preferences in fuzzy terms, transforms them into RDFs and sends them to a data adapter service.

Step 3:

The Data adapter service stores users’ preferences send by the collection service into database. Then, the data adapter service is responsible for maintaining the existing users’ preferences consistently as well as new ones. In addition, the adapter service makes sure that the data can be accessible coherently regardless their locations and physical database structures. In the end, the data adapter service makes the data available to the TOPSIS evaluation service to reason.

Step 4:

weight corresponding to importance of a criterion is represented by linguistic variables which are defined as triangle fuzzy numbers. Then, we transform a triangular fuzzy number into a crisp number thro

consensus by recommending appropriate services. The recommended services must be able to satisfy most users’ requirements. If not, it means that the group cannot reach a consensus.

Step 5:

(ESB) can bind these abstract services to the physical ones. In ESB, the

the result to users. The service normally

received the service, they can assess the results according to functional

We also used Tuscany to realize SCA In the previous step, the recommended services are abstract services. Enterprise Service Bus

Service Execution Engine (SEE) locates the designated services which can be a collection of atomic and composite services.

Step 6:

The service is located, invoked, and shows

runs on a web container which provides essential library for a runtime environment.

Step7:

Once users

and nonfunctional requirements. If the services cannot satisfy the requirements, the user can give their opinions and preferences again. These feedbacks will be included in the system as inputs for the next round of group consensus. The above steps will be carried out again in order to reflect new group requirements.

In our development, we adopted an open source project which is Synapse to support the required enterprise service bus.

development environment. With these enabling technologies and middleware along with other modules, the services can be advertised, discovered, selected, composed, and executed according to the requirements.