VS Praktikum 03 Konzept

Transkript

1 Darstellung der Architektur: Manager VS Praktikum 03 Konzept Account NameServiceServer Geldautomat Filiale Messagearten: Für jede unterschiedliche Message gibt es eine eigene Klasse: Object resolve(string): 1... ResolveMsg 2... ResolveBackMsg rebind(object, String): 3... RebindMsg String createaccount(string) und 4... ReqManMsg ("createaccount", owner) 5... RetManMsg (kontoid) boolean removeaccount(string): 4... ReqManMsg ("removeaccount", kontoid) 5... RetManMsg (true oder false) deposit(double) 6... ReqAccMsg (kontoid, "deposit", amount) withdraw(double) throws OverdraftException 6... ReqAccMsg (kontoid, "withdraw", amount) double getbalance() 6... ReqAccMsg (kontoid, "getbalance") 7... RetAccMsg (Balance)

2 Erklärung der Pakete und deren Klassen: cash_access: Account: Ist die Schnittstelle für das Userinterface Geldautomat und für das Erstellen einer neuen Accountobject -Instanz. Abstrakte Klasse. AccountProxy: Ist abgeleitet von o.g. Account-Klasse. Diese Klasse realisiert die Kommunikation zum AccountSkeleton mithilfe von Nachrichten (selbst erstellt: ReqAccMsg ) über einen eigenen Clienten. Bei einer Resolve-Anfrage über diesen Proxy wird vom NameService Host, Port und das Objekt (Account) zurück an den Geldautomaten geschickt. AccountSkeleton: Leitet die Anfragen an einen AccountWorker weiter, der diese bearbeitet. Das tut er mit einem eigenen Server und wird dort von den AccountProxies benachrichtigt. AccountProxy und AccountSkeleton agieren als Client und Server. branch_access: Manager: Ist lediglich die Schnittstelle zum Userinterface Filiale und zum Erstellen einer Instanz vom Managerobject und ist abstrakt. Abstrakte Klasse.

3 ManagerProxy: Ist abgeleitet von o.g. Manager-Klasse. Diese Klasse realisiert die Kommunikation zum ManagerSkeleton mithilfe von Nachrichten (selbst erstellt: ReqManMsg ) über einen eigenen Clienten. Diese Nachricht kann entweder den String createaccount oder removeaccount beinhalten. Bei einer Resolve-Anfrage über diesen Proxy wird vom NameService auch ein ManagerProxy- Objekt erstellt und zurück an den Geldautomaten geschickt. ManagerSkeleton: Leitet die Anfragen an die Bank weiter. Dort werden diese jeweiligen Anfragen ausgeführt (remove... oder create...). Auch hier wird ein eigener Server verwendet, der von den ManagerProxies angesprochen wird. Auch hier arbeiten Proxy und Skeleton im Client-/Server-Modell. mware_lib: LocalNameService: Erstellt ManagerSkeleton oder AccountSkeleton und reicht Anfragen an den Name ServiceServer weiter (also rebind und resolve) NameService: Ist die Schnittstelle für den Name ServiceServer. ObjectBroker: Stellt den Namensdienst bereit. mware_lib.ns: Data:

4 Beinhaltet nur Daten für die Verbindung zwischen Proxies und Skeletons (Host, Port,..) Name ServiceServer: Steht zentral im Gebilde der Kommunikation. Verwaltet die Daten in denen die Daten zum Aufbau der Kommunikation stehen. Schickt bei Anfragen passende Data zurück, wenn diese vorhanden ist. mware_lib.communication Client: Stellt ein Socket für die Verbindung zum Server bereit. Gesendet wird über einen ObjectStream. ObjectStream: Erstellt Objekt-In- und Objekt-Out-Stream aus In- und Out-Streams und verpackt diese in ein Objekt. Server: Stellt das Serversocket und akzeptiert dort Anfragen von Clients. Auch hier wird mit einem ObjectStream gearbeitet. mware_lib.messages: Enthält die Klassen für die selbst erstellten Nachrichten. mware_lib.exceptions: Enthält die eigenen Exceptions um Fehler über diese darzustellen.

5 Das Klassendiagramm (ohne Kommunikations-, Exception- und Nachrichtenpackages):

6 Proxyerstellung: Wird vom lokalen Namensdienst (LocalNameService) ein resolve aufgerufen, schickt dieser eine ResolveMsg an den Name ServiceServer. Wenn ein rebind von dem gewünschten Account oder Manager vorausgegangen ist, erhält der LocalNameService eine ResolveBackMsg. Diese enthält den Port und den Host von Account bzw. Manager. Damit kann er nun einen entsprechenden Proxy erstellen. Das erstellte Proxy-Objekt ist dann die Rückgabe der resolve-methode und ist von eine der beiden abstrakten Klassen (Account, Manager) abgeleitet. Fehlerbehandlung: Die eigens erstellten Exceptions werden zur obersten Eben durchgereicht und dort gefangen. Zum Einsatz kommen hier z.b.: IllegalParameterException: gibt bei Zugriff auf nicht vorhandene Bank oder Konto den erwarteten und den zurückgegebenen Parameter zurück. IllegalMessageException: gibt bei einer falschen Message die erwartete und die zurückgegebene Message zurück. RemoteException: gibt bei einem Zugriff auf ein RemoteObjekt das nicht verfügbar ist, z.b. der Server der durch einen Client kontaktiert werden soll, entweder nur eine Nachricht oder eine Nachricht und die ursprüngliche Exception weiter. UnknownMethodException: gibt bei Angabe einer falschen Methode eine Nachricht über die falsche Angabe zurück. OverdraftException: enthält eine Message die bei drohender Überziehung des Kontos ausgegeben wird. Verteilung: Da die Middleware über Host und Port angesprochen wird, funktioniert diese auch bei Verteilung der Packages gemäß Aufgabenstellung.

7 Die Kommunikation in einem Sequenzdiagramm für rebind und resolve: