SelfConFoil no 1

Self configuring systems

- introduction II

SelfConFoil no 2

From last time...

• System X: SDL syntax:

• a(2,2):AT - set of 2 instances called a of type AT

• b(,):BT - set of minimum null, maximum infinite instances called b of type BT

• *(,):* - set of minimum null, maximum infinite instances with undefined name and undefined type (not SDL syntax)

• System X: SDL syntax:

• a(2,2):AT - set of 2 instances called a of type AT

• b(,):BT - set of minimum null, maximum infinite instances called b of type BT

• *(,):* - set of minimum null, maximum infinite instances with undefined name and undefined type (not SDL syntax)

System X

*(,):*

c(10,125):CT

a(2,2):ATae(2,2):AET

Registry

ce(10,125):CET

Configurer

*(,):*

SelfConFoil no 3

Basic functionalities identified

Structural configuration:

• Detection, e.g. plug-in; plug-out

• Registry: register, de-register, find

• Bind-release

• Configurer: configure, re-configure

• Learn: load new types/code

• Explore/discover: find out what’s there - mutually

Structural configuration:

• Detection, e.g. plug-in; plug-out

• Registry: register, de-register, find

• Bind-release

• Configurer: configure, re-configure

• Learn: load new types/code

• Explore/discover: find out what’s there - mutually

System X

*(,):*

c(10,125):CT

a(2,2):ATae(2,2):AET

Registry

ce(10,125):CET

Configurer

*(,):*

Dynamic (service) execution:

• Find:

•Opportunities

•Service providers

•Agents

• bind-release

• Context/situation adaptation

Dynamic (service) execution:

• Find:

•Opportunities

•Service providers

•Agents

• bind-release

• Context/situation adaptation

Doctors

DoctorAgent[m]

Patients

PatientAgent[n]

Registry

Patology: refHart: ref....

SelfConFoil no 4

Service Oriented Architecture

• SOA is an architectural style that encourages the creation of loosely coupled business services Loosely coupled services that are interoperable and technology-agnostic enable business flexibility

• A SOA solution consists of a composite set of business services that realize an end-to-end business process

• Each service provides an interface-based service description to support flexible and dynamically re-configurable processes

[John Reynolds],

• see:

http://weblogs.java.net/blog/johnreynolds/archive/2005/01/the_soa_elevato.html

http://en.wikipedia.org/wiki/Service-oriented_architecture

• SOA is an architectural style that encourages the creation of loosely coupled business services Loosely coupled services that are interoperable and technology-agnostic enable business flexibility

• A SOA solution consists of a composite set of business services that realize an end-to-end business process

• Each service provides an interface-based service description to support flexible and dynamically re-configurable processes

[John Reynolds],

• see:

http://weblogs.java.net/blog/johnreynolds/archive/2005/01/the_soa_elevato.html

http://en.wikipedia.org/wiki/Service-oriented_architecture

SelfConFoil no 5

SOA – Registration, find, bind of service providers

• The Service Provider makes the service available with its Service Contract and advertise it on the Service Broker

• The Service Consumer find the compatible Service and its Service Contract using the Service Broker:

Find providers for given service

• The Service Consumer and the Service Provider interact.

• The Service Provider makes the service available with its Service Contract and advertise it on the Service Broker

• The Service Consumer find the compatible Service and its Service Contract using the Service Broker:

Find providers for given service

• The Service Consumer and the Service Provider interact.

Give some SOA examples

SelfConFoil no 6

SOA points

•SOA isn’t really new, but there are now some standard technologies (such as Web Services) that make it much easier to implement

•The “Services” in SOA are business services… updating a loan application is a business service, updating a record in a database isn’t

•Services are linked together to implement business processes... Business Process Engines make it easier to combine services into business processes, and BPEL is an emerging standard language for this purpose

•Business partners can use your company's services within their own business processes and your company can use services provided by business partners within your own business processes.

•SOA solutions favor flexibility over efficiency... machine cycles and network traffic are less important than being able to quickly implement and change business processes

•SOA isn’t really new, but there are now some standard technologies (such as Web Services) that make it much easier to implement

•The “Services” in SOA are business services… updating a loan application is a business service, updating a record in a database isn’t

