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

Access to the Customer DB and Service catalog (commercial service term) is implemen-
ted using DB adapters, as these resources do not provide public interfaces that are suitable
for the new OM system. These resources are also consumed by other applications that per-
form read-write operations. For a couple of hours every day, Customer DB handles ex-
cessive workload caused by some DWH OLTP operations; thus, to address latency during
this period, developers increased the timeout for this particular adapter.
The Product catalog (and its DB) is presented as a separate service with a standard con-
tract. The XSD for this service was autogenerated, ensuring that the data model was
presented very precisely in the XML schema.
The level of standardization of the presented contract is also ensured by the fact that it
was generated from an entity object based on an existing data model, which means that all
the basic operations such as GET and SET are in place.
Most importantly, developers confirmed that these three Orchestration services are truly
universal and ready to serve multitenant requests. It was achieved by placing complex
branching logic into TOM and COM with separate branches for each country/affiliate. For
some use cases, which are not formalized yet, separate placeholders are preserved for later
implementation. At some places, additional transformation will be implemented in the
next phases to make it rapidly available for adapters.
The development team is not concerned about the size of the composition, as they believe
that the partial state deferral DB will be capable of handling the process hibernation state.
Error-handling routines are covered by throwing SOAP fault errors with maximum de-
tails, as we mentioned previously.
A summary of the initial solution
Branching logic with dynamic expansion of branches depends on the root conditions that
lead to an avalanche-like physical implementation. Starting from obvious business frac-
tions, it would be very hard to stop. At the time of initial analysis, three coupled processes
had nearly 20,000 lines of BPEL code (the code was written over several years by a very
big consulting company). It not only makes the code unreadable (by other developers), but
also unmanageable (by ops, as opening the failed flow in the Enterprise Manager ( EM )
console could take five minutes). By the way, did we mention that the company has had
operations in ten countries, and the BPEL code branches have to accommodate each of
these countries' specific logic as well?