Toon posts:

[Java] ActiveX control porten naar Java servlet *

Pagina: 1
Acties:

Verwijderd

Topicstarter
Stel, er is een bepaalde database. En stel, men heeft een module waarmee vanaf een website bepaalde toegestane bewerkingen op de database worden uitgevoerd (het aanbieden van SQL-toegang is niet gewenst). Deze server-side module is een ActiveX control. Als men nou een platform-onafhankelijke module wil hebben, dus een die bijvoorbeeld ook met Linux-webservers kan werken, dan hebben we dus een probleem.

Nou overweeg ik voor het vinden van een oplossing een aantal benaderingen:

1) De ActiveX-control op de Linux-server laten draaien via Wine (krakkemikkig lapmiddel naar mijn mening)
2) De ActiveX-control op een aparte Windows-computer (of in een VMWare-box) laten draaien en via een of andere netwerk-koppeling met bijvoorbeeld Java-code te laten communiceren (erg omslachtig)
3) De ActiveX-control porten naar een Java servlet (op dit moment de meest realistische en praktische optie, naar mijn mening, maar lijkt mij ook het meeste werk)
4) suggesties van jullie die ik nog niet heb genoemd???

Wat ik wil weten is hoe ik deze uitdaging het beste kan aanpakken, bijvoorbeeld op een van de bovengenoemde manieren. Ik weet op dit moment overigens nog niet zeker of ik zelf toegang krijg tot de sourcecode van de ActiveX-control, maar indien wel: dan lijkt optie 3 mij het beste. Wie kan hierover meer vertellen (ervaringen, tips, etc)?

Op Google kon ik opvallend weinigs (eigenlijk niets concreets) vinden over het werkelijk porten van ActiveX-code naar Java. ActiveX-code is meestal in C++ geschreven, niet?

[ Voor 6% gewijzigd door Verwijderd op 25-06-2003 18:05 ]


Verwijderd

Topicstarter
Oh ja, dat was ik nog vergeten: kan Microsoft IIS ook overweg met Java servlets? Of moet die dan ook vervangen worden door bijvoorbeeld Apache?

  • hobbit_be
  • Registratie: November 2002
  • Laatst online: 04-07-2025
Hmm ActiveX is Windows en ofwel C/C++/VB of ook .NET (laatste ben ik niet zeker van).

Als je met servlets gaat werken dan moet je een container hebben (Tomcat bijvoorbeeld is gratis en industry - ok) waar je de Servlets serveert. Dan moet je je webserver (Apache, ISS maakt niet uit) even zeggen dat ie voor elke *.jsp (typische servelt extensie maar je kan kiezen) naar TC gaat (net zoals PHP 'naar' PHP gaat). En TC gaat dan het resultaat van je request geven.

