Deel 1. Wat u moet weten voordat u Spring en JavaEE leert

Als je al klaar bent met (of bijna) Java SE aan het leren bent, dan is het tijd om na te denken over je volgende stappen om het beroep van Java-ontwikkelaar te veroveren. Aan de ene kant heb je al een goede kennis van Java: je kunt werken met een IDE, programma's schrijven en nog veel meer. Maar wat moet u nu doen met uw programma's? Hoe maak je ze nog cooler en "laat je ze los op de wereld"? Het wordt steeds duidelijker dat het tijd is om bedrijfstechnologieën te bestuderen. En nu begint het plezier. Het maakt niet uit met welke technologiestack u besluit te beginnen. Of het nu JavaEE of Spring is, u zult waarschijnlijk een heleboel dingen tegenkomen die uw bevattingsvermogen ver te boven gaan. Tussen Java-basis en geavanceerde technologieën blijft er een tussenstap in kennis die moet worden genomen om te behouden wat er overblijft van uw zelfbeheersing en zelfvertrouwen terwijl u omvangrijke documentatie leest. Daarom,is om u de minimale theoretische kennis te geven die nodig is voor uw verdere studie van JavaEE of Spring. Dit materiaal is verdeeld in 7 delen:

1. We zullen het even hebben over netwerken.
2. We zullen de client-server- en drielaagsarchitectuur onderzoeken.
3. We zullen de HTTP/HTTPS-protocollen onderzoeken.
4. We leren alles wat je moet weten over Maven.
5. We hebben het over loggen.
6. Over servletcontainers.
7. En tot slot, over MVC.

Deel 1. We praten wat over netwerken.

Laten we beginnen met wat het belangrijkst is door te praten over waar elk sociaal netwerk, webservice en webapp, instant messenger en eenvoudige website op is gebouwd: het netwerk (in de context van deze reeks artikelen betekent de term 'netwerk' het internet ) . Het netwerk bestaat uit een groot aantal computers: ze zijn met elkaar verbonden en kunnen communiceren. Het is belangrijk om te begrijpen hoe ze dit doen, omdat webapplicaties informatie van de ene computer naar de andere sturen.

OSI-model

Het Open Systems Interconnection (OSI)-model creëert een gelaagde aanpak voor het bouwen van een netwerk. Het laat duidelijk zien hoe en op welke laag entiteiten van hetzelfde netwerk met elkaar kunnen interageren. In totaal bevat dit model 7 lagen: Door het model op te splitsen in abstractielagen, hoeven ontwikkelaars die bijvoorbeeld aan de transportlaag werken niet na te denken over implementatiedetails op het niveau van de netwerk- en sessielagen. Deze benadering wordt ook gebruikt bij het programmeren. Laten we alle lagen van het OSI-model bekijken en bepalen welke voor ons van belang zijn:

1. Fysieke laag - Deze laag behandelt de wetten van de fysica en hoe deze voor onze doeleinden te gebruiken. Bijvoorbeeld kabels maken en leggen naar entiteiten in het netwerk.

   Deze laag interesseert ons niet.

2. Datalinklaag - Deze laag is verantwoordelijk voor het verzenden van gegevens naar netwerkknooppunten en het creëren van gegevenstransmissiekanalen voor fysieke objecten.

   Deze laag interesseert ons niet, tenzij je firmware wilt schrijven voor de hardware die datalinks tot stand brengt.

3. Netwerklaag - Deze laag is voor het bepalen van de adressen van individuele netwerkgebruikers en de routes ernaar toe. Het is waardevol om meer te leren over de details van deze laag, namelijk netwerkadressen.

   Netwerkadressen worden gedefinieerd door een speciaal protocol: het meest voorkomende is IPv4 (Internet Protocol versie 4). Dit is het protocol dat een webprogrammeur moet gebruiken om contact op te nemen met een andere netwerkgebruiker.

   Een IPv4-adres bestaat uit vier bytewaarden gescheiden door punten, bijvoorbeeld: 192.0.2.235. U moet onthouden dat deze waarden bytes zijn, wat betekent dat ze binnen het bereik 0..255 liggen.

   IP-adressen zijn op hun beurt onderverdeeld in klassen. We kunnen onszelf niet zomaar een mooie cijfercombinatie toekennen, maar heel diep gaan we hier niet op in. Het is voldoende om te begrijpen dat een IP-adres een unieke identificatie is van een netwerkgebruiker en kan worden gebruikt om contact op te nemen met die gebruiker.

