Oracle Corporation

Introduction

In trying to come up with a comprehensive framework for Web Services
using XML, we have discovered use cases where a standard model for XML
Processing and XML Flow is very useful. In this paper we will describe a
system for Web Services Aggregation and Composition which incorporates
various use cases where XML processing is required.

XML Processing Modules and Web Services Aggregation

A Web Service is an encapsulation of functionality that can be accessed
using various internet protocols and can be reused across application
needs. XML plays an important role in the definition of particular Web
Services, as it is important also as a message protocol to achieve
maximum interoperability. In other words, a Web Service can be seen as a
black box that takes in requests in the form of XML and returns
responses also in the form of XML. Specifically in the definition of a
Web Service that aggregates other Web Services, there is a need for a
syntax that describes the different interactions among the sub-services
and other related XML processing. For example, a single Web Service
request may be used with multiple Web Sub-Services and therefore a
transformation is necessary to adapt its syntax for each of them.

In the specific case of Web Services Aggregation, an XML pipeline can be
built out of 6 types of simple processing blocks. The data flowing among
these modules consist of an array of XML messages whose cardinality can
vary according to the type of processing applied by the module. The
processing of the modules is activated by an incoming event containing
the XML messages. The processing flow is defined through a directed
graph.

1) Message Transformer: this module transforms the XML messages supplied
in the incoming by applying the XSLT stylesheet specified as a module
property. The module can be used to perform necessary transformations to
adapt the syntax of an XML message to fit the one requested by a
specific XML request. The cardinality of the XML message array in the
outgoing event is the same of the incoming one (n->n).

2) Message Splitter: this module splits a single message into multiple
messages. Its properties specify a set of XSLTs to be used to convert
the supplied message. Each of the specified XSLT will be applied to the
supplied XML message and the result
appended to the array of messages of the response event. The module can
be used to feed the same XML request to a multitude of Service Execution
modules after the message has been transformed to fit the right syntax.

The cardinality of the XML message array in the incoming event is 1,
while the cardinality of the outgoing XML message array is greater that
1, depending on the number of associated XSLTs (1->n).

3) Message Merger: this module merges multiple service messages into one
single message through the XSLT specified in its property. The module
can be used to merge the result of multiple service executions into one
single final response.The cardinality of the XML message array in the
outgoing event is 1, while the cardinality of the incoming XML message
array is greater that 1, depending on the number of associated XSLTs
(n->1).

4) Service Execution: this module executes one service. The service to
be executed is specified at design time by setting one of the module
properties. Its execution is triggered by an event which carries an
array of XML messages. The Service Execution module will interpret them
as requests, and, after the service execution, it will produce another
array of messages composed of the responses returned by the service
execution(s). It is particularly interesting to notice how compound
services can be used in service execution modules for building new
compound services. The cardinality of the XML message array in the
outgoing event is the same of the incoming one (n->n).

5) Conditional: this module can be used to take different execution
paths according to some conditions. The response event of this module
will instruct the compound service execution adapter on deciding which
execution flow (dependency matrix) to use to identify the next modules
in the execution flow. The conditional module does not have any impact
on the XML processing rather on the pipeline flow.

6) Custom: the logic in this module can be programmed using the Java
language. The module has to implement some interfaces for handling its
properties and events.

Conclusion

This paper has presented the various use cases for XML processing models
applied to Web Services. These use cases highlighted a need for a
standard model for processing XML. Here we present this to the
Workgroup, in the hopes of achieving our eventual goal of global synergy
in the area of XML Processing pipelines.