LaQuSo is an activity of Technische Universiteit Eindhoven and Radboud University Nijmegen Dagstuhl,...

LaQuSo is an activity of Technische Universiteit Eindhoven and Radboud University Nijmegen

Dagstuhl, July 2006

Relationships between services, components and workflows

Kees van Hee

Copyright © 2005 LaQuSo Eindhoven/Nijmegen 050615_HS_LQS 2/27

AGENDA

Service Oriented ArchitectureRole of process modelsComponents frameworkPatterns for SOAVerification


Components and services

Components deliver services to their clients

So components have a role as service provider

Components often use services offered by other components

So components have often the role of service client

softwareinterface

componentmonitorinterface

configurationinterface

user interface

Systems are networks of cooperating components

Systems can be considered as components themselves

Components may reside anywhere

Synonyms Capsules Modules Packages Classes


Role of software architecture

An architecture is used• to divide and conquer in development process• to identify, specify and select components• to test and integrate components• to manage a system when it is operational

The architecture of a system should be a

“living document” of the system


business architectureprocess model..................

information model............

software architecture:

logical model………….....

physical model.................

Infrastructure.....................

Typical way of architecture modeling


Service Orientation Architecture

Supplier

Service contract

Service

Client

ServicebrokerSearch Publish

ttp function


Unique features of SOA A SOA component is a service provider or “business unit” A SOA component will only survive if it offers added value Dynamic binding:

services are requested when they are needed services can be obtained from different providers.

Components do not have to know each other: the meet via a broker

A simple, universal protocol is required One service may be composed of many levels of components.

We only have to consider two:


AGENDA



Different roles of process models

Business processes:Enterprise Information Systems (EIS) are developed to automate or support business processesSo they have to be modeled, verified and validated before

Workflow processes in the EIS:an EIS takes care of enactment: the process model is the configuration parameter

Configuration of middleware:Components of an EIS cooperate by means of middleware; process models are the configuration parameters of orchestration


Academic formalisms (Labeled)Transition system Process algebra (e.g pi-calculus) Petri net (e.g.colored nets)

Engineering frameworks UML Activity Diagram UML State Chart BPMN BPEL EPC (defacto standard) Rose RT

Types of process models


AGENDA

Component-based worldService Oriented ArchitectureRole of process modelsComponents frameworkPatterns for SOAVerification


Reasons for a framework

We need to verify the behavioral properties of component-based (SOA) systems

Process models are good for modeling system dynamics But are often too abstract or too restrictive Therefore we need models that are closer to the software

systems and their “engineering models” We may check these models with formal methods, but we

must explain errors in terms of engineering models.


Essential features of a component

Every part of a system is a component: so the service brooker,

the middleware and the service’.

Each component consists of:

Monitor (with history log) Exception handler (with roll back mechanism) Communication ports (with message queues) Service catalog (workflow per offered service) Orchestrator (for workflow enactment) Clock (with timer and alarm) Configurator (for updating the service catalog) Application-specific subcomponents Application-specific datasets (variables)


Generic view: component infrastructure

P: portsH: history logC: service catalogV: application

specific variablesS: application

specific sub-components

Client ports

Provider ports

Exception

Handler

Monitor

C

Configurator

H

P P

P P

P P

Clock

Orchestrator

V

S


Application specific view (1)

Here we define the services

of a component by two

connected models:

• Process layer (wf model)• Events, activities, tasks

• Object layer (class model)• Variables

(volatile and persisitent)• Functions

(of input and variables to variables and output)

• Connection: tasks call functions and update variables

object layer

Comdef

Cinst

Portdef

Pinc

Objdef

Oval

C1

P0P2

Hcon

Vcon

T0T1

T2

T0

C0

E3

O

E1

P1

Cinc

E0

Procdef

Pstat

E2

Q0

E1

Task

P3

Q1

I3

I0

I1

I2

process layer


Application specific view (2)

Workflow model: Each service instance is a case or thread Case tokens are references to case objects Each task may have

