Aurora Borealis - PowerPoint PPT Presentation

1 / 48
About This Presentation
Title:

Aurora Borealis

Description:

... installation of component packages. Lack service-level management ... Container: a component hosting environment. Shield from server-specific dependencies ... – PowerPoint PPT presentation

Number of Views:2715
Avg rating:3.0/5.0
Slides: 49
Provided by: mar177
Category:

less

Transcript and Presenter's Notes

Title: Aurora Borealis


1
Aurora Borealis
http//www.ics.forth.gr/pleiades/projects/Aurora/a
urora.html
2
An Infrastructure for Service-level Management in
Distributed Work Sessions
Manolis Marazakis PhD Thesis Public
Defense March 10, 2000 Research Area Distributed
Systems
Department of Computer Science
3
The Problem
  • Provision of new services over the Internet
  • Integrated travel package
  • airlines, hotels, cars, reservations
  • Tourist information services
  • recommend nearby restaurants amusement parks
  • Information correlation services
  • find rank WWW pages
  • Multi-organization experiment management
  • global climate studies

4
Is it difficult ?
  • Global-scale interoperability
  • Autonomy
  • Severe restrictions on control of foreign systems
  • Large-scale distribution
  • Variable delays, partial failures
  • Increasingly interdependent systems
  • Mutual commitments, delegation

5
Is it significant ?
  • Service composition
  • Adding value to existing systems
  • The Web
  • Pervasive access medium
  • forces all to establish presence
  • Presence gives potential for external
    transactions
  • Shortcomings of existing approaches
  • Assumptions contradicting autonomy

6
Network-Centric Applications
7
A Motivating Example Recommending WWW Links
  • Collect links on given topic
  • Rank links
  • Filter out non-promising links
  • Present results

8
Composition of Services
9
Thesis
  • In order to facilitate reuse and combination of
    services from independent authorities, it is
    essential to support automatic sequencing of
    service-level agreements, and reliable tracking
    of interaction state. An appropriate component
    platform needs to be in place to enable SLAs.

10
Service Level Agreement (I)
  • expected/promised behavior of services
  • methods, parameters, results, exceptions
  • estimates of performance metrics
  • access control restrictions
  • compensating actions
  • Inspection manipulation of controls

11
Service-Level Agreement (II)
  • More predictable dependable services
  • Respects autonomy of providers
  • SLA mediates all interactions with service

12
Aurora in the Protocol Stack
13
Contributions (I)
  • Component platform
  • Design implementation
  • Service-level agreements
  • Log/monitor system, service contract object
    framework
  • Extensions to OMG CORBA
  • Component/container framework
  • Event notification services
  • Directory service for component/services metadata

14
Contributions (II)
  • Design implementation of a scripting language
  • Access to component/container services
  • Event-Condition-Action rules (WHEN, WHENEVER)
  • Demonstrator systems
  • Yahoo AltaVista recommendation service
  • E-commerce environment, agreements in order
    handling

15
Related Work (I)
  • WfMC family emphasis on state management
  • Process models, work items lists, roles,
    resources
  • State transitions upon events
  • generated by outcome of work assignments
  • DB-managed process state
  • Lacks service-level management
  • Assumes WFMS to be the sole work coordinator

16
Related Work (II)
  • Exotica/FMQM (IBM Research, 1995-1997)
  • Partitioning of process model (using a compiler)
  • Persistent queuing system (MQSeries) for
    integration
  • WIDE (EU Project, 1997-)
  • Use of DB triggers to support ECA rules
  • Research on exception handling
  • Lack service-level management
  • Rely on proprietary services for integration

17
Related Work (III)
  • CHAIMS (U. Stanford, 1996-1998)
  • A language for supporting exclusively composition
  • Compiler for decomposing a synchronous invocation
    into phases
  • SWAP (IETF Internet Draft, 1998)
  • request protocol for managing long-running
    activities
  • contributed to WfMC-TC-1023 (2000)
  • Lack service-level management
  • Assume static or manual sequencing

18
Related Work (IV)
  • INCAs (Barbara et al, 1996)
  • Self-contained units of work (mobile agents)
  • HADAS (Technion Institute, 1995-1999)
  • explicit links between sites
  • automated installation of component packages
  • Lack service-level management

19
Related Work (V)
  • Numerous business object frameworks
  • Oracles NCA (1997)
  • IBMs San Francisco Project (1998), and Component
    Broker (1998)
  • BEAs M3 (1998 / evolution of Tuxedo TP monitor)
  • SUNs Enterprise Java Beans (1998)
  • Combination of shared services and standard
    callback interfaces
  • Lack service-level management
  • Assume single authority

