Database Reference
In-Depth Information
Unfortunately, this principle is probably the hardest to implement. We all know that most
commonly used databases are shared resources. License costs, bundles of legacy applica-
tions, common network infrastructure, and so on are the reasons why this principle is very
hard to achieve without significant investment or considerable maintenance efforts.
This principle is quite often mistaken for Loose Coupling. Indeed, they are very similar
with regards to the negative impact on service reusability, although we can draw a distinct
line between them as mentioned as follows:
• Loose Coupling is the ratio between iterations, carrying through the service con-
tract from consumer and service resources (relatively positive coupling) and itera-
tions bypassing the contract (negative coupling). In fact, the service is always
coupled if it's in use, positively and negatively. Service-oriented architecture
based on components is more prone to negative coupling, as their APIs are more
technology-specific.
• Service autonomy is the measure of service independence. A business usually has
quite a limited number of
data warehouses
(
DWHs
) (usually one per business
domain and ideally—only one). Therefore, all analytical services (InvoiceHistory,
OrderHistory, and so on) using a single DWH DB will not be autonomous.
Present them as one service (this is not an advice), move into a private cloud, and
you will get a perfectly autonomous service. Now the question is the price.
The implementation of this principle directly promotes the composition and enterprise
centricity and vendor neutrality.
There are no negative impacts on other principles, but as we have said, true service
autonomy is the nirvana that is really hard to reach.
Service statefulness
This second technical and very tangible design principle is the support of the service re-
usability.
It's defined as an ability of a service to maintain low-resource consumption when needed,
namely between service activities, while waiting for a response, and so on.
At first glance, it's more applicable to the long running asynchronous services, which
could run for days or weeks. The deferring service state is vital here. We have to store ex-
ecution scope variables and preinvocation data in a special database with all necessary in-
formation for waking it up when the response arrives. In this Hibernation DB (
dehydra-
Search WWH ::
Custom Search