Title: Service-Oriented Architectures
1Service-Oriented Architectures
- Instructor Dr. Hany H. Ammar
- Dept. of Computer Science and Electrical
Engineering, WVU
2outline
- What is SOA.
- Perspective, Evolution, SOA v/s Traditional
Architecture - Key Concepts
- Differences between SOA and UDDI (UDDI vs SOA)
- Elements of SOA, SOA ERD Model
- Service-Oriented Architecture (SOA) Style
- What is a service, service characteristics,
service interface, and service types - The Enterprise Service Bus ESB
- Business Processes Management
3What is SOA?A Business Perspective
- SOA is the application of well-founded concepts
which exploit the modern ability for system
resources to - Collaborate independent of location
- Across Heterogeneous technologies
- A set of architectural principles backed by
technology to tap into system resources to freely
participate in a larger community - Provide tools and techniques to orchestrate the
reuse of these newly available resources into
processes that drive the business.
4What is SOA?A Technical Perspective
- A Service Oriented Architecture is a collection
of self-contained services that can communicate
with each other. - Key characteristics of services
- loosely coupled
- coarse grained
- typically published available for invocation on
a Service Bus - Defining services at a business level enables
rapid composition of end-to-end business
processes, delivering on the promise of greater
IT flexibility and agility
5The Evolution From Three-Tier Applications
Databases
Presentation Layer
Application
Application
Application
Business Layer
6The Evolution toSOA-Based Applications
Service Components
Process 1
Databases
Presentation
Process 2
Process 3
7SOA v/s Traditional Architecture
Calls for a Paradigm Shift
But must be built on standards to enhance
interoperability
8Service-Oriented Architecture Key Concepts
Service A unit of business functionality that can be invoked over the network
Web service A service that is called in a standard way, so anyone can use it without knowing its internals
Loosely coupled When services are self-contained, and can be easily combined and disassembled, they are called loosely coupled.
Service-Oriented Architecture A standards-based platform that lets you model, develop, find, and combine services into flexible business processes
Orchestration Combining and assembling services into a coherent business process also known as business process management
9Differences between SOA and UDDI UDDI vs SOA
- What is UDDI?
- UDDI is a platform-independent framework for
describing services, discovering businesses, and
integrating business services by using the
Internet. - UDDI stands for Universal Description, Discovery
and Integration - UDDI is a directory for storing information about
web services - UDDI is a directory of web service interfaces
described by WSDL (Web Services Description
Language) - UDDI communicates via SOAP (Simple Object Access
Protocol, ) - UDDI is built into the Microsoft .NET platform
10UDDI vs SOA
- What is UDDI Based On?
- UDDI uses World Wide Web Consortium (W3C) and
Internet Engineering Task Force (IETF) Internet
standards such as XML, HTTP, and DNS protocols. - UDDI uses WSDL to describe interfaces to web
services - Web Services Description Language (WSDL) is an
XML grammar that defines the functionality
offered by a Web service and the format of
messages sent and received by a Web service. - Additionally, cross platform programming features
are addressed by adopting SOAP, known as XML
Protocol messaging specifications found at the
W3C Web site.
11UDDI vs SOA UDDI Architecture
Another View
UDDI registry
look for service in UDDI registry
retrieve provider location and WSDL service
description
publish services in registry
requester
provider
bind and send request via SOAP/http or other
transport to provider
create request from WSDL description
It was assumed that fully automated agents
(request entities) could perform lookups and use
services thereby executing business tasks.
12UDDI vs SOAWhy UDDI Could Not Work
- central registries of
- service descriptions
- independent automatic agents searching for
services - machines understanding service descriptions
- machines deciding on service use
- machines being able to use a service properly
- machines being able to construct advanced
workflows (i.e., bussiness processes) from
different services
Even if you replace machines with human beings
(e.g. for the service decision) UDDI does not
work Too much in services is ambiguous,
undefined or expressed in different and
incompatible terms not to forget that the
service interface use (order of calls, meaning of
datatypes etc.) is undefined as well.
13WS Stack based on UDDI
Service Flow
WSFL
Service Discovery
UDDI
Service Publication
UDDI
Service Description
WSDL
XML-based Messaging
SOAP
HTTP, FTP, MQ Email, IIOP
Network
10/31/2013
13
14UDDI vs SOA Missing Technology Behind UDDI
Understanding and matching of constraints
Meaning of data types and interfaces
Ontologies
policies
Autonomous Agent
Business Process Exectution Languages
Meaning of actions
Business Domain knowledge
Trust Establishment
Understanding Flows and Goals
Risk
create request from WSDL description
Important to remember business languages which
standardize business terms like contract, sale,
customer etc. Generally speaking a ton of
meta-data where missing. Webservices (WSDL, SOAP)
merely covered the mechanics of message exchange.
15Elements of SOA
- Services offer high-level, business type
interfaces - Service Choreography (aka workflow) is performed
outside services which allows the combination of
services into larger business processes - A set of semantic standards and technologies
allows agents to understand services and their
interfaces (OWL, SAML, Semantic Web etc.) - Legacy applications will be wrapped through a
service interface and become available to other
companies - SOA will use Web Service technology as its base
16SOA Elements Model
This diagram from Web Services Architecture
shows internal and external elements of the SOA
architecture. Action e.g. is not an externally
visible element. Note the important roles of
policy and semantics
17Another Simplified Model
Policy
governed by
Adheres to
End Point
Exposes
Binds to
Serves
Service
Contracts
Service Consumer
implements
Understands
describes
Key
Component
Messages
Sends/Receives
Sends/Receives
Relation
18outline
- What is SOA.
- Perspective, Evolution, SOA v/s Traditional
Architecture - Key Concepts
- UDDI vs SOA
- Elements of SOA, SOA ERD Model
- Service-Oriented Architecture (SOA) Style
- What is a service, service characteristics,
service interface, and service types - The Enterprise Service Bus ESB
- Business Processes Management
19Service Oriented Architecture (SOA) StyleAn
Architecture Style
- Service-Oriented Architecture (SOA) is an
architectural style. - Applications built using the SOA style deliver
functionality as services that can be used or
reused when building applications - SOA uses open standards to integrate software
assets as services - It provides a standard form of interactions of
services
20A Map of SOA Components
Web Portals
Human Business Process Management (BPM)
Enterprise Service Bus (ESB)
Security
Registry and Repository
Manage and monitor
Data Services
Systems of Record
Databases
21Banking Examples of SOA
Internet Banking
Business Process Stop Payment
Registry and Repository Find Stop Payment
Service, Charge Fee service
ESB Routes to appropriate core system
Security Authenticate user
Manage and monitor
Data Services
Process Services
Orchestration
Business Logic If Customer_Status Gold
Service_Fee 8 else Service_Fee 20
DDA / Current Account
Fee database
22Place customer orders 1. Basic Data Service
access operations, 2. Composed Services -
business logic, 3. Process Services complex
business logic
23A Unified Patience Journal System
24Service Oriented Architecture (SOA) Style
- SOA services become the building blocks that form
business flows - Services can be reused by other applications
- What is a service?
- A service provides a discrete business function
that operates on data. Its job is to ensure that
the business functionality is applied
consistently, returns predictable results, and
operates within the quality of service required.
25Service Oriented Architecture (SOA) Style
- What is a service?
- A service is a reusable component that can be
used as a building block to form larger, more
complex business-application functionality. - A service may be as simple as get me some person
data, or as complex as process a disbursement.
26Service Oriented Architecture (SOA) Style
- Characteristics of a Service
- Supports open standards for integration
Although proprietary integration mechanisms may
be offered by the SOA infrastructure, SOAs
should be based on open standards. - Open standards ensure the broadest integration
compatibility opportunities - Loose coupling provides well defined interfaces
to clients - Stateless The service does not maintain state
between invocations. If a transaction is
involved, the transaction is committed and the
data is saved to the database.
27Service Oriented Architecture (SOA) Style
- Characteristics of a Service
- Location agnostic Users of the service do not
need to worry about the implementation details
for accessing the service. The SOA
infrastructure will provide standardized access
mechanisms with service-level agreements.
28SOA Design
Business Object
Business Object
Business Service
Component
Component
Choreography
Service
Service
This diagram is modelled after O.Zimmermann
et.al. Elements of a Service-Oriented Analysis
and Design. The paper also shows nicely how flow
oriented a SOA really is and that a class diagram
does not catch the essence of SOA. A
state-diagram performs much better. The authors
also note that SOA is process and not use-case
driven design.
29Interface Design
- Object interface accepts transactions, fast,
Object references - Component interface value objects, relatively
fast. Mostly stateless. - Service interface long running transactions
with state in DB. Composable to larger services
(choreography) or composed of smaller services
(orchestration). Stateless.
Only objects (classes) are programming language
constructs. But a detailed look at the interfaces
reveals that component and service type
interfaces are just different types of the
interface model.
30SOA Blueprint Service Types
- Basic Service atomic operation on a simple
object (e.g. DB-access) - Composite Service atomic, uses several basic
services (orchestration), stateless for caller. - Workflow Service Stateful, defined state changes
(state kept in persistent store) - Data Service Information integration via message
based request/response mechanism. - Pub/Sub Service typical event service with
callbacks and registration. - Service Broker Intermediate, rule based message
manipulation and forwarding - Compensation Service revert actions (not
rollback like)
31Service Oriented Architecture (SOA) Style Makes
use of an Enterprise Service Bus ESBUsed in
web-based systems and distributed computing
The SOA Style
Before SOA
nodes make resources available to other
participants in the system as independent
services that the participants access in a
standardized way using the ESB
32Legacy Integration
33SOA Integration
34Service Oriented Architecture (SOA) Style The
Enterprise Service Bus ESB
- An enterprise service bus is an infrastructure
used for building compound applications Similar
to the Software Bus in a CORBA based distributed
application architecture - The enterprise service bus is the glue that holds
the compound application together - The enterprise service bus is an emerging style
for integrating enterprise applications in an
implementation-independent fashion - An enterprise service bus can be thought of as an
abstraction layer on top of an Enterprise
Messaging System
35Service Oriented Architecture (SOA) Style The
Enterprise Service Bus ESB
- Characteristics of an ESB
- Streamlines development
- Supports multiple binding strategies
- Performs data transformation
- Intelligent routing
- Real time monitoring
- Exception handling
- Service security
36 Service Oriented Architecture (SOA) Style The
Enterprise Service Bus ESB Functions
- Invocation
- Synchronous and asynchronous
- transport protocols, service
- mapping (locating and binding)
- Routing
- Addressability,
- static/deterministic routing,
- content-based routing, policy-based routing
- Mediation
- Adapters, protocol transformation, service
mapping - Messaging
- Message processing, message transformation and
message enhancement
37The ESB Boundaries
The ESB (in its simplest form) is responsible for
getting a message from point A to point B.
38Get the Message on the Bus
A binding component speaks the services
protocol, which happens to be SOAP over JMS.
39Perform the Person Read
The request is now routed to the Get Person Data
Service, which will perform the business logic.
40Do the SSIM Lookup
A call is made to the SSIM service to perform a
lookup of the Student Identifier (SID). The SSIM
service lives inside the bus. Note The SSIM
binding components are not shown so the diagram
can remain simple.
41Return the Person Data
The process is reversed, returning the response
to the requester.
42Defining the Message
- Web Services Description Language
- Open Standard for describing Interfaces to
Services (http//www.w3.org/TR/wsdl) - Characteristics
- Describes data expected to be sent and received
- Describes what the service can do
- Describes how to reach the service
- WSDL description is an XML document
43Message-Exchange Patterns
- One-way. The endpoint receives a message.
- Request-response. The endpoint receives a
message, and sends a correlated message. - Solicit-response. The endpoint sends a message,
and receives a correlated message. - Notification. The endpoint sends a message.
44The Ingredients
The XSD is the XML schema definition For
variables
45outline
- What is SOA.
- Perspective, Evolution, SOA v/s Traditional
Architecture - Key Concepts
- Differences between SOA and UDDI (UDDI vs SOA)
- Elements of SOA, SOA ERD Model
- Service-Oriented Architecture (SOA) Style
- What is a service, service characteristics,
service interface, and service types - The Enterprise Service Bus ESB
- Business Processes Management
- Business Processes Flow, Business Process
Execution Language (BPEL), BPELJ, JBoss jBPM,
jPDL - The IBM Rational Software Development Platform
46Business Processes
- Business processes are a set of activities,
supported by services, that support a particular
business activity. - Business processes are business services built
using other business services. - Business Process Execution Language (BPEL) is a
specification for describing business processes
in a portable XML format. BPEL is widely
supported in both commercial and open source
products. - BPEL defines how services interact to form
complex business process. It provides a unit of
work context, fault handling, and compensation
(transaction rollback).
47Legacy Business Process
48Example of a Business Process
49The Shipping Workflow
50Grouping services
51SOA Business Process
ESB
Search
ESB Stored Information
52Business Processes span Organization and System
Boundaries
From Sequential and Divisional/Functional
Division
To Parallel and Collaborative
Need a flexible IT Infrastructure and Architecture
53Business Process Management
- What is a business process?
- A business process is a set of coordinated tasks
and activities, conducted by both people and
equipment, that will lead to accomplishing a
specific goal - Business process management (BPM) is a systematic
approach to improving an organization's business
processes
54Business Process Management
- BPM is a structured approach that models an
enterprise's human and machine tasks and the
interactions between them as processes - Evolving from document
- management, workflow and
- enterprise application
- integration (EAI),
- a BPM system
- can monitor
- and analyze tasks
55Business Process Modeling Notation
- A standardized graphical notation for drawing
business processes in a workflow - Flow objects
- Event
- Activity
- Gateway
- Connecting objects
56Example Business process 1
57Example Business process 2
58BPEL
- Business Process Execution Language BPEL is a
business process modelling language that is
executable - BPEL is a language for specifying business
process behavior based on Web Services - BPEL is serialized in XML and aims to enable
programming in the large
59What BPEL does
- BPEL binds services together to form larger
complex business services - Control Flow (branch, loop, parallel)
- Asynchronous correlation
- Transaction support, Units of Work
- Compensation
60WS-BPEL a brief introduction to some Language
Constructs,
61WS-BPEL
62WS-BPEL
63WS-BPEL
64WS-BPEL
65WS-BPEL
66BPEL example Withdrawing and depositing services
of the banking system logic
67BPEL and SOA
- Sample ESB
- Custom Services
- Transformation Services
- Orchestration
- Routing
- Application Server
68BPEL Reference Presentations
- OASIS BPEL Web page
- http//www.oasis-open.org/committees/wsbpel/
- Technical overview part 1
- Technical overview part 2
- Technical overview part 3
69BPELJ
- BPELJ is a combination of BPEL and Java allowing
the two languages to be used together to build
business process applications - BPEL ? programming in the large ? the logic of
business processes - It is assumed that BPEL will be combined with
other languages which are used to implement
business functions (programming in the small) - ? Java (J2EE)
70BPELJ
- BPELJ enables Java and BPEL to cooperate by
allowing sections of Java code, called Java
snippets, to be included in BPEL process
definitions - BPELJ Web page
- http//www.ibm.com/developerworks/library/specific
ation/ws-bpelj/
71jBPM
- JBoss jBPM is a framework that delivers workflow,
business process management (BPM), and process
orchestration - Enables enterprises to create and automate
business processes that coordinate between
people, applications, and services - Provides the tools and process execution engine
to integrate services deployed in a SOA and
automate workflows
72jBPM vision for BPM
73jBPM components
- The core workflow and BPM functionality is
packaged as a simple java library
74Example http//it.toolbox.com/blogs/the-soa-blog/
soa-diagram-16952
75jBPM process language - jPDL
- jPDL is a graph based process language that is
build on top of common jBPM framework
76Overview of the jPDL components
http//docs.jboss.com/jbpm/v3.2/userguide/html/int
roduction.html
77The jPDL graphical process designer
- jPDL includes a graphical designer tool for
authoring business processes. It's an eclipse
plug-in. - It includes support for both the business analyst
as well as the technical developer - Enables a smooth transition from business process
modeling to the practical implementation.
78jPDL vs BPEL
- Clients of a jPDL definition are expected to
start or resume process instances through the
jBPM API. - Methods such as ProcessDefinition.createProcessIns
tance and Token.signal allow client code to
interact directly with an executing process. - BPEL takes a different approach. Instead of
defining its own APIs, it accommodates custom web
service interfaces with which clients interact. - These interfaces describe meaningful business
operations and hide the fact that clients are
actually "talking" to an orchestrator
79jPDL vs BPEL
- jPDL specifies the execution flow of a process in
terms of a directed graph of nodes. It includes a
set of node types that intend to cover most
routing scenarios, and allows extensions to
includ custom routing logic - BPEL has a fixed set of structured activities
represented by XML elements, nested together to
model a particular execution path (such as,
sequence, while, etc.)
80BPEL support
- jBPM design and pluggable architecture makes it
possible to support different languages that can
be shown as a graph and represent some sort of
execution - jBPM provides BPEL support
- JBoss jBPM BPEL Extension, version 1.1.Beta3
- Download
- http//prdownloads.sourceforge.net/jbpm/jbpm-bpel-
1.1.Beta3.zip?download - Documentation
- http//docs.jboss.com/jbpm/bpel/
81XPDL
- The XML Process Definition Language (XPDL) is a
format standardized by the Workflow Management
Coalition (WfMC) to interchange Business Process
definitions between different workflow products,
i.e. between different modeling tools and
management suites. - Defines an XML schema for specifying the
declarative part of workflow / business process. - Designed to exchange the process definition, both
the graphics and the semantics of a workflow
business process.
82XPDL
- XPDL is currently the best file format for
exchange of BPMN diagrams - In April 2008, the WfMC ratified XPDL 2.1 as the
fourth revision of this specification. XPDL 2.1
includes extension to handle new BPMN 1.1
constructs, as well as clarification of
conformance criteria for implementations. - In contrast, BPEL focuses exclusively on the
executable aspects of the process, and does not
contain elements to represent the graphical
aspects of a process diagram, or human oriented
processes.
83References
- ESB Best Practices Presentation
http//www.fiorano.com/whitepapers/ESB_Best_Practi
ces.htm - jBPM Documentation Library http//labs.jboss.com/j
bossjbpm/docs/index.html - jBPM Presentations http//wiki.jboss.org/wiki/Wiki
.jsp?pageJbpmPresentations - XPDL
- http//www.wfmc.org/xpdl.html
-
84outline
- What is SOA.
- Perspective, Evolution, SOA v/s Traditional
Architecture - Key Concepts
- Differences between SOA and UDDI (UDDI vs SOA)
- Elements of SOA, SOA ERD Model
- Service-Oriented Architecture (SOA) Style
- What is a service, service characteristics,
service interface, and service types - The Enterprise Service Bus ESB
- Business Processes Management
- Conclusions
85Conclusions
- This lectures introduced the concepts of SOA
- We also discussed issues related to SOA as an
architecture style - We also discussed concepts of Business Process
Management and supporting technologies