Home Teaching Research Publications Presentations CV

CLIDE


Example
Setup

Services-oriented architectures aggregate a collection of web services in order to provide more sophisticated web services and to support web applications. The figure on the right shows a simple instance of such an architecture, where two sources support a computer shopping portal, such as CNET.com. The scenario assumes that Dell and Cisco export a set of web services on their computer and router catalogs, respectively. Since the user wants to be able to issue (distributed) queries, we associate schemas with Dell and Cisco and model the web services as parameterized views over those schemas. Part of their respective schema and the signatures of four Web services they export are listed below.

The Dell schema describes computers that are characterized by their cid, CPU model (e.g., P4), RAM installed and price, and have a set of network cards installed. Each network card has the cid of the computer it is installed in, accommodates a specific data rate (e.g., 54Mbps), implements one or more standards (e.g. IEEE 802.11g) and communicates with a computer via a particular interface (e.g., USB). The Web service ComByCpu returns the computers of a given cpu. The service ComNetByCpuRate provides computers of a given cpu that have installed network cards of a given data rate.

The Cisco source describes routers that also accommodate a specific data rate, implement standards, have their own price and are of a particular type. The rouByTypeW and rouByTypeWL services return routers that are of either wired or wireless type respectively.

The user builds the computer shopping portal by formulating queries against the source schemas, and deploys a mediator in order to execute queries against the exported web services during run-time. The mediator can answer the query ``return all P4 computers with a 54Mbps network card and the compatible wireless routers" by combining the answers of web service calls CompNetByCpuRate and rouByTypeWL. However, it cannot answer the query ``return all computers with 1GB of ram".

Dell Schema & Web Services
Computers(cid, cpu, ram, price)
NetCards(cid, rate, standard, interface)

V1: ComByCpu(cpu) -> (Computer)*
SELECT DISTINCT Com1.*
FROM Computers Com1
WHERE Com1.cpu=cpu

V2: ComNetByCpuRate(cpu, rate) -> (Computer, NetCard)*
SELECT DISTINCT Com1.*, Net1.*
FROM Computers Com1, Network Net1
WHERE Com1.cid=Net1.cid AND Com1.cpu=cpu
AND Net1.rate=rate

Cisco Schema & Web Services
Routers(rate, standard, price, type)

V3: rouByTypeW() -> (Router)*
SELECT DISTINCT Rou1.*
FROM Routers Rou1
WHERE Rou1.type='Wired'

V4: rouByTypeWL() -> (Routers)*
SELECT DISTINCT Rou1.*
FROM Routers Rou1
WHERE Rou1.type='Wireless'

Assume the user wants to formulate a query that returns computers that meet various conditions, including conditions about networked cards and routers - as long as those conditions are supported. The following snapshots are taken from of the user's interaction session with CLIDE, where CLIDE's color scheme suggests, at each interaction step, which actions lead to a feasible query. The first two snapshots explain the intuition behind the coloring scheme, while the last four present complex cases where the interface's color scheme informs the user about non-obvious series of actions leading to feasible queries.

Snapshot 1

In Snapshot 1, the user has dragged the Computers table name from the table list and dropped it into the main pane, subsequently performing two projection actions by checking the corresponding projection boxes of ram and price. These actions result in the Com1 table box, where the cpu selection box is yellow. The yellow signals that the corresponding selection action is required in order to formulate any feasible query that extends the current one. The rest of the selection boxes and projection boxes are white suggesting that these actions are optional, i.e., feasible queries can be formulated with or without these actions being performed. The feasibility flag on the upper right corner indicates that the currently formulated query is infeasible.

The user performs the yellow selection action on cpu by typing the constant `P4' in the selection box, which leads to Snapshot 2.


Snapshot 2

The flag now indicates that the current query is feasible. This query is feasible since the mediator can run view V1 with the parameter instantiated to 'P4' and then project out the cid and cpu columns.

At this point, the user either terminates the interaction session and incorporates the formulated query in her application or continues to extend the query. To accommodate the latter case, the front-end suggests that at least one of the Computers Com2, NetCards Net1 or Routers Rou1 table actions has to be performed by coloring the corresponding names in the table list blue. Intuitively, the blue table names indicate that in the FROM clause of feasible queries that extend the current one there has to be at least one of the NetCards Net1, Routers Rou1, or a second Computers Com2 table atom. However, a given blue atom, say NetCards Net1, does not appear in all feasible queries that extend the current query. If it did appear in all, then it would be yellow (i.e., required).


Snapshot 3

In Snapshot 3, the user has performed the NetCards Net1 table action. The front-end suggests either a join action on the cid of the two table boxes (it leads to the formulation of view V2) by drawing a join line connecting the two column names and coloring it blue. The join line is not colored yellow, because the user has another option. She can perform the blue Computers Com2 table action, which will lead toward a feasible query that joins Net1 with Com2 and takes a Cartesian product with Com1.


Snapshot 4

In Snapshot 4, the user has performed the suggested join action and Computers in the table list is now optional. If she performs the blue rate selection action next, then she will formulate a feasible query, since the mediator can run view V2 with the parameters cpu and rate instantiated to the constants provided in the selection boxes. Alternatively, she may perform the blue Routers Rou1 table action and join the rate columns of Net1 and Rou1, i.e., find network cards whose rates are compatible with the routers. Taking the latter option leads to Snapshot 5.


Snapshot 5

The front-end suggests the join action on the rate columns of Net1 and Rou1 table boxes. The Net1.rate selection box remains blue since the user still has the option to provide a constant and formulate, for example, the query that returns the Cartesian product of Rou1 and view V2. All table names in the table list are white, because no more table actions are needed at this point in order to formulate a feasible query. The Rou1.type column needs to be bounded and the front-end presents to the user a drop-down list that explains which constants may be chosen. She can either choose 'Wired' or 'Wireless'. The symbol * denotes any other constant and is colored red to indicate that no feasible query can be formulated if she chooses this option. Note that the options of a drop-down list can have different colors. If there were only one constant that she could choose, then this option would be yellow. In the special case where any constant can be chosen, then no drop-down list is shown, as in the case of the cpu selection box in Snapshot 1.


Snapshot 6

In the next steps, the user performs the suggested join action, chooses the 'Wireless' constant and checks several projection boxes. Snapshot 6 shows the new query, which is feasible. The mediator plan that implements this query first accesses view V4, then for each rate returned accesses view V2 with its parameters instantiated to `P4' and the given rate, and finally performs the necessary projections. Note that all table names in the table list are now blue, because any of those table actions lead to a feasible query.