Database Reference
In-Depth Information
Initial analysis
Something can be spotted immediately such as the service name(s). Yes, it's quite far from
canonical by any standard. Minor thing, you say? Unfortunately not. As mentioned, a lot of
vendors and solution providers are concurrently implementing different projects using cent-
ralized OEBS instance and an Adapter framework around it. How can we be sure that the
service purpose and context can be unambiguously understood and then properly used?
Regretfully, a strict governance policy and centralized control weren't established the best
from the very beginning of Service Inventory creation, which opens the door for redundant
logic implementation and service denormalization in general. This fact affected the Adapter
frameworks quite severely, leading to multiple adapters of the same nature and hybrid ser-
vices instead of task-orchestrated services in a right block of figure in the
Optimizing the
Adapter Framework
section.
External programmers and Trading Partners became confused by the magnitude of inter-
faces and business operations offered in unstructured and unclear ways, which inevitably
leads to a strong desire for most of them (internal TPs, developed and controlled by solu-
tion providers) to get direct access to underlying OEBS resources.
This is not the worst yet. We already mentioned the Oracle Business Event System as a
core component for handling business events in OEBS, acting as a subscribe-publishing
mechanism to all consumers for all business events occurred in any business domain. By
default, BES has more than 1,000 seeded events, preconfigured for most common business
cases per domain. Generally, it gives you a great flexibility to propagate the Event message
in order to trigger any process in OFM or run any custom module from the custom schema.
The configuration of events and event subscribers is relatively simple and can be done in a
few clicks using the OEBS Admin console. The problem here is that without proper guid-
ance, each vendor (such as IBM, Accenture, Capgemini, and lots of others) who is involved
in project delivery in RRD has their own understanding (or misunderstanding) of business
events and their relations. Some might think that there is no required event or no proper ac-
tion for the event and so on. Even with a common understanding of the concept, there is
enormous temptation to make a shortcut under the pressure of a tight project schedule. And
the result is hundred lines of code (literally!) in dozens of triggers, associated with main
business tables in each domain. Even more—lots of weird events registered in BES, con-
nected to dead or malfunctioning business procedures. After a year of such implementation,
the BES finally failed completely as a module and as a concept and RRD administrators
just shut it down.
Search WWH ::
Custom Search