For english below
Podczas laboratorium należy zbudować mały rozproszony system wykorzystując technologię RMI. W skład tego systemu mają wejść instancje klas uruchamiane równolegle (na jednym lub na kilku różnych komputerach). System powinien umożliwić zasymulowanie działania klubów poszukiwaczy skarbów. Jego architekturę przedstawiono na rysunku poniżej.
Specyfikacja problemu: W systemie wykorzystywany będzie następujący model danych: Map - Mapa, reprezentowana przez kwadrat składający się z 64 (8x8) sektorów oznaczonych jak pola na szachownicy (dolny lewy to sektor A1, prawy górny to sektor H8). Każdy sektor to kwadrat składający się ze 100 (10x10) pól oznaczonych podobnie jak sektory (dolne lewe to pole A1, górne prawe to pole J10). Na polach sektorów Mapy mogą pojawić się Artefakty. Sektory mogą być przeszykiwane przez członków Klubów, przy czym na ich przeszukiwanie Klub powinien mieć aktywne zezwolenie. Artifact - klasa reprezentująca Artefakt mogący pojawić się na Mapie. Artefakt może być Skarbem, Rupieciem lub Pustką. Wydobycie artefaktu zajmuje jakiś czas (ma ty być zasymulowane poprzez uśpienie wątku na czas określony w przekazanych danych). Trasure - Skarb, coś wartościowego, podlegającego kategoryzacji. Junk - Rupieć, coś bezwartościowego, podlegającego kategoryzacji. Blank - Pustka. Elementami systemu będą: OfficeApp - aplikacja reprezentująca urząd wydający pozwolenia na prowadzenie prac poszukiwawczych oraz monitorujący wyniki tych prac. Implementuje interfejs zdalny IOffice. Dostarcza graficzny interfejs, na którym widać Mapę z zakresem prowadzonych prac i ich wynikami (na odpowiednich polach pokazywane mają być znalezione Skarby oraz aktualnie zajmowane sektory przez Kluby). Sposób prezentacji informacji na tym interfejsie jest dowolny. Na przykład każdemu klubowi można przypisać inny kolor czcionki, a potem symbolami literowymi oznaczać raportowane wyniki poszukiwań. W systemie będzie istnieć tylko jedna instancja OfficeApp. ClubApp - aplikacja reprezentująca Klub zrzeszający poszukiwaczy. Implementuje interfejs zdalny IClub. Dostarcza graficzny interfejs, na którym widać stan prac prowadzony przez należących do klubu Poszukiwaczy w aktualnie obsługiwanych sektorach (pokazywane mają być wszystkie artefakty znalezione przez poszukiwaczy danego klubu wraz z położeniem tych poszukiwaczy oraz zaznaczeniem aktywnych sektorów przypisanych Klubowi). Klub powinien wiedzieć, gdzie działa rejestr RMI z zarejestrowaną namiastką Urzędu. Korzysta z tej namiastki, by zarejestrować się w Urzędzie. Korzystając z namiastki urzędu Klub występuje również o pozwolenie na prowadzenie prac poszukiwawczych w danym sektorze. Każdy klub może prowadzić równolegle prace w co najwyżej dwóch sektorach. Klub, z zadaną częstością, raportuje wyniki poszukiwań do Urzędu (wyniki te wcześniej muszą być zaraportowane w Klubie przez poszukiwaczy, przy czym poszukiwacze raportują klubowi wszystkie znaleziska, zaś klub raportuje urzędowi tylko znalezione Skarby), jak również sygnalizuje Urzędowi zakończenie poszukiwań w danym sektorze. W systemie może istnieć kilka instancji ClubApp. SeekerApp - aplikacja reprezentująca Poszukiwacza, który po zarejestrowaniu się w klubie może prowadzić prace w ramach pozwolenia wydanego klubowi. Implementuje interfejs zdalny ISeeker. Poszukiwacz powinien wiedzieć, gdzie działa rejestr RMI z zarejestrowaną namiastką Urzędu. Korzysta z tej namiastki, by pozyskać listę namiastek klubów i ostatecznie do któregoś z tych klubów się zapisać/wypisać. Poszukiwacz musi wiedzieć również, gdzie działa rejestr RMI z zarejestrowaną namiastką Świata, by ją pobrać i z niej korzystać. Poszukiwacz dostaje zlecenia z Klubu na eksplorację danego pola w danym sektorze. Eksploracja następuje poprzez komunikację ze Światem. W systemie może istnieć wiele instancji SeekerApp . WorldApp - aplikacja reprezentująca fizyczny Świat. Implementuje interfejs IWorld. Posiada własną Mapę, którą można skonfigurować, tj. umieścić na jej polach jakieś artefakty. Sposób konfiguracji jest dowolny - można Mapę wczytywać w pliku tekstowego (edytowanego jakimś edytorem tekstów), można też dostarczyć graficzny interfejs (pozwalający na edycję mapy w aplikacji). Pod tym względem pozostawiona jest dowolność. Mapa z biegiem czasu będzie podlegać zmianom (znikać z niej będą Artefakty odnajdowane przez Poszukiwaczy). Aktualna mapa powinna być wizualizowana na interfejsie graficznym (tutaj mają być prezentowane tylko artefakty jeszcze nieodkryte, bez Poszukiwaczy ani sektorów zajętych przez Kluby). W systemie istnieje tylko jedna instancja WorldApp. W trakcie implementacji należy wykorzystać skompilowane klasy z dostarczonego modułu treasures.jar. Proszę zajrzeć do kodu źródłowego, który również jest zamieszczony w module, by poznać detale klas.
During the lab, build a small distributed system using RMI technology. This system is to include instances of classes running in parallel (on one or more different computers). The system should make it possible to simulate the operation of treasure hunting clubs. Its architecture is shown in the figure below.
Problem specification: The system will use the following data model: Map - A map, represented by a square consisting of 64 (8x8) sectors labelled like boxes on a chessboard (the bottom left is sector A1, the top right is sector H8). Each sector is a square made up of 100 (10x10) fields labelled like sectors (bottom left is field A1, top right is field J10). Artefacts may appear in the fields of the Map sectors. Sectors may be searched by Club members, with the Club having active permission to search them. Artifact - a class representing an Artifact that may appear on the Map. An Artifact can be a Treasure, Rupee or Void. It takes a certain amount of time to extract an Artifact (you are supposed to be simulated by putting a thread to sleep for a time specified in the data provided). Trasure - Treasure, something of value, subject to categorisation. Junk - Junk, something worthless, subject to categorisation. Blank - Void. The elements of the system will be: OfficeApp - an application representing the office that issues permits for exploration work and monitors the results of that work. It implements the IOffice remote interface. Provides a graphical interface that shows a Map with the scope of the work carried out and its results (the relevant fields are to show the Treasures found and the sectors currently occupied by the Clubs). The way the information is presented on this interface is arbitrary. For example, each Club can be assigned a different font colour and then letter symbols can be used to denote the reported search results. Only one instance of the OfficeApp will exist in the system. ClubApp - the application that represents the club associating searchers. It implements the IClub remote interface. Provides a graphical interface that shows the status of the work carried out by the club's member Prospectors in the currently operated sectors (all the artefacts found by the Prospectors of a club are to be shown, together with the location of these Prospectors and the indication of the active sectors assigned to the Club). The Club should be aware of where the RMI register is operating with a registered surrogate for the Authority. It uses this surrogate to register with the Authority. Using the Authority's surrogate, the Club also applies for permission to carry out prospecting work in a particular sector. Each club may carry out concurrent work in a maximum of two sectors. The Club, at a set frequency, reports the results of the prospecting to the Authority (these results must first be reported to the Club by the prospectors, with the prospectors reporting all finds to the Club and the Club reporting only the Treasures found to the Authority), as well as signalling to the Authority the end of the prospecting in a given sector. There can be several instances of the ClubApp in the system. SeekerApp - an application that represents the Seeker who, once registered with the club, can carry out work under a permit issued to the club. It implements the ISeeker remote interface. The Seeker should know where the RMI registry with a registered Authority surrogate is operating. He/she uses this surrogate to obtain a list of surrogate clubs and eventually to enrol/subscribe to one of these clubs. The seeker also needs to know where the RMI register with the registered surrogate of the World operates in order to download and use it. The Seeker gets orders from the Club to explore a given field in a given sector. The exploration is done by communicating with the World. There can be multiple instances of SeekerApp in the system. WorldApp - an application representing the physical World. It implements the IWorld interface. It has its own Map, which can be configured, i.e. put some artefacts on its fields. The method of configuration is arbitrary - the Map can be loaded in a text file (edited with some text editor), or a graphical interface can be provided (allowing the Map to be edited in the application). In this respect, there is freedom. The map will be subject to changes over time (Artefacts found by Explorers will disappear from it). The current map should be visualised on the graphical interface (only artefacts not yet discovered are to be presented here, with no Seekers or sectors occupied by Clubs). There is only one instance of the WorldApp in the system. During implementation, use the compiled classes from the provided treasures.jar module. Please take a look at the source code, which is also included in the module, for details of the classes.