Stageopdracht

[Verwijderd]

Goeden...

Ik heb een vrij interresante stageopdracht "gekregen" al zeg ik het zelf . Ik heb er wel zo m'n ideeen over, maar het is natuurlijk altijd interresant om te zien hoe anderen er over denken.

Korte uitleg : Bij het bedrijf waar ik stage ga lopen hebben ze een applicatie gebouwd dat uit 2 onderdelen bestaat.
A. een client die via tcp/ip verbinding maakt met de applicatie server en dan communiceert met de applicatie.
B. applicatie die draait op een server
C. een db die benaderd wordt via de aplicatie

Schetsje:
| A | <--> | B | <--> | C |

Dit werkt tot op heden uitstekend, maar er is een groot nadeel aan de client, hij is namelijk platform afhankelijk. Wat ik dus als opdracht heb gekregen is het ontwikkelen van een client die vanuit een brouwser werkt.

Nieuw schetsje:
| A | <--> | B | <--> | C | <--> | D |

A. Client die vanuit een brouwser draait (dus A is bv IE5)
B. Bridge die gebouwd moet worden (Apache, .NET, Java WebServer???)
C. applicatie die draait op een server
D. een db die benaderd wordt via de aplicatie

Nu is het de vraag, hoe kan ik de communicatie tussen A <-> B en B <-> C het beste aanpakken/oplossen ???

