| Title: | ''Doxpects: XML Transformation Aspects'' |
| Timeframe: | 09.2005 - 08.2006 |
| Supervisor: | Eric Wohlstadter |
| Language: | Java 5 |
| | |
| Background: | The Enterprise Service Bus (ESB) is an architectural pattern that
is increasingly gaining the attention of architects and developers, as it provides an effective approach to
optimize the distribution of information between different types of applications across multiple locations.
 The Enterprise Service Bus architecture. The architecture is centered on a bus which provides a common backbone through which applications can interoperate. The bus provides message delivery services, based on standards such as SOAP and HTTP. Many enterprises find ESB attractive because it combines features from previous technologies with new services, such as message validation, transformation, content-based routing, security, load balancing, etc. ESB makes applications oblivious of the routing services and transport protocols details, and allows substitution of service implementations as needed. Web services in an ESB context provide an architectural approach to decomposing IT solutions into reusable pieces readily responsive to changing business demands. Developing a web service involves working with two different primary decompositions: the object-oriented design and the XML document structure. Developers often get frustrated when mitigating conceptual mismatches between the decompositions. The existing approach to modularizing document-oriented concerns in Web Services is through the use of specialized APIs. Some existing middleware standards, such as the Java XML Remote Procedure Call (JAX-RPC), allow custom Handlers to intercept and transform a SOAP message at various times during a service invocation. Handlers can manage various crosscutting concerns such as logging and auditing, encryption and decryption, and so on. However, they do not support the sound software-engineering principle of ''programming to an interface''. Their coarse-grained interface makes it difficult to map the design of concerns to the implementation and prevents useful static checking by a language compiler (e.g. checking whether two handlers may perform conflicting actions). Aspect-Oriented Programming (AOP) helps to localize code related to a crosscutting concern (aspect) in a single logical unit (aspect definition), and to define points (joinpoints) in the dynamic call graph of a program where aspect-related functionality should be inserted (woven) and executed. With aspects, concerns can be kept separate and be woven together with other concerns during compilation. Moreover, aspects improve modularization and make the system oblivious of the new concerns added into it. |
| | |
| Contributions: |
In our work, we introduce a new aspect-oriented programming model, called Doxpects,
which simplifies the development and maintenance of Handlers. The main benefit of Doxpects is the ability to
perform XML document transformation tasks (insertion, deletion, replacement) in a familiar object-oriented way.
We expand upon the standard AspectJ joinpoint model by including first class support for document content properties.
A content-based pointcut provides the programmer a convenient way to express properties of joinpoints where XML
messages are being processed. A property of a message is expressed in the pointcut using XPath expressions.
The document content matched by a pointcut is parsed into object-oriented entities with XMLBeans to provide a natural Java-based programming model for document-oriented aspects. An aspect does not have to perform the actual transformation, but its signature must contain Java annotations specifying where and how the transformation should be performed. Doxpects enable any request aspect in the Apache Axis environment to construct a response message and initiate a response flow without propagating the request message further towards the service endpoint. For example, an advice might find that the message content contains errors, which prevent further processing of the request. Doxpects can perform useful compile-time checking of pointcuts to detect situations where a parameter type is incompatible with the content matched by a pointcut. Doxpects compiler can analyze aspects to detect ones with conflicting transformations and to verify that the transformation output will be valid at runtime or that the transformations will succeed without runtime errors. For situations when a pointcut matches elements with different types, but with similar content, Doxpects provide a simple way to access and modify content common to the matched elements. The doxpect compiler can use XML Schemas to infer and create a new, dynamic, XML supertype not explicitly available. This supertype contains the common child elements of the matched elements. The schema of the new type is compiled into XMLBeans which provide get and set methods. Alternatively, the compiler can be instructed to generate a dynamic type corresponding to a union of child elements.  The Doxpects framework within the ESB architecture. |
| Downloads: | Paper (PDF) [457 KB] |
minevskiy
gmail.com
|
