Database Reference
In-Depth Information
By doing so, you are just forcing everyone to adapt to your specifications, which include
existing applications. Surely, if you are an architect in a big bank, this approach might
work; we're hesitant about the stub's implementation time at the remote end.
The second point here is that we can build a very robust service-oriented system without a
single web service. The Oracle PL/SQL will do it beautifully, and we will demonstrate it
in the next chapters. So, the contract could be anything that declares public operations,
available protocols, and data structures such as the PL/SQL package header
.pks
, C++
class header
.h
, and the Java interfaces (also called contracts). Component-based devel-
opment is a completely valid approach in SOA if it's approved by all the members of the
implementation domain. Interactions between different domains will require some integra-
tion efforts even if the technology is the same, but that would be true for web services as
well, so that's not a major drawback of using components as SOA's building blocks.
The problem here is that all components' contracts are nondetachable compared to
WSDLs. The true beauty of WS interfaces is that we can sit in a quiet corner along with
developers and business analysts and by using just a pen and a napkin describe the proto-
type of service compositions, go back to our stations, and start coding right away. Talking
seriously, by describing the detachable contract as WSDL, we can really provide a parallel
development process and work on an iterative development in a reasonably painless man-
ner. Simply speaking, you can compile the service logic (Java) without WSDL and try to
do the same with a PL/SQL package body without the package specification. Finally, the
most important thing is that this contract-first approach allows us to generate the code
based on an initially defined and mutually accepted contract, and Oracle is really good at
it. Practically, you can generate skeletons on any platform that you want to be your logic
carrier, such as Java, BPEL, and Mediators.
A standard contract is the primary means of presenting your service as a corporate asset to
maintain at least two main SOA characteristics: Composition-centric and Enterprise-cent-
ric. With the WS-based approach, you will achieve vendor neutrality as well.
Loose Coupling
This principle is probably the most well-comprehended principle. Everybody knows that
tight coupling is bad. Is it really? To discuss this, let's first describe what kind of coup-
lings we could get. You'll be able to understand this from the realization of service ana-
tomy. Basically, we have the following:
• Service resources, presented as DB, file structures, and so on
• Technology platform (Java, .NET)
Search WWH ::
Custom Search