Cześć, zanim zadam krótkie pytanko, postaram się opisać sytuację.
Posiadam masę kodu w C++/Fortranie(pliki zawierają funkcje które trzeba wywołać), w którym napisane są funkcje do oblicze MES. Chciałbym do tego napisać prosty REST, aby ułatwić sobie i innym uruchamianie takich zadań. Do tego potrzebuje zintegrować jakieś narzędzie, w którym będę monitorował, kiedy taka funkcja została uruchomiona i zakończona (nie wiem czy Prometheus + Grafana to dobry wybór). Finalnie, przejdę do pytania. Czy wybierając Jave do stworzenia tego REST'a będę miał duży problem z uruchomieniem w Javie tych funkcji z C++? Czy gra jest warta świeczki, czy lepiej stworzyć tego REST'a w C++, gdzie mogę sobie bez problemu wywoływać te funkcje, jednak wtedy mam mały problem z Prometheusem, gdyż nie ma oficjalnej libki do C++, a i w przyszłości pewnie chciałbym postawić coś do logów. Chciałbym spróbować stworzyć to w Javie, ze względu na szybkość stworzenia takiej aplikacji w porównaniu z C++, ale nie wiem czy to nie będzie overkill, kombinowanie z JNI lub tym podobnymi, chyba że są inne rozwiązania o których nie mam pojęcia, a ktoś mógłby mi doradzić? Z góry dziękuję za wszystkie pomysły i propozycje, każda krytyka i rada jest mile widziana.
Oprócz JNI jest jeszcze JNA: https://en.wikipedia.org/wiki/Java_Native_Access które ma wymagać mniej akrobacji z integracją.
Teoretycznie GraalVM potrafi kompilować jednocześnie Javę i C++, ale to dalej projekt eksperymentalny
Ja bym osobiście zapiął do tego Pythona. Postawienie RESTa flaskiem to 3 linijki, a odpalanie skompilowanych funkcji jest trywialne.
Jeżeli chcesz iść przez RESTful WS, to ja proponuje:
Java -> JNI -> C++/Fortran
Pamiętaj - czeka cię tak naprawdę:
Java -> JNI -> C -> C++/Fortran
Tutaj znajdziesz dużo przykładów dotyczących JNI: https://github.com/mkowsiak/jnicookbook.
Zawsze możesz całość w miarę sensownie opakować Dockerem - ten przykład nie jest wprawdzie tym, czego szukasz, ale jest czymś w rodzaju "prawie już": https://gitlab.com/mkowsiak/converter-docker.
Możesz też banalnie opakować Dockerem cały toolchain Fortrana - https://github.com/mkowsiak/coarrays-docker
Jeżeli nigdy nie debugowałeś aplikacji JNI to przygotuj się na to, że gdb/lldb albo CLion zostaną twoimi dobrymi przyjaciółmi: Debugging JNI code with IntelliJ/CLion
Jeżeli zdecydujesz się kroczyć ciemną ścieżką JNA, to tutaj znajdziesz świetną listę przykładów: https://www.eshayne.com/jnaex/.
A tutaj tekst: The good, the JNI and the JNA - czyli dlaczego "Hello world" w JNA jest wyczepiste, a potem są już tylko schody.
JNI to mordęga (z doświadczenia własnego i współpracowników, którzy robili to na co dzień). Jest trudne w użyciu i wymaga sporo uwagi, by doprowadzić go do prawidłowego działania (nie ma kontroli w trakcie kompilacji, łatwo się robi literówki, które są trudne do wykrycia).
JNA jest dużo prostsze w użyciu, ale wolne i jest pomostem tylko do C, a nie C++, więc w praktyce będziesz miał dwa pomsty Java->C oraz C->C++.
Rozważyłbym alternatywy dla Java. Wspominany już przez Shalom Python (nie praktykowałem), albo C# (to robiłem).
Pomosty między C# i C++ są bardzo łatwe do zrobienia, dużo jest zautomatyzowane, a to co z jakiegoś powodu nie działa w automacie, można łatwo ręcznie dostosować używając C++CLI. Wadą jest kotwica do Windows.
No w pythonie to jest:
lib = cdll.LoadLibrary("mojalibka.so")
lib.mojaFunkcja()
więc dużo roboty nie ma ;)
Czy wybierając Jave do stworzenia tego REST'a będę miał duży problem z uruchomieniem w Javie tych funkcji z C++?
Tak. Produkcyjnie robiłem takie manewry z użyciem Javy oraz NodeJS i z tej pary zdecydowanie wybrałbym NodeJS. Mimo, że samego NodeJS wciąż uważam za pół poważną technologie, tym nie mniej samo doklejanie natywnych bibliotek przychodziło całkiem naturalnie, zaś w JNI miałem poczucie jakbym hakował VMke i narażał jej stabilność, do tego ta konieczność generowania kodu. Takie były moje subiektywne odczucia przynajmniej.
Poza tym, jeśli faktycznie potrzebujesz tylko prostego RESTa to z NodeJS będzie dużo prościej wystartować, footprint na maszynie mniejszy i samego "adminowania" również dużo mniej.