Input and output messages (tiggers, events) Access to case object and other base objects Tasks exchange messages through ports with other

components Tasks execute operations on objects by method calls

Class model: Per service a case class: attribute types and methods

(functions on the attributes) Per case one object with its own attributes (variables) “Base” classes: objects that are independent of cases.

Like code tables, reference tables. It is persistent data.


Workflows for services

Made with Yasper

Intertwined workflowsOpen workflowsTranstion boarderedCase identities=threadCase sensitive:

E:emitorC:collector


Choices to be made

Communication ports: 1,2,3 asynchronous,

4,5 synchronous 3,4,5 need only arcs as glue 3 is favourite? (input place, output

transition) Reset and inhibitors only within components:

so a component can not reset an input of another

Time-outs only within components Identity management per component:

add per service a case id. “Case sensitivity”. Exception handling per component:

triggered by a task, stops orchestration and activates the compensation process based on the history log

Com

pone

nt 1

Com

ponent 2

1

2

34

5


Subcomponents

Subcomponents do not have the full functionality of a component: they use the infrastrucure of the component.

They are used as modules in a programming language: to manage complexity and for reuse in other components.

Subcomponents may have access to objects of their parents. So shared memory in the hierarchy.

Orchestrator

Component

Subcomp Subcomp

Workflow Workflow


AGENDA

Component-based worldService Oriented ArchitectureRole of process modelsComponents frameworkPatterns for SOAVerification


Example: service consumption

Made with Yasper

An RFI is broadcasted

to providers.

From the ones that

react 5 are selected for

an RFP.

From 3 of them a

selection is made and

negotiations are started.

Missing: at the end the

input place should be

reset


Example: execption handler

History log contains the

trace of tasks. For each

updated variable there is

a compensation action


Example: communication bus

Every components is connected to the bus.The bus filters the data, keeps a log and sends P2P

or broadcast. If the service directory is used, is it a broker


AGENDA



Verification: service integrity

Components deliver services, tiggered by a client A service may start up sub-services in other components Services should have a clearly defined start and end event; also

when a subservice does not deliver (X) A simple service has a Query-Answer protocol and behaves as an

RPC. These services are in fact transactions

X


Two important correctness criteria

Proper completion: services should always be able to terminate with an end event, and they should not leave any unfinished work

Invariants: constraints on case and base objects should be valid as soon as a service has finished

If we use Petri nets as modeling vehicle:Proper completion is called soundnessSoundness is decidable and there are software tools to check itMany other properties can be verified by model checking with (e.g.

reachability/coverability graph) often after applying reduction techniques

In practice we need to verify business rule like:

“always the total of received invoices should not exceed total of delivered services / goods”


Wish list

Patterns for the generic components to be combined with application specific models to verify the complete behaviorThese patterns need to be verified in isolation and be combined using construction rules that guarantee correctness. (nested Petri nets could be a solution here!)State space checking should be combined by reduction techniques.We need also symbolic model checking (see example business rule)The answers of verification should be translated into the original frameworks of the engineers

LaQuSo is an activity of Technische Universiteit Eindhoven and Radboud University Nijmegen

Visit Address:Technische Universiteit Eindhoven Radboud Universiteit

Faculteit NWIHoofdgebouw (HG) 5.91 Hoofdgebouw A6034Den Dolech 2, Eindhoven Toernooiveld 1, Nijmegen

Postal Address:HG 5.91 RUN-FNWI A6034P.O. Box 513 P.O. Box 90105600 MB Eindhoven 6500 GL NijmegenThe Netherlands The Netherlands

Phone: +31 (0)40 247 2526 +31 (0)24 365 3410Fax: +31 (0)40 247 4252 +31 (0)24 365 3137

E-mail: [email protected] [email protected] Website: www.laquso.com

LaQuSo is an activity of Technische Universiteit Eindhoven

Date post:	19-Dec-2015
Category:	Documents
View:	215 times
Download:	2 times

LaQuSo is an activity of Technische Universiteit Eindhoven and Radboud University Nijmegen Dagstuhl,...

Documents