5. Application Experiments
5.3 Application Examples of Semantic Web Service Orchestration
5.3.2 Conveyor System Example
The conveyor system domain presented in Section 5.1.2 is more complex than the Light Tower system considered in Section 5.3.1. In particular, the former includes several web services representing conveyor devices, as opposed to a single web ser-vice representing a light tower deser-vice. In addition, each of the conveyor deser-vices implements the service interface applied in Section 5.2. Nevertheless, the approach for orchestrating the services remains the same as in the previous subsection.
5. Application Experiments 105
Figure 5.20: The main components of the conveyor system ontology.
Because the conveyors are part of the larger system presented in Section 5.1.3, this section will consider only a simplified equipment ontology, which includes only those parts of the overall system that are relevant for this example. Figure 5.20 shows a class diagram of the simplified ontology. The ontology contains six individuals of the classBasicConveyor, each of which represents one of the six conveyor segments.
Because the conveyor segments are connected in a circle, the individuals in the ontology are connected in a loop by the hasNeighborOut property. Hence, a pallet may travel from conveyor A to conveyor B if and only if A is related to B by the hasNeighborOut property.
The conveyor system contains a pallet carrying a product, and the conveyor services are orchestrated so that the pallet traverses the conveyor loop a fixed number of times. The orchestration instructions are formulated as a BPEL process, which is then submitted to Orchestration Engine for execution.
The main part of the BPEL process consists of a cycle repeated for a fixed amount of times. In the beginning of each cycle, the Orchestration Engine sends a query to the Ontology Service to determine on which conveyor segment the product cur-rently resides. If the product is on segment 5, then the next destination is segment 2. Otherwise, the next destination is segment 5. Orchestration Engine then queries from the Ontology Service the shortest path from the current location to the des-tination segment. The SPARQL query uses the GLEEN2 library for requesting the shortest path. Once the shortest path has been determined, Orchestration Engine causes the pallet to traverse through the path by sequentially invoking the unloading and loading operations of each of the conveyor segments on the path. Invoking the operations causes the conveyor services to send event notifications, and Ontology Manager constantly sends update requests to Ontology Service so that the semantic
2GLEEN: Regular Paths for ARQ SparQL. Available at http://sig.biostr.washington.edu/
projects/ontviews/gleen/index.html. Accessed on 2013-5-15.
5. Application Experiments 106 model remains synchronized with the actual location of the pallet.
The BPEL process, which Orchestration Engine executes, begins with the ini-tialization of the orchestration support services: first, Orchestration Engine invokes theSetBaseOntology operation on Ontology Service, as well as the operations Scan-Network, SetUpdateRules, and SetActivityState on Ontology Manager. In addition, during each cycle, Orchestration Engine invokes the ExecuteSelectAndPick opera-tion to determine the current pallet locaopera-tion and theFindShortestPath operation to determine the route to the next destination segment. After determining the path, Orchestration Engine moves the pallet by sequentially invoking the LoadFromLeft and UnloadToRight operations of the conveyor services representing the conveyor segments on the path.
Resolving the partner links is more problematic than in the Light Tower scenario because the number of domain web services is larger. In particular, because all of the domain web services are of the same type, differentiating between various instances of the same service type is crucial. Nonetheless, this can be achieved by creating a separate partner link type for each of the partner links representing the conveyor segments. The partner link type definitions are based on different WSDL files representing the conveyor service. The syntactic interface definition is similar in each file, but the port type SAWSDL annotations refer to different OWL-S Profiles.
Thus, six instances of the conveyor serviceprofile are created, each of which denotes a different conveyor segment. Then, to perfectly match a partner link, a conveyor service must have a port type SAWSDL annotation referring to the correct profile instance. Otherwise, the match rating will be lower. This allows Orchestration Engine to select the correct conveyor service instance for each partner link.
In this example, six update rules must be used. Each update rule is intended for reacting to the event that the pallet arrives on one of the conveyor segments.
Each update rule contains a condition that matches the event that a pallet arrives on the latter sensor on the conveyor and an update statement which first erases any previous pallet location information from the equipment ontology and then sets the pallet location to the corresponding conveyor. In each update rule, the event source is given the same name as the partner link in the BPEL process, and the BPEL process contains an Invoke activity which reports the mapping between partner link names and endpoint URIs to Ontology Manager by invoking itsSetEndpointMapping operation.
The notification Sensor2Changed is used in determining when a pallet arrives on the latter sensor of a conveyor. The notification is sent each time the sensor changes its state. The notification message contains the string ‘ON’ if the sensor detects a pallet, or ‘OFF’ if the sensor no more detects a pallet. Thus, if conveyor 3 sends a Sensor2Changed notification carrying the string ‘ON’, then the ontology
5. Application Experiments 107
Listing 5.4: These SPARQL/Update operations set the location of the pallet to conveyor 3 in the equipment ontology.
is updated so that the new location of the pallet is conveyor 3. This is achieved by requesting the Ontology Service to execute the SPARQL/Update statement in Listing 5.4. The same statement both erases the previous location information of the pallet and writes the new information. This produces correct results because the system contains only one pallet. Basically, another update rule could be used to erase the previous information when a Sensor2Changed notification carrying the string ‘OFF’ was received. However, then the number of ontology update rules would be twice as large, which would require some additional work for performing the experiment. Moreover, if such a rule was used, then the equipment ontology would periodically reflect a state in which the pallet is on none of the conveyors.
This is because theLoadFromLeft operation of a destination conveyor is not invoked until theUnloadToRight operation of the source conveyor has completed.
Figure 5.21 shows a sequence diagram representing the conveyor system experi-ment scenario. The six conveyor services are represented as a single object for the sake of simplicity. The diagram shows that once the Orchestration Engine has de-termined the path from the source conveyor to the destination conveyor, it starts repeating a cycle during which the pallet is moved to the next conveyor on the path.
The loop is repeated until the pallet reaches the destination segment. The outer loop in the diagram corresponds to the BPEL ForEach activity that causes the pallet to repeat the loop a fixed number of times.
5. Application Experiments 108
Figure 5.21: The BPEL process, which Orchestration Engine executes, uses Ontology Service to determine the path between the start and destination conveyor segments.