1 / 9

The Open Group’s Real-time Aggregated Systems Challenge

The Open Group’s Real-time Aggregated Systems Challenge. Initial Requirements. Contributed by the OMG Real-time, Embedded, and Specialized Systems (RTESS) Task Force Dock Allen and Dr. Ben Calloni, Chairs. Introduction.

mfelicita
Download Presentation

The Open Group’s Real-time Aggregated Systems Challenge

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. The Open Group’s Real-time Aggregated Systems Challenge Initial Requirements Contributed by the OMG Real-time, Embedded, and Specialized Systems (RTESS) Task Force Dock Allen and Dr. Ben Calloni, Chairs

  2. Introduction • The Challenge is an Open Group Challenge, which is also supported by the Object Management Group (OMG) • OMG’s real-time group defined an initial set of requirements at their January 2003 meeting

  3. Aggregated Systems • Aggregation of independently developed systems • No common software infrastructure at any level • No common networking technology • Multiple programming enclaves • SQL database programming • Client-Server RPC (e.g. RT CORBA) • Message-based distribution (e.g. JMS) • J2EE remote invocation (and emerging Distributed RT Java) • Service-based systems (e.g. Web Services) • Information-centric systems (e.g. the C2ERA CII)

  4. End-to-End Honoring of QoS • Passing QoS parameters between nodes and between software environments • Translation QoS parameters into the local representation for each node or environment

  5. Top-to-Bottom Honoring of QoS • Passing QoS parameters up and down between infrastructure layers • Translation of QoS parameters into layer-specific representations • Ideal is that all layers honor QoS, but this is often not the case

  6. Local Honoring of QoS • preemption of the current task for a task with higher QoS • one of the policies that should be supported • QoS-sensitive queue management (items are serviced in QoS order) • QoS-based resolution of resource contention • processors, network access, etc • QoS-based resolution of resource contention • Ability to set QoS of internal threads

  7. QoS Policy Management • Ability to support more than one policy, and resolve conflicts between policies • aggregated systems may support applications with different QoS needs such as “run jobs to completion” versus “do the most important thing”

  8. Most Systems are Less-than-ideal • Do the best you can with what you have • e.g. RT CORBA over TCP/IP • Partial Solutions are Useful

  9. The Role of Network Management • In the aggregate, application data patterns can interfere with one another; • Network attempts to handle local overloads can exacerbate them • Can networks even out loads? • Ethernet protocols such as IETF DiffServ • Lui Sha’s work at CMU • U4EA

More Related