•Services are linked together to implement business processes... Business Process Engines make it easier to combine services into business processes, and BPEL is an emerging standard language for this purpose

•Business partners can use your company's services within their own business processes and your company can use services provided by business partners within your own business processes.

•SOA solutions favor flexibility over efficiency... machine cycles and network traffic are less important than being able to quickly implement and change business processes

SelfConFoil no 7

Web Services

• Web Services are services offered via the web.

• Services are developed and registered in business directories, e.g. UDDI

• Services are looked for and discovered from the registries.

• Services are descriped using WSDL.

• Buisnesses send requests for the service using SOAP protocol over HTTP.

• Essentially, WS too is about dynamic role binding!

• Web Services are services offered via the web.

• Services are developed and registered in business directories, e.g. UDDI

• Services are looked for and discovered from the registries.

• Services are descriped using WSDL.

• Buisnesses send requests for the service using SOAP protocol over HTTP.

• Essentially, WS too is about dynamic role binding!

SelfConFoil no 8

Essential attributes of a web service [1]:

• It can be described using a standard service description language, usually Web Service Description Language (WSDL);

• it can be published to a registry of services, usually a UDDI (Universal Description, Discovery, and Integration) registry;

• it can be discovered by searching the service registry; it can be invoked, usually remotely, through a declared API;

• it can be composed with other Web services.

[1] Huang, Walker; Extensions to Web Service Techniques for

Integrating Jini into a Service-Oriented Architecture for the Grid

have a look at:

http://en.wikipedia.org/wiki/Web_service

http://www-128.ibm.com/developerworks/webservices/library/ws-soad1/

• It can be described using a standard service description language, usually Web Service Description Language (WSDL);

• it can be published to a registry of services, usually a UDDI (Universal Description, Discovery, and Integration) registry;

• it can be discovered by searching the service registry; it can be invoked, usually remotely, through a declared API;

• it can be composed with other Web services.

[1] Huang, Walker; Extensions to Web Service Techniques for

Integrating Jini into a Service-Oriented Architecture for the Grid

have a look at:

http://en.wikipedia.org/wiki/Web_service

http://www-128.ibm.com/developerworks/webservices/library/ws-soad1/

What is current practice?

Any limitations?

How much self configuration?

SelfConFoil no 9

Is contemporary SOA or WS the solution?

Only if

• passive services are all you need

• there is little need for stateful sessions

• you are not too worried about interoperability and performance

• you are happy to live in a concrete architecture

Because these ”services” are essentially

• invocation interfaces bound to concrete components

• used for integration and distribution

• not for engineering end user and community services

Only if

• passive services are all you need

• there is little need for stateful sessions

• you are not too worried about interoperability and performance

• you are happy to live in a concrete architecture

Because these ”services” are essentially

• invocation interfaces bound to concrete components

• used for integration and distribution

• not for engineering end user and community services

Layer n-1

Layer n

C1 C2 Cn Don’t mix it up

Services are more than SOA and WS

SelfConFoil no 10

So … what is a service?

A service is:

an identified functionality aiming to establish some goals/effects among collaborating entities.

Captures:

• end user services

• active services

• passive services

• component interfaces (Web Services, CORBA, JINI, …)

• layered functionality (ISO OSI)

A service is:

an identified functionality aiming to establish some goals/effects among collaborating entities.

Captures:

• end user services

• active services

• passive services

• component interfaces (Web Services, CORBA, JINI, …)

• layered functionality (ISO OSI)

Layer n-1

Layer n

C1 C2 Cn

SelfConFoil no 11

The nature of services

• Service is functionality; i.e. behavior performed by entities.

• Service imply collaboration; it makes no sense to talk about service unless at least two entities collaborate.

• Service behavior is cross-cutting; it imply coordination of two or more entity behaviors

• Service behavior is normally partial; it is to be composed with other services

• Service is functionality; i.e. behavior performed by entities.

• Service imply collaboration; it makes no sense to talk about service unless at least two entities collaborate.

• Service behavior is cross-cutting; it imply coordination of two or more entity behaviors

• Service behavior is normally partial; it is to be composed with other services

Actor1 Actor2 Actor3 Actor4 Actor5Actor1 Actor2 Actor3 Actor4 Actor5

Service 3Service 3

Service 2Service 2

