Unit 1:

INTRODUCTION TO SOA

Contents
Introduction to services
Fundamentals to SOA
Definition to SOA
Common characteristics of contemporary SOA
Common misperceptions about SOA
Common tangible benefits of SOA
Common pitfalls of adopting SOA
The Evolution of SOA: from XML to Web
services to SOA
9. The continuing evolution of SOA
10.Comparing SOA with N-tier architecture: The
roots of SOA
1.
2.
3.
4.
5.
6.
7.
8.

1. What is Services?
Service is
component of distinctive functional meaning
that typically encapsulate a high-level
business concept
Lego block

Service contains
Contract message type def, contraint,
description (comment)
Interface set of operations
Implementation Logic and data

1.2 Type of Services

1.3 Examples of a Service

Creating a Purchase Order inside a
mainframe application
Requesting and reserving a room in a
hotel
Applying for a loan by filling out a
loan request form
Search books/music based on
keywords

2. Fundamentals of SOA
Logic required to solve a large
problem can be better constructed,
carried out, and managed if it is
decomposed into a collection of
smaller, related pieces.
Each of these pieces addresses a
concern or a specific part of the
problem.

2.1 A service oriented analogy:

Cosmopolitan city
Individual companies are service-oriented in that
each provides a distinct service that can be used by
multiple consumers
Business Community
By decomposing the community into specialized,
individual outlets, we achieve an environment in
which these outlets can be distributed.
SOA represents a model in which automation logic is
decomposed into smaller, distinct units of logic.
Collectively, these units comprise a larger piece of
business automation logic.
Service-oriented architecture (SOA) encourages
individual units of logic to exist autonomously yet not
isolated from each other

2.2 How services

encapsulate logic
To retain their independence,
services encapsulate logic within a
distinct context.
This context can be specific to a
business task, a business entity, or
some other logical grouping.

Services can encapsulate

2.3 How services relate

Within SOA, services can be used by
other services or other programs
they must be aware of each other
service descriptions
Description- name of the service and
the data expected and returned by
the service
relationship - loosely coupled

2.4 How services

communicate
After a message is sent- it loses
control of what happens to the
message
we require messages to exist as
"independent units of
communication.
Messages should be autonomous self-govern their parts of the
processing logic

 Service orientation 3 componentsservices, descriptions and messages

2.5 How services are

designed
service-orientation - commonly
accepted principles that govern the
positioning and design of our
architectural components
Service oriented solution- when a
solution is comprised of units of
service-oriented processing logic

 key aspects:
1. Loose coupling - minimizes dependencies and only retain an
awareness of each other.
2. Service contract - agreement, as defined collectively by one
or more service descriptions and related documents.
3. Autonomy - Services have control over the logic they
encapsulate.
4. Abstraction - services hide logic from the outside world.
5. Reusability Logic is divided into services with the intention of
promoting reuse.
6. Composability - Collections of services can be coordinated and
assembled to form composite services.
7. Statelessness - Services minimize retaining information
specific to an activity.
8. Discoverability- Services are designed to be outwardly
descriptive so that they can be found and assessed via
available discovery mechanisms.

 Need a Platform to shape up the

components using design principles
to build architecture
Web services technology set offers
us such a platform

2.6 How services are built

SOA can and should be realized
through the use of the Web services
technology platform

2.7 Primitive SOA

it represents a baseline technology
architecture that is supported by
current major vendor platforms

SUMMARY OF KEY
POINTS
SOA and service-orientation are
implementation-agnostic paradigms
that can be realized with any suitable
technology platform.
Our primitive SOA model represents a
mainstream variation of SOA based
solely on Web services and common
service-orientation principles.
"SOA" implies the primitive SOA model.

3. Definition of SOA
Gartner- A style of multi-tier computing
that helps organizations share logic and
data among multiple applications and
usage modes
IBM - An Application Architecture within
which all functions are defined as
independent services with well-defined
invokable interfaces which can be called
in defined sequences to form business
processes

 Service-Oriented Architecture is a businessdriven IT architecture approach that supports

integrating your business as linked,
repeatable business tasks, or services.
SOA helps customers increase the flexibility
of their business processes, strengthen their
underlying IT infrastructure and reuse their
existing IT investments by creating
connections among disparate applications
and information sources.

 SOA is based upon the interactions