Maar weet je wel het taaltje dat er gesproken word? En wat bedoel je met een Module op Client Side (ie een Active-X geval?). Dan moet je weten hoe die COM met de andere klapt en die moet je dan veranderen zodat je het met Java de juiste respons geeft - theorisch allemaal geen probleem - pratisch bijna onbegonnen werk als je niet precies weet welke packets er worden uitgezonden. In het ergste geval is die Server-Side een echte server die een persitent connectie maakt met de Client Side - dan moet je met Java een Server Maken (tamelijk eenvoudig als de #people klein zijn) ... Maar je moet meer zeggen ivm wat die Client-Side module is...

Verwijderd

Topicstarter
hobbit_be schreef op 25 June 2003 @ 18:56:
Hmm ActiveX is Windows en ofwel C/C++/VB of ook .NET (laatste ben ik niet zeker van).

Als je met servlets gaat werken dan moet je een container hebben (Tomcat bijvoorbeeld is gratis en industry - ok) waar je de Servlets serveert. Dan moet je je webserver (Apache, ISS maakt niet uit) even zeggen dat ie voor elke *.jsp (typische servelt extensie maar je kan kiezen) naar TC gaat (net zoals PHP 'naar' PHP gaat). En TC gaat dan het resultaat van je request geven.
Ah, dus Tomcat werkt ook met IIS? Daar had ik eigenlijk gewoon wat meer onderzoek naar moeten verrichten (even de website bezoeken, bijvoorbeeld).

Maar goed, het belangrijkste: server-side code (op dit moment dus nog ActiveX) op niet-windows server-platforms aan de praat zien te krijgen.
Maar weet je wel het taaltje dat er gesproken word? En wat bedoel je met een Module op Client Side (ie een Active-X geval?).
Ik had het juist over server-side, niet over client-side.

Voor de duidelijkheid: ga uit van ActiveX-code op de websever die aan de ene kant via ODBC met een database communiceert en aan de andere kant een API aanbiedt waarmee koppelingen gemaakt kunnen worden met server-side scripting talen zoals ASP of PHP.

Aangezien er niet altijd gebruik gemaakt wordt van een Windows-based webserver kan dus ook niet die ActiveX-code altijd worden gebruikt. Dat is dus het probleem: kan ik het beste emulatie gebruiken om de ActiveX-code op een niet-Microsoft-server te draaien, of kan ik beter de ActiveX-code porten naar Java, of is er misschien nog een andere mogelijkheid?

[ Voor 3% gewijzigd door Verwijderd op 25-06-2003 20:07 ]


  • hobbit_be
  • Registratie: November 2002
  • Laatst online: 04-07-2025
Verwijderd schreef op 25 June 2003 @ 20:05:
[...]
Ah, dus Tomcat werkt ook met IIS? Daar had ik eigenlijk gewoon wat meer onderzoek naar moeten verrichten (even de website bezoeken, bijvoorbeeld).
Ja dat gaat - tis niet HET eenvoudigste om alles te doen werken maar daar zijn vast heel wat posts over. Ik weet dat het kan want we hebben 'ooit' dit gedaan - maar toen was het iemand die het voor me deed :)
Maar goed, het belangrijkste: server-side code (op dit moment dus nog ActiveX) op niet-windows server-platforms aan de praat zien te krijgen.
Hoe je activeX aan de gang krijgt op *nix: geen idee - vast met een emulatie laag maar hoe je dan van een *nix webserver naar die emulatielaag moet gaan. Kan je alleen echt helpen met Java.
Ik had het juist over server-side, niet over client-side.
Dat begreep ik wel - maar wat ik doelde:

Client (Browser) -> Protocol -> Server -> Activex

Nu weet ik bijvoorbeeld niet dat je Client SIde dus OOK een activeX gebruikt of gewoon met HTTP protocol (GET/POST enzo) of dat je Client Side iets zend naar de server NIET via did systeem. If not (dus niet HTTP-based) dan gaat het al erg moeilijk worden. Snap je? Ik moet (en de rest hier ook) eerst weten wat en hoe je dingen doorstuurt naar de Server. Dan nog bepalen of je ActiveX (kan?) moet emuleren of ombouwen naar Java.
Voor de duidelijkheid: ga uit van ActiveX-code op de websever die aan de ene kant via ODBC met een database communiceert en aan de andere kant een API aanbiedt waarmee koppelingen gemaakt kunnen worden met server-side scripting talen zoals ASP of PHP.
Dat snapte ik ook wel - maar met Java iets 'aanbieden' alla dan moet je wel heel de serverside omgooien en dus puur met servlet gaan werken. (zover ik weet).

Ik wacht nog effe met je antwoord op wat er nu precies gebeurt en hoe de 'queries' nu opstuurt. Ik zie ook niet in wat het probleem is als je server-side met ASP/PHP werkt beide kunnen direct aan elke ODBC of Database. Vooral PHP is poep simpel. (ASP - tja voor *NIX weet ik er te weining over)...

Verwijderd

Het is niet mogelijk een activex component direct te porten naar Java.

Je kan natuurlijk wel in de source kijken hoe het component werkt en dit nabouwen in Java.

Misschien kun je wat specifieker zijn over wat het component doet?

Verwijderd

Topicstarter
Verwijderd schreef op 26 June 2003 @ 00:17:
Het is niet mogelijk een activex component direct te porten naar Java.

