SelfCon Foil no 1 Self configuring systems - introduction II

SelfCon Foil 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):AT ae(2,2):AET Registry ce(10,125):CET Configurer *(,):*

SelfCon Foil 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):AT ae(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 Doctor Agent[m] Patients Patient Agent[n] Registry Patology: ref Hart: ref....

SelfCon Foil 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: _elevato.html 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: _elevato.html

SelfCon Foil 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

SelfCon Foil 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

SelfCon Foil 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!

SelfCon Foil 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: 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: webservices/library/ws-soad1/ What is current practice? Any limitations? How much self configuration?

SelfCon Foil 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 C1C2Cn Don’t mix it up Services are more than SOA and WS

SelfCon Foil 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 C1C2Cn

SelfCon Foil 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 r2 r3 r1 service 2 service 1

SelfCon Foil 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

SelfCon Foil 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 r2 r3 r1 service 2 service 1

SelfCon Foil no 14 Collaboration as behavior contract: example

SelfCon Foil 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

SelfCon Foil 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 Application Stock Info Server > Sq:StockQuote requestorprovider

SelfCon Foil no 17 Conformance with contract 1.Project component behavior to interface behavior 2.Compare interface behavior with contract role behavior: are they equivalent or substitutable? 1.Project component behavior to interface behavior 2.Compare interface behavior with contract role behavior: are they equivalent or substitutable? Application Stock Info Server Project Compare >

SelfCon Foil no 18 An extended contract

SelfCon Foil no 19 With additional behavior Sq:StockQuoteSq:StockQuoteandNews

SelfCon Foil no 20 Safe substitution: equivalent reachable behavior Sq:StockQuote Sq:StockQuoteandNews >

SelfCon Foil no 21 Safe substitution Verified once at design time Simple checks at run time Verified once at design time Simple checks at run time

SelfCon Foil 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)

SelfCon Foil 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

SelfCon Foil 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 Doctor Agent[m] Patients Patient Agent[n] Registry Patology: ref Hart: ref....

SelfCon Foil 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 Call B A B A a b Terminal U T TerminalAgent POT 1 Terminal U T Ta: TerminalAgent Tb: TerminalAgent ua:UserAgent ub:UserAgent POT Caller callee POT Callee

SelfCon Foil 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 portfolio Provider/agent preferences policies context situation local situation Rb2 Rc1 Rb1 Rc2 b c > Rd1Rd2 d

SelfCon Foil 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)

SelfCon Foil no 28 Interface typing by contracts (semantic connectors) Y: UserAgent Callee B yi X: UserAgent Caller A xi W: UserAgent CalleeW wi B Z: UserAgent CallerW zi A UserCallW UserCall Incompatible Compatible {UserCallW.goal} Compatible {UserCall.goal}

SelfCon Foil no 29 Role negotiation pattern X: UserAgentY: UserAgent RoleRequest (Callee) RoleConfirm (Callee) Caller Callee A B Run-time role validation

SelfCon Foil no 30 Service role learning pattern X: UserAgentW: UserAgent RoleRequest (Callee) RoleConfirm (CalleeW) Caller CalleeW :ServiceBroker Lookup(CalleeW, Caller) Result(idCallerW, provider) Export (CallerW) provider :ServiceProvider Import (idCallerW) CA’ CallerW A BW CallerW

SelfCon Foil 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

SelfCon Foil no 32 Next Generation Service Engineering Service models Model transformation Functionality models Model transformation Realization Service models Model transformation Functionality models Model transformation Realization Systems Components, conectors NGN Monitoring Enablers Service platforms term UML Collaborations for services, connectors UCM for Use Cases, Scenarios GRL for Goals, Strategies GRL for Goals, Strategies

SelfCon Foil no 33 Case study: GRL Model for Availability Service provider User

SelfCon Foil no 34 Evaluation of a GRL strategy Service provider User

SelfCon Foil no 35 Use Case Maps with dynamic stubs for adaptation If location = unsequre & … If threatLevel =high & … Then UTPA If threatLevel = high & … Then ServerPull

SelfCon Foil no 36 UML 2 Collaborations for service structure and behavior

SelfCon Foil no 37 Compositional adaptation by replacement and insertion > {when threat level = 0 or location = secure} or {when threat level > 0 or location not secure} Server Pull {when...} UTPA {when...} UoPA {when...} User Pull {when...} using policy rules evaluated by agents upon role requests or

SelfCon Foil 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)

SelfCon Foil 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