Grunnleggende om flerlagsapplikasjoner i Oracle 12c - dummies

Oracle 12c innser at m ultimate applikasjoner er den nåværende bransjestandarden og komponerer flere web-, applikasjons- og database servere som gir innhold til tynne klienter med presentasjon via en nettleser. Noen gang lurt på hva som står bak kulissene når du logger deg på et webprogram for online kjøp eller bank?

Klientnivået er bare en nettleser som får tilgang til en webserver. Vise innhold til brukeren er det primære formål med klienten i denne arkitekturen; ingen faktisk behandling skjer i dette laget i nettleseren. Presentasjon skjer oftest via HTML (HyperText Markup Language), men det kan også være i en Java-applet eller en ActiveX-komponent og bruke JavaScript for mer dynamisk formatering og innhold.

Kommunikasjon fra nettleseren til webserveren skjer via HTTP (HyperText Transfer Protocol) eller HTTPS for sikre (krypterte) data. Webservere fungerer konsekvent som weblyttere; De mottar forespørsler fra nettlesere og returnerer formaterte resultatsett med liten behandling på egen hånd. En gang på webserveren blir nettleserforespørselen analysert og sendt til den aktuelle applikasjonsserveren for behandling.

Applikasjonsserverkomponenten kan være på samme fysiske server som webserveren, eller det kan være på en annen fysisk server. Den vanligste webserveren er langt Apache, eller en av sine kommersielle derivater, med over 50 prosent av markedsandelen i henhold til Netcraft.

På applikasjonsservernivået behandles brukerforespørselen ved hjelp av den aktuelle programlogikken. En svært vanlig metode er å bruke en Java-applikasjonsserver, for eksempel Tomcat, Orion eller Glassfish. I dette tilfellet utføres programlogikken i en Java Virtual Machine (JVM), som fungerer som runtime-miljøet for programkoden.

Et annet populært verktøy er Oracle Fusion Middleware (OFM). Innen OFM kan programmet kjøre som Oracle Forms, Reports, Discoverer, eller til og med Java via Oracle Containers for J2EE (OC4J). Uavhengig av produktet ligger det innenfor applikasjonsserverkomponenten som applikasjonslogikken utføres.

Under behandling på applikasjonsserveren er det vanlig å ha tilgang til database for å spørre, opprette, oppdatere eller slette data. Programserveren kommuniserer med databaseserveren via protokoller, for eksempel JDBC eller Oracle Net, for å få tilgang til dataene. I løpet av denne tiden får applikasjonsserveren tilgang til databasen på vegne av brukeren som gjør søknadsforespørselen.

I stedet for å koble til som en navngitt, distinkt bruker som JSMITH, kobler applikasjonsserveren til en generell webkonto (for eksempel WEB_USER). Flere samtidige tilkoblinger fra applikasjonsserveren til databasen danner en tilkoblingsbasseng som tillater en databasetilkobling for å få tilgang til data for en forespørsel. Forbindelsespooling er en ytelsesfordel fordi bare noen få databasetilkoblinger kan betjene tusenvis av forespørsler på vegne av mange brukere.

Når den logiske databasen forekommer, spør den generiske nettbrukeren eller utfører DML på vegne av applikasjonsserveren, som behandler en faktisk brukerforespørsel. Tilkoblingssamlede webbrukeren har ikke skjema eierskap i databasen; den har bare de tillatelsene som trengs for å få tilgang til eller oppdatere data på vegne av applikasjonsserveren.

I løpet av denne tiden brukes vanlige databasroller, tillatelser og tilskudd. I tillegg blir databaseprogramlogikk implementert i PL / SQL via prosedyrer, funksjoner og pakker ofte utført.

Etter at dataframstillingssettet er generert på databasenivået, sendes det tilbake til applikasjonsserveren for mer behandling. Deretter blir resultatene videresendt tilbake gjennom webserveren og over nettverket for presentasjon til brukeren via nettleseren.

Lyder komplisert med alle de forskjellige komponentene? Du kan tenke det i begynnelsen, men det finnes gode grunner for å bryte systemet inn i web-, applikasjons- og databasekomponenter:

• Du kan bruke komponenter fra forskjellige leverandører i en "best of breed" -konfigurasjon. For eksempel kan du bruke en gratis Apache webserver forekomst kombinert med Tomcat eller Glassfish for en billig applikasjonsserver komponent. Deretter knytter du det til makten i Oracle-databasen, og du har et solid system til lavere kostnader!

• Når flere brukere kommer på nettet, kan du legge til flere web-, applikasjons- eller databaseserverinstanser for å øke prosessorkraften. I stedet for å kjøpe større servere, bare kjøp mindre servere.

• Når du har en serie flere servere, får du feiltoleranse. Dette kalles clustering. Hvis en webserver krasjer eller applikasjonsserveren trenger vedlikehold, ikke noe problem - vil de overflødige serverne hente arbeidsbelastningen.

Forhåpentligvis viser disse fordelene hvorfor multi-tier-systemarkitekturer er bransjestandarden og har overgått klient-server-systemer.