1 / 39

Self configuring systems - introduction II

Self configuring systems - introduction II. 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

adah
Download Presentation

Self configuring systems - introduction II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Self configuring systems - introduction II

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

  3. System X *(,):* *(,):* ae(2,2):AET a(2,2):AT ce(10,125):CET c(10,125):CT Registry Configurer Basic functionalities identified • Dynamic (service) execution: • Find: • Opportunities • Service providers • Agents • bind-release • Context/situation adaptation 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 Registry Patology: ref Hart: ref .... Doctors Patients DoctorAgent[m] PatientAgent[n]

  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

  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. Give some SOA examples

  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

  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!

  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/ What is current practice? Any limitations? How much self configuration?

  9. C1 C2 Cn Layer n Layer n-1 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 Don’t mix it up Services are more than SOA and WS

  10. C1 C2 Cn Layer n Layer n-1 So … what is a service? A service is: anidentified 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)

  11. The nature of services • Service is functionality; i.e. behavior performed by entities. • Service implycollaboration; 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 1 service 2 r2 r1 r3

  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

  13. Service modeling using UML 2 collaborations service 1 • 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 service 2 r2 r1 r3

  14. Collaboration as behavior contract: example

  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

  16. Stock Info Server requestor provider Application Sq:StockQuote Using contract roles to type interfaces Sq:StockQuote • Compatibility of contract roles modelchecked at design time • Conformance with contract checked for each interface at design time • Simple compatibility assurance at runtime <<Provides>> <<Requests>>

  17. Project Project Stock Info Server Compare Compare Application Conformance with contract • Project component behavior to interface behavior • Compare interface behavior with contract role behavior: are theyequivalent or substitutable? <<Requests>> <<Provides>>

  18. An extended contract

  19. Sq:StockQuote Sq:StockQuoteandNews With additional behavior

  20. Safe substitution: equivalent reachable behavior <<Substitutes>> Sq:StockQuote Sq:StockQuoteandNews

  21. Safe substitution • Verified once at design time • Simple checks at run time

  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)

  23. Meaningful lookup (find) Registry • 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

  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 Registry Patology: ref Hart: ref .... Doctors Patients DoctorAgent[m] PatientAgent[n]

  25. TerminalAgent T U POT 1 Terminal Call Call Terminal Agent bind-release aspects UserAgent Caller T U a • 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 A B 1 2 Callee b 3 A B ub:UserAgent ua:UserAgent Tb: TerminalAgent Ta: TerminalAgent callee Caller POT POT 2 2 1 1 1 1 3 3

  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 Provider/agent Service and role portfolio ... preferences policies a b <<provides>> local situation context situation c d b Rb2 Rb1 c d Rc2 Rc1 Rd2 Rd1

  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)

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

  29. RoleConfirm (Callee) RoleRequest (Callee) Role negotiation pattern Run-time role validation X: UserAgent Y: UserAgent Callee Caller B A

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

  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 much current research focus on ontologies, and middleware for discovery, selection and adaptation

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

  33. Case study: GRL Model for Availability Service provider User

  34. Evaluation of a GRL strategy Service provider User

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

  36. UML 2 Collaborations for service structure and behavior

  37. Server Pull {when ...} UTPA {when ...} User Pull {when ...} UoPA {when ...} Compositional adaptation by replacement and insertion usingpolicy rulesevaluated byagentsuponrole requests {when threat level = 0 or location = secure} <<replaces>> or {when threat level > 0 or location not secure} or

  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)

  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

More Related