Information Technology Reference
In-Depth Information
often referred to as “Programming in the Large”. The composite web service
orchestrates the control flow between the original web services, stating the order
in which their methods are called. To keep services decoupled, their interaction
is managed by a client (i.e., a composer service like a workflow engine), and the
services do not have any information about the service to be called next.
While powerful in terms of compositionality, the downside of the “Programm-
ing-in-the-Large” paradigm is that the control flow dictates its structure onto
data-flow related concerns, which may not always be appropriate for them. We
have experienced problems related to this dominance of the control flow structure
during the development of a large-scale service-oriented platform for content-
based search in image and video databases [10,11]. Following the service-oriented
paradigm enables us to reuse multimedia algorithms, encapsulated as services, in
different workflow configurations. However, it also forces data transfers between
two subsequent multimedia services in a workflow to travel via the composition
client in the middle, which is neither necessary nor desirable: The available
network bandwidth of the machine hosting the BPEL engine can very quickly
become a bottleneck and the runtime performance will decrease significantly.
OnewaytosolvethisissueistoavoidthetransferofhugedataviatheBPEL
engine by using the Flex-SwA framework [12]. Instead of huge binary data,
only a small reference is transferred from the data-producing service via the
composition client to the data-consuming service. The data consuming service
resolves the reference and gets the binary data. However, this technique requires
that the involved services have reference data types in their method signatures
and in their return values, respectively. Furthermore, modularity and decoupling
of web services would suffer from scattered code for data handling.
It is preferable to have a solution that allows e
cient data transmission in
data-intensive service workflows without noticeable additional development ef-
forts and without losing modularity and decoupling of services. One would like
to be able to superimpose a structure over the service control flow such that the
data transfer cuts across the control flow. Aspect-oriented programming (AOP)
is a paradigm that is aimed at increasing the modularity of software [14]. Cross-
cutting concerns such as the ecient transmission of data can be modularized in
aspects. AOP enables a developer to integrate aspects into existing applications
via join points, i.e., particular points in the control flow that specify when such
modularized code (called “advice”) should be executed; the description of a set
of join points is called pointcut.
In this paper, we present
request/response aspects
for web services to address
this problem. The proposed request/response aspects allow to add non-functional
requirements at the web service communication level, and to execute aspect code
on a remote host where a web service is running. They are independent of a web
service's implementation language and do not assume that a web service imple-
mentation itself provides related functionality. For example, in the multimedia
workflow mentioned above, the components for ecient data transmission can
be woven dynamically into the communication infrastructure on top of which
the web services run
without
changing their implementations or their interfaces.
