Кэширование ответов SOAP - PullRequest
       13

Кэширование ответов SOAP

2 голосов
/ 13 апреля 2011

Наше текущее приложение должно взаимодействовать со слоем SAP PI в форме сервисов в стиле SOAP. К сожалению, этот уровень сервисов не реализует какую-либо форму кэширования, что приводит к большому времени отклика даже для последующих запросов. Мы думаем, что у нас есть два варианта решения этой проблемы. Обратите внимание, что это HTTP POST.

  • Кэшировать объект ответа Java, который мы создаем, после первого вызова.
  • Кэшируйте xml-ответ, вводя промежуточный прокси-сервер. Признание недействительными и проверка кэшированных ответов кажется здесь более трудным, потому что это будет включать в себя просмотр тел запросов.

Мы хотели бы знать, если бы у кого-нибудь был опыт использования этих подходов или когда вы сталкивались с подобной ситуацией, как бы вы ее решили?

1 Ответ

9 голосов
/ 14 апреля 2011

Прежде чем идти по пути разработки механизма кэширования, имейте в виду, что такое сервисы и процессы (SOA и BPM).Они предназначены для абстрагирования от фактической реализации некоторой бизнес-функциональности за интерфейсом, основанным на стандартах.

Когда вы говорите, что время отклика велико, вы проанализировали, какова причина задержки?1003 *

  • Сколько вашей задержки составляет сетевая задержка?
  • Сколько стоит стек интеграции для чтения и записи ваших запросов и ответов SOAP?
  • Существуют ли другие издержки, такие какрегистрация или сохранение ваших запросов / ответов (например, если в качестве транспортного уровня используется постоянный обмен сообщениями)?
  • Сколько составляет задержка при фактической обработке вашего запроса в SAP PI?

Службы и процессы, к которым вы обращаетесь, должны рассматриваться как черные ящики, т. Е. Вам не нужно знать, что происходит за прикрытием, а только то, что он выполняет функцию, которую вы просили его сделать.

Однако, если вы реализуете кеширование, вы исходите из предположения, что вызываемые вами сервисы не имеют побочных эффектов.такие действия, как обновление данных, ведение журнала аудита, уведомление других сторон или систем о событии и т. д. Поэтому, даже если вы найдете технический способ реализации вашего требования к кешированию, на самом деле вы можете подорвать реализацию сервиса.Для вашего приложения это будет выглядеть нормально, но вы можете воздействовать на другие системы или процессы, о которых вы не знаете.

Если вы уверены, что знаете, что делаете, то непременно взгляните на кэширование.Реализация его в вашем приложении путем сохранения объекта ответа, вероятно, будет самой быстрой, но не будет использоваться другими приложениями, поэтому выигрыш в производительности будет локализован.Если вы воспользуетесь этим подходом, вы все равно можете подумать о создании механизма избирательного кэширования, а не о применении ко всем.

Некоторые ESB и даже шлюзы / устройства XML имеют возможности кэширования.Я знаю, что устройства IBM DataPower, например, имеют возможности кэширования документов, с помощью которых вы можете контролировать, какие сервисы / URL-адреса кэшируются, и какое время жизни у этих кэшированных копий.Этот подход имеет то преимущество, что предлагает всем потребителям услуг SAP одинаковое повышение производительности, которое вы ищете.

Также имейте в виду, что кэширование увеличит потребление памяти, поэтому если вы не будете подходить к нему осторожно,может привести к тому, что вашему приложению, ESB или тому, с чем вы его реализуете, не хватит памяти.У DataPower, к сожалению, была привычка просто перезагружать себя, не сообщая никому, когда мы столкнулись с этой проблемой в проекте!:)

Надеюсь, это поможет.

...