Database Reference
In-Depth Information
•
Canonical Expression
: Operations such as
doTask
and
getOrdforPre-
vRepPeriodInVideoDomainperCountry
are two extreme cases of ex-
pressing service capabilities and neither is consistent or interpretable. In
Chapter
mentioned that the Java naming convention and XML naming standards docu-
mentation could be a good start for establishing a proper naming system.
•
Service Normalization
: Presence of redundant logic should be strictly justified
and generally avoided. Services should not have overlapping functional boundar-
ies, and if you have the same services working in a cluster for the reliability and
performance reasons, it means that you have a Redundant Implementation SOA
pattern in place, not a denormalized inventory. Constantly watch for new services
delivered by different project teams. Prevent any attempts to implement "another
version of that service, just a bit faster and better suited for our (projects) compos-
itions". Almost immediately after implementation, you will have to integrate this
"better service" in your service domain/enterprise and migrate customers.
•
Official Endpoint
: This is another Compound pattern, based on Logic Centraliz-
ation and Contract Centralization. Logic Centralization seems similar to the Ser-
vice Normalization pattern, but generally focusing on gathering agnostic logic in
atomic units of work and presenting them as unique blocks for reuse. The Con-
tract Centralization pattern in this case will guarantee the application of the Loose
Coupling principle and prevent negative coupling. Simply put, in order to keep
our inventory normalized, we will avoid building hybrid services with partial/in-
complete/mixed logic and strictly prevent access to service resources bypassing
service contract.
Thus, SOA methodology supplies us with all the necessary means to minimize the Ad-
apter framework in order to reduce integration efforts. We believe that some technical
demonstration will help you understand ways of service, "canonicalization" in this sense.
Arguably, the most common adapters in our Adapter layer are DB-Adapters, so, probably
we should concentrate our attention on them first in our examples.
Also, we would like to demonstrate how to use the elements of the custom service reposit-
ory we discussed in the previous chapter in our adapters design, mostly because of its
flexible taxonomy. Our intention is not really to build the Adapter layer, but find ways to
get rid of it. Therefore, for the next technical exercise, we would like to put CTU Telecom
aside for the moment (we will return to it soon, discussing Error Handling frameworks)
and select DB-centric Enterprise with lots of business logic concentrated in PL/SQL pack-
ages and a huge integration layer based on different BPEL processes, where most of the
flows are DB-adapters.
Search WWH ::
Custom Search