Paradigms of Distributed Software Systems

© W. Lamersdorf: ”Paradigms of Distributed Software Systems”, ICETE/ICE-B, Seville, Spain, July 2011

Paradigms of Distributed Software Systems:Services, Processes and Self-Organization

Winfried.Lamersdorf @ informatik.uni-hamburg.dehttp://vsis-www.informatik.uni-hamburg.de

Prof. Dr. Winfried Lamersdorf

Distributed and Information Systems (VSIS)Hamburg University, MIN‐Faculty, Informatics Dept.Vogt‐Kölln‐Straße 30, D‐22527 HAMBURG, Germany

2© W. Lamersdorf: ”Paradigms of Distributed Software Systems”, ICETE/ICE-B, Seville, Spain, July 2011

Service‐oriented Applications

eg Documenteg HotelPrint services

Service

Payment

Service user /Customer req.

Service Pro-vider / Offer

“Electronic Service Market”

Goal: System support forOpen world-wide co-operation (“e-services”)

Characteristics:Heterogeneity, Open-ness, Flexibility,Standards, …


Content

• Motivation

• Service‐oriented Architecture (SOA) Concepts, Reference Model & ArchitectureSOA Implementation: Web ServicesEU NoE S‐Cube: Software Services &Systems

• Self‐organizing (SO) Software SystemsConcepts: Bio‐inspired AlgorithmsDFG Project SodekoVSExamples

• SO Implementation: (Multi‐) Agent Systems Multi‐Agent System (Jadex)

Agent‐based Business Process Simulation & OptimizationDFG Transfer Project Go4Flex


Economic Background: Changing Business Organizations

”Service-Orientation”[SS10]

Economic challengesglobal markets deregulationfast technological developmentsshort product life cyclesworld-wide collaboration…

Market reactionlean processes, re-usable componentsconcentration on core competenciesjust-in-time productionoutsourcingIT: abstract programming paradigms …


Organisational Structure: From Function‐ to Process‐orientation

• Traditional functional organization (Taylor): i.e.separate tasks and sub‐organizations

hierarchical organizational structure

• New: Process and Service‐orientation:relating applications and IT organization

• Goals:adequate models of application requirementsflexible reaction to changesprocess-oriented application reflected also at IT-level

Two (adequate) views: „Processes“ vs. „Services“


Technical Background:a) Communication support: Use of Internet Infrastructure

end of 1960iesInternetmostly human‐to‐human communicationeMail, News, FTP, static WWW, …

since mid 1990iescommercializationhuman‐to‐computer interactionclient‐server co‐operationweb applications: Online‐shopping, ‐banking, etc. ‐>„B2C“

since 2000ies„B2B“ (new economy boom)goal: Business via Internetservice co‐operationdevelopment of standards: ebXML, RosettaNet, …later: social networks (Web 2.0 ‐> „C2C“)

2010ies: Mobile Services


Technical Background:b) Programming Concepts: From Data Objects to Services

1960ies: Assemblerhuman readable machine languagebasis: von‐Neumann‐architecture

1970ies: Structured programmingencapsulation of behaviorprocedures / subroutinesmodularization of program specificationsre‐usability (SW libraries)

1980ies: Object‐orientationcommon encapsulation of data and behaviorabstract data typesobjects, polymorphism, classes, inheritance

1990ies: Software componentshigher granularity of re‐usable artifactsapplication development (mostly) by re‐use of existing components “programming in the small” (single component level) vs.“programming in the large” (application level)

2000ies: Service‐Orientation


Processes

Applications / IT-Systems Machines Employees

Ressources / Individuals

Roles

Why Process Orientation?A

pplicationlevel

Organisation. level

Technicallevel


IT‐Structure of Process Organization

• Emphasis on organization‐wide process

• One virtual interface (GUI) per role

Traditional (sub‐) system „owners” become responsible for processes and/or services

System 1System 1

GUI

Processes

Functions(services)

DataSystem 2System 2 System 3System 3 [M10]


Processes, EAI and Distributed Systems

Computer 1

Local Operating System 1

Network

Application A Application B

Computer 2


Application C Application D

Computer 3


Application E Application F

Computer 4


Application G Application H

User 1 User 2 Device

Middleware

A2

A4

A3

A6XOR XORA1

A5

Process-oriented Application

Network Network


Businesss Processes: Modelling Levels

Level 1

Level 2

Level 3a Level 3b

Level 4b

Application level

Technical level

TechnicalProcess model

