Grundlæggende om multilagsprogrammer i Oracle 12c - dummies

Oracle 12c indser, at m ultimative applikationer er den nuværende industristandard og komponerer flere web-, applikations- og database servere, der giver indhold til tynde klienter med præsentation via en webbrowser. Har du nogensinde spekuleret på, hvad der ligger bag kulisserne, når du logger ind på en webapplikation til online-køb eller bank?

Klientniveauet er blot en webbrowser, der har adgang til en webserver. Visning af indhold til brugeren er det primære formål med klienten i denne arkitektur; ingen faktisk behandling foregår på dette lag i browseren. Præsentation forekommer oftest via HTML (HyperText Markup Language), men det kan også være inden for en Java-applet eller en ActiveX-komponent og bruge JavaScript til mere dynamisk formatering og indhold.

Kommunikation fra browseren til webserveren sker via HTTP (HyperText Transfer Protocol) eller HTTPS for sikre (krypterede) data. Webservere fungerer som weblyttere; de modtager anmodninger fra browsere og returnerer formaterede resultatsæt med lidt behandling på egen hånd. En gang på webserveren bliver browserapporten analyseret og sendt til den relevante applikationsserver til behandling.

Applikationsserverkomponenten kan være på samme fysiske server som webserveren, eller den kan være på en anden fysisk server. Langt den mest almindelige webserver er Apache, eller en af ​​sine kommercielle derivater, med over 50 procent af markedsandelen ifølge Netcraft.

På applikationsserverniveauet behandles brugerforespørgslen ved hjælp af den relevante applikationslogik. En meget almindelig metode er at bruge en Java-applikationsserver, som f.eks. Tomcat, Orion eller Glassfish. I dette tilfælde udføres programlogikken inde i en Java Virtual Machine (JVM), som fungerer som runtime-miljøet til programkoden.

Et andet populært værktøj er Oracle Fusion Middleware (OFM). Inom OFM kan programmet køre som Oracle Forms, Reports, Discoverer eller endda Java via Oracle Containers for J2EE (OC4J). Uanset produktet er det inden for applikationsserverkomponenten, at applikationslogikken udføres.

Under behandling på applikationsserveren er det almindeligt at have brug for databaseadgang til forespørgsel, oprette, opdatere eller slette data. Applikationsserveren kommunikerer med databaseserveren via protokoller, såsom JDBC eller Oracle Net, for at få adgang til dataene. I løbet af denne tid får applikationsserveren adgang til databasen på vegne af den bruger, der foretager ansøgningsanmodningen.

I stedet for at forbinde som en navngivet, særskilt bruger som JSMITH, slutter applikationsserveren ved hjælp af en generisk webkonto (som f.eks. WEB_USER). Flere samtidige forbindelser fra applikationsserveren til databasen udgør en tilslutningsbassin , der tillader enhver databaseforbindelse at få adgang til data til en forespørgsel. Forbindelsespooling er en præstationsfordel, fordi kun nogle få databaseforbindelser kan betjene tusindvis af anmodninger på vegne af mange brugere.

Når logget ind i databasen forekommer den generiske webbruger forespørgsler eller udfører DML på vegne af applikationsserveren, som behandler en faktisk brugeranmodning. Den forbindelsespoolede webbruger har ikke skema ejerskab i databasen; den har kun de tilladelser, der er nødvendige for at få adgang til eller opdatere data på vegne af applikationsserveren.

I løbet af denne tid anvendes normale databasroller, tilladelser og tilskud. Derudover udføres databaseprogramlogik implementeret i PL / SQL via procedurer, funktioner og pakker.

Efter datasættet er genereret på database-tieret, sendes det tilbage til applikationsserveren for mere behandling. Derefter relayeres resultaterne tilbage via webserveren og på tværs af netværket til præsentation til brugeren via deres webbrowser.

Lyder kompliceret med alle de forskellige komponenter? Du kan måske tænke det i starten, men der findes gode grunde til at bryde systemet i web-, applikations- og databasekomponenter:

• Du kan bruge komponenter fra forskellige leverandører i en "best of breed" -konfiguration. For eksempel kan du bruge en gratis Apache webserver forekomst kombineret med Tomcat eller Glassfish til en billig applikationsserver komponent. Derefter binde det til magten i Oracle-databasen, og du har et solidt system til lavere omkostninger!

• Da flere brugere kommer online, kan du tilføje flere web-, applikations- eller databaseserverinstanser for at øge din proceskraft. I stedet for at købe større servere skal du bare købe mindre servere.

• Når du har en række flere servere, får du fejltolerance. Dette kaldes clustering. Hvis en webserver krasjer eller applikationsserveren behøver vedligeholdelse, er det ikke noget problem - de overflødige servere vil afhente arbejdsbelastningen.

Forhåbentlig viser disse fordele, hvorfor multi-tier-systemarkitekturer er industristandarden og har overgået klient-server-systemer.