# VS Projekt
https://app.diagrams.net/#G19jjOEpCgqWyVCJkqhk2i1cQt_esM021v
http://edu.i4c.at/lab/vs/trading/index.html
https://edu.dedisys.org/cgit/ds-finance-bank_csdc21vz_05.git
## Projekt - Teil 1
### Architektur des Gesamtsystems inkl. Spezifikation der Funktionen, die von den einzelnen Teilen zur Verfügung gestellt werden. Ordnen Sie dabei die von Ihnen zu erstellenden Artefakte in einem Architekturdiagramm der Java Enterprise Architektur zu.
Java EE, ist die Spezifikation einer Softwarearchitektur für die **transaktionsbasierte** Ausführung von in Java programmierten Anwendungen bzw Webanwendungen. Die Spezifikation dient dazu, einen allgemein akzeptierten Rahmen zur Verfügung zu stellen, um auf dessen Basis aus modularen Komponenten verteilte, mehrschichtige Anwendungen entwickeln zu können.
:::warning
**Presentation Tier**
#### Der clientseitige Zugriff auf eine Java-EE-Anwendung erfolgt oft über einen **Browser**, daneben sind aber auch **Applikations-Clients** (Java-Applikationen, CORBA-Komponenten, Webservice-Clients) verbreitet.
:::
:::success
**Logic Tier**
#### Java-EE-Komponenten erfordern als Laufzeitumgebung eine spezielle **Infrastruktur**, einen sogenannten **Java EE Application Server**. Dieser Server stellt technische Infrastruktur zur Verfügung bereit, wie:
* Sicherheit (Security),
* Transaktionsmanagement,
* Namens- und Verzeichnisdienste,
* Kommunikation zwischen Java-EE-Komponenten,
* Persistenzdienste zum langfristigen Speichern von Java-Objekten,
* Management der Komponenten über den gesamten Lebenszyklus (inklusive Instanziierung),
* Unterstützung für die Installation (Deployment)
#### Ein Java-EE-Server wird in diverse logische Systeme unterteilt. Diese werden Container genannt. Die aktuelle Spezifikation erfordert die folgenden Container:
* einen **EJB-Container** als Laufzeitumgebung für Enterprise JavaBeans
* einen **Web-Container** als Laufzeitumgebung für Servlets und JavaServer Pages (JSP)
* einen **JMS-Provider** als Verwaltungssystem für Nachrichtenwarteschlangen.
#### Es sind zahlreiche Implementierungen für Java-EE-Server verfügbar, teils in Form frei verfügbarer **Open-Source-Lösungen z.B. *WildFly***.

:::
:::info
**Data Tier**
#### Als weitere Infrastrukturkomponente kommt für die persistente Speicherung von Daten ein Datenbankmanagementsystem (DBMS) zum Einsatz. Hierbei kann es sich um ein relationales System handeln, oder aber auch um ein vergleichbares System wie beispielsweise ein OODBMS. Die Anbindung der Datenbankmanagementsysteme erfolgt meist über einen JDBC-Treiber.
:::

:::danger
**Die Java-EE-APIs beinhalten verschiedene Technologien, die die Funktionalität des Basis-Java-SE-APIs erweitern bzw. ersetzen.**
:::
#### Enterprise JavaBeans (EJB)
* beinhalten die **Geschäftslogik** einer Enterprise-Anwendung oder **gestatten Zugriff auf persistente Daten**.
* Jeder Bean-Typ erfüllt einen Zweck und kann eine bestimmte Teilmenge von EJB-Diensten verwenden. Der eigentliche Zweck von Beans besteht darin, sie vor Überlastung mit drahtübergreifenden Diensten zu schützen.
* Session Beans und Message Driven Beans (MDBs) werden zum Erstellen von Geschäftslogik verwendet und befinden sich im Container, der diese Beans verwaltet und ihnen Dienste bereitstellt.
* Entities werden verwendet, um den Persistenzteil einer Anwendung zu modellieren. Wie der Container ist es der Persistence Provider, der Entitäten verwaltet. Ein Persistence Provider ist innerhalb des Containers steckbar und wird hinter der Java Persistence API (JPA) abstrahiert.

