Здравствуйте, denis_krg, Вы писали:

_>Задачи имеют тенденцию к усложнению. Это раз. Во-вторых трудоемкость резко возрастает. К тому же квалификация программиста, который должен писать разбор ХМЛ на САКС должна быть выше средней. В итоге в реальных проектах САКС практически не используют.

_>Потом. Мы ведь к тому же умолчали о том, что нагрузка на каналы в случае использования ХМЛ в качестве формата данных увеличивается в 3-5 раз. К тому же, если мы используем веб-сервисы это еще одно кратное увеличение требований к каналам.

_>В итоге по сравнению с бинарными форматами увеличение нагрузки на каналы просто убийственное. Причем особого выигрыша по сравнению с тем же RMI в простоте мы не получаем (я говорю про жаба-жаба).


_>Потом. У нас кроме разбора ХМЛ в бизнес-приложении будет еще и разбор ХМЛ, который есть вызов веб-сервиса. А там, я почти уверен (поправьте меня если ошибаюсь) — дом-модель со всеми ее тормозами и дикими требованиями к памяти.

Ошибатесь. SAX парсеры наоборот DOM модель не грузят целиком в память, а работают на событийном принципе, поэтому они в разы быстрее и экономней чем DOM-парсеры при разборе большого объема данных. Маленькие объемы проще DOM-ом разобрать: во-первых быстрее, во-вторых проще.

_>>>А Вы писали разборщики XML используя SAX? Если ХМЛ более-менее сложный это чрезвычайно трудоемкое занятие. Так что можно с чистой совестью говорить о том, что SAX-а для разработчиков бизнес-систем нет.

_>>>>>Если нужна производительность — нужно избавляться от XML и ВебСервисов. Другого пути нет.

Мы ж не в каменном веке живём. Есть XStream, котоорый сериализует любой объект вызовом одного метода, toXML(Object obj). Умеет юзать аннотации (свои).
Есть тулза, которая называется JAXB 2.0, построенная на сановской спеке. Она даже с XFire интегрируется путём прописывания одной строчки в конфиге. РАзбирает всё аннтациями. Так что не обязательно писать SAX-парсер, если уж вы не разбираете какой-то мегакривой xml.