Information Technology Reference
In-Depth Information
the proposed framework is to weave aspects into the SOAP message processing
chain. The weaving of aspects at this point enables us to be independent of
the concrete service implementation: the processing chain typically operates on
XML documents and weaving into it does not interfere with the service imple-
mentation. In advance, an aspect configurator enhances the existing middleware
by allowing to weave aspects and, e.g., to check whether it is allowed or pos-
sible to weave an aspect into a service based on the aspect definition and the
enforced security constraints. The framework is based on the following design
considerations:
Dynamic weaving:
Since the implementation language of a web service is typ-
ically unknown, and the client's and the service's administrative domain differ,
aspect weaving must be performed dynamically. As mentioned before, the mid-
dleware container hosting web services should expose web service methods for
adding and removing aspects during runtime.
SOAP message chain:
Due to the contract-first conception of web services,
aspects are not allowed to change the previously negotiated interface (i.e., the
WSDL description) of a service. Ideally, the aspects have to be placed in the
SOAP processing chain to circumvent a modification of the interface. They must
be able to deal with SOAP request and response messages such that a modifi-
cation of them does not change their syntactical representation.
Caller/callee interaction:
On the client side, the framework must have the
ability to distinguish between different web service invocations and communica-
tion partners who are possibly affected by an aspect. An aspect affecting two
subsequent services can only be added to a service if the corresponding aspect
on the subsequent service can also be applied. On failure, the aspect has to be
removed. Consequently, an atomic behavior of aspect weaving must be ensured.
This includes the possibility for a caller to check whether an aspect is available
that can be enabled, and to determine which aspects are currently active for this
particular caller.
Scope:
Aspects must have a certain scope [19]. A scope specifies whether the
aspect is only valid for the client that has woven the aspect or whether the aspect
is valid for all callers.
Security:
A security manager must ensure that only authorized clients and
aspects make use of the framework. The security manager can enforce that only
aspects that meet security requirements canbeusedordeployed.Usingestab-
lished authentication mechanisms (e.g., SSL/TLS with client verification [20]),
only authorized users are permitted to use the aspect configurator and to deploy
signed aspects.
State:
Since web services are stateless, aspects and advice should not maintain
any internal state, besides the information stored in the external key value store
(see 3.2) and in the message itself, respectively.
In Figure 1, the general design of the proposed framework for request/response
aspects is shown. Our framework operates on the server side as well as on the
client side. At the server side, there is a configuration interface (to be called by
the client), a configuration manager and a component that performs the actual