between three roles:
Provider - the owner of the service
Registry or Broker (bridge) - manages
repositories of information on providers
and their software assets
Requestor (consumer) - discovers and
invokes software assets provided by one
or more providers

Summary
SOA represents a model in which functionality is
decomposed into small, distinct units (services), which
can be distributed over a network and can be
combined together and reused to create business
applications.
Solutions that use a service-oriented approach are
intended to satisfy business or mission goals that
include:
quality requirements such as easy and flexible integration
with legacy systems (interoperability),
streamlined business processes (maintainability),
reduced costs (modifiability),
agility to handle rapidly changing business processes
(extensibility).

4. Common characteristics of
contemporary SOA
Major software vendors are continually
building new Web services specifications and
building increasingly powerful XML and Web
services support into current technology
platforms.
The result is an extended variation of serviceoriented architecture we refer to as
contemporary SOA
Contemporary SOA builds upon the primitive
SOA model by leveraging industry and
technology advancements to further its
original ideals

 Contemporary SOA represents an

architecture that promotes serviceorientation through the use of Web
services.

5. COMMON
MISPERCEPTIONS ABOUT SOA

5.1 "An application that uses Web

services is service-oriented."
There is a distinction between SOA as an
abstract model and SOA based on Web
services and service-orientation
Depending on which abstract model you use,
almost any form of distributed architecture
can be classified as being service-oriented
A traditional distributed architecture can be
called service-oriented as long as the benefits
associated with primitive and contemporary
SOA are not expected.

5.2 "SOA is just a marketing term

used to re-brand Web services."
SOA is a legitimate and relatively established
technical term.
It represents a distinct architecture based on
a set of distinct principles.
It just happens that contemporary SOA also
implies the use of a distinct set of technology
used to realize fundamental SOA principles.
The technology platform of choice is
currently Web services and all that comes
with it.

5.3 "SOA is just a marketing term

used to re-brand distributed
computing with Web services."
SOA consists of a set of design
principles that are related to, but
differ significantly from, the
distributed computing platforms of
the past

5.4 "SOA simplifies distributed

computing."
When integration requirements
emerge, when a sufficient number of
composable services exist, and when
service-orientation principles are well
integrated into an organization,
that's when SOA can simplify the
delivery of automation requirements

5.5 "An application with Web services

that uses WS-* extensions is serviceoriented."
Regardless of the functionality with
which Web services are outfitted,
what makes them part of a serviceoriented architecture is how the
architecture itself is designed.

5.6 "If you understand Web services

you won't have a problem building
SOA."
A technical and conceptual knowledge of
Web services is certainly helpful.
Service-orientation requires a change in how
business and application logic are viewed,
partitioned, and automated.
It therefore also requires that Web services
be utilized and designed according to
specific principles.
The manner in which Web services are
utilized in SOA is significantly different.

5.7 "Once you go SOA, everything

becomes interoperable."
Many assume that by virtue of
building service-oriented solutions,
their technical environments will
naturally transform into a united,
federated enterprise.
Though this ultimate goal is
attainable, it requires investment,
analysis, and, above all, a high
degree of standardization

6. COMMON TANGIBLE
BENEFITS OF SOA

 It is a list of the reasons why the IT

community is going through the
trouble of changing so much of its
philosophy and technology in an
effort to adopt SOA.

6.1 Improved integration (and

intrinsic interoperability)
SOA can result in the creation of solutions that
consist of inherently interoperable services.
Utilizing solutions based on interoperable
services is part of service-oriented integration
(SOI) and results in a service-oriented
integration architecture.
Intrinsic interoperability turns a crossapplication integration project into less of a
custom development effort, and more of a
modeling exercise

6.2 Inherent reuse

Service-orientation promotes the design
of services that are inherently reusable.
Building services to be inherently
reusable results in a moderately
increased development effort and
requires the use of design standards.
Subsequently leveraging reuse within
services lowers the cost and effort of
building service-oriented solutions.

6.3 Streamlined architectures and

solutions
Realizing this benefit requires adherence to
design standards that govern allowable
extensions within each application
environment.
Benefits of streamlined solutions and
architectures include the potential for reduced
processing overhead and reduced skill-set
requirements (because technical resources
require only the knowledge of a given
application, service, or service extension).

6.4 Leveraging the legacy

investment
The cost and effort of integrating
legacy and contemporary solutions is
lowered.
The need for legacy systems to be
replaced is potentially lessened.

6.5 Establishing standardized XML

