|
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.