1) XSLT - получаем сырой XML, трансофрмируем его к нужному виду, делаем POST на удаленный веб-сервис;
2) Jibx - получили сырой XML, преобразовали его к value object'ам по одному маппингу, потом преобразовали обратно в XML уже по другому мапипнгу, POST на удаленный веб-сервис.

JIBx это просто как идея, что можно сделать маршаллинг/анмаршаллинг, как одно из решений.
SAX/StAX - это, пожалуй, самое быстродейственное решение в принципе, но в то же время и самое "грязное" с точки зрения количества java-кода, который к тому же невозможно экстернализовать. Так что тут все зависит от деталей контекста задачи автора.

Blazkowiczsvenomсамое "грязное" с точки зрения количества java-кода
Почему??? На SAX вообще меньше всего кода будет. Всё что не нужно обрабатывать просто копируется как есть. Всё что нужно - заменяется. Если проанализировать нужно в одном месте, а заменить в другом, то тоже делается проще некуда - дампим в буфер, пока не будет всех данных для замены.Ну это и есть та самая громоздкость. Даже при средней сложности структуры XML работа с SAX быстро превращается в АДъ. Например, надо вам заменить тег с именем NAME1, вложенный в определенный тег NAME2, но при этом NAME1 встречается и в других местах. Что вы будете делать? Отслеживать "состояние" вашей позиции. А если у вас 5 таких мест? 5 состояний уже отслеживаете. Перебросить значение из одного места в другое? Еще + 1 состояние. А если вам в начало отправляемого документа надо вставить значение из конца исходного документа? Еще бОльшая жопа - SAX то у нас one-way. Как результат - трудноподдерживаемое спагетти. Поэтому самый true-подход здесь XSLT - чистенько и экстернализуемо. Но, конечно, несколько медленнее, чем SAX/StAX, которые можно потоково читать, потоково процессить (но, как я уже показал выше, не всегда), и потоково выдавать в сокет приемника.

Blazkowiczsvenomкоторый к тому же невозможно экстернализовать.Это как?SAX/StAX: изменились правила обработки XML - придется править Java-код.
XSLT: просто поменяли экстернализованные шаблончеги.