data representation
On its most fundamental level, SOA is
built upon and driven by XML.
As a result, an adoption of SOA leads
to the opportunity to fully leverage the
XML data representation platform.
A standardized data representation
format (once fully established) can
reduce the underlying complexity of all
affected application environments.

6.6 Focused investment on

communications infrastructure
This allows organizations to evolve
enterprise-wide infrastructure by
investing in a single technology set
responsible for communication.
The cost of scaling communications
infrastructure is reduced, as only one
communications technology is
required to support the federated
part of the enterprise.

6.7 "Best-of-breed"
alternatives
IT departments are frequently required
to push back and limit or even reject
requests to alter or expand upon existing
automation solutions.
Because SOA establishes a vendorneutral communications framework, it
frees IT departments from being chained
to a single proprietary development
and/or middleware platform.

6.8 Organizational agility

A standardized technical
environment comprised of loosely
coupled, composable, and
interoperable and potentially
reusable services establishes a more
adaptive automation environment
that empowers IT departments to
more easily adjust to change.

7. COMMON PITFALLS OF
ADOPTING SOA

7.1 Building service-oriented

architectures like traditional
distributed architectures
Building traditional distributed architectures under
the pretense that they are building contemporary
SOA.
This is often the result of an acceptance of one or
more of the misperceptions
The danger with this scenario is that an
organization can go quite far in terms of
integrating the Web services technology set
before realizing that they've been heading down
the wrong path.

7.2 Not standardizing SOA

SOA, like any other architecture,
requires the creation and
enforcement of design standards for
its benefits to be truly realized.
For example, if one project builds a
service-oriented solution in isolation
from others, key aspects of its
solution will not be in alignment with
the neighboring applications it may
be required to interoperate with one

7.3 Not creating a transition

plan
Transition plans allow you to
coordinate a controlled phasing in of
service-orientation and SOA
characteristics so that the migration
can be planned on a technological,
architectural, and organizational
level.

7.4 Not starting with an XML

foundation architecture
In the world of contemporary SOA, everything, in
fact, begins with XML.
It is the standard from which multiple supplementary
standards have evolved to form a de facto data
representation architecture.
It is this core set of standards that has fueled the
creation of the many Web services specifications that
are now driving SOA.
Standardizing the manner in which core XML
technologies are used to represent, validate, and
process corporate data as it travels
throughout application environments (both within
and between services) lays the groundwork for a
robust, optimized, and interoperable SOA

7.5 Not understanding SOA

performance requirements
Contemporary SOA's reliance on Web
services deepens its dependence on XML
data representation, which, in turn, can
magnify XML processing-related
performance challenges.
For example, Web services security
measures, such as encryption and digital
signing, add new layers of processing to
both the senders and recipients of
messages

7.6 Not understanding Web services

security
One of the more significant design
issues you may face when WSSecurity hits your world is the
potential introduction of centralized
security.
With this approach, the architecture
abstracts a large portion of security
logic and rules into a separate,
central layer that is then relied upon
by service-oriented applications.

7.7 Not keeping in touch with product

platforms and standards development
A transition to SOA opens up the
arena of products and platforms that
IT departments can choose from to
build and/or host custom-developed
application logic.
While the tendency will be there to
continue with what you know best,
the option to look elsewhere is everpresent.

SUMMARY OF KEY
POINTS
Many of the pitfalls relate to a limited
understanding of what SOA is and what is
required to fully incorporate and standardize
service-orientation.
A transition plan is the best weapon against the
obstacles that tend to face organizations when
migrating toward SOA.
Staying in touch with commercial and
standards-related developments is an
important part of keeping an existing SOA
aligned with future developments.

8. THE EVOLUTION OF SOA

FROM XML TO WEB SERVICES
TO SOA

 One of the SOA characteristics we identified is that

it is in a state of evolution.
To fully appreciate this quality we need to take a
look at what industry developments are influencing
SOA today and the overall direction SOA is headed.
This point examines the relationship between XML,
Web services, and SOA and explains how vendors
and standards organizations have formed a
strangely competitive and collaborative arena from
which Web services specifications are continually
surfacing

8.1. An SOA timeline 8.1.1 XML

