Databases Reference
In-Depth Information
Summary
In this chapter, we've provided you with a detailed introduction to the business
requirements of oBay—our fictional online auction site, as well as presenting you
with the architecture for our composite application.
Before we developed our solution, we took you through the process of defining our
high level SOA blueprint, outlining some of the objectives and considerations you
should take into account when developing an SOA-based architecture. Along the
way we've also thrown up a number of questions or issues that need to be addressed,
as well as highlighting particular areas of interest in our overall design.
In the remainder of this section, each chapter will focus on addressing a particular
subset of those issues raised, using various parts of the oBay application to illustrate
each answer. So that, by the end of this section, we will have tackled all the matters
that we've raised including the key question:
"What is the best way to combine/use all of these different components to
implement a real world SOA solution?"
As you are, no doubt, already gathering from this chapter, there isn't a single simple
answer, but rather you have many choices, each with their own set of advantages
and disadvantages. By the end of this section, you should at least be in a position to
understand those choices better and which ones are more applicable to you and that
of your own development.
