INFO
Sylabus
OMG CORBA, cz. 5
1. Usługa nazewnicza
2. Usługa nazewnicza: Wiązanie, rozstrzyganie
3. Usługa nazewnicza: kroki dla uzyskania referencji
4. Usługa handlowa (Trader)
5. Funkcje bazy danych Trader
6. Definicja typu usługi
7. Usługi w zakresie zdarzeń
8. Usługi w zakresie cyklu życiowego
9. Usługi w zakresie trwałych obiektów
10. Usługi w zakresie związków
11. Usługi w zakresie zapytań
12. Bieżące prace OMG
13. Najbardziej znane implementacje CORBA
14. Wady OMG CORBAi
15. Podsumowanie
Skorowidz
Wyście:
Wyklad V. Wprowadzenie do OMG CORBA, część 5 (KURS SSR)
I II III IV V VI VII VIII IX X XI XII XIII XIV
« poprzedni punkt   następny punkt »

6. Definicja typu usługi

Z każdą usługą przechowywaną w bazie danych Trader związany jest typ:
  • typ interfejsu dostarczającego usługę
  • typ właściwości opisujących tę usługę
  • usługa OperacjeBankowe { 
            interfejs :: Finanse :: Bank; 
            obowiązkowa właściwość short ProcentROR; 
            właściwość float MaxWysokośćKredytu; 
            tylko_do_odczytu właściwość boolean GwarancjePaństwowe; 
    };

    Jest to schemat (format) zapisu w bazie danych Trader

    Usługa OperacjeBankowe służy do zapisu informacji o warunkach kredytowania. Taka deklaracja przypomina deklarację schematu tablicy w SQL. Odpowiednio do tego, CORBA definiuje coś w rodzaju języka zapytań (a la SQL, ale znacznie niższego poziomu), przy pomocy którego można wyszukać obiekt (obiekty) spełniające kryteria wyszukiwania.


    7. Usługi w zakresie zdarzeń (Event Service)

    Usługa ustala dwie role obiektów: dostawcy zdarzeń i konsumenta zdarzeń. Komunikacja pomiędzy dostawcą i konsumentem wykorzystuje standardowe zlecenia CORBA

    Dwa modele komunikacji zdarzeń pomiędzy ich dostawcami i konsumentami:
    -pchający (push): dostawcy “pchają” zdarzenia i ich dane do konsumentów

    interface PushConsumer { 
       void push( in any data ) raises(Disconnected); 
       void disconnect_push_consumer(); };
    
    -ciągnący (pull): konsumenci “ciągną” dane zdarzeń od dostawców.

    Np. notowanie aktualizacji obiektu: aktualizowany obiekt działa jako dostawca zdarzenia. Inne relewantne obiekty (np. posiadające wskaźniki do obiektu aktualizowanego) działają jako konsumenci zdarzenia

    W modelu “ciągnącym” konsumenci periodycznie odpytują dostawcę (metoda try_pull) na okoliczność wystąpienia zdarzenia.

    « poprzedni punkt   następny punkt »