Like HTML, the Extensible Markup Language (XML) was a W3C
creation derived from the popular Standard Generalized Markup
Language (SGML)
This widely used meta language allowed organizations to add
intelligence to raw document data.
The XML Schema Definition Language (XSD) and the XSL
Transformation Language (XSLT) were both authored using XML.
The XML data representation architecture represents the
foundation layer of SOA.
Within it, XML establishes the format and structure of messages
traveling throughout services.
XSD schemas preserve the integrity and validity of message
data, and XSLT is employed to enable communication between
disparate data representations through schema mapping.
In other words, you cannot make a move within SOA without
involving XML.

8.1.2. Web services: a brief

history
A Web service is a service
offered by an electronic device

to another electronic device, communicating with each

other via the World Wide Web.
In a Web service, Web technology such as the HTTP,
originally designed for human-to-machine
communication, is utilized for machine-to-machine
communication, more specifically for transferring
machine readable file formats such as XML and JSON
Web services use SOAP over HTTP protocol
The term "Web service" describes a standardized way of
integrating Web-based applications using the XML, SOAP,
WSDL and UDDI open standards over an Internet protocol
backbone.
XML is used to tag the data, SOAP is used to transfer the
data, WSDL is used for describing the services available
and UDDI lists what services are available.

8.1.3 SOA: a brief history

Fig: An early
incarnation of
SOA

WSDL described the service.

SOAP provided the messaging format used by the
service and its requestor.
UDDI provided the standardized service registry
format.

8.1.4. How SOA is re-shaping XML

and Web services
As with any architecture, SOA introduces
boundaries and rules.
Though contemporary SOA is made
possible by the XML and Web services
technology platforms, these platforms are
required to undergo a number of changes
in order for their respective technologies
to be properly positioned and utilized
within the confines of service-oriented
architectures.

SUMMARY OF KEY
POINTS
The core XML technology set has become a common part
of distributed Internet architecture. It now also provides a
foundation data representation and data management
layer for SOA.
The first-generation Web services architecture grew out of
the development of three key standards: WSDL, SOAP, and
UDDI. While UDDI is still an optional discovery mechanism
for most environments, WSDL and SOAP have become core
technologies that build upon the XML layer to define the
fundamental communications framework for SOA.
Though contemporary SOA has been shaped by the
emergence and industry-wide acceptance of XML and Web
services, the arrival of SOA introduces changes to the
manner in which XML and Web services have been
traditionally applied.

9. THE CONTINUING EVOLUTION OF SOA

(STANDARDS ORGANIZATIONS AND
CONTRIBUTING VENDORS)

9.1. "Standards" vs. "Specifications"

vs. "Extensions"
These terms are often used interchangeably.
Standard: An accepted industry standard. All of
the first-generation Web services specifications
are considered standards, as are a number of
XML specifications.
Specification: A proposed or accepted standard,
described in a specification. XML standards,
first-generation Web services standards, and
WS-* extensions all exist within specifications.
Extension: An extension typically represents a
WS-* specification or a feature provided by a
WS-* specification.

9.2. Standards organizations that

contribute to SOA
Internet standards organizations have existed for
some time now, but their respective agendas are
not always distinct and sometimes even overlap.
Four separate working groups made significant
contributions to W3C Web Services Activity
projects, resulting in the development of
important base standards for Web services.
Organization for the Advancement of Structured
Information Standards (OASIS) group has been
instrumental in furthering the development of
XML and Web services security extensions.

 The primary objective of the Web

Services Interoperability Organization
(WS-I) is not to create new standards,
but to ensure that the ultimate goal
of open interoperability is realized.

A Comparison of Standards
Organizations

Major vendors that contribute to

SOA
Some of the companies that have participated
in the standards development processes include
Microsoft, IBM, BEA Systems, Sun Microsystems,
Oracle, Tibco, Hewlett-Packard, Canon,
Commerce One, Fujitsu, Software AG, Nortel,
Verisign, and Web Methods.
These same vendors supply a significant portion
of the contributors that actually end up
developing the standards.
Even though these organizations exist as
independent entities, their membership includes
pretty much all major software vendors.

Why standards are being developed

in support of SOA
No one person or organization owns
or controls SOA.
Having evolved from proprietary
platforms into an architecture that
promotes and supports open
standards and vendor-neutral
protocols, SOA will likely remain an
important architecture for as long as
the major software vendors choose
to support it.

The vendor influence

Even though no one exclusively
controls SOA, everyone has an
opinion as to how its underlying
technology platform should be
shaped.
To that end, the vendor's influence in
the standards development process
has turned the evolution of SOA into
a battle of agendas.

