Database Reference
In-Depth Information
• Your data model that is based on your corporate-approved entity's
Canonical
Data Model
(
CDM
)
• Your naming standards are very clean and comprehensible, based on industry
standards
Who can give you a warrant that the business logic, encapsulated in your service, will not
change tomorrow and that an auxiliary-declared operation becomes a burden or even an
unwanted shortcut in the business process? How about a number of consumers who be-
come dependent on your extra feature? Migration in SOA is not an easy task, even with
certain SOA patterns applied.
On the other hand, even in a relatively static business ecosystem, this new feature could
become so popular that all of the hardware power dedicated to your service scope will be
consumed by only this one operation.
Level of abstraction - granularity and models
So, do not promise anything and keep everything for ourselves? Let's not blow this out of
proportion. SOA is full of promises; it was designed in this way, and luckily, we have
enough methods to keep these promises. If service capabilities (that is, operations) are
correctly planned from the beginning and used unevenly, then maybe we have put too
much on a single service's plate. What is the functional scope of this service? If this ser-
vice handles one single business entity (such as invoice), then all our operations should be
bound to its functional context, which is abstracted to the level of a functionally com-
pleted environment. You would hardly keep salt, sugar, and flour in one jar in your kit-
chen just because all of them are white. Still, it's rather amazing how this simple thing
called granularity is neglected in the real life of service development.
Functional granularity is based on the understanding of service models. Entity services
that are already mentioned are the first and closest abstracts to the atomic data representa-
tions in an enterprise, for example, invoice, order, cargo unit, and customer. All operations
would be naturally based on the DB CRUD model but not limited by them. The number of
truly unique entity services is rarely more than 20 in any enterprise. The functional granu-
larity here is usually based on the OLAP/OLTP segregation:
•
Online transaction processing
(
OLTP
) as very short, real-time, CRUD-like op-
erations with high demands for response time are naturally the primary capabilit-
ies of the entity services, and their operational time slot is frequently within the
standard business hours (that is, 08:00-17:00)
Search WWH ::
Custom Search