||Thursday, September 16, 2004
|Aspect-oriented Networking. Its happening. Here's someone else making the
connection between the SOAP processing model and Aspect-Oriented Programming (or
more generally Aspect-Oriented Principles) in Identical
Principles, Higher Layers: Modeling Web Services as Protocol Stack:
[T]here is a fundamental difference between
the layered encoding of data within network systems (see Section Summary ) and
the SOAP approach of encoding layer-specific information in the header of a
SOAP message. While in strict layering, each layer adds a new envelope to the
data received from the layer above, thereby creating a multi-layer envelope
structure around the data, the SOAP approach uses XML's Namespace mechanism to
add new information to the SOAP message. Thus, the SOAP approach can be
seen as being comparable with the general idea of Aspect-Oriented Programming
[AOP] . AOP claims that closed components in software systems are not a
good idea, because there may be aspects cross-cutting through several
components. In the same way as AOP enables code to be written in a way that
transcends usual component boundaries, SOAP enables components on top of
SOAP to access component-specific information independent from the traditional
strict layering enforced by opaque data chunks with layer-specific headers.
The question of AOP vs. Layering and possible problems with one of the
approaches [Jung] is an interesting one and is a profound question of
the most appropriate way to model complex systems.
AOP and its remarkable similarity to the
way SOAP carries additional information in its header is something that we are
interested in investigating in more detail. It is possible that the strict
layering we describe in the Web Services layers 3-5 could and should be
replaced by something more flexible, so that the layering structure of
communicating Web Service peers must not match structurally, but only
semantically (in the spectrum allowed by constraints such as SOAP's
mustUnderstand attribute). It is possible that alternative models of protocol
structuring, such as the protocol graphs used in the context of Dynamic
Protocol Configuration [Plagemann] , provide a more appropriate way of
protocol modeling for the Web Services layers 3-5.
Emphasis added. See my last entry on this
subject, ESB vs.
ESN: Yet another end-to-end debate, which has references to previous
© Copyright 2006 Nicholas Gall.