Architecture of the Service Composer

Figure 4.2 shows the architecture of the Service Composer. The bold rectangle represents the scope of the Service Composer. Outside of the bold rectangle are other components that cooperate with the Service Composer. The components from up to down are the customer, AJAX Component, the Inference Engine, the Execution Engine, and the Com-munity Component in the Semantic Web Services composition architecture. We use arrows to represent the interaction between the components.Detailed definition of the components inside the bold rectangle are given below.

• Inner Knowledge Base / Ontologies and Rules

Our Knowledge base consists of Ontologies and rules. As we mentioned at previous

chapter, ontologies play an essential role in sharing and exchanging knowledge in the architecture of the Semantic Web Services composition. Each component in the architecture shares the set of ontologies and communicates with other components by accessing ontologies. Ontologies are kind of formal representations of knowledge.

Rules used to describe the complicated relationships between roles and we can use rules to capture the role composition in the ontologies. We use Inner Knowledge Base for certain functions:(1) data storage: Requirements, advertisements, and related information are described in OWL which based on DL. (2) With deduction power of the inference engine like RACER and, reasoning allows us to infer implicitly represented knowledge from the ontologies.

Because all data flows within the Service Composer are read from the knowledge base and are written back, the component in the Service Composer can communi-cate with the inner knowledge base directly or indirectly. (See the arrows in Figure 4.2) When the user input their requirement, they are stored in the inner knowledge base so that the data can be extracted later when needed.

• Integrated User Interface

The Integrated User Interface mashing up with AJAX component provide the cus-tomer responsive user interfaces and aid them input their requirements step by step.

It is also responsible for displaying the matched results after service matching. In-tegrated User Interface encapsulates the complex and formal information which are not proper for the customer. Integrated User Interface provides error detections if the customer inputs inappropriate data. Besides, it will invoke the constraint checker tools to check the consistency of the constraints after the user complete their requirements. The whole process can be simplified as follows. First, the cus-tomer sets their requirements by interacting with the AJAX component. Second, he/she can review and edit their requirements. Third, he/she submit the re-quirements to the Matchmaker to search for suitable advertisements and get the ranking scores of the advertisements. Finally, the customer can invoke the desired advertisements from the result list.

The Integrated User Interface plays an important role because it directly interacts

with the customer. To lower the entrance barrier of Semantic Web application, we should put the design of the friendly UI as the first priority.

• AJAX Module

Through cooperating with the AJAX Component and the Integrated User Interface, AJAX module is responsible for passing the parameters which involve in display-ing AJAX-based interfaces. While the Integrated User Interface is displaydisplay-ing the responsive user interface, for instance, a interactive map, AJAX module retrieves necessary information from the ontology, such as location name, descriptions of lo-cations. Meanwhile, it continuously listen the interaction events triggered by the customer’ behavior, such as mouse clicking, mouse trajectory. Through clicking mouse on the map, the customer input their requirement easily.

• Community Module

Community Module connects the Service Composer and the Community Compo-nent. After the customer input their requirements and select their desire ments, community module publish those requirements and corresponding advertise-ments to the Community Component. Besides, if the customer input a requirement that contain some information not in the ontologies, the Community Module will automatically report to the Community Component.

• Matchmaker

The Matchmaker is a matching module that invokes the Inference Engine to start reasoning. It acts as a bridge between the Service Composer and the Inference Engine. We implement the matching algorithm and the approach of computing similarity degree in this component. The service matching algorithms are tightly dependent with the domain ontology and are designed for a specific domain or a specific system. After finding matched services through the reasoning of the Inference Engine, the Matchmaker returns the desired advertisement lists according to the similarity degree.

• Service Execution Module

The Service Execution Module provides tools to generate executable processes from

abstract service descriptions and templates, and invokes the Execution Engine. It returns the results from the Execution Engine to the the customer. A more detailed description of the service execution stage is given in Section

• Knowledge Base Handler

The Knowledge Base Handler handles the all the access of the ontology, including write-in and read-out. Through the Knowledge Base Handler, every module in the Service Composer is able to retrieve the data from ontology.

• Dynamic Concept Component

To handle the subsumption between requirements and advertisements, we have to overcome the subsumption between the numeric concepts. Since the particular concepts like Time and Value Partition are related to unlimited concepts in the real-world, those concepts need to be created dynamically as a programming method that adds automatically time or value concept to the knowledge base while per-forming reasoning. This innovative approach avoids having large specific concepts in the inner knowledge base. The system administrator does not have to define and maintain large concepts manually. That makes ontology reasoning more efficient.