Vendor alliances
Forming an alliance allows vendors to
join forces in order to attain common
goals. Generally, the lifespan of an
alliance is centered around the
development cycle of a particular
specification.

Choosing a standards
organization
Vendors have market-driven goals fueled
by pressures to deliver product releases
that meet customer demands and match
or outdo what the competition is offering
(or planning to offer).
Given that the W3C relies on a longer
standards development process, it is
tempting for vendors to submit their
standards to OASIS instead.

SUMMARY OF KEY
POINTS
The W3C's contributions to advancing the World Wide
Web cannot be understated. In the SOA arena, its
role
has been primarily as a standards body responsible
for specifications that provide core and generic
functionality.
OASIS evolved from an SGML standards organization
to one focused almost exclusively on eBusiness
specifications. Its overall goal is to support the
creation of standards targeted at specific industries
and to foster trade and commerce between
eBusiness-enabled enterprises.

 As a group dedicated to the interoperability concerns of

disparate platforms, the WS-I does not produce technology
standards. Instead, this organization provides profile
documents that establish a proven and tested collection of
standards. Compliance to these profiles guarantees
organizations that their environments support a level of
industry-standard interoperability.
Though standards organizations exist as separate entities, all
are supported by and receive contributions from vendor
representatives. Vendor contributions are motivated by a
mixture of self-interest and common good.
It is important to stay on top of the standards development
landscape because it will allow you to plan a more educated
migration toward SOA.

10. THE ROOTS OF SOA (COMPARING

SOA TO PAST ARCHITECTURES)

10.1 Application
architecture
Application architecture is to an
application development team what a
blueprint is to a team of construction
workers.
Enterprise architecture is common for a
master specification to be created,
providing a high-level overview of all
forms of heterogeneity that exist within an
enterprise, as well as a definition of the
supporting infrastructure.

 Typically, changes to enterprise

architectures directly affect
application architectures, which is
why architecture specifications often
are maintained by the same group of
individuals.
Further, enterprise architectures
often contain a long-term vision of
how the organization plans to evolve
its technology and environments.

SOA
Service-oriented architecture spans both
enterprise and application architecture domains.
The benefit potential offered by SOA can only be
truly realized when applied across multiple
solution environments.
SOA belongs in those areas that have the most
to gain from the features and characteristics it
introduces.
An SOA can refer to an application architecture
or the approach used to standardize technical
architecture across the enterprise.

10.2. SOA vs. client-server

architecture

Application logic
Client-server environments place the
majority of application logic into the client
software. This results in a monolithic
executable that controls the user
experience, as well as the back-end
resources.
Any piece of software capable of
exchanging SOAP messages according to
required service contracts can be
classified as a service requestor.

Application processing
Because most client-server application logic
resides in the client component, the client
workstation is responsible for the bulk of the
processing. The 80/20 ratio often is used as a
rule of thumb, with the database server
typically performing twenty percent of the work.
Processing in SOA is highly distributed. Each
service has an explicit functional boundary and
related resource requirements. In modeling a
technical service-oriented architecture, you
have many choices as to how you can position
and deploy services.

Technology
The emergence of client-server applications
promoted the use of 4GL programming
languages, such as Visual Basic and
PowerBuilder.
The technology landscape of SOA, though, has
become increasingly diverse. In addition to the
standard set of Web technologies (HTML, CSS,
HTTP, etc.) contemporary SOA brings with it
the absolute requirement that an XML data
representation architecture be established,
along with a SOAP messaging framework, and
a service architecture comprised of the everexpanding Web services platform.

Security
Besides the storage and management of
data and the business rules embedded in
stored procedures and triggers, the one
other part of client-server architecture that
frequently is centralized at the server level
is security.
In SOA Security becomes a significant
complexity directly relational to the degree
of security measures required. Multiple
technologies are typically involved, many of
which comprise the WS-Security framework

Administration
Because each client housed the application
code, each update to the application
required a redistribution of the client
software to all workstations. In larger
environments, this resulted in a highly
burdensome administration process.
Once SOAs evolve to a state where services
are reused and become part of multiple
service compositions, the management of
server resources and service interfaces can
require powerful administration tools,
including the use of a private registry.

10.3. SOA vs. distributed Internet

architecture

