Building the Core – Enterprise Business Flows - Applied SOA Patterns on the Oracle Platform - page 184

Functional analysis would not be complete without defining the message structure that is
consumed and propagated between the controller, composition members, service pro-
viders, and composition initiator. Obviously, the message payload is the Order in the
CDM form according to the TMForum specification. As mentioned in Chapter 1 , SOA
Ecosystem - Interconnected Principles, Patterns, and Frameworks , discussing the Stand-
ardized Service Contract , the optimization of its structure is extremely important, but we
cannot approach it just yet due to compatibility reasons (external applications are used to
it) and because all those enormous BPEL processes are our primary concern at the time.
However, we will have to address message normalization as soon as possible. Due to this
pending task, we have to construct our message in such a way that the alteration of pay-
load would not affect Composition Controller's functionality, that is, make it universal (or
process agnostic). It could be possible if we isolate the payload and a dynamic part of it,
and expose the payload object's particulars in the message header. The Execution Plan(s)
must also be presented in the message, and mandatory routing slip(s) and statuses of ob-
ject alterations must also be preserved for the controller's convenience.
All these message components are best discussed in conjunction with the Service Reposit-
ory taxonomy, and we will do that in the coming chapters. We would just like to stress on
the fact that the implementation of a universal message-container will convert our Com-
position Controller into a truly agnostic service that is capable of serving not only Order
messages, but all types of payloads in a very dynamic and lightweight fashion. This will
inevitably lead to the following consequences:
• As you will realize, a universal message container can be designed by the imple-
mentation of the <any> element in the payload section. (Yes, by [CDATA] as
well, but we are not talking about this extreme case for obvious reasons.) We
mentioned this point in Chapter 1 , SOA Ecosystem - Interconnected Principles,
Patterns, and Frameworks , as rather undesirable: security considerations and ex-
cessive XML processing at the backend. This could be fairly and successfully
mitigated by the following:
◦ We are in the EBF framework behind security gateways in DMZ and the
conventional ESB. If the enemy is already present, it's too late anyway.
◦ Besides, our payload is not really <any> ; it's still a corporate EBO
(Order, Invoice, Client, Device, and Resource) and is strictly compliant
with CDM's XSD. If we would like to perform message screening in EBF
by means of an XDK, we can do that easily (although, it's rather unusual
and ineffective all the same).
• The message header will be in place despite the presence of any type of message
structure. Should we also mention that it will be SBDH-compliant (see Chapter 1 ,