O'Reilly logo

Patterns: Implementing Self-Service in an SOA Environment by Fernando Teixeira, Shashi Shrimali, Peter Hood, Sandy Grewal, Diego Cotignola, Anup Aggarwal, Carla Sadtler

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 3. SOA and the Enterprise Service Bus 27
򐂰 Virtualization
A key principle of SOA is that consumers who invoke the services are
oblivious to implementation details, including location, platform, and if
appropriate to the business scenario, even the identity of the service provider.
򐂰 Automation
Technologies, such as grid technologies, can apply SOA principles to
implementing infrastructure services that provide an evolutionary approach to
increased automation.
3.1.1 Definition of a service
SOA is an architectural approach to defining integration architectures that are
based on services. Now, it is important to define what is meant by a
service in
this context in order to fully describe SOA and to understand what you can
achieve by using it.
A service can be defined as any discrete function that can be offered to an
external consumer. The function can be an individual business function or a
collection of functions that together form a process.
There are many additional aspects to a service that must also be considered in
the definition of a service within an SOA. The most commonly agreed-on aspects
of a service are that:
򐂰 Services encapsulate a reusable business function.
򐂰 Services are defined by explicit, implementation-independent interfaces.
򐂰 Services are invoked through communication protocols that stress location
transparency and interoperability.
This book uses these commonly agreed upon aspects to define SOA.
Reusable function
Any business function can be a service. SOA often focusses on business
functions. However, many technical functions can also be exposed as services.
When defining function, there are several levels of granularity that you can
consider. Many descriptions of SOA refer to the use of
large-grained services;
however, some powerful counter-examples of successful, reusable, fine-grained
services exist. For example, getBalance is a very useful service, but is not
large-grained.
28 Patterns: Implementing Self-Service in an SOA Environment
More realistically, there are many useful levels of service granularity in most
SOAs. For example, all of the following are services that each have a different
granularity:
򐂰 Technical Function Services (for example auditEvent, checkUserPassword,
and checkUserAuthorization)
򐂰 Business Function Services (for example calculateDollarValueFromYen and
getStockPrice)
򐂰 Business Transaction Services (for example checkOrderAvailability and
createBillingRecord)
򐂰 Business Process Services (for example openAccount, createStockOrder,
reconcileAccount, and renewPolicy)
Some degree of choreography or aggregation is required between each
granularity level for them to be integrated in an SOA.
A service can be any business function. In an SOA, however, it is preferable that
the function is genuinely reusable. In an SOA, the service can be used and
reused by one or more systems that participate in the architecture. For example,
while the reuse of a Java logging API could be described as
design time (when a
decision is made to reuse an available package and bind it into application code),
the intention of SOA is to achieve the reuse of services at:
򐂰 Runtime
Each service is deployed in one place and one place only and is invoked
remotely by anything that must use it. The advantage of this approach is that
changes to the service (for example, to the calculation algorithm or the
reference data it depends on) need only be applied in a single place.
򐂰 Deployment time
Each service is built once but redeployed locally to each system or set of
systems that must use it. The advantage of this approach is increased
flexibility to achieve performance targets or to customize the service (perhaps
according to geography).
The service definition should encapsulate the function well enough to make the
reuse possible. The encapsulation of functions as services and their definition
using interfaces enables the substitution of one service implementation for
another. For example, the same service might be provided by multiple providers
(such as a car insurance quote service, which might be provided by multiple
insurance companies) and individual service consumers might be routed to
individual service providers through some intermediary agent.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required