Database Reference
In-Depth Information
• Service logic implementation
• Parent service logic
Anything that links your contract or, even worse, your consumer to one of those service
resources can obstruct the core SOA characteristics we are trying to maintain. So, all links
going from contract to service resources or bypassing the contract are bad. The opposite
direction is not much better because providing details of the technology platform or ex-
cessive resource demonstrations is not good, as it can provoke the service consumers to
build their consumption logic based on these details. However, what about the contract-
first principle? Yes, it's a positive thing, so coupling your service logic to the declared
contract is a natural and decent way of implementing the service. However, neither the
service logic nor the service contract has been set in stone—business is evolving, and so
are our services. Quite soon, a new contract version will be published or the core service
logic will be patched. It will eventually turn out that this positive coupling also has its de-
ficiencies. No reason to despair though; it's life. All of us are evolving, and customers
connected to our contract are always welcome. How to deal with this situation using vari-
ous Oracle SOA patterns will be discussed further.
In addition to this, we would like to emphasize that coupling from customer to contract is
the second positive coupling, although it is susceptible to the same problem like the one
with contract evolution. All other couplings must be prohibited if possible. This statement
is not as strong as you would expect. We have touched upon the reason for this earlier in
the tactical goal's architecture example, that is, performance. Standard contract denotes
the message processing overhead, some milliseconds (or more) in addition to the total
processing time, CPU utilization, and memory consumption. Is it worthy enough to jump
over the service contract and utilize service resources directly? Only you know what these
milliseconds of overhead mean for your business, and the decision on what to sacrifice is
yours. In general, the answer is no. Please look at your contract first. Is it truly standard?
Assess your needs using the following logic:
• Do you clearly define your data structures with the required elements only?
• Do you avoid autogeneration, especially for operations with CLOB fields without
CDATA
or
<any>
elements? (Memory leaks during marshaling is a common out-
come of this approach.)
• Can a concurrent contract with more lightweight technology (REST instead of
SOAP) possibly solve the problem? (Concurrent contracts will be discussed fur-
ther in the
Chapter 4
,
From Traditional Integration to Composition - Enterprise
Business Services
.)
Search WWH ::
Custom Search