Vagy nagyon advanced dolgot akarok, vagy nagyon nagy hülyeséget, ez remélem hamar kiderül, mindenesetre az élet tranzakciók nélkül piszok nehéz tud lenni, még akkor is ha web servicekről van szó. Persze egyszerű esetekben (örüljön az akinek a munkája egy egyszerű eset) egy tranzakcióban egy WS hívás van, ha sikerül akkor azt lehet mondani hogy oké, ha meg elfekszik akkor rollback és megpróbáljuk később esetleg. Nem ilyen ideális az élete azoknak akik kénytelenek egynél több hívást indítani egy tranzakcióban, főleg ha adat módosításáról van szó.
Kicsit utánnanéztem a WS-AtomicTransaction speckónak, találtam hozzá egy WSDL-t is, szóval akár implementálni is lehetne, csak elöbb gondol, mert annyira azért mégsem sürgős. A saját implementáció azért merül fel lehetőségként, mert még mindig senki sem csinálta meg. Pedig már nem annyira új a dolog, kiváncsi vagyok mi lehet az oka.
Mindenesetre egyelőre egy implementáció lehetőségét keresem, nem túl bonyolult, a kliens oldara kell egy tranzakció interceptor ami a kliens oldalon figyeli hogy létezik-e tranzakció, a hívott WS támogatja-e a tranzakciókat, meghívja a WS-Transactions api megfelelő hívásait, aztán prepare és commit esetén ilyesmi. A szerver oldalon pedig a transaction-managerrel kell összehuzalozni.
Húú, ha csak ilyen igazságosztásból kellene megélnem biztos rohadt könnyű lenne. A gond például a prepare hivásnál van, ahhoz programozói szintről vajon hogy lehet hozzáférni... Sehogy, mi?
Ilyenek lesznek...
Pár link..
- Guy Pardon előadása a Javapolison
- WSDL (Lényeg)
- Speckó, ezt is el lehet olvasni...
