Databases Reference
In-Depth Information
Like most architecture diagrams, this is over simplified. For example, it implies
here that the
User Interface
layer will always have to go via the business processes
layer to access a business service. In many circumstances, to mandate this as an
architectural requirement would be over-burdensome, and as a result, impair our
key goals of re-usability and agility.
While we've labeled the top layer
User Interface
, it could potentially be any
consumer of our services, who sits outside our domain of control, whether internal
or external to our organization. Let's examine these layers one-by-one, starting at the
bottom and working our way up.
Application services layer
When we look at the various layers within a service-oriented architecture, each layer
typically builds on the previous layer. However, at some point we need to hit the
bottom. This is the layer we have termed the '
Application Services
layer'. This layer
is typically where the core service is actually implemented, or if you like, where the
"real" work happens.
We refer to it as the
Application Service
layer, as most services are typically
provided by existing applications. These could be packaged applications, such as
Oracle E-Business Suite, Siebel, PeopleSoft, SAP, or custom applications developed
in-house using technologies, such as Java, C#, Oracle Forms, PL/SQL, and so on.
Many modern day applications are web service-enabled, meaning that they provide
web services out-of-the-box. For those that aren't, adapters can be used to service
enable them (as we discussed in
Chapter 3
,
Service-enabling Existing Systems
).
The key here is that from our perspective, this is the lowest level of granularity that
we can go down to, and also the actual control we have over the interface of services,
at this level, is limited or non-existent. This tends to be the case regardless of whether
or not we have control of the application that provides the service, as the actual
interface provided is often a reflection of the underlying application.
It's for this reason (that is, lack of control over the service interface) that we also
include in this category native web services provided by other third parties, for
example, services provided by partners, suppliers, customers, and so on, as well
as
Software as a Service
(
SaaS
).
Virtual services layer
This is a relatively thin layer that provides a façade on top of the
Application
Services
layer. The key driver here is to achieve our goal of decoupling the services
provided by the underlying applications (over which we have varying degrees of
control) from any consumers of that service.
