Service-Oriented Architectures

1
Service-Oriented Architectures

• Instructor Dr. Hany H. Ammar
• Dept. of Computer Science and Electrical
  Engineering, WVU

2
outline

• 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

3
What 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.

4
What 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

5
The Evolution From Three-Tier Applications
Databases
Presentation Layer
Application
Application
Application
Business Layer
6
The Evolution toSOA-Based Applications
Service Components
Process 1
Databases
Presentation
Process 2
Process 3
7
SOA v/s Traditional Architecture
Calls for a Paradigm Shift
But must be built on standards to enhance
interoperability
8
Service-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
9
Differences 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

10
UDDI 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.

11
UDDI 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.
12
UDDI 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.
13
WS 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
14
UDDI 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.
15
Elements 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

16
SOA 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
17
Another 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
18
outline

• 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

19
Service 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

20
A 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
21
Banking 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
22
Place customer orders 1. Basic Data Service
access operations, 2. Composed Services -
business logic, 3. Process Services complex
business logic
23
A Unified Patience Journal System
24
Service 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.

25
Service 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.

26
Service 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.

27
Service 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.

28
SOA 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.
29
Interface 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.
30
SOA 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)

31
Service 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
32
Legacy Integration
33
SOA Integration
34
Service 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

35
Service 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

37
The ESB Boundaries
The ESB (in its simplest form) is responsible for
getting a message from point A to point B.
38
Get the Message on the Bus
A binding component speaks the services
protocol, which happens to be SOAP over JMS.
39
Perform the Person Read
The request is now routed to the Get Person Data
Service, which will perform the business logic.
40
Do 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.
41
Return the Person Data
The process is reversed, returning the response
to the requester.
42
Defining 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

43
Message-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.

44
The Ingredients
The XSD is the XML schema definition For
variables
45
outline

• 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

46
Business 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).

47
Legacy Business Process
48
Example of a Business Process
49
The Shipping Workflow
50
Grouping services
51
SOA Business Process
ESB
Search
ESB Stored Information
52
Business Processes span Organization and System
Boundaries
From Sequential and Divisional/Functional
Division
To Parallel and Collaborative
Need a flexible IT Infrastructure and Architecture
53
Business 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

54
Business 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

55
Business Process Modeling Notation

• A standardized graphical notation for drawing
  business processes in a workflow
• Flow objects
• Event
• Activity
• Gateway
• Connecting objects

56
Example Business process 1
57
Example Business process 2
58
BPEL

• 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

59
What 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

60
WS-BPEL a brief introduction to some Language
Constructs,
61
WS-BPEL
62
WS-BPEL
63
WS-BPEL
64
WS-BPEL
65
WS-BPEL
66
BPEL example Withdrawing and depositing services
of the banking system logic
67
BPEL and SOA

• Sample ESB
• Custom Services
• Transformation Services
• Orchestration
• Routing
• Application Server

68
BPEL 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

69
BPELJ

• 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)

70
BPELJ

• 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/

71
jBPM

• 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

72
jBPM vision for BPM
73
jBPM components

• The core workflow and BPM functionality is
  packaged as a simple java library

74
Example http//it.toolbox.com/blogs/the-soa-blog/
soa-diagram-16952
75
jBPM process language - jPDL

• jPDL is a graph based process language that is
  build on top of common jBPM framework

76
Overview of the jPDL components
http//docs.jboss.com/jbpm/v3.2/userguide/html/int
roduction.html
77
The 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.

78
jPDL 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

79
jPDL 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.)

80
BPEL 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/

81
XPDL

• 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.

82
XPDL

• 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.

83
References

• 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

84
outline

• 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

85
Conclusions

• 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