* Die Beans laufen in einem EJB-Container ab. Es gibt drei unterschiedliche Typen von EJBs:
* ***Session-Beans***, sowohl zustandsbehaftet als auch zustandslos, implementieren die Geschäftslogik und sind meistens vom Client zugreifbar. Eine Session Bean kann entweder lokal oder remote mit Java RMI aufgerufen werden. Eine zustandslose Session-Bean kann als Webdienst verfügbar gemacht werden.
* SB wird von einem Client aufgerufen, um einen bestimmten Geschäftsvorgang auszuführen, z. B. um die Bonitätshistorie für einen Kunden zu überprüfen.
* Der Name "Session" impliziert, dass eine Bean-Instanz für die Dauer einer "Arbeitseinheit" verfügbar ist und einen Serverabsturz oder das Herunterfahren nicht überlebt. Ein Session Bean kann jede Anwendungslogikfunktionalität modellieren.
* Ein Stateful Session Bean speichert automatisch den Bean-Status zwischen Clientaufrufen, ohne dass man zusätzlichen Code schreiben muss. Ein typisches Beispiel für einen zustandsbewussten Prozess ist der Warenkorb für einen Web-Händler wie Amazon.
* Stateless Session Beans verwalten keine Status- und Modellanwendungsdienste, die in einem einzelnen Clientaufruf ausgeführt werden können. Man kann zustandslose Session-Beans erstellen, um Geschäftsprozesse wie das Aufladen einer Kreditkarte oder das Überprüfen des Kundenkreditverlaufs zu implementieren.
* ***Message-Driven-Beans***, kurz MDB, für die Verarbeitung von JMS-Nachrichten
* Wie SB verarbeiten MDBs Geschäftslogik. Clients rufen MDB-Methoden jedoch niemals direkt auf. Stattdessen werden MDBs durch Nachrichten ausgelöst, die an einen Nachrichtenserver gesendet werden, wodurch asynchrone Nachrichten zwischen Systemkomponenten gesendet werden können.
* MDBs werden normalerweise für eine robuste Systemintegration oder asynchrone Verarbeitung verwendet. Ein Beispiel für Messaging ist das Senden einer Bestandsauffüllungsanforderung von einem automatisierten Einzelhandelssystem an ein Supply-Chain-Management-System.
* ***Entity-Beans*** für die Abbildung von persistenten Datenobjekten
* Persistenz ist die Fähigkeit, Daten in Java-Objekten automatisch in einer relationalen Datenbank wie Oracle oder SQL Server zu speichern
* Die Persistenz in EJB 3 wird von der JPA verwaltet. Es speichert die Java-Objekte automatisch mithilfe einer Technik, die als objektrelationales Mapping (ORM) bezeichnet wird. ORM ist im Wesentlichen der Prozess der Zuordnung von Daten in Java-Objekten zu Datenbanktabellen mithilfe der Konfiguration.
[Quelle](http://what-when-how.com/enterprise-javabeans-3/understanding-ejb-types/)
#### Java Servlet
* Als Servlets bezeichnet man Java-Klassen, deren Instanzen innerhalb eines Webservers Anfragen von Clients entgegennehmen und beantworten. Der Inhalt der Antworten kann dabei dynamisch, also im Moment der Anfrage, erstellt werden und muss nicht bereits statisch (etwa in Form einer HTML-Seite) für den Webserver verfügbar sein.
* Java Servlet erlaubt die **Erweiterung von Servern**, deren Protokoll auf Anfragen und Antworten basiert. Primär werden Servlets im Zusammenhang mit dem Hypertext Transfer Protocol (HTTP) verwendet, wo sie in einem **Web-Container** leben und Anfragen von Webbrowsern beantworten.
#### JavaServer Pages (JSP)
* sind Textdokumente, die zum einen aus **statischem** Text und zum anderen aus **dynamischen** Textelementen – den JSP-Elementen – bestehen. Die JSP-Seiten werden transparent vom Web-Container in ein **Servlet umgewandelt**.
#### Webservices (WS)
* definieren **Schnittstellen zu EJBs**, die mit einem Uniform Resource Identifier (URI) eindeutig identifizierbar sind und deren Schnittstellen als XML-Artefakte definiert, beschrieben und gefunden werden können.
#### Java Message Service (JMS)
* ist eine API für die Ansteuerung einer Message Oriented Middleware (MOM) zum **Senden und Empfangen von Nachrichten** aus einem Client heraus, der in der Programmiersprache Java geschrieben ist. JMS hat das Ziel, **lose gekoppelte, verlässliche und asynchrone Kommunikation** zwischen den Komponenten einer verteilten Anwendung zu ermöglichen.
#### Java Persistence API (JPA)
* stellt eine einheitliche und datenbankunabhängige Schnittstelle für Object-Relational-Mapping und das Arbeiten mit Entitäten bereit.
* Sie vereinfacht die Lösung des Problems der objektrelationalen Abbildung, das darin besteht, Laufzeit-Objekte einer Java-Anwendung über eine einzelne Sitzung hinaus zu speichern (Persistenz), wobei relationale Datenbanken eingesetzt werden können, die ursprünglich nicht für objektorientierte Datenstrukturen vorgesehen sind.
[Three Dimensions of Java Enterprise System Architectural Framework](https://docs.oracle.com/cd/E19263-01/817-5764/architecture.html)
---
:::danger
### Projekt incl. Design des Mitarbeiter-Clients inkl. Interaktionen mit dem Server und Design des Kunden-Clients inkl. Interaktionen mit dem Server
:::

Serverseitige Überprüfung von Client-Art
* Thin Client → Teil der Client-Funktionen liegt am Server - Login Oberfläche
* Web Browser → GUI (serverseitig zur Verfügung gestellt)
* Am Server: Web Container → hier erfolgt die serverseitige Prüfung ob Kunde oder MA (weil nur clientseitig nicht ausreicht)
* Der Client und der EJB Container kommunizieren via RMIs.
* Im EJB Container befinden sich die mit @Entity annotierten Klassen woraus die JPA Entities instanziiert werden.


### Spezifikation der am Bankserver persistent verwalteten Daten (JPA Entities).
Während EJB eine große Anzahl von Spezifikationen (Sicherheit, Transaktionen, Persistenzmanagement, Zeitgeberdienste, Administrationen) bietet, ist JPA ein **Teil der EJB-Spezifikation**, die sich auf die **Persistenz** bezieht. JPA ist eine Sammlung von Klassen und Methoden zum **dauerhaften Speichern der großen Datenmengen** in einer Datenbank, die von der Oracle Corporation bereitgestellt wird. Diese Sammlung bietet alles, was man zum **Organisieren der Zuordnung von Objekten zu Datenbanktabellen**, **CRUD-Operationen** und zum **Verwalten von Transaktionen** benötigt.
Um die Belastung durch das Schreiben von Codes für die Verwaltung relationaler Objekte zu verringern, folgt ein Programmierer dem JPA-Provider-Framework, das eine einfache Interaktion mit der Datenbankinstanz ermöglicht. Hier wird das erforderliche Framework von JPA übernommen.
[Quelle](https://www.tutorialspoint.com/jpa/index.htm)


---
:::danger
### Projekt incl. Spezifikation der am Bankserver persistent verwalteten Daten (JPA Entities).
:::
* Personen
* Mitarbeiter
* Kunden
* Aktienanteil
Diese Klassen werden mit @Entity annotiert, damit man dann im Folgenden Instanzen dieser Klassen als JPA Entities in der DB speichern kann.
### Remote Interface-Definition des Bankservers (inkl. typisierten Methodenparametern) und Festlegung der Technologie (RMI oder Web Services).
:::danger
### Projekt incl. Remote Interface Definition und RMI.
:::

Die typisierten Methodenparameter werden im Klassendiagramm bei den jeweiligen Methoden beim Interface, das zur Verfügung gestellt wird, angegeben.
* Wir haben uns für **RMI** entschieden, weil wir ausschließlich mit Java arbeiten werden und RMI für kleine Projekte die bessere Performance und Sicherheit bietet.
* Web Services sind plattformübergreifend und besser geeignet, wenn man mit unterschiedlichen Technologien arbeiten will, dafür hat es keine eingebauten Sicherheitsmechanismen was eine gewisse Komplexität mit sich bringt, da man die Sicherheit selbst dazu implementieren muss. Dafür sind Webservices besser was Wartbarkeit und Änderungen betrifft. Für ein kleineres Projekt wie unseres erscheint uns RMI aber die bessere Wahl zu sein.