<<It seems the virtues of SOA are finally beginning to pervade the
corporate consciousness. While architects have considered it a best
practice for decades, business managers are beginning to catch onto
the fact that SOA may be their best ticket to business agility, and
they're starting to invest.
According to a recent ebizQ online survey of over 300 members from 21
industries, increasing business agility is the number one reason for
SOA adoption. In fact the basic tenet of SOA is agility. The goal of
SOA design is to minimize impact of change.
However, while it is fairly straight forward to teach programmers how
to write or call a Web service interface, it is far more difficult to
teach them how to create loosely coupled reusable services that can
easily be changed. This is truly a new programming paradigm.
This article is based on an event-driven service design method that
helps business analysts, architects and developers design services
optimized for agility and reuse. Part of this method provides a
framework for identifying service characteristics and patterns that
can used to create reusable services.
Types of Services
A service is a software component or module that can be combined with
other services to create a business solution or application. Types of
services include:
* Process oriented services. These are business processes that
have multiple steps but fulfill a single business purpose, such as
opening an account, or placing an order.
* Function oriented services. This includes both business and
system functions. Examples of a business function include a software
module that calculates a mortgage, or performs a credit check.
Examples of system functions include error handling and security
authentication.
* Data oriented services. There are a myriad of data oriented
services required to maintain the integrity of distributed data across
the architecture. These include accessing distributed data and
presenting a single view, data mapping and transformation, maintaining
data quality and integrity, and maintaining metadata.
A single process can include all of these types of services. But it
is useful to classify the type of service because different types of
services inherently have different characteristics, including behavior
patterns and communication style.
Levels of granularity
A service can be comprised of one or more services. Getting the level
of granularity right is the greatest factor in enabling reuse. To aid
developers in defining the right level of granularity for the services
we have defined three levels of granularity.
* Business Services represent the coarsest level of granularity.
A business service performs a logical business function or process,
such as opening a customer account. This is the level that business
monitoring and metrics would be applied to.
* Intermediary Services provide location, semantic, and technology
independence between service consumers, business services and provider
services. For example, if the business service requires customer
information that is sourced in several different back end systems, an
intermediary service performs the distributed query and aggregates the
data into a single view. Many of the system function oriented
services, including integration services, can be characterized as
intermediary services.
* Provider Services are the finest level of granularity. Provider
services map to application level interfaces. For example, if a
business service or process includes functions from several different
back end systems, the functionality in each of these systems would be
a provider level service. Examples include retrieving a customer
record or doing a mortgage calculation.
When levels of granularity are defined for different types of
services, patterns begin to emerge. For example, data oriented
provider services will probably need to be provisioned for each of the
CRUD operations for critical enterprise data to maximize reuse.
Service Communication Style
Given the pervasive use of Web Services in SOA implementations,
request-reply is often thought to be the only single communication
style. In fact, SOA has several communication styles, including
asynchronous no reply mechanisms which enable event-driven SOA.
The types of possible communication styles include:
* Synchronous communication requires direct connection between
services. Like a telephone call, the other party must be available in
order for the communication to take place. Synchronous communications
are often blocking - no further processing can occur until a reply is
received.
* Asynchronous communication is like an email or telephone
message. The message is sent to a queue, and read at another time.
There is no live session maintained with the requestor. The actions
are non-blocking, meaning that the requestor continues processing
while waiting for a reply. Asynchronous communications are more
scalable than synchronous communications.
* Request reply is a communication where a consumer, or another
service, makes a direct request to a provider service, and the
provider replies. The interaction is usually synchronous and blocking,
although it is possible to have non-blocking asynchronous
request/reply interactions.
* One-to-one message based communications are generally
asynchronous and non-blocking. An event triggers a request to a
service. The provider service processes the request when it becomes
available, and then (optionally) replies via a message. This creates
loosely coupled communications which provide greater agility and
scalability.
* Publish and subscribe communications are a broadcast type of
communication. Services subscribe to information based on topic or
event, and the information is distributed to those on the subscription
list. Publish and subscribe is an asynchronous non-blocking form of
communication useful when the originating service does not need to be
aware of the downstream consuming services.
An enterprise SOA will likely include all types of interactions. The
key is to know when to use which type of interaction.
Service Behavior Patterns
We have defined three groups of service behavior patterns. An
individual service can include a combination of behavior patterns.
The first group reflects the job of the service.
* Worker is a service that performs a requested function or
process. A worker can be information bearing, or change the state of
the entity it works on.
* Monitor is a service that observes something and report on its
findings based on monitoring and notification rules.
* Agent is a service that observes something and then acts on its
findings, such as providing information to a monitor, generating an
event, or invoking a service.
A service can either be stateful or stateless. It must be one or the
other.
* Stateful behavior means that the state of the service is
actively managed, for example in a transaction. Until the transaction
has committed, the resource(s) may need to remain locked. The
transaction then either must successfully commit or be rolled back.
Process-oriented services are examples of stateful services.
* Stateless behavior means that the state of the service is not
retained between service invocations, or over time. The vast majority
of services are stateless.
Services that include transactions can either be short or long lived.
Essentially this refers to the shelf life of the transaction.
* Short-lived transactions are measured in nanoseconds or machine
processing time. An example would be updating an account balance.
Short-lived transactions are usually stateful and synchronous.
* Long-lived transactions can take minutes, hours, days, even
weeks. Distributed processes which cross organizational boundaries
often include long-lived transactions. An example would be
provisioning a telephone service, or a drop shipment from a third
party supplier. Long-lived transactions are asynchronous. They have
state that must be persisted in the system.
Conclusion
The above framework for characterizing types of services serves a
number of purposes. It helps developers understand the different types
of services that need to be designed. It will help classify service
templates for common patterns, such as a stateless service that
aggregates information from multiple sources, or publishes
information. Over time these templates will become building blocks for
creating reusable business services.
In the short term, one of the low-hanging fruits for reuse is
intermediary system services. These are the services that integrate
and manage disparate services, especially while evolving existing IT
systems into SOA services. Examples include common security services,
translation and transformation services, run-time policy management,
etc. Currently companies are gaining substantial ROIs from deploying
common intermediary services that are reused across projects.
Increased business agility will come from developing business services
and processes that can easily be changed. Increased reuse will come
from developing the finer grained provider services. As organizations
progress down the SOA path and build out all the types of services,
ROI and business agility will increase exponentially.>>
You can read this at:
<http://www.ebizq.net/hot_topics/soa/features/7477.html>
Gervas
