Scribd
Upload
3 views

soa-introduction

The document discusses service-oriented architecture (SOA), emphasizing the importance of loosely coupled services that encapsulate distinct functionalities and can interact through service descriptions. It outlines key principles of SOA, such as autonomy, reusability, and discoverability, while highlighting the role of messaging as a communication framework. Additionally, it addresses considerations like performance, service granularity, and governance in the context of SOA implementations.

Uploaded by

2003021019
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
3 views

soa-introduction

The document discusses service-oriented architecture (SOA), emphasizing the importance of loosely coupled services that encapsulate distinct functionalities and can interact through service descriptions. It outlines key principles of SOA, such as autonomy, reusability, and discoverability, while highlighting the role of messaging as a communication framework. Additionally, it addresses considerations like performance, service granularity, and governance in the context of SOA implementations.

Uploaded by

2003021019
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

Example: A City

• Let's take your average cosmopolitan city.


• It is already full of service-oriented businesses. Individual
companies are service-oriented in that each provides a
distinct service that can be used by multiple consumers.
• Collectively, these businesses comprise a business
community.
• It makes sense for a business community not to be
served by a single business outlet providing all services.
• By decomposing the community into specialized,
individual outlets, we achieve an environment in which
these outlets can be distributed.
• services encapsulate logic within a distinct context. This
context can be specific to a business task, a business
entity, or some other logical grouping.
• when building an automation solution consisting of
services, each service can encapsulate a task performed
by an individual step or a sub-process comprised of a set
of steps.
• A service can even encapsulate the entire process logic.
• the larger scope represented by the services may
encompass the logic encapsulated by other services.
For services to use the logic
they encapsulate they can
participate in the execution of
business activities.
To do so, they must form
distinct relationships with those
that want to use them.

Figure 3.1: Services can encapsulate varying amounts of logic.


Within SOA, services can be used by other services or other programs.
Regardless, the relationship between services is based on an understanding
that for services to interact, they must be aware of each other. This awareness
is achieved through the use of service descriptions.
A service description in its most basic format establishes the name of the
service and the data expected and returned by the service. The manner in
which services use service descriptions results in a relationship classified as
loosely coupled.

Figure 3.2: Because it has access to service B’s service


description, service A has all of the information it needs to
communicate with service B.
For services to interact and accomplish something meaningful, they must exchange
information. A communications framework capable of preserving their loosely
coupled relationship is therefore required. One such framework is messaging.
After a service sends a message on its way, it loses control of what happens to the
message thereafter. That is why we require messages to exist as "independent
units of communication."
This means that messages, like services, should be autonomous.

Figure 3.3: A message existing as an


independent unit of communication.
Much like object-orientation, service-orientation has become a distinct design
approach which introduces commonly accepted principles that govern the positioning
and design of our architectural components
The application of service-orientation principles to processing logic results in
standardized service-oriented processing logic. When a solution is comprised of units
of service-oriented processing logic, it becomes what we refer to as a service-
oriented solution.

Figure 3.4: Service-orientation principles address design issues.


•Loose coupling
•Services maintain a relationship that minimizes dependencies and only requires that
they retain an awareness of each other.
•Service contract
•Services adhere to a communications agreement, as defined collectively by one or more
service descriptions and related documents.
•Autonomy
•Services have control over the logic they encapsulate.
•Abstraction
•Beyond what is described in the service contract, services hide logic from the outside
world.
•Reusability
•Logic is divided into services with the intention of promoting reuse.
•Composability
•Collections of services can be coordinated and assembled to form composite services.
•Statelessness
•Services minimize retaining information specific to an activity.
•Discoverability
•Services are designed to be outwardly descriptive so that they can be found and
assessed via available discovery mechanisms.
• the term "service-oriented" and various abstract SOA
models existed before the arrival of Web services.
– However, no one technology advancement has been so suitable
and successful in manifesting SOA than Web services.
Introduction
Definitions
– Sommerville
● “Service-oriented architectures (SOAs) are a way of developing
distributed systems where system components are stand-alone services,
executing on geographically distributed computers”

– OASIS (Organization for the Advancement of Structured Information Standards)


● “A paradigm for organizing and utilizing distributed capabilities that
may be under the control of different ownership domains. It provides a
uniform means to offer, discover, interact with and use capabilities to
produce desired effects consistent with measurable preconditions and
expectations.”OASIS
Introduction
Components
● services
– “A loosely-coupled reusable software component that
encapsulates discrete functionality, which maybe distributed
and programmatically accessed.” SOMMERVILLE
Connectors
● messages
– meta-data
● service descriptions, service interface etc.
● semantic meta-data
Introduction

Functional Apps Enterprise Apps SOA Apps

Paul A. Strassmann
Professor of Information Sciences
Volgenau School of Information Technology and Engineering at George Mason University
http://www.strassmann.com/
Characteristics
Integration
● “mesh-up” of different services
– does a newspaper qualify as an SOA?
● an application
– various services linked together
– really an ad-hoc application
Scope
● narrowly focused
● services are simple and generally perform a single task
Characteristics
Dependency
● deployment
● execution
● usage
– need to know what a service expects and what it returns
Stateful vs. Statelessness
● ask the class??
Characteristics
Loose coupling
● service bindings can change whenever
– different but equivalent services can execute at different times
● interface definition does not change
Reusability
● desirable to have reusable services
Characteristics
Independent of
● Platform
● Implementation
Discoverable Service
Broker
● published Publish
Discover
● discovered via
discovery mechanisms Service Service
Consumer Provider
– UDDI – web services
service
service
– simple search client service
service
Ian Gorton, Essential Software Architecture
Considerations
Performance
● Computational penalties
– introduction of extra layers
– slower then native/binary RPC
– Do we need to use XML based RPC?
● Communication latency
Evolution
● how should we handle legacy systems
– wrap the legacy system in service wrappers
Considerations
Service granularity
● reuse vs. performance
Fault-Tolerance
● partial failure vs. complete failure
● idempotent request
Service agreement
● availability, cost,
● performance
Considerations
Governance
● increases in difficulty
– with an increase in diversely deployed services
– many service providers
● meta-data management
● trust

You might also like