Je kan natuurlijk wel in de source kijken hoe het component werkt en dit nabouwen in Java.
Herschrijven, dus. Daar was ik al bang voor.
Misschien kun je wat specifieker zijn over wat het component doet?
Zie het als een abstractielaag tussen de ODBC-interface van een database en een website.

Er wordt een softwareproduct verkocht aan meerdere klanten. Dit product is gebaseerd op een SQL database. Alleen wil men (gezien de complexiteit van de tabelstructuur) voorkomen dat klanten die zelf websites aan de database willen koppelen de mogelijkheid krijgen om dit via SQL te doen, omdat ze de database zouden kunnen beschadigen. (Bij read-only access is dit uiteraard geen probleem, maar bij write-access wel.) Er is een beperkt aantal operaties die op de database kunnen/mogen worden uitgevoerd en daarom wordt er aan klanten die een webkoppeling willen maken een "interface" gegeven. Dat is dus in de vorm van een module die men op de webserver kan installeren en die dus de "lijmlaag" vormt tussen de database (via ODB) en de webkoppeling van de klant.

Een voorbeeld van een standaard schrijf-actie is "voeg een klant toe" (om maar wat te noemen). Dan bestaat er in de module bijvoorbeeld een function call "bool voegKlantToe(string naam, string adres, string woonplaats)". Zodra die function (door andere server-side code) wordt aangeroepen met de juiste parameters, formuleert die intern de correcte SQL-opdracht en stuurt die naar de database. Of als er sprake is van stored procedures, dan stuurt de function de juiste RPC naar de database toe. Het enige wat de website van de module terugkrijgt is de return value (true bij succes en false bij een mislukking).

Het probleem op dit moment: veel webservers zijn gebaseerd op Linux of BSD. Als zo'n module een ActiveX-component is, dan beperk je dus het aantal platforms die de klanten kunnen gebruiken met een dergelijke module.

Maar tot nu toe heb ik eigenlijk alleen maar bevestigingen gehoord van wat ik eigenlijk al vreesde: herimplementeren met een platformonafhankelijke taal/platform is kennelijk de enige oplossing. Als je de SQL-quri

Server-side scripting talen (zoals PHP of Perl) zijn uiteraard een optie, maar als je die aan klanten levert, dan zouden ze ook daaraan aanpassingen kunnen maken. De enige door mij te bedenken platform-onafhankelijke oplossing die niet aan te passen is door degenen aan wie je de module distribueert is om de module in de vorm van een Java servlet te implementeren.

Nogmaals: voor read-only operaties kan het geen kwaad (je maakt geen wijzigingen aan de database), maar als je de klanten script-code geeft die de database ook kunnen wijzigen, dan kan het een "support nightmare" worden, zodra klanten aan die code gaan knoeien. Om die reden is alleen een read-only ODBC-toegang direct toegankelijk voor de klant (en dan kan de klant scripten wat ie wil), maar wil ik wel afdwingen dat de beperkte hoeveelheid (vooraf gedefinieerde) toegestane schrijf-bewerkingen via een API worden aangeboden en dat klanten de database dus niet zelf via ODBC mogen wijzigen met alle mogelijke complicaties van dien. Het bedrijf heeft echter al code geschreven, maar heeft dit (gezien in-house kennis en ervaring) in ActiveX gedaan.

[ Voor 18% gewijzigd door Verwijderd op 26-06-2003 02:04 ]


  • hobbit_be
  • Registratie: November 2002
  • Laatst online: 04-07-2025
en nu heb je nog steeds niet gezegd hoe de request worden doorgestuurt....

met java is zoiets op 1 dag gedaan (zelfs voor een newbie) met JBDC (wat op zowat elke known Database werkt). Dan maak je gewoon een servlet die in feite zoals jij bedoelt een SOAP/XML-RPC server is. Die laatste zijn allemaal gemaakt en dan wordt het echt POEP simpel. MAAR wil je nu eindelijk zeggen wat er CLIENT side gebeurt....???? is het een pure HTML pagina met een form : if yes -> no problem (echt niet) (ook niet met PHP ofzo), if not dan wordt het al wat moeilijker...

