1 / 12

Presentation 14: Callbacks

Objektorienteret Middleware (TIOOMI). Presentation 14: Callbacks. Outline. Motivation Using TTS as example CORBA Callbacks Issues & solutions Alternative solutions. Data Collection & Presentation. TRS. Server. New Reading. CORBA Object. PSP. View Readings. DB.

parry
Download Presentation

Presentation 14: Callbacks

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. Objektorienteret Middleware (TIOOMI) Presentation 14: Callbacks

  2. Outline • Motivation • Using TTS as example • CORBA Callbacks • Issues & solutions • Alternative solutions

  3. Data Collection & Presentation TRS Server New Reading CORBA Object PSP View Readings DB Classic CORBA Client / Sever model is sufficient for Data Collection & Presentation

  4. Alarm level surveillance TRS Server (TRS) New Reading CORBA Object PSP View Readings Present Alarm DB Problem: The client / server pattern breaks down when we want to notify FROM the server to the client. Solution: Client polling OR peer-to-peer model -> e.g. using Callbacks

  5. CORBA Callbacks • CORBA specification: • ORB is BOTH client AND server channel • Peer-to-peer architecture • All client programs may register server objects - e.g. Callback object • How-to: • TTS: RegisterCallback(ObjRef) -> list of PSP’s • PSP: Notify() • Callback object should be transient only

  6. Issues • Distributed Deadlock • If client and server single-threaded • Client calls server, server calls client at same time • Deadlock – both are blocked, waiting for a response • OB: recommends thread-per-request semantics • Solutions: • Do not make single-threaded applications • Problem: not all OS’s support multithreading • Inconvenience : multithreading introduces new complexities • OR use “oneway” semantics • Problem with oneway: • “Maybe” semantics, no return value, no exceptions • Some ORB’s ignores “oneway” and performs a regular synchronized call – but this can be tested • Check ORB vendor manual for recommendations!

  7. Other issues (Henning & Vinoski) • Callback Persistence • Server should store registered callbacks on persistent storage in case of server failure • Callback Failure • As callback objects are transient, server should employ a “timeout” strategy for callback communication • Coupling • Callback objects comes at a price of higher coupling

  8. Alternative solutions • Event Service • Suppliers produces events, consumers receives them through an event channel • Push or Pull model • Decouples using Mediator pattern & asynchronous communication, and exchanging “Any values” • Read more in OOMI-3: chapter 12 • Notifcation Service • Extends the Event Service • Allows the use of well-defined data structures • http://www.borland.com/resources/en/pdf/white_papers/borland_notification_service_visinotify.pdf

  9. Good support for the Event Service & Notifcation Service Source: http://www.puder.org/corba/matrix/

  10. Group Assignment 1 • Use the rest of todays lesson for group work • Each Group Should: • Make a pseudo code implementation of a multi-client GPS location system, where each client logs its current location with a “configurable interval”, records it with a single CORBA servant, including its own ID and the “current interval setting” and the local time of the device, while at the same time keeping up to date with the other clients current GPS position utilizing callbacks • Consider which patterns might be helpful? • Consider what might happen if you implement an xml file on the server for storage. What might go wrong? • Discuss how your system might deadlock – and discuss what you could do about it • REMEMBER: theres a page 2 here? (see next slide)

  11. Group Assignment 2 • Now consider how we might optimize performance, in the case of some clients being located within the same WiFi LAN area, but the server is only available via WAN. Consider also that different groups of clients might be within different WiFi LANs. • At home: • try to implement a sample CORBA system (e.g. the above) that will deadlock at some point in time (and explain why) • Implement a fix to the above CORBA system that will solve the deadlock – and explain why

  12. CORBA er velegnet Til at lave Callbacks Og dermed Observer pattern. Det er ikke alle Middlewares der er det. Læringsmål Alignment Når kurset er færdigt forventes den studerende at kunne: • Definere, beskrive og sammenligne forskellige typer af objektorienterede middleware frameworks til apparater og computere, med primær fokus på CORBA og sekundært .NET Remoting teknologierne, herunder fordele og ulemper forbundet med de forskellige teknologier • Definere og beskrive principper omkring transparens og heterogenitet i relation til middlewareteknologier • Definere og beskrive gængse teorier, metoder og retningslinier indenfor det objektorienterede middleware paradigme og anvende disse til at designe effektive distribuerede systemer • Designe og konstruere et distribueret system der gør brug af CORBA og .NET Remoting teknologierne med tilhørende værktøjssupport CORBA er mere access trans end mange andre fsva Callbacks Væsentligt at forstå Callback / Observer Mekasismen som design Instrument. MANGLER: hvordan I praktisk omsætter denne viden. Fås ved projekt.

More Related