Zalety ręcznej obsługi web serwisów

Czy możliwe jest zaimplementowanie web serwisu bez wykorzystania żadnego frameworku typu Axis, CXF czy JAX-WS? Ba, bez wykorzystania jakiegokolwiek wsparcia dla przetwarzania XML typu JAXP czy JAXB? Choć może się to wydawać pomysłem gorączkującego programisty, coś takiego zostało zrobione w projekcie, w którym obecnie pracuję.

Gdy natknąłem się na fragmenty kodu odpowiedzialne za renderowanie requestów SOAPowych przy pomocy konstrukcji typu

request.append("<?xml version="1.0" encoding=\"UTF\""?>")

i parsowanie odpowiedzi przy pomocy

response.indexOf("<soap:envelope"),

w pierwszej chwili nie mogłem uwierzyć własnym oczom. Składanie i rozkładanie XMLa na części przy pomocy podstawowego API Javy, konwersja znaków specjalnych, przepisywanie danych do klas Javy i na odwrót - żmudna praca, której nigdy nie przyszłoby mi do głowy wykonywać ręcznie.

W czasie, kiedy opracowywałem propozycję ponownej implementacji funkcjonalności, za którą odpowiedzialny jest powyższy kod, wydarzyły się jednak trzy rzeczy, które nieco rozszerzyły mój pogląd na tę sprawę.

Po pierwsze, w web serwisie, z którym komunikuje się wspomniany kod, zmodyfikowano kontrakt poprzez zmianę namespace. Projekty, które wykorzystywały ten web serwis, musiały się do tej zmiany zaadoptować - wygenerować nowe klienty na podstawie kontraktu, a następnie wypuścić nowe wersje aplikacji. Lecz nie wszystkie - w przypadku kodu, o którym wspominam, wystarczyła jedna zmiana w pliku konfiguracyjnym i wszystko działało jak przedtem.

Po drugie, podczas poszukiwania przyczyn pewnego błędu w systemie konieczne było przeanalizowanie żądań wysyłanych przez klienta do web serwisu. Zazwyczaj robię to przechwytując komunikację przy pomocy Wiresharka, co jest dosyć kłopotliwe w przypadku gdy spośród dziesiątek komunikatów trzeba wysupłać ten, o który chodzi. Tymczasem ręczne generowanie XMLa ma tę zaletę, że nie ma żadnego problemu z wpisaniem go do pliku, wyświetleniem podczas debuggowania itp.

Po trzecie, uświadomiłem sobie, że używając jakiegoś frameworku do obsługi web serwisów skazany jestem na używanie takich klas, jakie zostaną wygenerowane na podstawie WSDLa. Istnieje wprawdzie pewna możliwość manewru dzięki konfigurowaniu bindowania XML-Java, ale pewnych rzeczy się nie przeskoczy. Na przykład pomysłu, aby definiować kontrakt pobieżnie, tj. deklarować dla każdej metody web serwisu wartość string na wejściu i wartość string na wyjściu, a do tych stringów wkładać rozbudowane XMLe, których struktura nie jest opisana w WSDLu, tylko... czemu by nie... uzgadniana telefonicznie. Jest to oczywiście przypadek skrajny (z życia wzięty, niestety), ale problem pojawia się nawet wtedy, gdy WSDL zawiera wprawdzie opis struktury żądań i odpowiedzi, lecz struktura ta jest zła, bądź z jakichś powodów nam nie odpowiada. Tymczasem parsując odpowiedzi web serwisu ręcznie można dane przepisać do klas o całkowicie dowolnej strukturze.

Opisane przypadki nie zmieniły moich poglądów na to jak powinno się implementować web serwisy i nadal jestem za wyrzuceniem tego kodu i ponownym zaimplementowaniem funkcjonalności z wykorzystaniem np. JAX-WS. Uświadomiłem sobie jednak, że kod, na którym wieszałem psy, w niektórych sytuacjach wykazał się bardzo istotnymi zaletami.