Slide 1 of 11 © Ingeniørhøjskolen i Århus Presentation 14: Callbacks Objektorienteret Middleware (TIOOMI)

Præsentationer af emnet: "Slide 1 of 11 © Ingeniørhøjskolen i Århus Presentation 14: Callbacks Objektorienteret Middleware (TIOOMI)"— Præsentationens transcript:

1 Slide 1 of 11 © Ingeniørhøjskolen i Århus Presentation 14: Callbacks Objektorienteret Middleware (TIOOMI)

2 Slide 2 of 11 © Ingeniørhøjskolen i Århus Outline Motivation Using TTS as example CORBA Callbacks Issues & solutions Alternative solutions

3 Slide 3 of 11 © Ingeniørhøjskolen i Århus Data Collection & Presentation Server TRS CORBA Object New Reading DB PSP View Readings Classic CORBA Client / Sever model is sufficient for Data Collection & Presentation

4 Slide 4 of 11 © Ingeniørhøjskolen i Århus Alarm level surveillance Server (TRS) TRS CORBA Object New Reading DB PSP View Readings 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 Present Alarm

5 Slide 5 of 11 © Ingeniørhøjskolen i Århus 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 Slide 6 of 11 © Ingeniørhøjskolen i Århus 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 Slide 7 of 11 © Ingeniørhøjskolen i Århus 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 Slide 8 of 11 © Ingeniørhøjskolen i Århus 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/borla nd_notification_service_visinotify.pdfhttp://www.borland.com/resources/en/pdf/white_papers/borla nd_notification_service_visinotify.pdf

9 Slide 9 of 11 © Ingeniørhøjskolen i Århus Good support for the Event Service & Notifcation Service Source: http://www.puder.org/corba/matrix/

10 Slide 10 of 11 © Ingeniørhøjskolen i Århus 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 Slide 11 of 11 © Ingeniørhøjskolen i Århus 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 Slide 12 of 11 © Ingeniørhøjskolen i Århus 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 velegnet Til at lave Callbacks Og dermed Observer pattern. Det er ikke alle Middlewares der er det. CORBA er velegnet Til at lave Callbacks Og dermed Observer pattern. Det er ikke alle Middlewares der er det. MANGLER: hvordan I praktisk omsætter denne viden. Fås ved projekt. CORBA er mere access trans end mange andre fsva Callbacks CORBA er mere access trans end mange andre fsva Callbacks Væsentligt at forstå Callback / Observer Mekasismen som design Instrument. Væsentligt at forstå Callback / Observer Mekasismen som design Instrument.