Databases Reference
In-Depth Information
Defining the 'wrapper' elements
In the 10gR3 release of SOA Suite, we used to advocate defining the wrapper
elements within the WSDL document of the web service, as separating those out into
a standalone schema provided little value.
With 11gR1, we recommend a
different
approach—to define the wrapper elements
in a separate schema in their own namespace, which we then import into our WSDL
document. This allows us to reuse these wrapper elements within our composite.
Recall the basic composite design pattern that we introduced in the previous
chapter, where we use a Mediator as the entry point for a composite, as shown
in the following screenshot:
With this pattern, the Mediator implements the abstract WSDL for our service, and
acts as a proxy responsible for routing requests from the service consumer to the
appropriate components within the composite.
Each of these components, in turn, implements one or more of the operations defined
in our abstract WSDL. By separating out the wrapper elements into a separate
schema, we can reuse these when defining the WSDL for each of these components.
This ensures that within our composite, we have a single consistent definition of
our message types. This makes it simpler to manage change as well as ensuring
our proxy is not required to perform any transformations.
Whichever approach you follow, resist the temptation to define your wrapper
elements
within your canonical model, as doing so will pollute your model as
well as make changes harder to manage.