4. Transportlaag - Deze laag zorgt voor het leveren van informatie aan een geadresseerde. Hiervoor worden verschillende protocollen gebruikt. Voorlopig zijn we er niet in geïnteresseerd. We zijn veel meer geïnteresseerd in het concept van een poort , dat op deze laag verschijnt.

   Poorten zijn verantwoordelijk voor het identificeren van een specifieke toepassing op een computer. Stel, je schrijft een chat-app in Java, installeert deze op 2 computers en je wilt een bericht sturen naar je buddy. Je bericht wordt verpakt, naar een specifiek IP-adres gestuurd en afgeleverd bij je buddy, maar zijn computer weet niet wat hij met de ontvangen informatie moet doen, omdat hij niet begrijpt welke applicatie je bericht moet verwerken. Wanneer netwerkentiteiten communiceren, worden poorten gebruikt om aan te geven welke applicatie de informatie moet verwerken.

   De poort is een nummer in het bereik van 0 tot 65535. Het wordt toegevoegd aan het IP-adres na een dubbele punt: 192.0.2.235:8080 . Maar u kunt niet alle poorten in het opgegeven bereik gebruiken: sommige zijn gereserveerd voor het besturingssysteem, andere worden gewoonlijk voor specifieke doeleinden gebruikt. We zullen niet ingaan op de doeleinden van verschillende poorten. Voor nu is het voldoende om hun rol in het communicatieproces op het netwerk te begrijpen.

5. Sessielaag — Deze laag maakt en beheert communicatiesessies. Op deze laag wordt het voor applicaties mogelijk om te communiceren en verzoeken op serviceniveau te verzenden. Wat we moeten weten, is dat op deze laag een sessie wordt geopend tussen twee gebruikers en dat we met de sessie moeten werken.

   Een sessie is een entiteit die ontstaat wanneer een verbinding tot stand wordt gebracht tussen twee gebruikers. Het kan noodzakelijke informatie over een gebruiker en over de geschiedenis van interactie met de gebruiker opslaan. Een belangrijk detail is dat wanneer de informatie-uitwisseling stopt, de sessie niet verdwijnt. In plaats daarvan behoudt het zijn status voor een bepaalde tijd, zodat gebruikers na een pauze informatie kunnen blijven uitwisselen.

   Als een applicatie tegelijkertijd met meerdere gebruikers communiceert, wordt een overeenkomstig aantal verbindingen (en dus sessies) tot stand gebracht. Elke sessie heeft een unieke identifier (ID) , waarmee de toepassing onderscheid kan maken tussen de gebruikers met wie deze communiceert.

6. Presentatielaag — Deze laag is verantwoordelijk voor het coderen/decoderen van gegevens. Het is duidelijk dat als we de string "Hallo web" naar een andere gebruiker moeten sturen, deze eerst wordt omgezet in (gecodeerd als) binaire code en pas daarna wordt verzonden. Bij het bereiken van de ontvanger wordt het bericht terug geconverteerd (gedecodeerd) en kan de ontvanger de originele string zien. Deze acties vinden plaats op de presentatielaag.

7. Applicatielaag is voor ons de meest interessante laag. Hiermee kunnen applicaties communiceren met het netwerk. Op deze laag ontvangen en verzenden we berichten en doen we verzoeken aan services en externe databases.

   Op deze laag worden veel protocollen gebruikt: POP3, FTP, SMTP, XMPP, RDP, SIP, TELNET en natuurlijk HTTP/HTTPS. Een protocol is een universele afspraak waar we ons aan houden bij de communicatie. We zullen zeker een aparte gedetailleerde bespreking van HTTP/HTTPS geven.

