Time-Independent Invocation(TII) and Interoperable Routing

Transkript

1 Time-Independent Invocation(TII) and Interoperable Routing Presentert av: Henning Kulander Eivind Mork Erlend Garberg

2 Introduksjon TII er en teknikk som muliggjør at forespørsler kan leve i nettet uten at klienten er tilkoblet. Utvider CORBA med Store-and-Forward funksjonalitet. En utvidelse av AMI.

3 Bakgrunn De tidligste CORBA-systemene baserte seg på synkron kommunikasjon. Eneste mulighet for asynkron kommunikasjon var oneway-kall og Deferred synchronous-kall. Problemene med disse var at man enten mangler garantier, eller at de vanskelige å bruke i applikasjonene.

4 Bakgrunn (2) Synkrone kall

5 Bakgrunn(3) Messaging spec Muliggjør applikasjoner med asynkrone metodekall. I tillegg kan man bruke tidsuavhengige metodekall, som vil si at et asynkront kall kan få svar også i en annen kjøring eller etter eventuelle nettavbrudd.

6 Bakgrunn(4) - TII 1. Forespørsel fra klient. 2. Ruter sender forespørsel videre til enderuteren. 3. Ruteren sender forespørselen til målobjektet. 4. Målobjektet behandler forespørselen. 5. Svar sendes tilbake til enderuteren. 6. Svaret sendes til klientruteren. 7. Applikasjonen mottar svaret.

7 AMI (Asynchronous method invocation) Nytt i CORBA Messaging Asynkronitet fører til mindre komplekse programmer, fordi man slipper å ha tråder. Med CORBA AMI slipper man å bruke one-way operasjoner som workaround. Tilbyr to modeller for asynkron metodeinvokering, Polling og Callback.

8 AMI(2) - Polling Ved metodekall får du et Pollerobjekt i retur. Klienten kan bruke pollerobjektet til å sjekke om det har kommet svar fra serveren, og også eventuelt blokkere i påvente av dette.

9 AMI(3) - Callback Her sendes en ReplyHandler som parameter i metodekallet. Når serveren sender svar blir det sendt som en forespørsel til ReplyHandleren. Mer effektiv, men gir økt kompleksitet i klienten.

10 Motivasjon for TII Mulighet for å køe opp meldinger når du ikke er online. Forespørselen vil ikke dø mens maskinen er avslått eller offline. Klient- og tjenerobjektet trenger ikke å endres for å ta i bruk TII. Interoperable Routing muliggjør forespørsler til maskiner du ikke har direkte tilgang til. (For eksempel bak en brannvegg)

11 Grunnleggende om TII Er essensielt en spesialisering av AMI. Brukes av applikasjoner som krever garantert levering av forespørsler selv om klient eller tjener midlertidig er avkoblet nettet. Sendes gjennom et nettverk av rutere fra klient til tjener. (Som SMTP i epost) Forespørslene kan lagres i ruterne, selv om klient og/eller tjener går ned.

12 TII i en aksjeapplikasjon Applikasjonen brukes til å kjøpe aksjer og hente aksjekurser over et WAN. Applikasjonen kjører på en laptop, som ikke alltid er oppkoblet mot nettet. Brukeren skal kunne bruke applikasjonen sømløst, selv om maskinen ikke er på nett. Dette nødvendiggjør bruk av TII, som bufrer forespørsler og svar i ruterne. Legg merke til at det finnes en ruter i CORBAmellomvaren på laptopen.

13 TII 1 Initiell forespørsel 1. Bruker klikker kjøp-knapp i GUI. 2. Applikasjonens ORB prøver å sende forespørselen direkte til server gjennom AMI. 1. Hvis maskinen er på nett, vil ORBen sende forespørselen og motta svar. 2. I vårt tilfelle vil dette feile, da maskinen ikke er på nett.

14 TII 2 Valg av ruter 1. Siden bruk av AMI feilet, leter klient-orben etter en ruter som kan behandle forespørselen. 1. Hvordan ORBen finner ruteren er implementasjonsspesifikt, for eksempel kan den lokale CORBA-ruteren brukes. 2. CORBA-ruteren identifiseres med en vanlig CORBA objektreferanse, siden den implementerer standard CORBA Messaging IDL.

15 TII 3 Sending av forespørsel Sendingen av forespørselen kan skje ved to ulike modeller, avhengig om du har valgt Callback eller Polling i klienten. Dersom klienten bruker Callbacks, benytter ORBen Router-interfacet til MessageRoutermodulen, dersom klienten bruker Polling, benyttes PersistentRequestRouter-interfacet i stedet.