IT Specification

StrategicProcess model

Operative Process model

Implementation

Content: Process overviewGoal: Rapid understanding

Operative workflowsWork and implementation model

Execution without process engine

Execution with process engineTechnical DetailsRealization

Content:Goal:

Content:Goal:


Business Process: Life Cycle Model

Technical Level

Application Level

Deployment

TechnicalModelling

Controlling and Evaluiation

Instantiiation

Executionand Monitoring

Identification and Analysis of Application

ApplicationModelling

(Implementation)


Overall Application Scenario: „Cloud“ Services

Vision:


Content

• Motivation

• Service‐oriented Architecture (SOA) Concepts, Reference Model & ArchitectureImplementation: Web ServicesEU NoE S‐Cube: Software Services &Systems





SOA Basic Concepts

Service:Mechanism for interconnection needs and capabilities

Service description: Artifact which contains all relevant aspects of a service which are necessary for interaction

..

Execution Context: Technical and application‐oriented elements which inter‐connect needs and services; enables information exchange, execution of actions, related contracts and policies

Policies: Constraints for using a service

Capabilities: Abilities to execute operations with “real world effect”

Real World Effect: Result of a service interaction

Interaction:Model for using a service


SOA‐Definition(s) of OASIS

SOA is…

“An architectural paradigm for organizing and using distributed capabilities that may be under the control of different ownership domains.”

“A framework for matching needs and capabilities.”

“A view of architecture focusing on services as a mechanism to allow interactions between those with needs and capabilities.”

OASIS: (*1993, ex: SGML Open): Organization for the Advancement of Structured Information Standards, Standards bodies for E‐Business etc., as, e.g., UDDI, EbXML, WS‐BPEL


The Magic SOA Triangle

Distribution of services (organizational units) and applications

Servicedirectory

Servicesupplier

Serviceuser

Service description Service discovery

Interaction


Serviceuser

Serviceuser

Serviceuser

Alternative View of SOA Architecture

“Enterprise Service Bus” (ESB) as Mediator

Serviceoffer

Serviceoffer

Serviceoffer

Serviceoffer

ESB


SOA Temple

Distribution

Loose coupling

Address service

Process

orientationSimplicity

Security

Standards

Service-oriented architecture


SOA Implementation: „Web Services“ – Definition(s)