Service 1Service 1

Horizontal composition(within a service)

Vertical composition (within an actor)

r2

r3

r1

service 2service 1

SelfConFoil no 12

Services and compositional adaptation • Service structures define ”horizontal” dependencies and

variability in terms of collaborating roles

• Service compositions define ”vertical” dependencies and variability in terms of roles played by actors

• Static and dynamic role binding is key to compositional adaptation using Find; Bind-Release

• Provides practical means to ensuring ”Horizontal” compatibility and ”vertical” conformance

• Expressed using UML 2.x collaborations

• Service structures define ”horizontal” dependencies and variability in terms of collaborating roles

• Service compositions define ”vertical” dependencies and variability in terms of roles played by actors

• Static and dynamic role binding is key to compositional adaptation using Find; Bind-Release

• Provides practical means to ensuring ”Horizontal” compatibility and ”vertical” conformance

• Expressed using UML 2.x collaborations

Actor1 Actor2 Actor3 Actor4 Actor5Actor1 Actor2 Actor3 Actor4 Actor5

Service 3Service 3

Service 2Service 2

Service 1Service 1

Horizontal composition(within a service)

Vertical composition (within an actor)

SelfConFoil no 13

Service modeling using UML 2 collaborations

• Matches the concept of service: Collaborative; Cross-cutting; Partial; Functionality

• Can model services separately in terms of role structures and behaviours

• Allows flexibility in binding roles to classes

• Require conformance between roles and classes

• Can model interfaces and contracts as two-party collaborations

• Matches the concept of service: Collaborative; Cross-cutting; Partial; Functionality

• Can model services separately in terms of role structures and behaviours

• Allows flexibility in binding roles to classes

• Require conformance between roles and classes

• Can model interfaces and contracts as two-party collaborations

Actor1 Actor2 Actor3 Actor4 Actor5Actor1 Actor2 Actor3 Actor4 Actor5

Service 3Service 3

Service 2Service 2

Service 1Service 1

Horizontal composition(within a service)

Vertical composition (within an actor)

r2

r3

r1

service 2service 1

SelfConFoil no 14

Collaboration as behavior contract: example

SelfConFoil no 15

Collaboration as behavior contract:• Two connected roles with

•Static interfaces

• Interface behaviors

• Connector properties•Asynchronous or synchronous

•Bidirectional or unidirectional

• Modelchecked to ensure compatibility between roles

• Publishable using WSDL

• Two connected roles with•Static interfaces

• Interface behaviors

• Connector properties•Asynchronous or synchronous

•Bidirectional or unidirectional

• Modelchecked to ensure compatibility between roles

• Publishable using WSDL

SelfConFoil no 16

Using contract roles to type interfaces

• Compatibility of contract roles modelchecked at design time

• Conformance with contract checked for each interface at design time

• Simple compatibility assurance at runtime

• Compatibility of contract roles modelchecked at design time

• Conformance with contract checked for each interface at design time

• Simple compatibility assurance at runtime

Sq:StockQuote

ApplicationStock Info

Server

<<Requests>> <<Provides>>

Sq:StockQuote

requestor provider

SelfConFoil no 17

Conformance with contract

1. Project component behavior to interface behavior

2. Compare interface behavior with contract role behavior: are theyequivalent or substitutable?

1. Project component behavior to interface behavior

2. Compare interface behavior with contract role behavior: are theyequivalent or substitutable?

ApplicationStock Info

Server

Project Project

CompareCompare<<Requests>> <<Provides>>

SelfConFoil no 18

An extended contract

SelfConFoil no 19

With additional behavior

Sq:StockQuote

Sq:StockQuoteandNews

SelfConFoil no 20

Safe substitution: equivalent reachable behavior

Sq:StockQuoteSq:StockQuoteandNews

<<Substitutes>>

SelfConFoil no 21

Safe substitution

• Verified once at design time

• Simple checks at run time

• Verified once at design time

• Simple checks at run time

SelfConFoil no 22

Use in Registry• By typing providers with semantic connectors/basic service roles

• One gets meaningful lookup

• With lean and strong compatibility assurance (modelchecked, safe substitution)

• By typing providers with semantic connectors/basic service roles

• One gets meaningful lookup

