Child pages
  • EJB + ESB == SOA ?
Skip to end of metadata
Go to start of metadata

Van egy JEE alkalmazasom es most egy masik rendszerrel kellene adatokat cserelni, web-service-n keresztul. A kerdes az, hogy ha web-service-t epitek az alkalmazasomba, attol mar SOA (ez  SOA is olyan tag fogalomnak tunik nekem) standard lesz? Vagy kellene ESB, hogy SOA standard legyen? Mivel osszesen alig par hivasrol van szo, ezert nem annyira latom ertelmet az ESB bevezetesenek, ill. rule-ok sem lennenek es transzformacio sem. Erdemes ESB-t tenni kozejuk esetlegesen a jovore gondolva (ha barmelyik fel is valtoztatna valamit, akkor eleg lenne az ESB-t butykolni)? Masik kerdes, hogy az ESB-t lehet-e ear fileba csomagolni(egy szerveren futna a JEE alkalmazas es az ESB termeszetesen)? Bar az a tippem, hogy ezeknek kulon kellene futniuk ez esetben is, akkor lenne szep architekturalisan, vagy nem? (smile)

 

      
      
Page viewed times
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels

5 Comments

  1. Ha nincs rá szükséged, ne használd. Lásd KISS elv. A SOA-t amúgy is minden cég a saját szája szerint értelmezi. Ha pályázat miatt, kell, bármibe SOA-t lehet magyarázni. (smile) Amúgy ha az architektúra azon alapul, hogy a rendszereidre, mint szolgáltatást nyújtókra, s azokat igény bevevőkre gondolsz, amelyek lazán kapcsolódnak egymáshoz, már jó lesz. Igazából SOA-ra én csak nagy számosságú rendszer esetén gondolok, két alkalmazásnál még mindegy. Én nem tenném egy alkalmazásszerverre sem az ESB-t, mivel az egy single point of failure, legyen független az alkalmazásoktól, és általában sokkal magasabbnak kell lennie a rendelkezésre állásának, hiszen ha az leakad, akkor minden leakad.

  2. ESB-t akkor vezess be, ha masszívan aszinkron a kommunikáció és szükséged van rugalmasabb transzformációkra. ESB-t nem feltétlen tudsz EAR-be csomagolni, általában különálló termékek.

  3. Köszi szépen a válaszokat. Egyébként végül úgy döntöttem, hogy az EAR-ban lesz még egy EJB modul a web-servicek-nek és arra azt mondom, hogy SOA architektúra, hisz az meg majd szépen meghívja a EJB-ket. (smile)

     

    Igazából SOA-ra én csak nagy számosságú rendszer esetén gondolok, két alkalmazásnál még mindegy

    De ilyenkor már értelemszerűen jön az ESB is? Vagy milyen alternatívák léteznek? Csak az ESB-t ismerem, azzal votl eddig tapasztalatom.

    Másik kérdés esetleg: Sajnos még JBoss 6.1.0-Final-on fut az alkalmazás(amikor indult a fejlesztés, akkor még sehol nem volt a 7-es és még 6.1 Final sem volt), amin ha nem muszáj, akkor nem változtatnánk. Viszont nekem is kell hívni web-serviceket a másik rendszerből. Ezzel nem lenne gond, mert legeneráltam a kliens oldali bean-ket wsimport-al, viszont a hívás hibára fut, valami Spring bean-ket nem talál. Gyorsan utánanéztem, elvileg a JossWS-CXF-et kellene telepítsem. De ahogy nézem, a 3.4.1GA nem támogatja még a 6.1 AS-t a 4.0 meg már nem... Szóval, a 3.4.1 megy a 6.1-el szerintetek (a konfig fileban csak 6.0.1-et láttam)? Mondjuk holnap legkésőbb kiderül, de ha más már esetleg szívott ezzel, akkor elkerülném. (smile)

  4. Nem feltétlenül jön bonyolultabb rendszereknél az ESB, vannak még régi technológiák, EAI, message broker, ilyenek. Nem mindenhol van költségvetés/tapasztalat a SOA-ra.

    A második kérdésed nem is értem, de remélem megoldódott. (smile)

  5. Igen, szerencsére megoldódott a második kérdésem is, igazából ez egy kompatibilitási kérdés volt. Végülis 6.1.0 AS-re sikerült a JBossWS-CXF 4.0-CR1-et feltenni, és azzal ok minden. Csak hát a verzió nem tetszik, de hát a korábbi és későbbi GA verzió nem támogatja a 6.1.0-ás AS-t. Valószínű előbb vagy utóbb úgy is át kell állni majd 7.1.1-re, akkor majd rendbe tesszük.