Het bedrijf dat heeft zelf een protocol ontwikkeld voor de communicatie tussen B <-> C. Dat is niet het grote probleem. Het probleem zit meer in hoe zorg ik ervoor dat als een opdracht binnenkomt van de client op poort 80, doorgestuurd wordt naar de applicatie( die dan weer de communicatie regelt met de applicatieserver(C) ?

Ik zat zelf aan een aantal mogelijkheden te denken, waarvan ik niet zeker ben of dat ze in de praktijk ook echt geimplementeerd kunnen worden.
- Apache met een aparte module die de communicatie tussen B <-> C regelt en dat apache de communicatie regelt tussen A <-> B.
- .NET, ik heb hier heel weinig verstand van. Dus als iemand weet of dit via .NET zou kunnen, hoor ik het graag.
- Java webserver met een servlet die de communicatie regelt tussen B <-> C.

Er is geen voorkeur voor een programmeertaal, zelf ben ik echt opgeleid als java developer, maar ik vrees dat java hier niet echt geschikt voor is. Dus C++/C# VB/VB.NET kunnen allemaal.

Nogmaals, ik weet niet of de oplossingen die ik hierboven aangedragen heb uberhaubt mogelijk zijn. Dus ik ben heel benieuwd hoe jullie dit zouden aanpakken.

[CyBeR]

java is toch platformonafhankelijk?
dan kun je het toch als java[applet|applicatie] maken?

overigens zie ik 3 onderdelen, niet 2

[_Stryker_]

gewoon een client server applicatie dus....
Kijk eens naar MTS (Microsoft transaction server)

Maak een thin client ( bijv. in VB) die aan de server connect. De server connect via ODBC aan de database.

Simpelle oude technologie.

btw ik denk dat de regels voor huiswerk opdrachten op dit topic ook toepasselijk zijn op stageopdrachten ........

[Alarmnummer]

Hmmm.. ik zit er beetje over te denken.. Ik heb de volgende vragen:

1. Waarom zou een applet nu ineens niet met de server kunnen praten? Die oude client kon het ook, ik vraag me af waarom de applet het niet kan.

2. Als de applet niet met de server kan praten (bv omdat java niet geschikt is voor het oude 'protocol server client', zou de server dan niet aangepast kunnen worden?

Je zou gerust in java (server) applicatie kunnen bouwen die als proxy werkt tussen de applet en de server. En als jij opgeleid bent als java 'developer' dan moet jij dit ook zelf kunnen bedenken (netwerk basics).

Je zou er ook voor kunnen kiezen om die bridge meteen zo op te zetten dat je niet vast zit aan java applet. Je zou bv Corba of XML kunnen gebruiken als communicatie tussen de client en de bridge. Als ze dan later een andere applicatie bij ontwikkelen dan kan deze met dezelfde bridge praten ipv dat er nog een bridge gebouwd moet worden.

[Verwijderd]

Op vrijdag 11 januari 2002 19:03 schreef CyB3R het volgende:
java is toch platformonafhankelijk?
dan kun je het toch als java[applet|applicatie] maken?

Hoe heb je dat dan in gedachten ?! Een applet draaid op een webserver (eigenlijk op de client, maar je hebt de webserver nodig om te hosten) en de applicatie draaid op een applicatie server (??).
Het is dus niet de bedoeling dat een applet direct met de applicatie server communiceert, het kan trouwens ook niet, want de applicatie werkt niet op poort 80 en maakt geen gebruik van het http protocol. Het zou misschien wel mogelijk zijn om een applet te bouwen en een standalone java applicatie, waarbij de applet contact onderhoud met de java applicatie en die weer op z'n beurt met de applicatie server.

Ik zit zelf aan iets meer geintegreerds te denken, dus dat de applicatie sterk verbonden is met de webserver.

[Alarmnummer]

een webserver (vb iis, apache) is in veel gevallen niets meer dan een opgevoerde file server. Hij kan meestal niets bijzonders (scripts terzijde) Ik heb eerlijk gezegd mijn vragen over je netwerk kennis.

http protocol???? TCP/IP verbinding is voldoende.. http is leuk voor webpagina`s, maar je java applet die communiceerd via TCP/IP en is niet geinterseerd in http.

Als jij in java een applicatie (bridge) kan schrijven die met die oude server communiceerd, dan kan een applet het ook. Je zit alleen met de 'api' van de server. Hoe kan een java proggie de server aanspreken? Hoe gebeurde dat in het oude systeem? In het ergste geval is er een taal afhankelijke interface gemaakt en zit er niet veel anders op dan of een nieuwe interface voor die server te schrijven die niet taal afhankelijk is, of een proxy voor de server te plaatsen die wel met die server kan praten en een niet taal afhankelijke interface neerzet (vb corba).

[Verwijderd]

je zou het op twee manieren kunnen aanpakken,

een html pagina waar er met de server gecommuniceerd wordt door forms etc. Je kunt dan de backend maken in wathever language you like. JSP of VB. Deze backend communiceerd dan weer met B

Ook zou je een applet kunnen inschakelen die communiceerd met de backend (java servertje, zelfde als chatservertje).
Voordeel van de applet, het kan response van de backend ontvangen zonder pagina's te hoeven herladen, etc. De java server kan dan weer communiceren met B

[Verwijderd]

Op vrijdag 11 januari 2002 19:06 schreef _Stryker_ het volgende:
gewoon een client server applicatie dus....

Nee, niet helemaal dus. De client server applicatie bestaat al en werkt ook. Nu moet er dus ook een "bridge" gemaakt worden.

Maak een thin client ( bijv. in VB) die aan de server connect. De server connect via ODBC aan de database.
Simpelle oude technologie.

Dat gaat dus niet. De client moet in een browser kunnen draaien en volgens mij kan dat niet met VB (of ik moet verkeerd ingelicht zijn).

btw ik denk dat de regels voor huiswerk opdrachten op dit topic ook toepasselijk zijn op stageopdrachten ........

Ach, het leek mij wel een interressante vraag in het algemeen hoe zo'n koppeling het beste tot stand zou kunnen worden gebracht. Dus het had ook een algemene vraag kunnen zijn.

[mbravenboer]

Waarom zou Java voor de client niet geschikt zijn? Dat is hij juist wel . Maar ik zou me niet vastleggen op een bepaalde technologie. Je ziet nu al de problemen die dat veroorzaakt.

Het volgende lijkt mij een goede opzet:

server-side applicatie geschreven in taal x (irrelevant welke, als je Java kent is dat een prima keuze). Deze applicatie communiceert met de database en stelt gegevens beschikbaar in XML vorm. Ook input gebeurt in XML vorm.

Client applicatie in Java, bijvoorbeeld met gebruik van Java Web Start. Communicatie met de server applicatie mbv XML.

Je kunt uiteraard ook gebruik maken van RMI of Corba. Dat is wellicht een eenvoudigere oplossing, maar het beperkt wel gelijk de mogelijkheden van de client implementaties.

[Alarmnummer]

in mijn reply hierboven heb ik wat veranderd, misschien is het verstandig om die even door te lezen. En alleen een applet die kan op de client draaien.

[Alarmnummer]

Op vrijdag 11 januari 2002 19:30 schreef mbravenboer het volgende:

Je kunt uiteraard ook gebruik maken van RMI of Corba. Dat is wellicht een eenvoudigere oplossing, maar het beperkt wel gelijk de mogelijkheden van de client implementaties.

[off-topic]
Corba is taal onafhankelijk je legt jezelf geen taal verplichtingen op (algemene interface declaratie doe je in IDL (Interface Definition Language), RMI is wel taal afhankelijk, maar RMI/IIOP niet.
[/off-topic]

[mbravenboer]

Alarmnummer: Corba is taal onafhankelijk

Uiteraard. Dat is het grote voordeel van Corba en de enige reden voor de invoering van RMI-IIOP. Ik bedoelde echter dat niet alle omgevingen een goede Corba implementatie hebben. .

[Alarmnummer]

Op vrijdag 11 januari 2002 19:50 schreef mbravenboer het volgende:

[..]

Uiteraard. Dat is het grote voordeel van Corba en de enige reden voor de invoering van RMI-IIOP. Ik bedoelde echter dat niet alle omgevingen een goede Corba implementatie hebben. .

Bestaat er een implementatie voor linux? (Ik gebruik het zelf verder nooit meer namelijk).

[edit] dom dom tuurlijk... het zit oa in java en java is ook uit voor linux.

[mbravenboer]

Alarmnummer: Bestaat er een implementatie voor linux?

Het is meer een probleem per taal... Heel vee 'community' talen hebben wel een min of meer redelijke implementatie. Microsoft doet echter hard zijn best om Corba volledig te negeren.

Maar inderdaad, Java kan prima tegen Corba aanpraten. Zowel via RMI-IIOP als direct via de Corba interfaces. Wel is de standaard implementatie in de JVM niet echt grandioos, maar ja .

[Verwijderd]

Op vrijdag 11 januari 2002 19:18 schreef Alarmnummer het volgende:
een webserver (vb iis, apache) is in veel gevallen niets meer dan een opgevoerde file server. Hij kan meestal niets bijzonders (scripts terzijde) Ik heb eerlijk gezegd mijn vragen over je netwerk kennis.

Ik weet redelijk hoe een webserver in elkaar zit, maar sommige servers hebben nog extra functionaliteiten dan alleen het aanbieden van pagina's. Neem tomcat bv. bevat een standaard webserver, maar heeft ook de mogelijkheid om met servlets/JSP om te gaan. Maar goed, daar ging het even niet om.

Als jij in java een applicatie (bridge) kan schrijven die met die oude server communiceerd, dan kan een applet het ook. Je zit alleen met de 'api' van de server. Hoe kan een java proggie de server aanspreken? Hoe gebeurde dat in het oude systeem? In het ergste geval is er een taal afhankelijke interface gemaakt en zit er niet veel anders op dan of een nieuwe interface voor die server te schrijven die niet taal afhankelijk is,

Je hebt het probleem dus vrij goed gezien. Er is dus een interface gemaakt in C++. De interface is als een module geprogrammeerd, het kan dus makkelijk in allelei programma's geimplementeerd zonder dat die hele interface opnieuw zou moeten worden herschreven, onder voorwaarde dat het programma in C++ geschreven wordt. Dus het is volgens mij niet mogelijk om vanuit java gebruikt te maken die interface. Omdat het niet tot de mogelijkheden behoort om de interface taalonafhankelijk te maken (dan zou namelijk ook de bestaande standalone client herschreven moeten worden, en dat is niet de bedoeling) moet die interface dus op de een of ander manier aangsproken worden.

of een proxy voor de server te plaatsen die wel met die server kan praten en een niet taal afhankelijke interface neerzet (vb corba).

Dat is dus min of meer wat ik bedoel met een bridge. Misschien dat mijn woordkeus verkeerd is geweest. Maar dat is wat ik in geachten heb.

[Alarmnummer]

Dan zit je denk ik vast aan een C++ programma (de bridge dus) die bv een Corba interface aanbiedt. Maar maak die nieuwe interface wel taal onafhankelijk, dat bespaard je in de toekomst veel ellende. En een bridge is geloof ik ook een goeie benaming hoor, maar ik ben de laatste tijd veel door mijn 'Design Patterns - Elements of Reusable Object-Oriented Software' boek aan het ploegen.

quotes uit het boek:

Bridge: Decouple an abstraction from its implementation so that the two can vary independently.

Proxy: Provide a surrogate or placeholder for another object to control access to it.

[Verwijderd]

Op vrijdag 11 januari 2002 20:09 schreef Alarmnummer het volgende:
Dan zit je denk ik vast aan een C++ programma (de bridge dus) die bv een Corba interface aanbiedt. Maar maak die nieuwe interface wel taal onafhankelijk, dat bespaard je in de toekomst veel ellende.

Duidelijk, maar zou .NET in combinatie met C# hier geen oplossing voor bieden ?

Ik moet me nog echt verder gaan verdiepen in dit probleem, maar ik moest gewoon een idee hebben hoe en met wat ik dit aan zou kunnen pakken.

[Alarmnummer]

Op vrijdag 11 januari 2002 20:30 schreef Zpeedy het volgende:

[..]

Duidelijk, maar zou .NET in combinatie met C# hier geen oplossing voor bieden ?

Ik moet me nog echt verder gaan verdiepen in dit probleem, maar ik moest gewoon een idee hebben hoe en met wat ik dit aan zou kunnen pakken.

Hmmm... Microsoft die gaat altijd tegen de draad en houd zich niet aan reeds bestaande interfaces/mogelijkheden. Ik vraag me af of je het voor elkaar krijgt om een os onafhankelijk systeem in elkaar te zetten met .NET

Je zou er ook voor kunnen kiezen om wel een java bridge te maken en die mbv JNI met die c++ interace communiceerd. Maar ik herhaal nog een keer, laat je niet verleiden om die applet via rmi ofzo met die server te laten praten. Je zit dan helemaal vast aan java.

[Verwijderd]

jij zegt in post 1 dat de nieuwe applicatie ( client ) in de browser moet werken. Dan hou je (dacht ik) 3 alternatieven:
* HTML (dynamisch door php/jsp/asp/zelf geschreven prog whatever (PHP roeld))
* Java applet
* activeX applet

Kies je voor de html versie, dan heb je aan de clientside geen problemen meer, aangezien HTML (mits netjes opgemaakt en niet teveel exotische scripts) op elk platform weergegeven kan worden. Je mist wel enkele (mischien noodzakelijke) opties die niet in html bekend zijn
aan de serverside, zal je een nieuwe applicatie server moeten inrichten en maken, namelijk de scripts. Ik ga even verder alsof het PHP is De webserver zal na wat configuratie de communicatie tussen de php-engine en de webserver zelf regelen. PHP kan dankzij ziijn brede database ondersteuning de connectie met de databse makkelijk aangaan.

dus
a= Database blijft hetzelfde
b= PHP engine in dit verhaal
c= webserver ( apache is mijn voorkeur)
d= html-compatible browser
( asp zou op dezelfde manier werken, verander overal waar "php" staat in "asp" (JSP enzo ook dacht ik)

is dit wat ?

/*
java-applet is wel platform onafhankelijk, maar zal het oude communicatie model gebruiken. De webserver zal maar 1x nodig zijn om de applet van te downloaden, voor de rest kan de applet uit zichzelf met de application-server kunnen praten.
Ditzelfde geld voor ActiveX-applets
*/

Grtz, Lyon, wiens username al in gebruik was

[Verwijderd]

Hmmm... Microsoft die gaat altijd tegen de draad en houd zich niet aan reeds bestaande interfaces/mogelijkheden. Ik vraag me af of je het voor elkaar krijgt om een os onafhankelijk systeem in elkaar te zetten met .NET

Maar het is dus niet de bedoeling/noodzaak dat de bridge platform ontafhankelijk wordt. De client die met de bridge communiceerd moet platform onafhankelijk zijn (en in een browser draaien). Dus misschien is het mogelijk om de communicatie tussen de browser en de bridge via XML te laten verlopen ???

Iemand zei het al eens in deze topic :

een html pagina waar er met de server gecommuniceerd wordt door forms etc. Je kunt dan de backend maken in wathever language you like. JSP of VB. Deze backend communiceerd dan weer met Been html pagina waar er met de server gecommuniceerd wordt door forms etc. Je kunt dan de backend maken in wathever language you like. JSP of VB. Deze backend communiceerd dan weer met B

Ik denk dat dus een goede oplossing is voor de comm tussen client en bridge. Voor de comm tussen bridge en applicatie server zou ik dus gebruik kunnen maken van Cobra bv.

[The - DDD]

Ik zou zeggen: gebruik een goeie scripting taal op je webserver. Iets als: JSP/ASP (PHP is leuk, maar niet toegespitst op dit soort zaken).

Je kent al Java, dus waarom niet Java gebruiken.

Tomcat is een JSP container met als extra een HTTP server en niet andersom.

In ieder geval... Maak een weergave voor de communicatie met je server. Dit is allemaal TCP/IP dus dit moet te doen zijn met Java. Als je pech hebt moet je wat zaken schrijven op het niveua van bytearrays om de juiste boodschappen over je connectie te zetten, maar het is te doen. Grootste probleem wat je zult zien is volgens mij dat de bit grootes van de in de huidige client gebruikte variabelen anders zijn dan die van Java daarnaast: PAS GOED OP MET BIG ENDIAN EN LITTLE ENDIAN notaties.

Je maakt dus een weergave van de communicatie met de server. Dit is je client. Vervolgens handel je via JSP de communicatie met de gebruiker af. MAAR!! ondertussen heb je je een instantie van het net gebouwde object als sessie variabele aangemaakt. Je leest het goed, een object als sessie variabele in een JSP pagina. Op een gegeven moment moet er op basis van gebruikers input een transactie plaatsvinden, deze voer je uit door de juiste methode (die je zelf gedefinieerd hebt) aan te roepen in je sessie object (die dus in direct contact met je server applicatie staat).

Op deze manier heb je per connectie op je JSP server een 1 op 1 overzetting naar je applicatie server. Dus 1 client = 1 connectie. Zodra je sessie afgelopen is sluit je netjes de connectie door een sluit methode aan te roepen in je sessie object. Daarna laat je alle referenties vallen en het ding opruimen door Mr. GC.

Dit houdt in dat in jou A-B-C verhaal. Je A herschrijft als een JSP app met de naar B gerichte functionaliteit in een Sessie object per gebruiker. A komt op een JSP server te staan en de gebruiker connect met IE/NS/whatever op jou JSP server.

[mbravenboer]

.NET en C# bieden geen oplossingen, ze bieden andere methoden. .NET is zeker geen oplossing voor je probleem, maar wel een manier om je probleem op te lossen.

Je kunt exact hetzelfde ook implementeren in Java. Communicatie via IIOP, eigen-XML, XML-RPC, SOAP, allemaal geen enkel probleem in Java en .NET.

Je moet eerst kijken wat de mogelijke technieken zijn waarmee je je probleem kunt oplossen. Daarna kan je gaan kiezen welke tool je daarbij het beste kunt gebruiken. Dit hangt af van je doelgroep en je eigen kennis .

[Alarmnummer]

In ieder geval... Maak een weergave voor de communicatie met je server. Dit is allemaal TCP/IP dus dit moet te doen zijn met Java. Als je pech hebt moet je wat zaken schrijven op het niveua van bytearrays om de juiste boodschappen over je connectie te zetten, maar het is te doen. Grootste probleem wat je zult zien is volgens mij dat de bit grootes van de in de huidige client gebruikte variabelen anders zijn dan die van Java daarnaast: PAS GOED OP MET BIG ENDIAN EN LITTLE ENDIAN notaties.

Volgens mij is een JNI wrapper om die bestaand C++ lib een stuk eenvoudiger En aangezien hij wel java kan lijkt me dit ook de meest voor de hand liggende opl. En ik zie dat een paar mensen het over COM objecten hebben, maar volgens mij vinden de Linux mensen en Maccers dit niet zo leuk.

En het probleem aan html gebaseerd systeem (ook al is het via jsp of php op de server een stuk slimmer) je hebt niet altijd dezelfde mogelijkheden als een 'echte' taal zoals Java,C,C++,C#,Delphi, VB *kuch* etc. Het is de vraag hoeveel kunstjes eruit gevoerd moeten worden door de client.

Maar het is dus niet de bedoeling/noodzaak dat de bridge platform ontafhankelijk wordt. De client die met de bridge communiceerd moet platform onafhankelijk zijn (en in een browser draaien). Dus misschien is het mogelijk om de communicatie tussen de browser en de bridge via XML te laten verlopen ???

Ik had het eerst verkeerd gelezen maar dat zou een mogelijkheid zijn. Ik kan je hier alleen niet veel over vertellen.

[Alarmnummer]

java-applet is wel platform onafhankelijk, maar zal het oude communicatie model gebruiken. De webserver zal maar 1x nodig zijn om de applet van te downloaden, voor de rest kan de applet uit zichzelf met de application-server kunnen praten.

Dit kan niet (of de applet moet via DDD zijn bit verhaal gaan werken). Daarom moet juist die bridge ertussen.. Of die applet die heeft een JNI wrapper om die c++ interface heen. Maarja. dit is geen generieke opl. Want je komt hetzelfde probleem tegen als je mbv vb Delphi met die 'oude' server wil gaan communiceren. Vandaar juist die taal onafhankelijke interface.

Ditzelfde geld voor ActiveX-applets

Hmmm.. dit draaid geloof ik alleen op windows, geen fijne oplossing dus.

[Alarmnummer]

dus
a= Database blijft hetzelfde
b= PHP engine in dit verhaal
c= webserver ( apache is mijn voorkeur)
d= html-compatible browser
( asp zou op dezelfde manier werken, verander overal waar "php" staat in "asp" (JSP enzo ook dacht ik)

Aha.. en de oude server is ineens niet meer nodig?

Tomcat is een JSP container met als extra een HTTP server en niet andersom.

Ik vind anders Apache is een HTTP server met Tomcat als extra ook niet al te gek klinken

[Verwijderd]

De oplossing van DDD lijkt me goed voor de comm tussen de client en de bridge, maar het is geen oplossing voor de comm tussen de bridge en de applicatie. Je zou dan namelijk het eigen protocol opnieuw moeten gaat schrijven (en dat is iets wat ik probeer te vermijden ... mocht het echt noodzakelijk blijken te zijn dan moet het maar, maar liever niet dus).

.NET is zeker geen oplossing voor je probleem, maar wel een manier om je probleem op te lossen.

Geweldige uitspraak, die houden we er in.

Je moet eerst kijken wat de mogelijke technieken zijn waarmee je je probleem kunt oplossen.

Daar ben ik dus nu mee bezig. Tot vanavond had ik echt geen concrete oplossingen, maar nu zijn er al een paar aangedragen.

Later wat meer reacties, nu naar huis ... genoeg gewerkt vanavond .

[Alarmnummer]

Op vrijdag 11 januari 2002 21:57 schreef Zpeedy het volgende:
De oplossing van DDD lijkt me goed voor de comm tussen de client en de bridge, maar het is geen oplossing voor de comm tussen de bridge en de applicatie. Je zou dan namelijk het eigen protocol opnieuw moeten gaat schrijven (en dat is iets wat ik probeer te vermijden ... mocht het echt noodzakelijk blijken te zijn dan moet het maar, maar liever niet dus).

Dat moet je op deze manier sowieso. JNI wrapper om die lib is hier de opl. voor. Je zou ook met delphi ed dit kunnen doen en dan aan de andere kant een taal onafhankelijke interface neerzetten.

.NET is zeker geen oplossing voor je probleem, maar wel een manier om je probleem op te lossen.

[Verwijderd]

Op vrijdag 11 januari 2002 21:33 schreef Alarmnummer het volgende:

[..]

Dit kan niet (of de applet moet via DDD zijn bit verhaal gaan werken). Daarom moet juist die bridge ertussen.. Of die applet die heeft een JNI wrapper om die c++ interface heen. Maarja. dit is geen generieke opl. Want je komt hetzelfde probleem tegen als je mbv vb Delphi met die 'oude' server wil gaan communiceren. Vandaar juist die taal onafhankelijke interface.

een applet kan wel degelijk zelf een connectie maken op een willekeurge port naar een andere server ( zelf bloody chatclient erin geschreven ) dus in dit geval zou hij zonder tussenkomst van C(webserv), B(appserv) met D(applet/client) kunnen praten

en die ene server niet meer gebruikt worden ? nee, dat klopt, dat zeg ik ook, de webserver word in het applet verhaal een beetje overbodig (drm vind ik het ook niet echt een opplossing )

[Verwijderd]

Op zaterdag 12 januari 2002 00:01 schreef TheViP het volgende:
een applet kan wel degelijk zelf een connectie maken op een willekeurge port naar een andere server ( zelf bloody chatclient erin geschreven ) dus in dit geval zou hij zonder tussenkomst van C(webserv), B(appserv) met D(applet/client) kunnen praten

Maar een applet kan niet met rechtstreeks met het protocol van de applicatieserver overweg. Daarom heb je die bridge, die krijgt de intelligentie hoe die met de interface van de applicatie server moet babbelen.

[Alarmnummer]

een applet kan wel degelijk zelf een connectie maken op een willekeurge port naar een andere server ( zelf bloody chatclient erin geschreven ) dus in dit geval zou hij zonder tussenkomst van C(webserv), B(appserv) met D(applet/client) kunnen praten

Ik heb ook niet beweerd dat die applet nergens een connectie mee kan maken. Maar hij wil niet dat die applet (of welke client dan ook) rechtstreeks met de db contact maakt.


En anders zou je dan alle server logica nog een keer moeten schrijven (zodat de applet wel rechtstreeks met de db kan praten) maar elke vorm van redunatie is vragen om problemen.

Hij heeft die server dus nodig. En het is dus onmogelijk dat een java applet met een rauwe C++ server kan communiceren. Of hij moet het verhaal van DDD toepassen om met streams van bytes die commando`s gaat simmuleren wat me een vrij onmogelijke zaak lijkt. Of hij moet een JNI wrapper om de reeds bestaande communicatie lib (geschreven in c++) met de server moeten gaan praten.

Maar hoe dan ook.. die oude server die moet blijven bestaan omdat die oude client daar ook mee communiceerde, en moeten ze die aanpassen. En je weet niet hoe gecompliceerd die server is.

En het meest voor de hand liggende ontwerp is een nieuwe bridge te schrijven die zelf met die oude server kan praten . Eventueel is die bridge ook geschreven in C++. Maar als frontend moet die bridge dan een taal onafhankelijke interface aanbieden zodat in de toekomst iedere client er mee kan communiceren.

[Alarmnummer]

Op zaterdag 12 januari 2002 00:09 schreef Zpeedy het volgende:

[..]

Maar een applet kan niet met rechtstreeks met het protocol van de applicatieserver overweg. Daarom heb je die bridge, die krijgt de intelligentie hoe die met de interface van de applicatie server moet babbelen.

precies.. had jij niet al thuis moeten zijn

[Verwijderd]

En het meest voor de hand liggende ontwerp is een nieuwe bridge te schrijven die zelf met die oude server kan praten . Eventueel is die bridge ook geschreven in C++. Maar als frontend moet die bridge dan een taal onafhankelijke interface aanbieden zodat in de toekomst iedere client er mee kan communiceren.

Alarmnummer ... nu ben ik ervan overtuigd dat je uit mijn wazig verhaal het probleem begrijpt ... en nog netjes samengevat ook !

BTW, ik ben thuis ... jaja, daar heb ik ook inet (ik weet het, ben een van de weinigen met die luxe ).

[mbravenboer]

Alarmnummer: Hij heeft die server dus nodig. En het is dus onmogelijk dat een java applet met een rauwe C++ server kan communiceren.

Dat ligt eerder aan de server dan aan de Java applet . Je moet gewoon op de een of andere manier een protocol opstellen voor communicatie: messaging, remote-method-calls of wat dan ook. Dat is geen beperking van een java-applet maar een ontbrekend deel van de server .

Hum, dit was eigenlijk al duidelijk .

En het meest voor de hand liggende ontwerp is een nieuwe bridge te schrijven die zelf met die oude server kan praten . Eventueel is die bridge ook geschreven in C++. Maar als frontend moet die bridge dan een taal onafhankelijke interface aanbieden zodat in de toekomst iedere client er mee kan communiceren.

+1, duidelijk .

[The - DDD]

Op zaterdag 12 januari 2002 00:43 schreef mbravenboer het volgende:

[..]

Dat ligt eerder aan de server dan aan de Java applet . Je moet gewoon op de een of andere manier een protocol opstellen voor communicatie: messaging, remote-method-calls of wat dan ook. Dat is geen beperking van een java-applet maar een onbekend deel van de server .

Zie de bold aanpassing.

Zowiezo vreemd dat een dergelijk communicatie protocol niet gespecificeerd is. Als je dat hebt, dan is het namelijk alleen nog een kwestie van de juiste bytes over je TCP verbinding naar de server pompen. Het zal de C++ server een worst wezen van wie het afkomstig is, zolang het aan het protocol voldoet werkt het.

[Verwijderd]

Op zaterdag 12 januari 2002 01:49 schreef The - DDD het volgende:
Zowiezo vreemd dat een dergelijk communicatie protocol niet gespecificeerd is.

Het protocol is wel gespecificeerd (intern).

Ik ga ff proberen om een vergelijking te maken met iets dat misschien wat meer allerdaags.
Stel dat de applicatie server een FTP server is. De geschreven client is een FTP client. Communicatie tussen die 2 werkt via het FTP protocol. De client werkt alleen nog maar op een windows bak. Het volgende moet nu dus gebeuren : Er moet een bridge geschreven worden die weet hoe die met het FTP protocol moet om gaan zodat die contact kan onderhouden met de server. Er moet een client geschreven worden die eigenlijk niets van het FTP protocol af weet, maar wel weet hoe die met de bridge moet communiceren (opdrachten geven). Dus de bridge is zowel client als server. Iemand zou bv via de client (via een browser) een opdracht aan de bridge kunnen geven in de trend van "download dit bestand" (deze opdracht wordt dan via HTTP doorgegeven) . De bridge interpreteerd dat commando dan en gaat zelf aan de slag om via FTP om bestand x te downloaden. Als het bestand gedl is door de bridge, stuurt de bridge weer het bestand door naar de client, via http bv.

Vervang FTP in dit geval met het eigen protocol en dan heb je globaal de situatie denk ik zoals die nu is en hoe die moet worden.