Ukládání a přeposílání SOAP zpráv rubrika: Programování: Java

Anonym
položil/-a 22.4.2017
 
upravil/-a 22.4.2017

Ahoj,
v práci jsem se dostal k zajímavé Java aplikaci. Máme testovací SOAP server, který je taková ořezaná verze reálného SOAP serveru. Byl vygenerován z XSD schemata za pomocí JAX-WS. Tento server momentálně zobrazuje přijatá a odesílaná data v konzoli a přes UDP je možné mu nastavit odeslání nějaké hodnoty do konkrétního klienta nebo se ho naopak dotázat na přijatá data z konkrétního klienta. Tyhle data přes UDP posílá/vyčítá typicky test nebo do budoucna například UI aplikace. Momentálně si drží jen poslední přijatou zprávu v paměti jako objekt.
Když se dotážu na nějaké hodnoty z klienta, vrátí mi je jako String v custom formátu přes UDP.
A tohle řešení je na houby. Chci přidat podporu pro vyčítání dalších hodnot a serializovat to na straně serveru do Stringu v custom formátu a v testu to zase deserializovat je na pytel, zvlášť když už mám z JAX-WS vygenerované entity a mohl bych rovnou pracovat s objekty nebo to aspoň skoro bez práce serializovat do XML.
Jaký způsob a formát byste doporučili při komunikaci mezi testem a tím SOAP serverem?
Přemýšlel jsem nad několika možnostmi. Jako první krok bych si přijaté zprávy ideálně ukládal do nějaké embedded databáze (nebo aspoň do nějaké fronty v paměti). A jak vyřešit komunikaci mezi serverem a testem je věc druhá. Napadlo mě buď klasické REST API+JSON, XML přes TCP nebo přímo posílat serializované objekty přes TCP.
Ideálně se co nejvíc vyhnout nějakému manuálnímu parsování/serializaci/deserializaci a využít vygenerované entity z JAX-WS. Vidí na ně i test, takže to by nebyl problém.

EDIT:
Reálný server je obrovská aplikace s grafickým rozhraním a slouží k managementu jednotlivých klientů. Jdou přes to nastavovat parametry (do klientů), provádět firmware upgrade a naopak vyčítat různé hodnoty a zprávy.
Tu řeší jiný tým a je poněkud dost neflexibilní, takže pro účely vývoje a testování v našem týmu (programujeme ty klienty) jsme si vytvořili ořezaný test SOAP server.
Komunikace je obousměrná, tzn. klient se periodicky každých pár minut dotáže serveru jestli má něco udělat. Mimo jiné v dalším vlákně odesílá zaregistrované informace (ty které si server vyžádal).
U testu řeším například takovýto use case (pro ilustraci hodně přitažené za vlasy):
1) Nastartuj testovací SOAP server
2) Nastav do klienta spojení se SOAP serverem a zahaj komunikaci
3) Zeptej se serveru jestli klient s daným ID poslal korektní hodnoty v úvodním requestu na server
4) Nastav do klienta ať spočítá 10+10 a výsledek pošle na server
5) Zeptej se serveru jestli klient s daným ID poslal výsledek=20
6) Nastav do serveru ať na klienta pošle příkaz s upgradem firmwaru na verzi 999, který se nachází na URL XYZ
7) Zeptej se serveru jestli klient s daným ID poslal zprávu s úšpěšně dokončeným upgradem
7) Vypni testovací SOAP server

Komunikace testu s klientem je řešená přes websockets+JSON, komunikace testu se serverem je momentálně UDP+stringy.

Komentáře

  • harrison314 : Mozno by bolo lepsie, keby pipises trosku sirsi kontext na co ten server. 22.4.2017
  • Anonym : Doplněno :-) 22.4.2017
odkaz Vyřešeno
8 tdvorak
odpověděl/-a 24.4.2017

Asi bych ty přijaté a odesílané zprávy serializoval do XML pomocí JAXB, když už máte vše generováno ze schématu. Tady třeba ukázka, jak to řeším v javě pro EET: https://github.com/todvora/eet-client/blob/client-interface-changes/src/...

Nemusíš tak řešit vlastní formát a při změně schématu se ti automaticky vše překlopí na novou strukturu.

Samotnou komunikaci mezi testem a SOAP serverem bych pak asi postavil na ZeroMQ: http://zguide.zeromq.org/page:all

Asi bych si nechal posílat každý request/response přes pub-sub, přes request-reply pak nějaké dotazovací a control API. Pro asserty v testech to klidně znovu deserializovat pomocí JAXB zpět na objekty.

Data pak přes JPA ukládat do nějaké databáze, JPA tě odstíní od toho, jestli je to teď in-memory / in-file H2 nebo Oracle v budoucnu.

Když si budeš všechny requesty a response publikovat do nějakého topicu, můžeš pak v testu pozorovat celou komunikaci a nemusíš se periodicky dotazovat, co poslal klient, co odpověděl server. Prostě jen posloucháš, jak si spolu povídají, nastavíš očekávané asserty a timeouty.

Komentáře

  • harrison314 : Trochu offtopic otazka ZeroMQ este zije? 24.4.2017
  • Anonym : Super, moc díky za tipy. JAXB serializaci/deserializaci už mám více méňě zprovozněnou, použití fronty a JPA je super nápad. 24.4.2017
  • tdvorak : @harrison314: Řekl bych, že ZeroMQ stále žije: https://github.com/zeromq. @karelzpola: Raději bych na to pohlížel jako na protokol / komunikační platformu než na frontu v klasickém významu. V tom duchu bys pak možná mohl místo ZeroMQ použít stejně dobře websockets, abys netahal další technologii do stacku. Ta flexibilita asi nebude taková, ale třeba to pro tvé použití bude dostatečné. 24.4.2017

Pro zobrazení všech 2 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.