Database Reference
In-Depth Information
•
Online analytical processing
(
OLAP
) operations are not that demanding when it
comes to response times, but data volumes are usually higher and operational
time slots are either evenly distributed around the clock or tend to be close to the
regular nightly batch-operations time.
As you can see, mixing them together would not be a good idea if we have an overlapping
operational time slot. The possible conflict between high volumes and high throughput
will require your attention at the very early stages of service modeling. Should we abstract
OLAP operations to DWH-specific services?
The second service model is the utility that usually presents the most reusable and supple-
mental logic, consumed by all other services. The level of functional abstraction here is
really high and business-independent. Your transformation, translation, or measure-unit
conversion services are typical representatives of this model. The level of functional gran-
ularity can be easily defined and operations can be tuned for high-usage demands. Migra-
tion issues are not that frequent here, so functional abstraction is fairly simple.
The last model or task service is what we usually know as workflow, which is the com-
position of other services combined together in order to fulfill one single task such as
OrderProcurement and BookingRequest.
Distinctive properties of this service model comprise one task, one operation, and one
business context. Functional abstraction should not be a big puzzle, but still we can see a
lot of misinterpretation caused by the deceptive simplicity of modern development tools,
providing neat visualization of service compositions, plus very mature resource adapter
frameworks starting from order fulfillment (many thanks to Oracle for providing an ex-
tremely detailed
Fusion Order Demo
(
FOD
), available at
http://www.oracle.com/tech-
network/developer-tools/jdev/learnmore/fod1111-407812.html
)
. An enthusiastic developer
can soon include Invoice, Booking, and General Ledger flows into one monster. Entity
services are commonly neglected, as we do not need them anymore; a DB adapter can
provide us with the perfect result in five clicks. Additional interfaces that were construc-
ted while composing this task service can be easily exposed to external consumers. The
problem here is that this service is not a task anymore; it's a hybrid with the worst possible
functional granularity, combining business-specific and business-agnostic capabilities. A
thorough application of the abstraction principle from the very beginning could prevent
this problem.
The deceptive simplicity of development can hoodwink developers, who are left alone
without architectural guidance. This fact provokes developers to use it everywhere,
Search WWH ::
Custom Search