Download Introduction to SOA

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
Introduction to SOA
1
The Service-Oriented
Enterprise


eXtensible Markup Language (XML)
Web services


Service-oriented architecture (SOA)


XML-based technologies for messaging, service
description, discovery, and extended features.
A methodology for achieving application
interoperability and reuse of IT assets.
Business process management (BPM)
2
Service-Oriented Development


A service is defined by the messages it
exchanges with other services.
Benefits of service-oriented development




Reuse: services for reuse
Efficiency: to quickly and easily create new
services and applications
Loose technology coupling: independent to
execution environment
Division of responsibility: separation of
concerns between the business analysts and
service developers
3
What is SOA?





A style of design that guides all aspects of
creating and using business services
A way to define and provision an IT
infrastructure to allow different applications to
exchange data and participate in business process
Business services are the key organizing principle
Service orientation focuses on the description of
the business problem
Cleanly and completely separate, by interpreting a
text file, a service description from its execution
environment
4
Web Services



Web services are pervasive,
simple, and platformneutral.
The provider publishes a
WSDL description of its
Web service.
The requester accesses
the description using a
Requester
UDDI registry and
requests the service by
sending a SOAP message.
UDDI
Registry
WSDL
SOAP
Provider
5
Primary Service
Characteristics

Loosely coupled




Interface coupling
Technology coupling
Process coupling
A well-defined interface (or service
contract)


Define the service’s capabilities and how to
invoke the service
Separate the externally accessible interface
from the implementation
6
Primary Service
Characteristics (cont.)

Meaningful to service requesters




Capture the essence of the business service
without restricting future reuse
Use a business-oriented vocabulary
Avoid exposing technical details
Standards-based

Services should be based on open standards as
much as possible
7
Secondary Service
Characteristics

Predictable service-level agreements


SLA defines response time, throughput,
availability, etc.
Dynamic, discoverable, metadata-driven



Services can be discovered and consumed
without intervention of the provider.
The interface should use metadata to define
service capabilities and constraints.
The interface should be machine-readable so
that they can be dynamically registered and
discovered.
8
Secondary Service
Characteristics (cont.)

Design service contracts with related
services in mind



Design the service-level data model (or the
XML Schema definition of the documents) and
all of the related interfaces together
Implementation independent of other
services
Consider the need for compensating
transactions

A compensating transaction can undone a
completed transaction by canceling its results.
9
Secondary Service
Characteristics (cont.)

Design for multiple invocation styles



If forced to choose one, choose asynchronous
queuing
Stateless
Design services with performance in mind


Service invocations should NOT be treated like
local function calls
Avoid fine-grained services
10
Object Reuse vs. Service Reuse



Building objects is
easy
Building high-quality,
reusable objects is
hard
Reusing object
libraries and object
frameworks is
moderately hard



Building Web services
is easy
Building high-quality,
reusable business
services is hard
Reusing business
services is relatively
easy
11
Too Much Reuse?

A highly reusable service


The interface for the data access service
accepts a SQL query as input and returns an
XML structure as the result.
It violates SOA’s loose-coupling principle


The service requester needs to know about how
the data is stored and the structure of data.
Expensive maintenance problem.
12