C++ Als Backend

jd

Hallo Gemeinde,

wir sind gerade da bei eine Software zu entwickeln, für Datenauswertung (Geldstatistik) zum Anfang war für uns klar das der Vertrieb von Libraries(C++) das kreterium darstellt. Und ist an sich für Entwickler gedacht,
die diese Libraries dann in Ihren Produkten verwenden kann. Das hat sich an sich sehr gut angehört und wir haben auch schon einige Aufträge bekommen. Nun bekomme ich aber mit steigender Häufigkeit anfragen
wie es denn aussieht Mit anderen Produkten sprich Java-Applikation, PHP, etc...

Wir denken uns halt wenn wir nur Libraries verkaufen, würden wir halt nicht an alle verkaufen können. Jetzt versuche mich mir gedanken zu machen wie ich das Problem lösen kann. Da ich natürlich nicht für jede sprache eine
Schnittstelle entwickeln kann, muss was anderes her, was Sprach-Unabhänig ist.

Ich habe da 2 Ideen gehabt.

Option 1:
Man macht nehmen den Lirbraries noch einen Daemon der XML versteht. Wenn man das mit XML vernünftig macht dürfte es an sich kein Problem sein mit dem Darmon zu kommunizieren.
Was dagegen spricht ist, das man immer einen XML-Parser zu hand haben muss (Für die jeweilige Sprache), was auch nicht so ohne ist. Ich persönlich finde XML nicht so einfach zu Parsen, es ist zwar auch nicht schwer,
aber es hat auch einen relativ hohen Aufwand jenach dem wie die XML Schnittstelle gestrickt ist.

Option 2:
Wie schaut es den mit Webservices aus. Ich ziele da speziell auf SOAP ab. Aber ich kenne mich im bereich Webservices so gut wie garnicht aus. Aber wenn ich mir zB Map-Server anschaue die Geo-Daten via Webservice anbieten,
gehe ich mal davon aus das ein Webservice genug Power hat.

Was mich auch interessiert ist wie würde es denn mit der Sicherheit bei SOAP stehen.

Geplant ist jetzt also einmal der Entwicklung / Vertrieb von Libraries (für Entwickler) und ein Daemon als Backend der Sprach-Unabhänig läuft.

Oder gibt es auch noch andere Optionen, die ich eventuell nicht beachtet habe? Zu was würdet ihr mir raten?

Bin über jeden Rat dankbar.

so long
jd

nep

Irgendwie versteh ich dein Posting nicht so ganz...
Laufen bzw. liegen diese Bibliotheken auf einem Server, so dass man als Entwickler entfernte Methodenaufrufe durchführen muss, oder sind das ganz normale lokale Bibliotheken (also z.B. DLL Dateien die man sich einfach bei nem Projekt dazu linkt)?

Zur WebService-SOAP-Frage: SOAP-Nachrichten werden ja immer mit einem anderen Protokoll transportiert, z.B. HTTP. D.h. im unterliegenden Protokoll könnte man dann z.B. auch HTTPS benutzen. Das ist allerdings nicht die beste Möglichkeit. Es gibt aber innerhalb der WebService-Standards einige Ansätze zur Sicherheit, wobei ich nicht weiß wie ausgereift (bzw. vor allem wie weit standardisiert) das alles ist. Als ich mir das das letzte mal angeschaut hab (ist aber schon länger her) gabs da scheinbar noch Probleme.

jd

Hallo,

ja das sind Lokale Bibliotheken die man sich dann hinzu linken kann. Die Sache ist jetzt wie gesagt die, das die Libs nicht nur für C++ sein sollen, sonder auch für Java PHP etc. Viele wollen halt nur Webbased krämpel.

Da habe wir uns halt überlegt wie wir das hinbekommen das wir es von der Programmiersprache unabhängig machen können.

Mir sind da 2 Wege eingefallen einen Daemon(Linux-Daemon) schreiben (der alle lokalen Libs enthält und zusätzlich eine XML-Schnittstelle verpasst bekommt, um die Kommunikation zu gewärleisten.)

Somit wäre es kein Problem mit dem Daemon zu kommunizieren. Alternativ habe ich wie gesagt über einen Webservice nachgedacht. Aber das was du mir da so erzählt hast, klingt nicht gerade erfreulich.

So das ich Quasi unsere Software nicht nur als Libs anbieten kann, sonder auch als komplettes Backend für jede Programmiersprache.

jd schrieb:

So das ich Quasi unsere Software nicht nur als Libs anbieten kann, sonder auch als komplettes Backend für jede Programmiersprache.

aber als libs würde ich die trotzdem in unterschiedlichen varianten anbieten. nicht jeder kann oder will mit 'nem webserver kommunizieren. die gängigsten systeme haben ja alle irgendwie 'ne möglichkeit, externe libs zu benutzen. also machst du einfach verschiedene 'hüllen' um deine libs, z.b. eine für PHP, eine für Java, einmal als linux.so, einmal als windoze-dll usw. so schlimm wird das schon nicht.

nep

Richtig.
Also das XML bzw. WebService-Gedöhns passt hier nicht wirklich...
So viele Sprachen werden das auch sicherlich nicht sein.

Auch wenns nicht mehr so zeitgemäß ist, kannst du ja auch z.B. einen COM-Wrapper außen rumbauen (sofern das Zeugs auf Windows läuft, ansonsten halt für jede Sprache eigene Schnittstellen). Damit hast du schon mal alle Microsoft-lastigen Sprachen erschlagen. Rein theoretisch kann man ja sogar auch mit Java COM-Objekte benutzen, aber da wärs wohl besser direkt ein eigenes Java-Interface zu bauen.

jd

Ich gehe jetzt mal von PHP aus, da es kein Neuland für mich ist.

Du meinst also eine Extension für PHP sprich solche teile die man bei: http://pecl.php.net/ runderladen und installieren kann, die bekannteste ist da wohl die APC-Engine. So da ich mir ja den Code angucken kann musste ich gerade feststellen das es auf C geschrieben ist. Ist bei solchen Extensions nur C erlaubt oder geht da auch C++. Wenn da nur C erlaubt ist, fällt das aus. Aber an sich eine schicke Idee, sofern ich dich richtig verstanden habe.

rüdiger

Schau dir mal SWIG an: http://www.swig.org/

jd

Also, ich muss sagen, was ich bis jetzt gelesen habe ist echt der blanke Wahnsinn.
SWIG scheint genauch das zu sein was ich will, und ist mir auch schon sehr sympatisch zwecks CMake support

Vielen Dank für eure Hilfe, werde mich gleich mal an die Doku ran setzen.

so long

jd

jd schrieb:

Ist bei solchen Extensions nur C erlaubt oder geht da auch C++. Wenn da nur C erlaubt ist, fällt das aus.

du kannst doch exportierte C++ funktionen als extern "C" deklarieren. dann ist es C-aufruf kompatibel.