Database Reference
In-Depth Information
• ABCS is responsible for consistently maintaining all message header elements.
• Error occurring in the active (poller) northbound ABCS will be not propagated
further. Acknowledge the message returned to the northbound application if ne-
cessary, and a record is usually created in the audit log. Numbers of extraction re-
tries could be unlimited, as a business transaction is not started yet. Still, limiting
the number of retries can be wise.
• Error occurring in southbound ABCS is reported back to the composition control-
ler or actual service worker. The number of retries allowed is limited and policy-
based. Depending on the type of transaction (sync-async), ATC rules are applied.
• ABCS is highly tailored to the endpoint application service. It is not recommen-
ded to have one terminal adapter for several endpoints. It would be quite right to
say that the adapter belongs more to a service-enabled application than an SOA
inventory.
• If the number of identical adapters is substantial, the Adapter Factory pattern
could be applied for instantiating particular adapters of similar types (only the ac-
tual endpoint is different and looked up from the registry). Adapter Factory Ser-
vice acts as a coordinator and does not belong to the ABCS technology layer.
• Transaction Coordinator is a valid SOA pattern for ABCS if data extraction pro-
cedures require transactional control. For instance, some of the data must be ex-
tracted from the first DB and the extraction flags subsequently updated, then an-
other portion of data extracted from second DB, and values changed again and
after that consolidated and validated following the final update. We must remem-
ber that data extraction routines must not be mixed with business logic; otherwise,
we unconsciously introduce a hybrid service on an adapter layer, scattering the lo-
gic over and making this solution very hard to maintain.
Again, from pure logic, ABCS's have no right to exist. If your application is not capable
of being a reliable composition member, it is better to something about it, such as re-
design, rewrite, retest, and reimplement. Alas, it doesn't work this way in real life. From
the version control standpoint, ABCS's are inevitable; however, how many times did we
witness that adapter services with complexities are compared to the application logic it
tried to isolate and abstract. From very beginning though, it meant presenting a light-
weight wrapper only. In most cases, that's the result of the second dissonance with reality,
that is, Assumption 1 is wrong and our application, even with proper WS API, is too
bulky, sluggish, and not reliable to act as a composition member. Yes, implementation of
ABCS could potentially help, but some SOA principles have to be sacrificed (original ap-
plications such as Autonomy, Loose Coupling, and Abstraction), which makes the situ-
ation even worse. Thus, a service must be redesigned in this scenario, as an adapter alone
cannot improve its composability.
Search WWH ::




Custom Search