SOA Application Development

Web

Ser

vice

s &

SOA:

Pr

inci

ples

& T

echn

olog

y SOA Design & Development Lifecycle

Prof. dr. ir. Mike P. Papazoglou European Research Ins9tute

in Service Science (ERISS)

[email protected] hAp://infolab.uvt.nl/staff/mikep/ hAp://www.eriss.org

2

Outline

•  SOA based applica.on development • Proper.es of service development methodology

• Quali.es of service development methodology

• SOA development lifecycle • SOA analysis • SOA design • SOA construc.on

Michael P. Papazoglou Web Services & SOA: Principles & Technology -‐ Pren9ce-‐Hall, Pearson January 2012 © 3

Web services development methodology

  Introducing a thin SOAP/WSDL/UDDI veneer atop of exis9ng apps or components is widely prac9ced by the so[ware industry. –  Unless the nature of the component makes it suitable for use as a Web service -‐ & most are not -‐ it takes serious thought & redesign effort to deliver component func9onality through a Web service.

  A methodology is of cri9cal importance to specify, construct, refine & customize business processes from internally and externally available Web services. –  A sound methodology allows an organiza9on to avoid the pi^alls of deploying an uncontrolled maze of services and provide a solid founda9on for service enablement of IT assets in an orderly fashion.


Related development methodologies Modelling techniques such as OO Analysis and Design (OOAD), Component-‐based Development (CBD), and Business Process Modelling are useful within their own scope but cannot be directly applied to service development.   OOAD allows designers to focus aAen9on on units such as classes & objects, which

match enterprise or business concepts. –  its level of granularity is focused on the class level, which resides at a too low

level of abstrac9on for business service modelling & creates 9ght coupling.

  CBD offers a “separa9on-‐of-‐internal and external perspec9ves”, however, is limited in approaching flexibility, composability & reusability. –  CBD carries with it all the difficul9es of OO modelling & mul9plies the

complexity by increasing the scale of the model. Let alone if models are extended across enterprises.

–  The selec9on of a service is usually done dynamically on the basis of policies. Use of installed components does not allow for the same kind of reuse and dynamic behaviour.


  Business Process Modeling examines business processes, iden9fies ways to improve them, & addresses barriers that impede their ability to achieve their business goals. –  The result is a prac9cal ac9on plan that provides a blueprint for achieving an organiza9on's goals and implemen9ng change, while respec9ng the enterprise's strategic mission.

Related development methodologies (cntd)


A[erthoughts   OOAD, CBD & BPM are not grounded on SOA principles & fail to

address the three key elements of an SOA: services, service assemblies (composi9on), and components realizing services.

  They also do not support: –  distributed and hybrid service development and deployment –  service provisioning –  service management

  OOAD, CBD & BPM only address part of the requirements of service-‐oriented compu9ng applica9ons. These prac9ces fail when they aAempt to develop service-‐oriented solu9ons while being applied independently of each other.

  Service oriented design and development requires an inter-‐disciplinary approach that fuses together & extends element of OO and component design with element of business modeling.


Outline



• SOA development lifecycle • Service analysis • Service design • Service construc.on

Elements of SOA based applica9ons

  Services comprise the usual cons9tuent parts that we have introduced earlier, namely:  Service contract  Interface  Implementa9on

  Services also follows important principles, such as loose coupling, strong cohesion and are offered to clients at the appropriate level of granularity.

These principles become the major driving forces for successful SOA design.


Elements of SOA based applica9ons (cntd)

SOA-based Application

Infrastructure & Management

ESB

Cloud-enabled

Governance

Centralized

Federated

Services

Core Principles

Coupling

Cohesion

Granularity

Contract

Functional Requirements

Non-Functional Requirements

Business Rules & Policies

Interface

Process-centric

Business Processes

Roles & Responsibilities

Data-centric

Data Transformation

Data Aggregation

Implementation

Programming Model

Resources (EIS, COTS, Legacy apps)

Service-Level Agreements

Reference Model

Maturity Level Maturity Indicators


Michael P. Papazoglou Web Services & SOA: Principles & Technology -‐ Pren9ce-‐Hall, Pearson January 2012 ©

Reference Model for SOA development

  When so[ware developer are building a service oriented applica9on, they must rely on an SOA development methodology.

  The methodology focuses on analysing, designing, & producing an SOA in a way it aligns with business process interac9ons between trading partners to achieve a common business goal.   It interrelates en99es in an SOA development effort & helps streamline, discipline, and structure the work of so[ware professionals who aims to create successful and widely used SOA based applica9ons.

10


Layers in the SOA reference model

  The SOA reference model regards SOA development in terms of two tracks:

 Logical view: captures the layers of business domain, business processes an business services.

 Physical view: capture the layers of infrastructure services, component based service realiza9on, and opera9onal systems and resources.

11


Layers in the SOA reference model (cntd)

Infrastructure Services

Business (service) Domain

Business Processes

Business Services

Distribu7on

Component-‐based service realiza7ons

Order Management Purchasing Inventory

create, modify, suspend, cancel orders, schedule orders, create, modify, delete bulk orders, order progress

Databases Packaged

Applica;ons Legacy

Applica;ons ERP CRM

Opera7onal Systems

Logical

Physical

Process decomposition/ composition


Layers in the SOA reference model (cntd)

  Star9ng from the top, each SOA preceding layer relies on its successor layer to accomplish its func9onal objec9ves:   The business domain describes the line of business the enterprise in

engaged in.

  The business process layer provides the en99es (business processes) that collec9vely fulfill the func9ons of a specific business domain.

  The business process layer is decomposed into a number of business services, which are implemented in the lower level layers by reusing IT resources and legacy applica9ons.

  What is important to note is that the SOA reference model is technology independent.

13


SOA Reference Model: Ques9ons to ask

Infrastructure Services

Business (service) Domain

Business Processes

Business Services

Distribu7on

Component-‐based service realiza7ons

Order Management Purchasing Inventory

create, modify, suspend, cancel orders, schedule orders, create, modify, delete bulk orders, order progress

Databases Packaged

Applica;ons Legacy

Applica;ons ERP CRM

Opera7onal Systems

Logical

Physical

Process decomposition/ composition

IMPORTANT QUESTIONS TO ASK: How to compose/decompose business Processes? How to carve out business services? Which operations does a business service support? How to leverage loose-coupling, reusability and manageability? Which infrastructural services do I need to realize business services? Do I buy/lease/outsource new services? Or can I reuse my legacy resources? How can I manage and govern the development process? ….

15

Outline





QoS considera9ons in the SOA reference model

  Besides ensuring the func9onal requirements, SOA development also deals with non-‐func9onal service concerns. We dis9nguish between:  Business level QoS: is associated to the logical view of SOA

reference model & concerns itself with SLA associated metrics, legal constraints & compliance to standards.

 Resource level QoS: is associated with capacity, performance, security & transac9onal integrity related issues in confec9on with opera9onal systems & resources.

Its objec9ve is to match the technical capacity of a service to agreed upon SLA s9pula9ons.

16


Important milestones

  Re-‐use exis.ng func.onality   Minimize costs of disrup.on

  Employ an incremental mode of integra.on

  Provide increased flexibility   Provide scalability

  Provide (design for) compliance with standards


Guiding principles for SOA applica9on development

  In order to design useful & reliable business processes that are developed on the basis of reusing exis9ng services or use newly coded services, we need to apply sound design principles.

  These principles guarantee that services are self contained and come equipped with clearly defined boundaries and services interfaces to allow for service composability. The key principles are:

 Service Coupling  Service Cohesion  Service Granularity


Coupling is the degree of interdependence between any two business processes.

  Representa7onal service coupling: Services should not depend on specific representa9onal or implementa9on details and assump9ons of one another. It supports:

 Service interchangeability: Exis9ng services may be swapped with new service implementa9ons, e.g., changing service providers, without disrup9ng the overall business process func9onality.

 Service versioning: Different versions of a service may work best in parts of a business process depending on the app’s needs, e.g., a purchase order service may provide different levels of detail -‐ internal or external requisi9on details such as internal or external accounts, depending on the ordering op9ons.

Service coupling


–  Iden7ty Service coupling: Connec9on channels between services should be unaware of who is providing the service. It is not desirable to keep track of the recipients of the service.

–  Loca7on coupling: Clients don’t need to know (or care) about where a process or service is actually located. The client reques9ng the service is decoupled from the service itself.

–  Temporal coupling: it is achieved when service invoca9on is based on an event based or asynchronous messaging communica9on backbone.

–  Message exchange paHern coupling: A sender of a message should rely only on those effects necessary to achieve effec9ve communica9on. The number of messages exchanged between a sender and addressee in order to accomplish a certain goal should be kept minimal.

Service coupling (cntd)


Cohesion is the degree of the strength of func9onal relatedness of opera9ons within a service.

–  Func7onal Service Cohesion: performs one and only one problem-‐related task and contains only services necessary for that purpose. At the same 9me, the opera9ons in the services of the business process must also be highly related to one another, i.e. highly cohesive

–  Communica7onal Service Cohesion: ac9vi9es & services use the same input and output messages. Communica9onally cohesive business processes are cleanly decoupled from other processes as their ac9vi9es are hardly related to ac9vi9es in other processes.

Service cohesion


–  Logical Service Cohesion: services all contribute to tasks of the same general category. They perform independent but logically similar func9ons (alterna9ves) that are 9ed together by means of control flows.

–  Temporal Service Cohesion: it is achieved when parts of a process or service are grouped by the 9me when they are processed.

–  Sequen7al service Cohesion: it is achieved when opera9ons of a service are grouped because the output from one opera9on is the input to another part like in an assembly line.

Service cohesion (cntd)


Service cohesion (Example) Logically Cohesive service Communicationally Cohesive service

Functionally Cohesive service Sequentially Cohesive service

Functionally Cohesive service Temporally Cohesive service


Service granularity

  Service granularity is the scope of func9onality exposed by a service.

  Services may come at two levels of granularity: –  A coarse-‐grained interface might be the complete processing for a given service, e.g., “SubmitPurchaseOrder” •  the message contains all business informa9on needed to define a PO •  A fine-‐grained interface might have separate opera9ons for: “CreateNewPO”, “SetShippingAddress”, “AddItem”, etc.

  Fine-‐grained services usually provide basic data access or rudimentary opera9ons.

  Coarse-‐grained services are composed from finer grained services.


Service granularity (Example)

Simple-‐Service: Review Order

Submit Purchase Order

Simple-‐Service: Review Order

Review Order

Business Rule: Get customer

Status Simple-‐Service: Approve

Order

Approve Order

Access Right: Approve Order

Simple-‐Service: Update Order

Store Order

Implementa;on: Access to an ERP

system

Business Process: Purchase Order

Implementation part


  A service interface (WSDL port type) should generally contain more than one opera9on, suppor9ng a par9cular business ac9vity

 The frequency of message exchange is an important factor. Sending & receiving more info. in a single request is more efficient than sending many fine-‐grained messages. – Several redundant, fine-‐grained services lead to increased message traffic & tremendous overhead & inefficiency.

– A small collec.on of coarser-‐grained services -‐ each of which implements a complete business process -‐ that are usable in mul.ple scenarios is a beNer op.on.

  Heuris9cs iden9fy the right level of granularity for services.

Service granularity concerns


 Manage the en9re services lifecycle;   Establish a pla^orm, programming model and managing services

  Adopt “best-‐prac9ces” and tools;   Deliver high-‐quality SOA solu9ons

SOA design and development concerns

28

Outline

• SOA based applica.on development • Proper.es of service development methodology




SOA development lifecycle

  SOA development lifecycle (SDLC) is a highly itera9ve or service oriented design and development methodology for developing, implemen9ng, deploying and maintaining SOA applica9ons.

  It provides a con9nuous refinement using a closed loop approach providing end-‐to-‐end business process func9onality.

  It facilitates designing SOA solu9ons as assemblies of services in which each service assembly is a managed, first class aspect of the solu9on, and, hence, amenable to analysis and change.

  SDCL provides models, best prac9ces, standards, reference architectures & run 9me environments that are needed to supply guidance and support through all SOA development, deployment, and produc9on phases.


SOA development lifecycle

•  service porJolio analysis •  service iden;fica;on •  service scoping •  service realiza;on analysis •  designing services •  designing business processes •  designing service policies

SOA Analysis & Design

Analysis &

Design

Construc;on &

Tes;ng

Provisioning

Deployment

Execu;on &

Monitoring

•  implemen;ng service composi;ons •  construc;ng provider services •  construc;ng client services •  service scoping •  func;onal tes;ng •  interface tes;ng •  assembly tes;ng

SOA Construc;on & Tes;ng

•  SOA governance •  service cer;fica;on •  service metering & ra;ng

SOA Provisioning

•  Service execu;on in an SOA •  Managing services in an SOA •  Monitoring services in an SOA

SOA Execu;on & Monitoring

SOA Planning

•  Gather requirements for SOA •  Analyze business needs for SOA •  Review technology landscape


Outline

• SOA based applica.on development • Proper.es of service development methodology



32

  Service analysis aims at iden9fying & describing the processes in a business problem domain & on discovering poten9al overlaps & discrepancies between processes under construc9on & available system resources needed to realize services.

  It helps priori9ze business processes where SOA can contribute to improvements & offer business value poten9al.

  It iden9fies, conceptualizes, & ra9onalizes business processes as a set of interac9ng services;

  Develops in-‐depth understanding of func9onality, scope, reuse & granularity of business processess & services.

Service analysis


33

Steps in SOA analysis Applica;on PorJolio Analysis

-‐ determine core business processes Cost Es;ma;on

Cost benefit analysis

SWOT & ROI analysis

“As-‐is” process map

“As-‐is” Process Model

Process & service iden;fica;on

Process scoping

PorJolio of “to-‐be” processes

SOA Gap analysis

Redesigned “to-‐be” processes

Green-‐field development

Top-‐down development

BoQom-‐up development

Meet-‐in-‐middle development

Process realiza;on analysis

“To-‐be” Process Model

High-‐level business process inventory & architecture Design

Phase

Process iden;fica;on & scoping

Process simula;on


34

  Por^olio analysis requires that apps and business processes that are candidates for re-‐engineering be priori9zed according to their technical quality and business value. –  Business objec9ves are derived from business strategies and processes,

while technical assets are mapped and weighted against these business objec9ves and evaluated using a comprehensive set of metrics.

  Current apps and processes are assessed using various techniques

including: –  Reverse-‐engineering –  Architectural Knowledge Elicita9on –  Business Process Mapping –  Process Mining

Portfolio analysis


35

LOW HIGH Derived Business Value

LOW

H

IGH

Technical Con

di9o

n Reassess Renew

Re9re Redevelop

Portfolio analysis (cntd)


36

  Service iden9fica9on inspects enterprise core business en99es, ascertains business concepts & leads to the forma9on of conceptual business processes and business services. Takes into account important issues such as: –  consolidation, –  decomposition, –  reuse, simplification & –  refactoring of legacy assets

  Service scoping defines the scope of a business process as an aggrega9on of aspects that include: –  where the process starts and ends, typical customers, –  inputs & outputs that customers expect to see, –  external en99es that the process is expected to interface with, –  different types of events that start an instance of the process.

Service identification & scoping


37

RosettaNet PIP3A4 “Manage Purchase Order”

Order Management

PIP3A, 3C

PIP3C “Returns and Finance”

Service identification

Start with comparing the abstract business process por^olio with standard process defini9ons, e.g., RoseAaNet


38

SOA Gap Analysis

•  It aims to asses the gap between the por^olio of to-‐be services and IT resources that are available to implement them, and then puvng in place a gap mi9ga9on strategy.

•  It commences with comparing the the por^olio of to-‐be service func9onality available so[ware service implementa9ons so these can be assembled within the enclosures of a newly conceived business process.

•  It tries to determine which available so[ware assets, such as legacy systems, ERP packages, etc. can be used to construct to-‐be business processes.

•  It ascertains which resources & apps can become service enabled to provide to-‐be service content.


39

Gap Analysis

Legacy Repositories

COTS

PorKolio of Candidate Services

Buy/Lease/Pay per use

Outsource

Develop

Repurpose

Service Registries

Revamp

SOA gap analysis


40

Process realization analysis


Exis;ng service

Exis;ng applica;on Service wrapper

Exis;ng applica;on Service wrapper

Exis;ng service

New service

Applica;on logic

Applica;on logic

service orchestra;on specifica;on

Service client

Web service proxy Client-‐applica;on

use

Service Provider #1

Service Provider #2

Service Provider #3

Web service provided interface

Web service content

Assembled (orchestrated)

service applica;on

Service-‐ Enabled

pre-‐exis;ng applica;on

Simple service

applica;on

Applica;on logic

41

  Green-‐field development: describes how new interface for a service will be created.

  Top-‐down development: a new service can be developed that conforms to an exis9ng service interface.

  BoAom-‐up development: a new service interface is developed for an exis9ng applica9on.

  Meet-‐in-‐the-‐middle development: this op9on is used when an already exis9ng service interface -‐ for which an implementa9on already exists – is par9ally mapped onto a new service or process defini9on.

Process realization analysis (cntd)


42

Process realization analysis (cntd)

Service realiza9on alterna9ves: ①  Reusing or repurposing already exis9ng Web services, business

processes or business process logic. ②  Developing new Web services or business processes logic from

scratch. ③  Purchasing/leasing/paying per use for services. ④  Outsourcing service design and implementa9on of Web services

or (parts of) business processes. ⑤  Using wrappers and/or adapters to revamp exis9ng enterprise

(COTS) components or exis9ng (ERP/legacy) systems. –  Revamping so[ware components including database func9onality or legacy

so[ware results in introducing service-‐enabling implementa9ons for these systems in the form of adapters or wrappers.


43

Outline



• Web services development lifecycle • SOA analysis • SOA design • SOA construc.on

44

SOA design

  Service design requires developers to define related, well-‐documented interfaces for all conceptual services iden9fied by the analysis phase, prior to construc9ng them.

  The design phase encompasses the steps of: –  singular service specifica9on, –  business process specifica9on, and –  policy specifica9on for both singular services and business processes.

  Service design is based on a twin-‐track design approach that provides two produc9on lines – one along the logical part and one along the physical part of the SOA – and considers both func9onal & non-‐func9onal service characteris9cs.


Steps in SOA design


Physical SOA Design Designed business processes are applied within an SOA in round-‐trip fashion

Fine-‐tuning of business processes within an SOA

Abstract Business Process Inventory & Architecture

Simulation and modeling of abstract “to-be” business processes resulting

from the SOA analysis phase Services

Reusable services that can be composed to specify business

processes

Business Processes

Composition of business processes from services, specification of process

activities, flows, roles and business rules

Physical SOA Design

Design of service components for the realization of services & business processes from services, re-

engineering and transformation of legacy applications and systems

Logical SOA Design

46

  Concerns: design for reuse, design for composi9on and granularity

  Specifica9on: structural specifica9on, behavioral specifica9on, service programming style and policy specifica9on.

  Scope: Choice of “right” approach & standards, e.g., orchestra9on vs. choreography

Service design concerns & scope


Specifying the service interface


Interface defini9ons for PO requests.

48

Specifying opera9on parameters

Type defini9ons for POs & PO requests.


49

  Describe the process structure: –  Iden9fy and group ac9vi9es that implement a business process; –  Describe ac9vity dependencies, condi9ons or synchroniza9on –  Describe implementa9on of the business process.

  Describe roles.

  Capture non-‐func9onal process concerns, e.g., security and transac9ons.

Specifying business processes


50

Process flow

BPEL process flow for PO process


51

Defining roles for composite services


Purchase Order Process

ComputePricePT

InvoiceCallbackPT

ShippingPT

ShippingCallbackPT

ShedulingPT

PartnerLink Purchasing

PartnerLink Invoicing

PartnerLink Shipping

PartnerLink Sceduling

PurchaseOrderPT

Defining roles in BPEL


BPEL roles for PO process

Michael P. Papazoglou Web Services: Principles & Technology Prentice-Hall, October 2007 © 53

Specifying service policies

Service policies could specify three sets of constraints:   Business constraints: such as opera9ng ranges, regulatory and

legal constraints, or standards established in specific ver9cal industries, e.g., delivery performance, fill rates, replenishment, etc.

  Technology constraints: based on choices, decisions, & commitments to specific technologies in current & con9nued use in the enterprise infrastructure –  e.g., choice of specific applica9on packages, legacy applica9ons,

commitments to industry specific standards, etc.

  Run.me quality constraints: services aspects that are directly related to system dynamics e.g., performance, scalability, transac9onal integrity, security, and fault tolerance. –  In SOAs run9me quali9es are captured by SLAS.

Specifying security policies


Specifying a security policy in WS-‐Security Policy

Referencing the above security policy

Michael P. Papazoglou Web Services: Principles & Technology Prentice-Hall, October 2007 © 55

Outline



• Web services development lifecycle • SOA analysis • SOA design • SOA construc.on

SOA programming & implementa9on model


Physical SOA Design Building SOA apps by using the

Service Component Architecture (SCA) model

57

Constructing a service

The provider perspec9ve

Service endpoint

Service endpoint

Service endpoint

Provider

Logical view Physical view

Environment

URL

URL Service

access point

Client

Service implementa;on



Service

Service

Service

SOAP message

WSDL defini;on


58

Constructing a service

The client perspec9ve

Provider

Provider

client

client

client

Client

Logical view Physical view

Environment




Request dispatch point

SOAP message

WSDL defini;on


SOA Application Development

Documents

Transcript of SOA Application Development