Functie webserver bij EJB's

[Verwijderd]

Voor het weergeven van mijn architectuurbeeld zou ik graag inzicht willen krijgen in de functie van de webserver in dit geheel.

De client roept in mijn geval een webservice aan bij een bepaalde maatschappij. Naar mijn idee ontvangt de webserver dit verzoekt en geeft dit direct (zonder omwegen?) door aan de application server.

Klopt bovenstaand verhaal of heeft de webserver een grotere rol dan forwarden van het request?

[Verwijderd]

Toevoeging: wordt er bij het maken van een webservice automatisch een servlet (oid) gegenereerd om de request af te handelen of forward de webserver het request naar de application server die voor de client de session beans aanspreken? (ik kijk dus naar J2EE...)

[Bobco]

Op woensdag 03 april 2002 09:20 schreef NestorY2K het volgende:
Klopt bovenstaand verhaal of heeft de webserver een grotere rol dan forwarden van het request?

Het terugsturen van de response lijkt me ook een functie van de webserver Heb je al bij Sun gekeken? De webcontainer zoals getekend in dat plaatje bevat volgens mij ook gewoon de webserver. Zelf gebruik ik Orion (tegenwoordig heet dat Oracle AS) en daar zit gewoon een uitgeklede webserver in de webcontainer. Is uiteraard ook los van elkaar op te zetten. Apache lijkt dan een logische keuze, maar daar heb ik geen ervaring mee.

[Verwijderd]

In het figuur van Sun praat de client rechtstreeks met de EJB container. Heeft Sun hier (voor de duidelijkheid ) de webserver weggelaten? Duidelijk is in ieder geval wel dat er geen servlets/JSP paginas noodzakelijk zijn om de EJB's aan te roepen, dit kan ook direct!

[Verwijderd]

Ik heb zelf een beetje ervaring met Allaire's JRUN (EJB application server onder o.a. Windows); een onderzoek naar EJB's is mijn stage opdracht geweest.

Ik het geval van JRUN is het zo dat de webserver (IIS in dit geval) verantwoordelijk is voor het aannemen van een http request en het versturen van het antwoord naar een web client. De application server houdt zich daar niet bezig met het http protocol.

Als je een Java EJB client programma hebt (dus niet een web browser maar een 'echt' programma) wordt de webserver stap overgeslagen en communiceert de client wel direct met de applicatieserver. Ik vond zelf deze aanpak minder plezierig werken dan alle aanvragen in een web-request verpakken, omdat er een logischere scheiding is tussen je client en server programmatuur, maargoed, dat is natuurlijk persoonlijke voorkeur.

[Bobco]

Op woensdag 03 april 2002 11:59 schreef Qlone het volgende:
Ik heb zelf een beetje ervaring met Allaire's JRUN (EJB application server onder o.a. Windows); een onderzoek naar EJB's is mijn stage opdracht geweest.

Als je een Java EJB client programma hebt (dus niet een web browser maar een 'echt' programma) wordt de webserver stap overgeslagen en communiceert de client wel direct met de applicatieserver. Ik vond zelf deze aanpak minder plezierig werken dan alle aanvragen in een web-request verpakken, omdat er een logischere scheiding is tussen je client en server programmatuur, maargoed, dat is natuurlijk persoonlijke voorkeur.

Ik heb zelf geen ervaring met het maken van 'echte' EJB clients. Ik weet wel dat je in je deployment descriptor kunt aangeven hoe de EJB via JINI gevonden kan worden door een client. Zelf ben ik nog steeds (met tussenpozen) bezig om de J2EE tutorial door te werken. Het is complex, maar wel erg krachtig.

[Verwijderd]

EJBs en eigenlijk meer J2EE leent zich uitstekend om volgens het MVC principe te programmeren.
Het is voor mij ook een stageopdracht geweest om een huidige java applicatie om te zetten naar een EJB model met Controller (StateMachine) en View (Webserver)
Door zo'n uitsplitsing te maken is meteen duidelijk dat het View, de webserver in dit geval dus, uitwisselbaar is. Je kan dus ook een AWT of Swing view voor hangen. De rest van de applicatie hoef je dus niet aan te passen daarvoor.
De webserver is in een EJB cq J2EE applicatie dus alleen een hulpmiddel en geen doel