16 TII 3 Callbacks module MessageRouting { struct RequestInfo { /* described below */ }; typedef sequence<requestinfo> RequestInfoSeq; interface Router { // Send one request to a server. void send_request (in RequestInfo req); // Send multiple requests to a server. void send_multiple_requests (in RequestInfoSeq req_seq); }; };

17 TII 3 Callbacks (2) Ved Callbacks brukes Router-interfacet når man sender meldinger. Interfacet bruker send_request() til å sende en forespørsel, og send_multiple_requests() for å sende flere. Som parameter(e) sendes en eller flere RequestInfo-structer. RequestInfo-structen inneholder informasjon ruteren bruker til å sende forespørselen.

18 TII 3 Callbacks (3) module MessageRouter { interface Router; // Defined above typedef sequence<router> RouterList; struct RequestInfo { // List of routers visited thus far. RouterList visited; // List of routers remaining to visit. RouterList to_visit; // Object we re invoking our request upon. Object target; }; // Index of IOR profile being used to send // this request. unsigned short profile_index; // Location where the reply should return to. ReplyDestination reply_destination; // Quality of service parameters. Messaging::PolicyValueSeq selected_qos; // Contents of the message. RequestMessage payload;

19 TII 3 Callbacks (4) module MessageRouting { enum ReplyDisposition { TYPED, UNTYPED }; struct ReplyDestination { ReplyDisposition handler_type; Messaging::ReplyHandler handler; sequence<string> typed_excep_holder_repids; }; }; For å bruke en applikasjonsspesifikk ReplyHandler, settes handler_type feltet til TYPED av klient-orben. UNTYPED feltet brukes mellom rutere, siden de ikke kan vite om datatypene til operasjonene.

20 TII 3 Polling module MessageRouting { //... RequestInfo og Router som vist tidligere. // Forward declaration. interface PersistentRequest; interface PersistentRequestRouter { PersistentRequest create_persistent_request(in unsigned short profile_index, in RouterList to_visit, in Object target, in CORBA::PolicyList current_qos, in RequestMessage payload); }; };

21 TII 3 Polling (2) Ved Polling brukes PersistentRequestRouterinterfacet når man sender meldinger. Interfacet bruker create_persistent_request() til å sende en forespørsel, og får tilbake et PersistentRequest objekt, som klient-orben kan bruke til å sjekke om det har kommet svar og eventuelt hente svaret.

22 TII 3 Polling(3) module MessageRouting { interface PersistentRequest { readonly attribute boolean reply_available; GIOP::ReplyStatus get_reply(in boolean blocking, in unsigned long timeout, out MessageBody reply_body) raises (ReplyNotAvailable); attribute Messaging::ReplyHandler associated_handler; }; };

23 TII 3 Polling (4) PersistentRequestobjektet som returneres av create_persistent_request() implementeres av ruteren selv, og brukes av klient-orben til å sjekke etter tilgjengelig svar med reply_available() og å hente svaret med get_reply(). Attributtet associated_handler er nil dersom klienten bruker polling. Klienten kan skifte fra polling til callback ved å la associated_handler peke på en ReplyHandler som kan ta imot svaret.

24 TII 3 Polling (5) module MessageRouting { interface UntypedReplyHandler : Messaging::ReplyHandler { void reply(in string operation_name, in GIOP::ReplyStatus reply_type, in MessageBody reply_body); }; }; Dersom klienten bruker Polling-modellen, etablerer ruteren seg som reply target ved å implementere UntypedReplyHandler interfacet. Målobjektet sender svaret til ruteren gjennom dette interfacet.

25 TII 4 Målruteren Forespørselen ender opp i en ruter som kan kontakte målobjektet. Denne ruteren fungerer som en proxy for klienten. Forespørselen fra ruteren til objektet skjer synkront, som for en vanlig forespørsel.

26 TII 5 Behandling av svar Målruteren omgjør svaret til en forespørsel, enten ved å kalle en annen ruters send_request() eller ved å kontakte ReplyHandler-objektet direkte. Vitsen med å ikke levere direkte, er at ruteren ikke nødvendigvis har direkte tilgang til ReplyHandler-objektet, for eksempel pga en brannmur.

27 Konklusjon TII er en spesialisering av AMI som støtter Store-and-forward semantikken. TII-forespørsler kan overleve klientprosessen, noe som betyr at svaret kan bli behandlet av en helt annen applikasjon. TII krever ingen endringer i allerede eksisterende klient- og tjenerobjekter som bruker AMI.