Databases Reference
In-Depth Information
A business process is more likely to span multiple systems, which has led to the
proliferation of point-to-point integration solutions, aimed at tying those bits of
process together into an end-to-end business process. This can further obfuscate
the business process, making it more resistant to change.
Abstracting out a business process into a separate layer gives us a number of
advantages. Firstly, rather than having the process logic buried across multiple
applications, we can now define a single end-to-end process with a far higher level of
visibility and clarity than would normally be achievable. This makes it far simpler to
monitor the end-to-end process, as well as modify it in the future.
It also simplifies our underlying business services, as by extracting the business
process specific logic from them, they naturally become more generic, and therefore
more reusable.
Another byproduct is that as processes are long running in nature, whether for
minutes, hours, days, months, or even years, they are inherently stateful. Thus, the
need for other services to manage state is often removed, again simplifying them as
well as making them more reusable.
It is currently deemed the best practice to make services stateless, as
stateless architectures are typically more scalable (or at least easier to
scale) than stateful ones. In addition, stateless services tend to be simpler
to build and use, making them more reusable.
While to a certain extent this is true, you could argue that up until
recently, many of the WS-* standards and corresponding vendor tools
have not had the required completeness of functionality to support
stateful services. This is now starting to change, so going forward there is
likely to be more of a mix of stateless and stateful services within SOA.
User interface layer
As the top layer within our architecture, this is the layer that consumes the services
provided by the business processes and business services layers. We have labeled
this the user interface layer, mainly because we are using our SOA Architecture as
the blueprint for building a composite application, and this is the layer where the
GUI (either web-based or thick client) would sit.
For the purposes of this topic we will not spend much time looking at this layer, as
it falls outside the boundary of what is provided by the Oracle SOA Suite. However,
for the purposes of delivering a fully-working application, we have provided a
simple web-based user interface developed using JDeveloper.
