1. Service-Oriented Architectures
Instructor: Dr. Hany H. Ammar
Dept. of Computer Science and Electrical Engineering, WVU

2. outline What is SOA. Service-Oriented Architecture (SOA) Style
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 to: SOA-Based Applications
Service
Components
Process #1
Databases
Presentation
Process #2
Process #3

7. Calls for a Paradigm Shift
SOA v/s Traditional Architecture
Calls for a Paradigm Shift
Functionality Driven
Long development cycles
Tightly Coupled
Application Specific
Designed to last
Data Oriented
Traditional Architecture
Service Oriented Architecture
Process Oriented
Iterative development
Loosely Coupled
Heterogeneous
Designed for change
Business Service Oriented 
But must be built on standards
to enhance interoperability

8. Service-Oriented Architecture: Key Concepts
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 SOA:Why 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
Security
Management
Quality of Service
Service Discovery
UDDI
Service Publication
UDDI
Service Description
WSDL
XML-based Messaging
SOAP
HTTP, FTP, MQ
, IIOP
Network
4/7/2017 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
Adheres to
governed by
End Point
Binds to
Exposes
Serves
Service
Consumer
Contracts
Service
Understands
implements
describes
Key
Component
Messages
Sends/Receives
Sends/Receives
Relation

18. outline What is SOA. Service-Oriented Architecture (SOA) Style
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) Style: An 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)
Security
Manage and monitor
Registry and Repository
Enterprise Service Bus (ESB)
Data Services
Process Services
Orchestration
System BPM
Business Logic
Databases
Systems of Record

21. Banking Examples of SOA
Internet Banking
Business Process: Stop Payment
Registry and Repository: Find Stop Payment Service, Charge Fee service
Security: Authenticate user
Manage and monitor
ESB: Routes to appropriate core system
Data Services
Process Services
Business Logic: If Customer_Status = Gold Service_Fee = $8 else Service_Fee = $20
Orchestration:
Fee database
DDA / Current Account

22. Place customer orders: 1. Basic Data Service – access operations, 2
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, SOA’s 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
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 ESB Used 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. Characteristics of an ESB
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 service’s 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 (
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. Service-Oriented Architecture (SOA) Style
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. Invoicing & Receivables Vendor Managed Inventory
Business Processes span Organization and System Boundaries
From Sequential and Divisional/Functional
Division
To Parallel and Collaborative
Outsourced
Division
Customer
Shared Service
Supplier
Customer Order Entry
Marketing
Invoicing & Receivables
Vendor Managed Inventory
Shipping (UPS)
Collections
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
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:

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

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.createProcessInstance 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
Documentation

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
jBPM Documentation Library
jBPM Presentations
XPDL

84. outline What is SOA. Service-Oriented Architecture (SOA) Style
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