We hoeven niet te weten hoe elke laag van het model werkt. Het belangrijkste is om de principes te begrijpen achter de werking van de elementen waarmee we zullen moeten werken bij het schrijven van webapplicaties, namelijk:

• IP-adres — Het adres van de gebruiker in het netwerk
• Poort — Het adres van de toepassing van een specifieke gebruiker
• Sessie — Een entiteit die bestaat gedurende de periode van communicatie tussen twee gebruikers
• Applicatieprotocollen (HTTP/HTTPS) — Dit zijn regels die we zullen volgen bij het opstellen en verzenden van berichten.

Wanneer we bijvoorbeeld een webwinkel bezoeken, geven we het adres en de haven aan. Bij ons eerste bezoek wordt er een sessie aangemaakt. De winkel kan informatie vastleggen in de sessie. De winkel kan bijvoorbeeld informatie opslaan over artikelen die we in het winkelwagentje hebben achtergelaten. Als we het tabblad met de online winkel sluiten en er later weer in gaan, zullen onze artikelen nog steeds in de winkelwagen zitten omdat ze in de sessie zijn opgeslagen. Natuurlijk ontvangen we alle informatie die we van de winkel ontvangen via het HTTP/HTTPS-protocol en onze browser weet hoe hij deze moet verwerken. U kunt bezwaar maken door te zeggen dat u het adres en de poort nooit in de browser hebt ingevoerd, en u zou gedeeltelijk gelijk hebben. Wat je wel deed, was de domeinnaam invoeren, die werd omgezet door een DNS-server. Laten we eens beter kijken naar wat hier is.

DNS (Domeinnaamsysteem)

Zoals we al hebben geleerd, heeft elke netwerkgebruiker een uniek adres. Als we het over de applicatie hebben, dan is het unieke adres IPv4-address:port . Als u dit adres kent, heeft u direct toegang tot de applicatie. Stel je voor dat we een webapplicatie hebben geschreven die de gemiddelde luchttemperatuur in alle landen real time weergeeft. We hebben het geïmplementeerd op een server met het adres 226.69.237.119, op poort 8080. Om informatie van ons te kunnen ontvangen, moet de gebruiker 5 cijfers invoeren in de browser: 226.69.237.119:8080. Mensen houden er niet van om cijferreeksen uit het hoofd te leren: velen van ons kunnen niet meer dan twee telefoonnummers onthouden. Daarom het Domain Name Systemis uitgevonden. We kunnen een "alias" voor ons adres maken, bijvoorbeeld wereld-temperatuur.com. In plaats van ons te zoeken aan de hand van een adres bestaande uit vijf moeilijk te onthouden cijfers, kan de gebruiker onze domeinnaam in de adresbalk van de browser invoeren. Er zijn DNS-servers die domeinnamen toewijzen aan echte adressen. Wanneer een gebruiker bijvoorbeeld codegym.cc invoert in een browser, wordt haar verzoek naar een DNS-server gestuurd, die het omzet in het daadwerkelijke adres. Dit is belangrijk voor ons om te begrijpen, omdat onze applicaties externe services zullen aanroepen, zowel met domeinnamen als met echte adressen. We moeten begrijpen dat de services in beide gevallen hetzelfde zijn. Dat is het voor nu! In dit artikel hebben we gekeken naar de basisprincipes van netwerken, wat van pas zal komen als je webprogrammering begint te leren.De volgende keer zullen we kijken naar wat een client-serverarchitectuur is en waarom het zo belangrijk is om deze te begrijpen. Deel 2. Laten we het hebben over software-architectuur Deel 3. HTTP/HTTPS Deel 4. De basisprincipes van Maven Deel 5. Servlets en de Java Servlet API. Een eenvoudige webapplicatie schrijven Deel 6. Servlet-containers Deel 7. Introductie van het MVC-patroon (Model-View-Controller)