Dotaz: Perl - pridani web rozhrani k aplikace

[roman]

Dobry den, mam aplikaci v perlu, ktera bezi jako demon a resi komunikaci s nekolika zarizenimi pres RS232(obdrzi/posle do linek data), prijata data ze seriovych linek vyhodnoti a uklada do vlastni db (sqlite), dle nastavenych parametru posila do linek nova data, potud nic sloziteho.

Rad bych tento uzavrenych system propojil s cizim systemem, tedy aby si mohli vymenovat data, cizi system pozaduje predavaci rozhrani pres sadu webovych sluzeb (cas od casu si reknou o nejaka data, nebo naopak zaslou nejaky pozadavek).

Premyslel jsem tedy jak toho dosahnout a v jednu chvili se mi pomerne zacala libit db couchdb od apache, ktera cely problem s HTTP zastresuje, tedy sypal bych do ni data a vytvoril pro cizi system sadu "view", ktery by jim v json vracel hodnoty a naopak by dokazali stejnym zpusobem mi data predavat, bohuzel zde jsem narazil ja jedem problem a tim je nutnost mit moznost "okamzite" akce na pozadavek zaslany z ciziho system (tedy necekat ve smyslu, ze ja budu z perlu v intervalech poolovat couch db na nova data a pak neco vykonam, ale resit neco hned). (navic noSQL neni uplne idealni pro me, ale to bych prekousnul, libilo se mi hlavne to vyreseni HTTP komunikace)

Takze co s tim? Nechce se mi zrovna kvuli tomu pridani "web rozhrani" do aplikace instalovat na muj system apache nebo snad PHP a zpracovavat pozadavek, ten predat nejak do me aplikace, vratit zpet data apod silenosti.

Napadlo me to nejak zkusit vyresit treba s nginx a fastcgi , ale nevim zda-li to lze udelat s perlem nejspise ano a zda-li je to prijatelne stabilni.

Nejaky napad? Nelze obalit perl nejakym modulem co mi takoveto rozhrani poskytne?

Diky za podnety. Roman

Odpovědi

[camel1cz]

Zdravím,

nejsem si úplně jistý v čem je problém. To původní řešení s couchdb mi stejně příjde na to co potřebujete zbytečně složité (jedině jestli jste nechtěl migrovat to sqlite do couchdb).

Tím, že to musí být synchronní webservice je dost omezený výběr...

Vídím varianty: a) nainstalovat apache (popř. něco lehčího - boa atd.) a v perlu udělat alternativního klienta do vaší aplikace b) napsat přímo v perlu nového démona co bude implementovat HTTP server (knihoven, co to zvládnou na 5 řádků budou mraky) c) upravit stávajícího démona ve smysl u bodu b) - prostě že by nezpracovával jen data z sqlite, ale i z příchozích HTTP requestů asynchronně

webservice/rest interface nebude v perlu určitě žádný problém.

[roman]

Diky za reakci, ano puvodne jsem uvazoval vymenit kompletne sqlite za couchdb, ale trochu me odrazuje prave fakt, ze couchdb jr ne bezschemova/dokumetova db, data mam jasne dana (zadny "chaos", jsou jasne organizovana do tabulek), velkou devizu vidit u couch db prave v tom HTTP rozrahni, ktere se mi opravdu libi a vymysleno je to velmi velmi dobre.

Neexistuje takove rozhrani i k nejake jiz exsitujici SQL db (napr. mysql)?

Body b/c si dovedu predstavit, jak je mysleno A (s tim klientem netusim)? Muzete to rozvect, prilis se mi nechce implementovat web server v perlu. R

[camel1cz]

No úvodem - protože potřebujete synchronní webservice, tak vám přímé HTTP rozhraní do DB moc nepomůže - stejně nestačí ten požadavek zaspoolovat.

Ze zadání mi vychází, že je nutné zavolat přes webservice přímo kód vaší existující aplikace a jeho výsledek ihned vrátit.

Tedy mé závěry:

1) změna DB nesouvisí s požadavkem na zřízení webservice a tedy bych jí pro teď dal stranou

2) není dobré řešení dělat standalone démona jen na webservice (možné souběhy, tahání se o RS232 atd.)

3) stejně tak není dobré komunikovat skrze SQL

4) bude nutné rozšířit stávajícího démona o možnost poslat nový request - toto bude vyžadovat nějaký komunikační protokol, implementovaný v démonovi.

Podle toho co vím, tak bych opravdu napsal přímo v tom perlu HTTP server (např. HTTP::Daemon) a případné požadavky řešil podobně jako ty interní - má to výhodu, že se nebudou dít souběhy, budete požadavky zpracovávat sériově a tak jak bude linka stíhat - navíc to rozhraní ke stávajícímu démonovi stejně bude nutné a tedy proč by nemohlo být rovnou přímo webservice?

Jako alternativa mi příjde právě to, co se mi nelíbí v bodě 3) - komunikovat skrze SQL - webservice by pak vložila do SQL požadavek a pak aktivně čekala např. 30s, jestli se v DB objeví odpověď. Ale jak říkám, moc se mi to nelíbí...

P.S. O webservice rozhraní k běžným databázím nevím

P.S.2. Tím bodem a) sem myslel vytvoření aplikace přístupné přes HTTP, která by podstrčila démonovi data a počkala si na výsledek.

[Ladicek]

bohuzel zde jsem narazil ja jedem problem a tim je nutnost mit moznost "okamzite" akce na pozadavek zaslany z ciziho system (tedy necekat ve smyslu, ze ja budu z perlu v intervalech poolovat couch db na nova data a pak neco vykonam, ale resit neco hned)

_changes?feed=continuous, totéž v The Definitive Guide