Database Reference
In-Depth Information
essence of all the SOA principles. Still, we will not crown it above all others, as it cannot
be maintained alone without proper foundation of the first three. In the topic dedicated to
the Java EE enterprise architecture,
Sun Certified Enterprise Architect for Java EE Study
Guide (2nd Edition)
by
Mark Cade, Humphrey Sheil, Prentice Hall Publishing
, this prin-
ciple is not included in the requirements for the component's architecture. The first three
include performance, scalability, and reliability, and that's absolutely true. No one needs
reusable components that are unreliable and cannot perform as intended.
We just have to realize that these illities here are applied to the service logic, presented by
Java components. If it's not reliable, and we would like to put that first, we must not
present this logic as a public service. In traditional component architecture, the reusability
support is delegated to the integration layer. In SOA, we strive to make services reusable
by means of the following:
• Defining the standard contract, exposing canonical data and canonical operations.
• Making internal service logic more universal (another synonym for abstract) and
suitable for reutilization by other services. As discussed earlier, only one service
model is allowed to be highly specific, that is, task, as a composition of other ser-
vices, fulfilling the specific operation.
• Preventing negative couplings by promoting the technical contract as only one
way of accessing the service logic.
The level of reusability is really easy to assess: just count the number of compositions
where this service participates. The implementation of this principle directly promotes
composability and the enterprise's centricity. Let's now look at the two pure technical prin-
ciples that support reusability.
Service autonomy
An service can maintain the required level of reliability (measured by MTBF as time, or
percentage as an availability) necessary for consistent reuse only if it can possess and con-
trol its own underlying resources. Database, file objects, physical realization of the service
logic, and so on should not be shared or delegated to other services. The service should be
perceived as an atomic unit of concrete logic, functioning in a dedicated technical envir-
onment. In this case, the service behavior will be predictable, fulfilling scalability require-
ments, and making it possible to relocate the service into a similar technical environment
with reasonably low efforts. This last illity is highly desirable for a cloud-based imple-
mentation.
Search WWH ::
Custom Search