20
Related Work (VI)
  • Collaboration Management Infrastructure (MCC,
    1999-)
  • descriptions of services, currently for dynamic
    binding
  • COYOTE (IBM Research, 1998)
  • Compiler-assisted generation of contract wrappers
  • Reliance on stubs undermines autonomy

21
Related Work Distributed Objects
  • No standard model for server-side components
  • interoperable components (e.g. CORBA/IIOP, DCOM)
  • No standard way of accessing basic services
  • inflexible dependencies on run-time services
  • Important developments
  • OMG CORBA Components Specification (draft 1999)
  • EJB (1998) persistent state transactions
  • SUNs Jini architecture (1998) join discovery
  • HPs eSpeak architecture (1999) E-Services vision

22
Technical Details Components, Containers,
Requests
23
The Architecture of Aurora
24
Interoperability Problems
25
Component Model Concepts
  • Overlapping but different concerns
  • component development
  • application assembly
  • application deployment
  • component hosting
  • server platform
  • Container a component hosting environment
  • Shield from server-specific dependencies
  • references to services
  • notify components when actions are needed

26
Container Run-Time
27
Service State Transitions
Minimal requirements for request processing state
exposure.
Providers may expose more detailed FSM.
28
Service Control Model
Separation of concerns Provider vs. Requester
29
Request Management
30
Workflow Model
Shift of emphasis from state/product to
satisfaction of commitments
31
WfMC Reference Model
32
Work Session Framework
33
Access Control
  • Actions
  • use an interface
  • monitor an event
  • invoke an interface method
  • Clients need explicit permissions to assume
    roles
  • Security credentials (ID, public key, authority)
  • associated with work session participants through
    directories
  • Access Controller
  • Permissions/restrictions to assume roles
  • Enforcement of access control policy

34
SLA Framework (I)
Normal flow order fulfilled within deadline
Provider
35
SLA Framework (II)
Deviation missed order deadline
36
Case Study
37
Order Tracking Workflow (I)
  • Services by independent providers
  • Products catalogue
  • Inventory
  • Shopping basket
  • Payment processor
  • Order tracking
  • Feedback log
  • Two implementations
  • OMG jointFlow
  • Aurora work session framework

38
Order Tracking Example (II)
39
Order Tracking Example (III)
  • Aurora services used
  • asynchronous event notifications (FSM)
  • log/monitor system
  • access control for setting order state
  • service-level agreements
  • deadline for shipping an order
  • deadline for claiming a refund
  • compensations when returning products

40
Technical Details Scripting
41
Configuration Example
corba_init HERMES
corba_resolve csrv container_init reqMgr csrv
demo1 set
yahoo_pkgK load_component_package_drep reqMgr
yahooPkg yahooPkg_dkey
set yahoo_iK init_component_instance r
eqMgr yahoo_pkgK yahoo_init_args
42
Composition Example
set yahoo_rid request_issue reqMgr callerID
cbSpec yahoo_iK ifN methodN slaSpec ifrK
yahoo_args set yahoo_results request_wait
reqMgr yahoo_rid set altavista_args lindex
yahoo_results 0
set altavista_rid
request_issue reqMgr callerID
cbSpec altavista_iK ifN methodN slaSpec
ifrK altavista_args
43
Reactive Rule Example
proc condition1 varList action examine
status_taskA, status_taskB to determine
value of res if res 1 action
varList corba_resolve prompter set
varSpecA rule_variable state_taskA REQUIRED
statusA prompter set varList list varSpecA
varSpecB set rk1 when rule1 varList
condition1 action1
44
Conclusions Perspective
45
Conclusions
  • Network-centric applications
  • large-scale distribution
  • autonomy
  • dynamic environment
  • Aurora
  • service-level agreements
  • component/container framework
  • Extensions to OMG CORBA

46
Composing Service-Level Agreements
  • Provider P0 uses services of P1, P2
  • Each provider offers its own contracts
  • SLA(P0), SLA(P1), SLA(P2)
  • P2 changes parameters of SLA(P2)
  • How to propagate changes ?
  • In real-time

47
Supporting Thin Clients
  • Service access devices of limited capabilities
  • PDAs, 3rd-generation cellular phones
  • Limited CPU, bandwidth memory
  • Intermittent connectivity
  • Their number will soon surpass that of PCs
  • Support for transactional applications ?

48
Aurora Australis
http//www.ics.forth.gr/pleiades/projects/Aurora/a
urora.html
Write a Comment
User Comments (0)
About PowerShow.com