SOA Ecosystem–Interconnected Principles, Patterns, and Frameworks - Applied SOA Patterns on the Oracle Platform - page 23

that with a more fine-grained XSD, you will put more processing demands on the con-
tract's message processing logic—XDK marshalers (serializers). With a more coarse-
grained granularity, you inevitably put the big chunk of message parsing and validation
logic into the service's component logic behind the contract. It could also make service
difficult to test, as highly abstracted contract will not reflect any changes that are sup-
posed to be presented to the Consumer.
Other abstractions include the abstraction of technical details hidden behind the service
contract, and programming language aims to increase the federation of our heterogeneous
service infrastructure. Abstracting contract-related parts of SLA, such as quality of ser-
vice, availability information, and performance metrics also helps to standardize service
profiles within a service inventory.
We have deliberately put aside the security considerations related to the abstraction prin-
ciple until now. By declaring more precise data types, you could reveal technical informa-
tion necessary for data-oriented attacks. When using the data type casts features, the at-
tacker could trigger the error, revealing internal data structures associated with the ele-
ment (the point of the attack) and exploit them. An element with the type <any> reveals
nothing, but at the same time allows it to send any types of data, including the harmful
code. With such a high level of abstraction, presenting the service contract with the opera-
tion Process and data model Any , you literally open the door for all kinds of parser-re-
lated attacks, memory leaks, and buffer overflows. Possible ways of balancing the granu-
larity and abstraction levels for services that operate on different technology layers will be
discussed further in Chapter 7 , Gotcha! Implementing Security Layers .
The ultimate purpose of principles' implementation in SOA is to increase the service com-
posability options as a direct method of increasing ROI. A less abstract service contract
where more information is revealed tends to be more attractive for developers as they are
more interpretable.
The implementation of this principle directly affects SOA characteristics such as composi-
tion centricity and vendor neutrality. This principle directly supports Loose Coupling. Ab-
straction from excessively expressed technical details will certainly increase the business
value of the service (business-driven).
Service reusability
The first three fundamental principles combined together will lead us to the declaration of
the first really tangible design principle, that is, reusability . One can say that this is the