Grondbeginselen van multi-tier-applicaties in Oracle 12c - dummies

Oracle 12c realiseert zich dat m ultieme toepassingen de huidige industriestandaard zijn en meerdere web-, applicatie- en databasecombinaties vormen servers die inhoud leveren aan thin clients met presentatie via een webbrowser. Ooit afgevraagd wat er achter de schermen gebeurt wanneer u inlogt op een webtoepassing voor online aankopen of bankieren?

De clientlaag is slechts een webbrowser die toegang heeft tot een webserver. Inhoud weergeven voor de gebruiker is het primaire doel van de client in deze architectuur; er vindt geen daadwerkelijke verwerking plaats op deze laag in de browser. Presentatie gebeurt meestal via HTML (HyperText Markup Language), maar het kan ook binnen een Java-applet of een ActiveX-component zijn en JavaScript gebruiken voor meer dynamische opmaak en inhoud.

Communicatie van de browser naar de webserver vindt plaats via HTTP (HyperText Transfer Protocol) of HTTPS voor veilige (gecodeerde) gegevens. Webservers fungeren conceptueel als webluisteraars; zij ontvangen verzoeken van browsers en geven opgemaakte resultaatsets met weinig verwerking op zichzelf terug. Eenmaal op de webserver wordt de browserverzoek geparseerd en ter verwerking naar de juiste toepassingsserver verzonden.

Het onderdeel van de toepassingsserver bevindt zich mogelijk op dezelfde fysieke server als de webserver of bevindt zich mogelijk op een andere fysieke server. Veruit de meest voorkomende webserver is Apache, of een van zijn commerciële derivaten, met meer dan 50 procent van het marktaandeel volgens Netcraft.

Op toepassingsniveau wordt het gebruikersverzoek verwerkt met behulp van de relevante toepassingslogica. Een heel gebruikelijke methode is om een ​​Java-toepassingsserver te gebruiken, zoals Tomcat, Orion of Glassfish. In dit geval wordt de programmalogica uitgevoerd in een Java Virtual Machine (JVM), die fungeert als de runtime-omgeving voor de programmacode.

Een andere populaire tool is Oracle Fusion Middleware (OFM). Binnen OFM kan het programma worden uitgevoerd als Oracle Forms, Reports, Discoverer of zelfs Java via Oracle Containers voor J2EE (OC4J). Ongeacht het product bevindt de applicatielogica zich binnen de toepassingsservercomponent.

Tijdens de verwerking op de toepassingenserver is het vaak nodig om databasetoegang te hebben voor het opvragen, maken, bijwerken of verwijderen van gegevens. De toepassingsserver communiceert met de databaseserver via protocollen, zoals JDBC of Oracle Net, om toegang te krijgen tot de gegevens. Gedurende deze tijd opent de applicatieserver de database namens de gebruiker die de aanvraag doet.

In plaats van verbinding te maken als een benoemde, afzonderlijke gebruiker zoals JSMITH, maakt de toepassingsserver verbinding met behulp van een generiek webaccount (zoals WEB_USER). Meerdere gelijktijdige verbindingen van de toepassingsserver naar de database vormen een verbindingspool die elke databaseverbinding toegang geeft tot gegevens voor een aanvraag. Pooling van verbindingen is een prestatievoordeel omdat slechts een paar databaseverbindingen duizenden verzoeken namens veel gebruikers kunnen uitvoeren.

Wanneer u bij de database-instantie bent aangemeld, zoekt of voert de generieke webgebruiker DML uit namens de toepassingenserver, die een daadwerkelijke gebruikersaanvraag verwerkt. De webgebruiker met verbindingspool heeft geen schema-eigendom in de database; het heeft alleen die toestemmingen die nodig zijn voor toegang tot of bijwerken van gegevens namens de applicatieserver.

Gedurende deze periode worden normale databaserollen, machtigingen en subsidies gebruikt. Bovendien wordt de logica van het databaseprogramma geïmplementeerd in PL / SQL via procedures, functies en pakketten vaak uitgevoerd.

Nadat de set met gegevensresultaten in de databaselaag is gegenereerd, wordt deze voor verdere verwerking doorgegeven aan de toepassingenserver. Vervolgens worden de resultaten teruggestuurd via de webserver en over het netwerk voor presentatie aan de gebruiker via hun webbrowser.

Klinkt ingewikkeld met alle verschillende componenten? In eerste instantie denkt u van wel, maar er zijn goede redenen om het systeem te onderbreken in web-, applicatie- en databasecomponenten:

• U kunt componenten van verschillende leveranciers gebruiken in een "best of breed" -configuratie. U kunt bijvoorbeeld een gratis Apache-webserverinstantie gebruiken in combinatie met Tomcat of Glassfish voor een goedkope toepassingsservercomponent. Koppel dat vervolgens aan de kracht van de Oracle-database en u hebt een solide systeem tegen lagere kosten!

• Naarmate er meer gebruikers online komen, kunt u meer web-, applicatie- of databaseserverinstanties toevoegen om uw verwerkingskracht te vergroten. In plaats van grotere servers te kopen, hoeft u alleen kleinere servers te kopen.

• Nadat u een reeks van meerdere servers hebt, krijgt u fouttolerantie. Dit wordt clustering genoemd. Als een webserver crasht of de applicatieserver onderhoud nodig heeft, geen probleem - de redundante servers halen de werklast op.

Hopelijk tonen deze voordelen waarom multi-tier systeemarchitecturen de industriestandaard zijn en client-server-systemen hebben overtroffen.