Каким образом можно кэшировать Marshalled SOAP XML, созданный Apache CXF для конкретного объекта Java, чтобы повысить производительность?

Question

В моем приложении у нас есть метод webservice, называемый getFoo(), который возвращает объект Foo. Метод getFoo() вызывается несколько сотен раз в секунду. Объект Foo Marshalled от нашего объекта Java до XML-ответа SOAP с использованием Apache CXF.

Из профилирования нашего приложения мы определили, что сортировка этого объекта (java object -> soap encoded xml) является самым большим потребителем циклов процессора., и поскольку наш объект Foo не меняется очень часто, ремаркетинг этого объекта каждый раз не нужен.

Я понял, что это общая оптимизация и задается вопросом, как другие обратились к ней. Я кратко рассмотрел документы CXF, и есть перехватчик Marshall, который я, вероятно, мог бы использовать. Я мог бы создать карту, которая могла бы сопоставлять объекты Foo с XML-кодированной версией. Но тогда возникает несколько других проблем, например, как вы удаляете объекты с этой Карты, как только они больше не нужны и т. Д. Было бы неплохо, если бы была встроена поддержка для того, чтобы как-то обнаружить изменения объекта и перемаркировать. Ничего невозможного, но не хотел изобретать велосипед.

EDIT (6/16/09): Сделали некоторый прогресс, создав пользовательский BareOutInterceptor и изменив цепочку Interceptor, чтобы вызвать пользовательскую. Пользователь настраивает дополнительную логику только для вызова метода writeParts (....) ", который выполняет сортировку только один раз для данного java-объекта. Поставит решение после завершения. Кроме того, я переименовал этот вопрос.

Answer 1

Хорошо, это не тот ответ, который вы ищете, но в любом случае: причина, по которой REST используется в веб-службах с высоким трафиком (например, Google), заключается в том, что REST предназначен для кэширования - тогда как SOAP просто НЕ предназначен для быть кашируемым.

SOAP в основном основан на запросах POST без кэширования, а REST использует GET, который легко кэшировать.

Вам нужно будет проверить запрос SOAP (POST), прежде чем он перейдет к фактическому веб-сервису, то есть с использованием прокси-сервера. «Стандартные» прокси-серверы обычно не знают синтаксиса SOAP.

IBM's WebSphere Application Server though can do that

С уважением, Olaf

Answer 2

Там нет строгого требования в SOAP, что вам нужно использовать такую ​​структуру, как CXF для обработки сервера или клиента SOAP конечных точек. Мы просто столкнулись с тупиками клиентских потоков при использовании клиента SOAP на основе Axis 1.4, чтобы поговорить с сервером на базе Axis 1.1 и зафиксировали их, нажав Axis и выполнив запросы в рукописном коде. Мы должны были лгать на сервере Axis, сообщая, что у нас все еще есть клиент Axis, но не было никакого раскаяния! ;-)

Аналогичным образом вы можете обойти CXF и генерировать ответы SOAP в собственном рукописном Java-коде. Затем вы можете использовать карту для кэширования строковых XML-строк (unparsed, serialized) и исключить эту точку доступа.

Полностью согласен с Olaf on REST: если вы полностью используете HTTP, то все это кэширование происходит бесплатно во всех промежуточных кэшах между вашим сервером и вашими клиентами. Это, безусловно, что-то для рассмотрения для новых услуг.

Обновление: CXF имеет понятие настраиваемого interceptor chains. Один тип исходящего перехватчика предназначен для фазы MARSHAL, поэтому звучит так, будто вы можете добавить этот кеш туда, не имея возможности вырезать CXF.Возможно, эксперт CXF может проверить это для нас?

Answer 3

Объект Foo Marshalled от нашего объекта Java до XML-ответа SOAP с использованием Apache CXF.
.. самый большой потребитель циклов процессора. и поскольку наш объект Foo не меняется очень часто, ремаркетинг этого объекта каждый раз не нужен.

Необходимо ли мгновенное или как можно скорее узнать о изменениях в Foo?

Почему бы не кэшировать его на стороне потребителя/клиента? Дизайн, в котором вы вызываете один и тот же метод веб-службы сотни раз в секунду, вероятно, не самый лучший.