• With lean and strong compatibility assurance (modelchecked, safe substitution)

SelfConFoil no 23

Meaningful lookup (find)

• Modelchecked collaborations

• Verified relationships

• Simple search

• Strong compatibility

• Run-time efficiency

• For active and passive services

• For finding providers of given services

• and discovering service opportunities

Registry

SelfConFoil no 24

Agent find; bind-release Sometimes there are constraints on what actors can be bound:

• the individual identified by a name or identifier

• an individual with a given responsibility

• an individual in a given location, etc.

The requestor may need to adapt to the services the actor provides

Sometimes there are constraints on what actors can be bound:

• the individual identified by a name or identifier

• an individual with a given responsibility

• an individual in a given location, etc.

The requestor may need to adapt to the services the actor provides

Doctors

DoctorAgent[m]

Patients

PatientAgent[n]

Registry

Patology: refHart: ref....

SelfConFoil no 25

Agent bind-release aspects

• Dynamic links imply that roles are dynamically assigned to actors.• This requires dynamic role management mechanisms for discovery, selection,

adaptation and invocation.• A large class of services are triggered in response to dynamic bind requests (at least

communication control services).• The state of an actor may determine what roles the actor is able to play at any given

time, e.g. busy, free.• Compatibility rules must be applied on dynamic liks to ensure goal and progress

• Dynamic links imply that roles are dynamically assigned to actors.• This requires dynamic role management mechanisms for discovery, selection,

adaptation and invocation.• A large class of services are triggered in response to dynamic bind requests (at least

communication control services).• The state of an actor may determine what roles the actor is able to play at any given

time, e.g. busy, free.• Compatibility rules must be applied on dynamic liks to ensure goal and progress

UserAgent

Caller

CallB A

Call BAa

b

Terminal UTTerminalAgent

POT 1

Terminal UT

Ta: TerminalAgent

Tb: TerminalAgent

ua:UserAgent ub:UserAgent

3

21

1 1 2

3

2

31 1POT Caller callee POT

Callee

SelfConFoil no 26

Service providers/agents:

• Have portfolio of provided services and roles

• Inner structure of actors with associated roles

• May support exploration/discovery (reflection)

• Manages role invocation in response to Role (bind) request

• Enforces policies concerning:

•situation

•user preferences

• Ensures role alignment

• Have portfolio of provided services and roles

• Inner structure of actors with associated roles

• May support exploration/discovery (reflection)

• Manages role invocation in response to Role (bind) request

• Enforces policies concerning:

•situation

•user preferences

• Ensures role alignment

a b

c d

...Service and role portfolioProvider/agent

preferencespolicies

context situation local situation

Rb2

Rc1

Rb1

Rc2

b

c

<<provides>>

Rd1Rd2 d

SelfConFoil no 27

Levels of role alignment

Validation. Checking that the roles are compatible – safety and liveness.

Adaptation. Selecting substitution roles, negotiating and adapting the roles (within bounds).

Learning. Learning to play new roles by receiving role definitions (e.g. using Java class loading)

Validation. Checking that the roles are compatible – safety and liveness.

Adaptation. Selecting substitution roles, negotiating and adapting the roles (within bounds).

Learning. Learning to play new roles by receiving role definitions (e.g. using Java class loading)

SelfConFoil no 28

Interface typing by contracts (semantic connectors)

Y: UserAgent

CalleeB

yi

X: UserAgent

CallerA

xi

W: UserAgent

CalleeWwiB

Z: UserAgent

CallerW ziA

UserCallW UserCallW

UserCall UserCall

Incompatible

Compatible {UserCallW.goal}

Compatible {UserCall.goal}

Compatible {UserCall.goal}

SelfConFoil no 29

Role negotiation pattern

X: UserAgent Y: UserAgent

RoleRequest(Callee)

RoleConfirm(Callee)

Caller CalleeA B

Run-time role validation

SelfConFoil no 30

Service role learning pattern

X: UserAgent W: UserAgent

RoleRequest(Callee)

RoleConfirm(CalleeW)

Caller CalleeW

:ServiceBroker

Lookup(C

alleeW

, Calle

r)

Result(i

dCallerW

, pro

vider)

Exp

ort

(Cal

lerW

)

provider:ServiceProvider

Imp

ort