„A web service is any service that is available over the Internet, uses a standardized XML messaging system, and is not tied to any one operating system or programming language.”[Ethan Cerami, Web Services Essentials, O'Reilly, 2002 ]

“A Web service is a software system identified by a URI, whose pub-lic interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner pre-scribed by its definition, using XML based messages conveyed by Internet protocols.”[W3C, Web Services Glossary]

Web Services are „self-contained, modular business applica-tions that have open, Internet-oriented, standards-based interfaces.”[UDDI consortium: UDDI_Executive_white_paper, 2001]


Web Services: Characteristics

A Web Service is a service which……is available via Internet or Intranets,

…uses a standardized (XML-) message system,

…is independent of programming language and operating system,

…is self-describing by use of an XML grammar, and

…is detectable via simple mechanism.

Register Service user Service supplier

find service

find service description

use service

[W3C04]


Roles and Standards for Web Services

Service directory

Service supplier Service userSOAP

WSDL

UDDIWSDL

SOAP


Web Service Protocol Stack

Discovery UDDIDiscovery UDDI

Description WSDLDescription WSDL

XML Messaging SOAP, XML-RPCXML Messaging SOAP, XML-RPC

Transport HTTP, SMTP, FTP Transport HTTP, SMTP, FTP

Transport: responsible for message transport between applications

XML Messaging: responsible for transport and messages encoding (in XML)

Description: responsible for description of public service interfaces(functional, procedural, quality-of-service)

Discovery: service directory with easy service registration and discovery

[OASIS04] [OASIS09]


Web Services: The “Big Picture”

Transport (HTTP, SMTP, JMS, …)

Representation (XML, XMLSchema, …)

Protocol (SOAP, REST, …)

Security (WS-Security, WS-Policy, …)

Processes (WS-BPEL, WSCI, …)

Further Paradigms (EDA/CEP, …)

Des

crip

tion

(WS

DL,

…)

Dis

cove

ry(U

DD

I, W

S-In

spec

tion…

)

Impl

emen

tatio

n &

Met

hods

(Axi

s, J

AX

-WS

, SO

MA

, …)


SOA in a Distributed World

CentralizedApplication

EnterpriseSoftware Suite

EnterpriseApplication

Integration (EAI)

B2C

B2B

Distribution overApplicationsSingle application Homogeneous

Application environmentHeterogeneous

Application environment

Distribution overOrganizations

Centralisedcontrol

Independentusers

Independentapplication

components

SOA

SOA

SOA

SOA SOA

SOAVision

Open service markets

Business networks

Virtual organizations


Ongoing SOA Research

• Duration: 2008 – 2012

• EU Program: Service and Software Architectures, Infrastruc‐tures and Engineering

• total cost: approx. 11 Mio EUR for 16 partner institutions

Detailed Information: Web: http://www.s‐cube‐network.eu

„Software Services and Systems“ (S3, S-Cube):Topic: Service-oriented development of distributed

software and applications

EU Network of Excellence


S‐Cube Partners

University of Duisburg-Essen

(Coordinator)

Tilburg University

City University London

Lero

INRIA

MTA SZTAKI

University of Crete

Université Claude Bernard Lyon

Universidad Politécnicade Madrid

University of Stuttgart

Vienna University of Technology

Politecnico di Milano

Consiglio Nazionale delleRicerche (CNR)

Center for Scientific and Technol. Research (FBK)

University of Hamburg

Vrije UniversiteitAmsterdam


S‐Cube: Motivation

Integration of research expertise and an better collaboration of resear‐chers (and industry) in the field of software services and systems in order to address the following key problemskey problems:

Reduce research fragmentation: Current research activities are fragmen‐ted and each research community (e.g., grid computing, distributed sys‐tems or software engineering) concentrates mostly on its own specific techniques, mechanisms and methodologies. Resulting solutions are not aligned with or influenced by activities in related research fields.

Address future challenges: E.g. build service‐based systems so that they can self‐adapt while guaranteeing the expected level of service quality. (Adaptation may be required due to changes in a system’s environment or in response to predicted and unpredicted problems.)


ResearchEstablish agile & holistic service engineering & adaptation principles, techniques & methods to foster innovation

Invent the next wave of service technologies

IntegrationEstablish a unified, multi‐disciplinary research community

Establish a trust relationship with industry (via NESSI)

Integration of technical infrastructure (Lab)

Spread of ExcellenceInaugurate a Europe‐wide education and training programme for researchers and industry

Spread results / outreach to communities

S‐Cubes Objectives: Overview

S-Cube Main Objectives are

Integration

Research

Spread of Excellence

S-Cube Main Objectives are

Integration

Research

Spread of Excellence

[PPPM10]


Business ProcessManagement

Service Composition

Service Infrastructure

S‐Cube’s Research Framework

DesignSpecifications

CapabilitiesStatus

Status

Status

AdaptationSpecifications



Specifications

CapabilitiesEngineering

& Design

Adaptation

&

Monitoring


Capabilities


Capabilities


S‐Cube: Activities & Work Packages

JRA-2: Distributed SystemRealisation Mechanisms

for Service-based Systems

JRA-2: Distributed SystemRealisation Mechanisms

for Service-based Systems

WP-JRA-2.1: Business Process Management

WP-JRA-2.2: Adaptable Coordinated Service Compositions

WP-JRA-2.3: Self-* Service Infrastructure & Service Discovery Support

JRA-1: Engineering andAdaptation Methodologiesfor Service-based Systems

JRA-1: Engineering andAdaptation Methodologiesfor Service-based Systems

WP-JRA-1.1: Engineering Principles,Techniques & Methodologies

WP-JRA-1.2: Adaptation & Monitoring Principles, Techniques & Methodologies

WP-JRA-1.3: End-to-End Quality Provision & SLA Conformance

SoE-

1: S

prea

ding

of E

xcel

lenc

eSo

E-1:

Spr

eadi

ng o

f Exc

elle

nce

WP-

SoE-

1.1:

Vi

rtua

l Cam

pus

WP-

SoE-

1.2:

Com

mun

ity O

utre

ach

IA-1: Integrating Knowledge and ResourcesIA-1: Integrating Knowledge and ResourcesWP-IA-1.1: Convergence

Knowledge ModelWP-IA-1.2: Pan-European Distributed

Service Laboratory

Mgt

-1: M

anag

emen

tM

gt-1

: Man

agem

ent

IA-2: Integrating CommunitiesIA-2: Integrating CommunitiesWP-IA-2.1: Mobility of

ResearchersWP-IA-2.2: Alignment with European

Industry Practices

IA-3: Integration Framework for Service-based SystemsIA-3: Integration Framework for Service-based Systems

WP-IA-3.1: Integration Framework:Baseline and Definition

WP-IA-3.2: Integration Framework:Validation and Personalisation

WP-

Mgt

-1.1

Ove

rall

Man

agem

ent

WP-

Mgt

-1.2

Scie

ntifi

c an

d Te

chni

cal

Man

agem

ent

WP-

MG

T-1.

3A

djus

tmen

t of J

PAW

Ü-M

gt-1

.4G

ende

r Iss

ues


Example Research Topics (UniHH)

WP‐JRA‐2.1 Business Process Management

WP‐JRA‐2.2 Adaptable Coordinated Service Compositions

WP‐JRA‐2.3 Self*‐Service Infrastructure and Service Discovery Support

WP‐IA‐1.1 Knowledge Model

WP‐IA‐3.1 and 3.2 Integration Framework

WP‐IA‐2.1 Mobility Program


WP‐JRA‐2.2Adaptable Coordinated Service Compositions

Goal: Distributed process execution

Partition 4

Partition 3Partition 2

Partition 1

Site A

Site B

Site D

Site C

Potential problems:What if a site is not available?What if is does not perform?What if is has not enough resources?... Adaptation to dynamic changes


Distributed Environment for Mobile Processes

• Specify complete process (all, i.e. functional and non‐functional process characteristics only once regardless of all distribution aspects (‐> abstract machine)

• Monitor and manage process execution environment (changes!)

• Execute process dynamically based on process specification and actual environment data

• Collect an keep execution data for further process monitoring and management

Site A Site B Site C Site D

Partition 1 Partition 2 Partition 3 Partition 4


Life Cycle of a Business Process Execution

Assign-ment and process

execution

5.Process

modellingGeneration of migration

meta dataDeploy-ment

1. 2. 3.

Design time Runtime

PMi

Tool support

Manual config.

PMi + MMiMMi

Pi + Mi

Instan-tiation

4.

Pi + Mi

Mig

ratio

n

PM: Process ModelMM: Migration Metadata Model

P: Process InstanceM: Migration Metadata Instance

“Migrating processes”: Development & Execution

[KZTL08]


Generalizing the Model: Generalizing the Model: ““Mobile Process as a ServiceMobile Process as a Service””

Traditional business process management: Individual acquisition and operation of (specialized) business process management systems (BPMS)

www

ProcessC

BPMSC

CompanyC

www

ProcessA

BPMSA

CompanyA

www

ProcessB

BPMSB

CompanyB

www

ProcessC

BPMSC

CompanyC

www

ProcessA

BPMSA

CompanyA

www

ProcessB

BPMSB

CompanyB

ProcessA

CompanyA

ProcessB

CompanyB

www

BPMS

BPMS as a Service

ProcessZ

CompanyZ

...

www

ProcessC

BPMSC

CompanyC

New trend: Software as a Service (SaaS) [TBB03]: Central business process management system operated by (external) service provider

Increasing need for flexibility, dynamism, mobility, QoS, avoidance of bottlenecks, …: →Distribution and decentralization of BPM

Initiator

Process

www

Distributed BPM as a Service?

BPMS1

BPMS2

BPMS3


Challenges

Initiator

Process

www

BPMS1

BPMS2

BPMS3

QoS: "Execute my process as fast as possible!"

Mobility: "My process / a part of my process has to be executed in a certain location!"Control: "I want to cancel my process!"Monitoring: "During the execution of my process, I want to receivelogs and status information!"Security: "I don't care how my process is executed- but I do not want participation of my competitors!"


Content

• Motivation






Aiming at autonomous systems: Self‐organization (SO)

Visible in

‐ physical

physical structure:- liquids- magnets- laser

biologicalcollectives(swarms)

Principles:Global structures “emerge” form local interactions

basis: autonomous individuals particles, cells, “agents”, ...

System properties: adaptation, robustnessestablishment / support of structures with external disturbancestable in dynamically changing environments

collectivephenomena in society &business:- urban development- traffic- …

‐ biological‐ social systems


Using Self‐Organization for SW Development

Robotics:- Motion control- (Self-) assembly

Productions mangmnt:- Production lines- Warehouse logistics

Network Management:- Routing- Intrusion detection

Infrastructure-Mangt:- Green-IT- Virtualization, …

Decentralized Coordination

as, e.g., in

Software development for distributed applicationsbased on distributed, de-centralized

problem solving strategies

Usable for Systems with: autonomous elementshigh degree of distribution


SO for Distributed Systems and Services

Goal: Internet of Services ̶ realizing

scalable, robust and adaptive applications

Architecture alternatives:managed hierarchical distributed

local adaptive entities (“agents”) problem: effective coordination

Self-organizing service andprocesses

Scalability,Robustness, …

Managing Entity

Pyramid of Managing

Entities


Industry Example: IBMs “Autonomic Computing”

self‐management:‐ self‐configuration‐ self‐healing,‐ self‐protection, ‐ self‐optimization

Touchpoints, Autonomic Managers, “MAPE” Loops etc.Pyramid of Ma-naging Entities


Realizing SO Systems: “SodekoVS”

DFG project, based on nature-inspired coordination mechanisms, as, e.g.:

swarms, ants, bees, …

http://www.gatech.edu/newsroom/release.html?id=1605b

Approach:distinguish

functionality co-ordination

co-ordination as (con-struction) aspect

co-ordination strategies asre-usable,exchangeabledesign elements

[SR10][SBPRL09]

Realization: based on • coordination layer &• multi-agent system platform


Example 1: Motor Highway Management (1)

Quelle: http://www.ndr.de

Commission of the European Communities,“White paper: European transport policy for 2010: time to decide” 2001, cOM (2001) 370 final.

Challenges:• Motorway infrastructure with ever-increasing traffic volumes• Traffic jams cause high costs (up to 1% of EU GNP in 2010)

Need for more intelligent and adaptive solutions



Approach:• use of nature-inspired coordination patterns for optimizing

resource usage• model based on independent autonomous entities• model, simulate and evaluate alternative strategies for traffic

management • implement and analyze system behavior with multi-agent

platform

Focus:• agent-based system model, simulation & implementation• adaptive management strategies• dealing with new and/or unknown situations where heuristics

cannot be used[VL11]





Result:• Simulation of both individual as well as

system behavior independent model of behavior


Example 2: Notebook manufacturer

Exemplary order process

Autonomous management:business process execution − based onautomatic service selection − based onfunctional and non‐functional criteria

[VHLSR11]


Example 2 ‐ Order Process: Service Selection

• many requestors and provider(s)

• servers are potentially unreliable

• built‐up usage statistics • service selection based on different preferences

• meet requirements of all contract partners

• adapt to changes autono‐mosly

• use automatic negotiation patterns

Situation

Goals

using non‐functional criteria


Goal

Realization: Service selection based on dynamic „trust model“• introduce trust level for each service • evaluate services based on criteria set• select components dynamically

Method: Dynamic service selection based on (multi‐) functional and non‐functional criteria

Benefits: • reduced manual management

effort• automatic adaptation to changes

Automated management of service selection and business process execution in market‐based business domains, basis: “trust”


Implementation: System Architecture

[SBPRL09]DFG Project „SodekoVS“


Exemplary Communication Pattern


Simulation of Multi‐criteria Service Selection: Example scenario

Reliability

Costs

Goal: Balance service „cost“ vs. „trust“ – by evaluating an „optimal“ relation between reliability (trust) and cost (profit)


Vision: Systematic Integration of Self‐organizing Dynamics

[SBPRL09]

[SR10]

Development steps:

Requirements: define intended system behavior

Analysis: select + combine self‐organizing processes design metaphors

Design: select + configure agent coordination mechanisms interaction

techniques

Implementation: enact systemic models of self‐organizing processes

Test / Validation: check manifestation of feedback structures at run‐time


Content

• Motivation



• SO Implementation: (Multi‐) Agent Systems Multi‐Agent System (Jadex)Agent‐based Business Process Simulation & OptimizationDFG Transfer Project Go4Flex


Realization Basis: „Agent“ Technology

• Agent-metaphor is useful for…• modeling & building complex applications

with autonomous components• making complexity manageable at a conceptual level• realizing adaptive, self* behavior

• .. and attractive for the development of SO-applications:

• Autonomous actors (i.e. agents) are useful for: • Service provision:

• self-managed service execution• Service invocation:

• autonomous srv. selection and invocation• automatic service composition• adaptation to dynamic environments


BDI Agents: Belief‐Desire‐Intention

Philosophical model [B87]explains human action based on beliefs, desires, intentionsmain concept: future‐directed intention (consistent, stable) “goal”realization relies on the practical reasoning process

Software architecture [RG95]BDI reduced to beliefs, goals, plansGoals: conflict‐free desires, modeled as eventsBeliefs and goals lead to selection and stepwise execution of plansIntentions are represented implicitly by running plans

Advantages of BDI Modelsimple!describes how humans think that they think (mentalistic notions)successful implementations already exist


Goal: Agent‐based Coordination

Agent‐oriented software engineering (AOSE)applications = sets of autonomous actors

Technical basis: multi‐agent platformJava‐based, open source

distributed middleware

development environment

Agent‐based realization of co‐ordination architecturecoordination endpoint• agent module concept

coordination medium:• distributed co‐ordinat. spaces

declarative programming model• spec. of co‐ordination logic

http://jadex.informatik.uni-hamburg.de

[BP10]

[SR10]


Abstract BDI Agent Architecture

AgentAgent

CapabilityCapabilityPractical reasoning

interpreterPractical reasoning

interpreter

PlansPlans

GoalsGoalsBeliefsBeliefs

Incomingmessages

Dispatch(sub‐)goals

Selectplans

Handleevents

Read/writefacts

Application events

Goalconditions

EventsEvents

Goal events

Goaldeliberation

Goaldeliberation

Means‐endreasoningMeans‐endreasoning

Outgoingmessages

Conditionevents

Selectgoals

Handledeliberationsituations


Generalization of Agents+SOA ‐> “Active Components”

Definition: “An active component (AC) is an autonomous, managed and poten-tially hierarchical software entity that is capable of interacting with other active components in different modes including message passing and method calls.”

• management infrastructure and composability of components• invocation styles like agents and services/active objects• rich behavior styles like agent architectures or workflows

[BP11]

[PB11]

Active ComponentActive Component

InternalArchitecture

ProvidedServiceInterfaces

Properties

BusinessLogic

RequiredServiceInterfaces

based on

AgentAgent

InternalArchitecture

SCA ComponentSCA Component Sensors Effectors

Subcomponents


AC Implementation Platform: „Jadex v2”

A platform is the management infrastructure for components, which is responsible for their execution as well as for providing administration capabilities like a messaging system or a component service registry.

Design Goals:Platform can execute different kinds of (“active”) components Component kernels should be enabled to run on different platformsApplications should be platform independentApplications should be composable from arbitrary component types (heterogeneous applications)

Concrete ApplicationConcrete ApplicationJadex ACJadex AC

n m n1PlatformPlatform KernelKernel Active

ComponentActive

Component n

m

StandaloneStandalone

Java EEJava EE

……

BDIBDI

BPMNBPMN

……

Sales AssistantSales Assistant

Order ProcessOrder Process

……


Jadex Tool Support

• Currently available modeling toolsFor micro and BDI agents IDEs are sufficient, as no new agent programming language is introducedFor BPMN and GPMN workflows eclipse‐based editors can be employed

• Currently available runtime toolsAccess point for platform tools is the Jadex Control Center (JCC), which offers a plugininterface for concrete toolsStarter: Browse component models, start and stop componentsDF‐Browser: View DF registrationsConversation Center: Compose and send messages to componentsCommunication Analyzer: Monitor message exchange between componentsTest Center: Execute component‐based test suitesSimulation Control: Manage the execution mode, i.e. realtime, event‐driven or time‐drivenDebugger: View component internals and execute components stepwiseLibrary Service:Manage the Java classpath used for loading models and executing componentsAwareness: Settings for the automatic detection of other Jadex platforms in the local netComponent Viewer: Allows viewing component and service GUIs


Example: Business Process Simulation & Optimization

Example application: Car production process(es) at Daimler AG

• Goal: specify, analyze & optimize flexible and ”agile” production workflows

• Approach: Simulation and validation based on MA/AC technology (Jadex)• Orga: DFG‐funded Technology Transfer Project

(Uni HH & Daimler AG)

• Realization: Add goals to process model – related

to explicit context and behavior characteristics


“Agile” Production Workflows

• Traditional workflows are rather static and inflexible → changes are difficult• Agile processes adapt to such changes dynamically & flexibly

• sometimes (very) long duration (e.g. months/years)• no overall process co-ordination → distributed co-ordination

Customer order process

Productionplanning process

SupplierProcess(es)

Suppliers

Customers

[PB11]


Traditional Workflow Modeling – e.g. BPMN

Implementation:Each task is implemented and can be customized via a specific Java classGateways and events offer predefined property settings (e.g. in case of a time event, the duration can be set)

However: This is an operational specification ‐ How to specify more abstract goal(s) of the workflow?


New: GPMN Workflows for Agile Processes

• GPMN = “Goal Process Modeling Notation”as developed in DFG project “Go4Flex” [PBJ11]

→ realize flexible and agile workflow concepts with agent technology

• Modeling:GPMN workflows are described by (a hierarchy of) goalsLeaves of this hierarchy are concrete BPMN processes (“plans”)

• Realization: GPMN workflows are modeled with eclipse‐based editor similar to BPMNGPMN workflows are executed via model transformation as BDI agentsCo‐ordination layer is realized by multi‐agent platform

• Consequences:• high flexibility, automatic reaction to dynamic changes• no central control, higher productivity• drawback: sometimes more flexibility than necessary


Real GPMN Workflow Application (Car Production)


GPMN/Jadex Modeling and Runtime Tool Support


Summary and General Conclusion

Presented actual software development paradigms for distributed systems and applications:

• Process‐oriented business organizations lead to service‐ and process‐ori‐entedmodels and implementations –> Realization: SOA & Web Services (incl. standards, middleware, software tools etc.)

• Complex distributed systems/ workflows should be increasingly “autono‐mic” – i.e. self‐organize

• ”Active components” can be used for specification, simulation, realiza‐tion and evaluation of autonomous applications, based on modern ext‐ended (multi‐) agent technology

• Combination(s) of paradigms are possible – and attractive…

• Next step (e.g.): extension of event processing strategies


References[BP11] Braubach, L, Pokahr, A: "Addressing Challenges of Distributed Systems using Active Components", in: Proceedings of 5th Inter‐

national Symposium on Intelligent Distributed Computing (IDC‐2011)“, Delft, Netherlands, October 2011

[B87] Bratman, M.: Intention, Plans, and Practical Reason, Harvard University Press., Cambridge, MA, USA, 1987

[JL11] Jander, K., Lamersdorf, W.: “GPMN‐Edit: High‐level and Goal‐oriented Work‐flow Modeling”, in: Hellbrück, H., Luttenberger, N., Turau, V. (Eds.): Proc. Workshops der wissenschaftlichen Konferenz Kommunikation in verteilten Systemen 2011 (WowKiVS2011), Electronic Communications of the EASST, 2011, pp. 146‐157

[JBPL11] Jander, K., Braubach, L., Pokahr, A., Lamersdorf, W.: "Goal‐oriented Processes with GPMN", International Journal on Artificial In‐telligence Tools (IJAIT), World Scientific Publishing, Singapore, 2011

[KZTL08] Kunze, C.P., Zaplata, S., Turjalei, M., Lamersdorf, W.: “Enabling context‐based cooperation: A generic context Model and Mana‐gement System”, in: 11th International Conference on Business Information Systems (BIS 2008), Abramowicz, W., Fensel, D. (Eds.), Springer‐Verlag, 2008; 459–470

[M10] Melzer, M. (Ed.): “Service‐orientierte Architekturen mit Web Services“, 4th Edition, Spektrum Akademischer Verlag, Springer‐Verlag, Heidelberg, 2010

[MZL10] Meiners M., Zaplata S., Lamersdorf W.: “Structured context prediction: A generic approach”, in: Proceedings of the 10th IFIP In‐ternational Conference on Distributed Applications and Interoperable Systems (DAIS 2010), F. Eliassen R.K. (Eds.), IFIP, Springer, 2010; 84–97

[OASIS04] Clement, L., Hately, S., von Riegen, C., Rogers, T.: “UDDI Spec Technical Committee Draft”, Version 3.0.2,

[OASIS09] Modi, V., Kemp, D. (Editors): ”Web Services Dynamic Discovery” (WS‐Discovery) Version 1.1

[P08] Papazoglou, M.P.: “Web Services: Principles and Technology”, Pearson, 2008

[PPPM10] Papazoglou, M.P., Pohl, K., Parking, M., Metzger, A.: „Service Research Challenges and Solutions for the Future Internet: S‐Cube ‐Towards Engineering, Managing and Adapting Service‐Based Systems“, Springer‐Verlag, Heidelberg, 2010

[PBJ10] Pokahr, A., Braubach, L., Jander, K.: "Unifying Agent and Component Concepts – Jadex Active Components", in: Proc.s Seventh German conference on Multi‐Agent System TEchnologieS (MATES‐2010), Springer‐Verlag, Berlin, Heidelberg, 2010, pp. 100‐112

[PB11] Pokahr, A., Braubach, L.: "Active Components: A Software Paradigm for Distributed Systems", in: Proc.s 2011 IEEE/WIC/ACM „International Conference on Intelligent Agent Technology“ (IAT‐2011), Lyon, France, 2011


References[RG95] Rao, A, Georgeff, M: “BDI Agents: from theory to practice”, in: V. Lesser (Ed.): Proceedings of the First International Conference on

Multi‐Agent Systems (ICMAS'95), The MIT Press. Cambridge, MA, USA, 1995, pp.312‐319.

[SBPRL09] Sudeikat, J., Braubach, L., Pokahr, A., Renz, W., Lamersdorf, W. “Systematically Engineering Self‐organizing Systems: The Sodeko‐VS approach”, Electronic Communications of the EASST, vol. 17, 2009

[SR10] Sudeikat, J, Renz, W: "On the Modeling, Refinement and Integration of Decentralized Agent Coordination ‐ A Case Study on Disse‐mination Processes in Networks", in: "Self‐Organizing Architectures“ Springer‐Verlag, Heidelberg, 2010, pp. 251‐274

[SS10] Schmelzer, H, Wolfgang Sesselmann, W: „Geschäftsprozessmanagement in der Praxis Kunden zufrieden stellen ‐ Produktivität steigern ‐Wert erhöhen“, 7. Edition, Carl Hanser‐Verlag, München

[TBB03] Turner, M, Budgen, D, Brereton, P: „Turning Software into a Service“, IEE Computer, 2003, pp. 38‐44

[VL11] Vilenica, A., Lamersdorf, W. “Simulation Management for Agent‐Based Distributed Systems”, in: Filipe, J., Cordeiro, J. (Eds.): Enterprise Information Systems, Springer‐Verlag, Heidelberg New York, 2011, pp. 477‐492

[VHLSR11] Vilenica, A. Hamann, K. Lamersdorf, W. Sudeikat, J. Renz, W.: “An Extensible Framework for Dynamic Market‐Based Service Selec‐tion and Business Process Execution”, in: Proc. 11th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS 2011),Springer‐Verlag, 2011

[W3C04] Champion, M., Ferris, C., Newcomer, E., Orchard, D.: “Web Services Architecture”, Working Group Note, Feb. 2004

[WBG10] Weiss, G., Braubach, L., Giorgini, P.: “Intelligent Agents”, in: “Handbook of Technology Management“, Wiley, United States, 2010, pp.

[ZKML09] Zaplata, S., Kottke, K., Meiners, M., Lamersdorf, W.: “Towards Runtime Migration of WS‐BPEL Processes ", in: Dan, A., Gittler, F., and Toumani, F. (Eds.): "Service‐Oriented Computing”, Proc.s ICSOC/ServiceWave 2009 Workshops", Springer‐Verlag, Berlin/Heidelberg, 2010, pp. 477–487

[ZKL09] Zaplata, S., Kunze, C.P., Lamersdorf, W.: “Context‐based Cooperation in Mobile Business Environments: Managing the Distributed Execution of Mobile Processes”, BISE 10, vol. 4, 2009

[ZSWBHL10] Zaplata, S., Straßenburg, D., Wunderlich, B., Bade, D., Hamann, K., Lamersdorf, W.: "Ad‐hoc Management Capabilities for Distri‐buted Business Processes", in: Abramowicz, Alt, Fähnrich, Franczyk, Maciaszek (Eds.): „3rd International Conference on Business Process and Services Computing“ (BPSC 2010), Lecture Notes in Informatics, GI‐Edition, Bonn, 2010, pp. 139‐152


Thank you for your attention…

Questions ???

Winfried LamersdorfHamburg University, Informatics Dept.Distributed and Information Systems (VSIS)Vogt-Kölln-Straße 30, D-22527 HAMBURG, Germany


International Federation of Information Processing: (Software) Service‐related Working Groups

a) TC 6 (Communications):WG 6.11WG 6.11: „Communication Aspects of the e‐World“:

e‐Business, e‐Services and e‐Society

since 2000, reg. international conference series on

“e‐Business, e‐Services & e‐Society” (I3E)

b) TC 2 (Software Engineering):New WG 2.14New WG 2.14: „Service‐oriented Systems“:

Service‐oriented architecture & applications

new; initial meeting at ECOWS 2011, Lugano, Switzer‐land, September 2011

Documents

Paradigms of Distributed Software Systems