Verwijderd

Topicstarter
hobbit_be schreef op 26 June 2003 @ 14:37:
en nu heb je nog steeds niet gezegd hoe de request worden doorgestuurt....

met java is zoiets op 1 dag gedaan (zelfs voor een newbie) met JBDC (wat op zowat elke known Database werkt). Dan maak je gewoon een servlet die in feite zoals jij bedoelt een SOAP/XML-RPC server is. Die laatste zijn allemaal gemaakt en dan wordt het echt POEP simpel. MAAR wil je nu eindelijk zeggen wat er CLIENT side gebeurt....???? is het een pure HTML pagina met een form : if yes -> no problem (echt niet) (ook niet met PHP ofzo), if not dan wordt het al wat moeilijker...
Nee, volgens mij beschrijf jij dat best wel aardig zo.

Ik ben er inmiddels achter dat het mijn opdrachtgever niet per sé om ActiveX gaat, maar dat ze op dit moment Visual Basic als ontwikkelomgeving gebruiken. En Visual Basic code voor websites is zover ik weet alleen in ActiveX-vorm te realiseren.

De vraag is dus: kan Visual Basic code makkelijk geport worden naar andere platforms? Ik weet dat er een dergelijk project bestond (Visual Basic voor Linux). Of zal men moeten overstappen op bijvoorbeeld Java en zo ja, hoeveel moeite is dat voor iemand die Visual Basic kennis heeft?

Verwijderd

Topicstarter
Oh, shit... This doesn't look good:
Date: 11-7-00 "So far, there are currently 3 developers for the VB4Linux project. We'll probably begin in about a week or so... Still looking for more developers!"
Site: http://vb4linux.sourceforge.net/

Hier zal ik in elk geval niet veel aan hebben, vrees ik. :+

Verwijderd

Topicstarter
Oh, wacht, hier heb ik wellicht wat meer aan: http://www.janus-software.com/

Het heet Phoenix Object Basic. Gratis te downloaden en vrijelijk te gebruiken. De source is echter niet vrijgegeven, maar dat is geen ramp. Heeft iemand hier ervaring met dit product (of iets soortgelijks)?

Persbericht over Phoenix Object Basic: http://linuxpr.com/releases/2611.html

Ook is er nog KBasic, een Basic-ontwikkelomgeving voor KDE, maar hier wordt het me niet zo gauw duidelijk of het wel compatible is met VB. Oh, wacht, uit de FAQ: "And please remember: KBasic is not a VB clone." Okay, dat valt dan kennelijk ook af. :(

[ Voor 48% gewijzigd door Verwijderd op 27-06-2003 17:43 ]


  • hobbit_be
  • Registratie: November 2002
  • Laatst online: 04-07-2025
je zou eventueel Mono en VB.Net kunnen gebruiken. Persoonlijk zou ik gewoon met Java werken want:

a) je weet dat het gaat werken
b) het erg eenvoudig is - java is echt gemaakt voor netwerk / database spul
c) het helemaal niet uitmaakt op welke OS (nou ja FreeBSD moet je nog wel een oude versie pakken)

Maar zoals ik het dus begrijp heb je geen een paar HTML paginas met daarin wat forms en die moeten dus serverside iets doen. Tja PHP gaat dan ook net evengoed - maar je wou dat de customer de code niet kon zien toch. Tja elke taal kun je dessassembleren :) Java dus ook en als je een JSP gebruikt - daar zit de code ook los op (tenzij je met Beans / Tags gaat werken). Zelf schrijf ik het liefst pure servlets (ie een JSP word uiteindelijk ook maar een servlet) of Java - servers (voor persistant connections - dus niet applicabel op typisch webforms).

Kun je ons een voorbeeldje geven van wat de data is die de client opstuurt? Lijkt me dat jullie allemaal heel moeilijk doen voor iets dat wel erg eenvoudig is...
Pagina: 1