(idC

alle

rW)

CA’CallerW

A BWCallerW

SelfConFoil no 31

Find, bind-release aspects

• Service identification:

•at least terminology

• trend towards ontology

• Precise interface definitions:

•at least static interfaces

• trend towards dynamic (protocol) interfaces

•and ultimately semantic interfaces

• Substitution mechanisms

•substitution relationships

•substitution policies

•negotiation mechanisms

• Compatibility validation

• Role learning

• Service identification:

•at least terminology

• trend towards ontology

• Precise interface definitions:

•at least static interfaces

• trend towards dynamic (protocol) interfaces

•and ultimately semantic interfaces

• Substitution mechanisms

•substitution relationships

•substitution policies

•negotiation mechanisms

• Compatibility validation

• Role learning much current research focus on ontologies,

and middleware for discovery,

selection and adaptation

much current research focus on ontologies,

and middleware for discovery,

selection and adaptation

SelfConFoil no 32

Next Generation Service Engineering

Service models

Model transformation

Functionalitymodels

Model transformation

Realization

Service models

Model transformation

Functionalitymodels

Model transformation

Realization

Systems Components,conectors

NGN

Monitoring EnablersService platformsterm

UML Collaborations for services, connectors

UCM for Use Cases,Scenarios

GRL for Goals,Strategies

GRL for Goals,Strategies

SelfConFoil no 33

Case study: GRL Model for Availability

Service provider

User

SelfConFoil no 34

Evaluation of a GRL strategy

Service provider

User

SelfConFoil no 35

Use Case Maps with dynamic stubs for adaptation

If location = unsequre & …

If threatLevel =high & …

Then UTPA

If threatLevel = high & …

Then ServerPull

SelfConFoil no 36

UML 2 Collaborations for service structure and behavior

MMoIP

UserServiceProvider

Request MMoIP

MMoIP Use

END MMoIP

SecureMMoIP (Userpull)

User

AccessControl Server

ServiceProvider

Request MMoIP

Authorization

MMoIP Use

END MMoIP

SelfConFoil no 37

SecureMMoIP (Userpull)

User

AccessControl Server

ServiceProvider

Request MMoIP

Authorization

MMoIP Use

END MMoIP

Compositional adaptation by replacement and insertion

<<replaces>>

MMoIP

UserServiceProvider

Request MMoIP

MMoIP Use

END MMoIP

{when threat level = 0or location = secure}

or

{when threat level > 0orlocation not secure}

Server Pull {when ...}

UTPA {when ...}

UoPA {when ...}

User Pull {when ...}

using policy rules evaluated by agents upon role requests

using policy rules evaluated by agents upon role requests

or

SelfConFoil no 38

Controlled locally by actors

The actors use policies to decide which role to offer when a role is requested

(part of the role binding)

The actors use policies to decide which role to offer when a role is requested

(part of the role binding)

<<Actor>>ServiceProvider

MMCall

<<Actor>>UserAgent

RequestMMoIP

TerminalSession

ENDMMoIP

TerminalCall

Authenti-cation

DistributeAuths

Authori-zation

MMoIPUse

RequestMMoIP

Authori-zation

MMoIPUse

ENDMMoIP

SelfConFoil no 39

New architectural opportunities in a nutshell

• Using semantic connectors (contracts) for:

•Typing components

•Lean and srong compatibility

•Meaningful lookup

•Safe substitution

• Compositional adaptation to

•Situation

•User preferences

• using policy to direct:

•Collaboration replacement

•collaboration insertion

• Using semantic connectors (contracts) for:

•Typing components

•Lean and srong compatibility

•Meaningful lookup

•Safe substitution

• Compositional adaptation to

•Situation

•User preferences

• using policy to direct:

•Collaboration replacement

•collaboration insertion

SecureMMoIP (Userpull)

User

AccessControl Server

ServiceProvider

Request MMoIP

Authorization

MMoIP Use

END MMoIP

<<Actor>>ServiceProvider

MMCall

<<Actor>>UserAgent

RequestMMoIP

TerminalSession

ENDMMoIP

TerminalCall

Authenti-cation

DistributeAuths

Authori-zation

MMoIPUse

RequestMMoIP

Authori-zation

MMoIPUse

ENDMMoIP