1 / 20

Wyszukiwanie i odzyskiwanie

Wyszukiwanie i odzyskiwanie. informacji o obiectach. CORB'a. Wstęp. W ostatnim okresie jesteśmy świadkami ogromnemu postępowi w technologiach rozproszonych systemów informatycznych a co za tym idzie rozproszenie danych. Rozproszenie systemów powoduje ich heterogeniczność, która bierze

selene
Télécharger la présentation

Wyszukiwanie i odzyskiwanie

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. Wyszukiwanie i odzyskiwanie informacji o obiectach CORB'a

  2. Wstęp W ostatnim okresie jesteśmy świadkami ogromnemu postępowi w technologiach rozproszonych systemów informatycznych a co za tym idzie rozproszenie danych. Rozproszenie systemów powoduje ich heterogeniczność, która bierze się z mnogości rozwiązań systemowych i sprzętowych. Wyjściem z tej jakże trudnej sytuacji może być rozproszona obiektowa technologia umożliwiająca tworzenie obiektów, które są samodzielnymi jednostkami o sprecyzowanej funkcjonalności dzięki czemu mogą być używane w wielu różnych aplikacjach. Podejście obiektowe do problemu ułatwia i przyśpiesza tworzenie aplikacji.

  3. CORBA - wybór standardu . . . Podejmując temat rozproszonego programowania oczywistym wyborem był standard CORBA, gdyż zetknąłem się z nim teoretycznie na zajęciach w PJWSTK. OMG CORBA jest specyfikacją ułatwiającą tworzenie obiektowych systemów rozproszonych. Podstawową jej cechą jest komunikacja pomiędzy rozproszonymi w sieci obiektami bez ingerencji w tajniki implementacji rozproszonych systemów.

  4. Obiekty aplikacji Object Request Broker Corba Services CORBA Facilities Architektura CORBA

  5. Rdzeniem systemu jest ORB. Pozwala na definiowanie obiektów i komunikację ich w rozproszonym środowisku. Obiekty aplikacji to te, które implementują interfejsy IDL zdefiniowane przez twórcę aplikacji. Obiekty te komunikują się z innymi przy pomocy ORB korzystając z usług CORBA Services i CORBA Facilities. CORBA Services i CORBA Facilities są obiektami standardu CORBA i dostarczają aplikacjom rozproszonym wielu użytecznych usług.

  6. Motywacja . . . Wybór tej pracy magisterskiej jest podyktowany rosnącym zainteresowaniem rynku pracy na inżynierię oprogramowania rozproszonego. Programowanie rozproszone ma wielką przyszłość z uwagi na łatwość i szybkość tworzenia nowego oprogramowania. Ta praca magisterska w dziedzinie rozproszonych obiektów ma z mojego punktu widzenia pomóc mi dokładnie i szczegółowo poznać to środowisko od podszewki.

  7. Co zyskam . . . • Dzięki tej pracy mam zamiar : • podnieść kwalifikacje analityczne. • Nauczyć się poprawnej analizy problemu i postawionych zadań do zrealizowania. • Opanować tworzenie dokumentacji. • Zapoznać się w praktyce z tworzeniem systemów rozproszonych. • Opanować szacowanie czasu potrzebnego na poszczególne etapy pracy magisterskiej.

  8. Cel pracy . . . Celem moje pracy magisterskiej jest wytworzenie narzędzia dla osób posługujących się technologią CORBA/IIOP. Ma ona na celu wyszukiwania odległych obiektów oraz odzyskiwanie informacji o obiektach. Przyszłe wykorzystanie aplikacji może być wykorzystywane jako rodzaj HELP’u dla piszących programy w środowisku rozproszonym.

  9. Przydatność . . . Skorzystać z tej pracy będą mogli programiści, którzy za pomocą tego narzędzia w łatwy sposób odnajdą konkretne obiekty w systemie rozproszonym, dowiedzą się o ich własnościach. Będą mogli w prosty sposób z niego skorzystać. Dzięki wykorzystaniu pulpitu graficznego do reprezentowania wiedzy o obiektach system będzie prosty w obsłudze i nie będzie stwarzał problemów w jego zrozumieniu. Jednym z moich drugorzędnych celów będzie tez optymalizacja wyświetlanej informacji na pulpicie poszczególnych ekranów.

  10. Potrzebna teoria . . . • Ważną rolę w pisaniu tej pracy będą solidne podstawy • teoretyczne, które zdobywam poprzez WWW. • Teoria moja będzie wspierana o wiedzę z książek, które zamówił • mój zakład pracy. Tytuły, do których będę miał dostęp to: • CORBA 3 Fundamentals and Programming 2nd Ed. Pana • Siegel J. • Client/Server Programming With Java and CORBA, 2nd Ed. • Panów Orfali R., D. Harkey • Zagadnienia standardu CORBA będę poznawał też podczs • wdrażania nowego systemu billingowego w zakładzie pracy w • czym chcę czynnie brać udział.

  11. implementacja . . . Głównym trzonem pracy będzie produkt JavaORB, w którym zaimplementowany jest standard CORBA 2.3.1( wersja standardu może się zmienić na wyższą gdyż trudno przewidzieć kiedy pojawi się nowa wersja i w jakie dodatkowe cechy będzie standard wyposażony a chciałbym aby przy obronie praca była jak najbardziej nowoczesna ) . Produkt ten zawiera całkowity standard CORBA i jest zaimplementowany w języku Java (co ułatwi zrozumienie mechanizmów CORBY oraz ułatwi pisanie pracy, gdyż ta będzie implementowana też w języku JAVA) i co ciekawsze jest darmowy dla komercyjnych i nie komercyjnych produktów.

  12. Pakiet JavaORB zawiera najważniejsze cechy CORB’y tj.: • serwis kolekcji - dostarcza w prosty sposób zarządzanie grupami • obiektów. • Serwis wyjątków - zapewnia obsłużenie wyjątków pojawiających się • w komunikacji pomiędzy obiektami CORB’y. Obiekty mogą • wymieniać między sobą wyjątki poprzez specjalny kanał wyjątków. • Serwis nazwowy - jest bazą danych przechowującą referencje do • obiektów. Każda taka referencja jest skojarzona z pewną • abstrakcyjną nazwą nadaną przez użytkownika. Struktura takiej bazy • danych jest strukturą drzewiastą. Przechowującą strukturę obiektów.

  13. Persistent State Service - serwis dostarczający prostych metod do • stworzenia trwałych (persitance) aplikacji opartych o CORBA. • Property Service - umozliwia łatwo rozbudować obiekt w czasie • jego działania. • Security Service - zabezpiecza dostęp do obiektów CORBA. • Dostarcza sposoby autentykacji osób w stosunku do obiektów. • Trading Service - baza danych umożliwiająca klientom • wyszukanie informacji o usługach jakie są dostarczane przez dany • obiekt przy specyfikacji złożonych wymagań. Udzielone • informacje przez ten serwis klient może wybrać konkretnego • dostawcę usługi.

  14. Transaction service - udostępnia usługi zarządzania kontrolą • procesów, dając stabilny system odwracania transakcji • obiektowych.

  15. Aplikacja będzie zasilana danymi z sieci internet jak i sieci LAN. Do optymalizacji przy wyszukiwaniu obiektów użyję małej relacyjnej bazy opartej o plik ACCESSa, który też będzie służył jako słownik przy prezentacji graficznej aplikacji na ekranie. Do zaimplementowania całego systemu jako języka programowania posłużę się językiem Java.

  16. Kompilator Flicj IDL– kompilator języka IDL. Zawiera zaawansowane mechanizmy optymalizacji. Wiedzę o tym kompilatorze zaczerpnąłem ze stron WWW o tematyce rozproszonych obiektów. Jest to darmowy kompilator i ogólnie dostępny poprzez WWW.

  17. Merytoryka planu pracy . . . • Analiza problemu pod względem założeń do realizacji przez system. • Analiza i wybranie odpowiednich narzędzi do wykonania pracy, • narzędzi spełniające wymagania szybkość działania systemu, • łatwość implementacji. • Rozpoznanie cech i właściwości(w miarę możliwości) narzędzi o • ile jakieś ich funkcje są nam nieznane. • Implementacja systemu. • Opis systemu wraz z opisem technicznym. • Testowanie

  18. harmonogram pracy . . . Czas poświęcony na dogłębne zrozumienie problemu – 2 tygodnie. Koncepcja sformułowania założeń do pracy oraz koncepcja rozwiązania zadania – 1 miesiąc. Tworzenie oprogramowania – 2,5 do 3 miesięcy. Testowanie oprogramowania – 1 tydzień. Opis teoretyczny - od 1 do 2 tygodni. Opis zastosowanych metod i rozwiązań – 1 tydzień. Opis implementacji – 1 tydzień.

  19. Zagrożenia . . . - niewiele czasu zrealizowanie aplikacji. - kłopoty z dostępem do sali projektowej z klientem systemu Windows NT. - kłopoty z tworzeniem kopii zapasowych systemu na uczelni po wprowadzeniu zmian do systemu.

  20. KONIEC.

More Related