Application logic
Traditional distributed applications consist of a
series of components that reside on one or
more application servers. Components are
designed with varying degrees of functional
granularity, depending on the tasks they
execute, and to what extent they are considered
reusable by other tasks or applications.
Contemporary SOAs still employ and rely on
components. However, the entire modeling
approach now takes into consideration the
creation of services that encapsulate some or all
of these components. These services are
designed according to service-orientation
principles and are strategically positioned to
expose specific sets of functionality

Application processing
Distributed Internet architecture promotes
the use of proprietary communication
protocols, such as DCOM and vendor
implementations of CORBA for remote
data exchange.
SOA, on the other hand, relies on
message-based communication. This
involves the serialization, transmission,
and deserialization of SOAP messages
containing XML document payloads.

Technology
Because many current distributed applications use XML
and Web services, there may be little difference
between the technology behind these solutions and
those based on SOA.
One clear distinction, though, is that a contemporary
SOA will most likely be built upon XML data
representation and the Web services technology
platform.
Beyond a core set of Internet technologies and the use
of components, there is no governance of the
technology used by traditional Internet applications.
Thus XML and Web services are optional for distributed
Internet architecture but not for contemporary SOA.

Security
To ensure the safe transportation of information and
the recognition of user credentials, while preserving
the original security context, traditional security
architectures incorporate approaches such as
delegation and impersonation.
SOA- Relying heavily on the extensions and
concepts established by the WS-Security framework,
the security models used within SOA emphasize the
placement of security logic onto the messaging
level. SOAP messages provide header blocks in
which security logic can be stored.

Administration
Maintaining component-based applications
involves keeping track of individual component
instances, tracing local and remote communication
problems, monitoring server resource demands,
and, of course, the standard database
administration tasks.
Enterprise-level SOAs typically require additional
runtime administration. Problems with messaging
frameworks (especially when working with
asynchronous exchange patterns) can more easily
go undetected than with RPC-based data
exchanges.

10.4. SOA vs. hybrid Web service

architecture

Web services as component

wrappers
The primary role of Web services in this context has
been to introduce an integration layer that consists
of wrapper services that enable synchronous
communication via SOAP-compliant intgration
channels.
These integration channels are primarily utilized in
integration architectures to facilitate
communication with other applications or outside
partners. They also are used to enable
communication with other (more service-oriented)
solutions and to take advantage of some of the
features offered by third-party utility Web services.

 Instead of mirroring component interfaces

and establishing point-to-point connections
with Web services, SOA provides strong
support for a variety of messaging models
(based on both synchronous and
asynchronous exchanges).
Additionally, Web services within SOAs are
subject to specific design requirements,
such as those provided by serviceorientation principles.

Web services within SOA

SOAs are built with a set of Web services designed
to collectively automate (or participate in the
automation of) one or more business processes
and that SOA promotes the organization of these
services into specialized layers that abstract
specific parts of enterprise automation logic.
Also by standardizing on SOA across an
enterprise, a natural interoperability emerges that
transcends proprietary application platforms.
This allows for previously disparate environments
to be composed in support of new and evolving
business automation processes.

10.5. Service-orientation and

object-orientation
Service-orientation emphasizes loose coupling between units
of processing logic (services). Although object-orientation
supports the creation of reusable, loosely coupled
programming routines, much of it is based on predefined class
dependencies, resulting in more tightly bound units of
processing logic (objects).
Service-orientation encourages coarse-grained interfaces
(service descriptions) so that every unit of communication
(message) contains as much information as possible for the
completion of a given task. Object-oriented programming fully
supports fine-grained interfaces (APIs) so that units of
communication (RPC or local API calls) can perform various
sized tasks.
Service-orientation expects the scope of a unit of processing
logic (service) to vary significantly. Object-oriented units of
logic (objects) tend to be smaller and more specific in scope.

 Service-orientation promotes the creation of activity-agnostic units

of processing logic (services) that are driven into action by
intelligent units of communication (messages). Object-orientation
encourages the binding of processing logic with data, resulting in
highly intelligent units (objects).
Service-orientation prefers that units of processing logic (services)
be designed to remain as stateless as possible. Object-orientation
promotes the binding of data and logic, resulting in the creation of
more stateful units (objects). (However, more recent componentbased design approaches deviate from this tendency.)
Service-orientation supports the composition of loosely coupled
units of processing logic (services). Object-orientation supports
composition but also encourages inheritance among units of
processing logic (objects), which can lead to tightly coupled
dependencies.