Вопрос о дизайне веб-сервисов - регистрация сообщений - PullRequest
1 голос
/ 27 января 2011

У нас в офисе состоялась дискуссия о ведении журнала аудита сообщений, полученных и отправленных через веб-службы.

Я придерживаюсь мнения, что не следует регистрировать все сообщение SOAP в журналах аудита приложений, если только не указано, что это требуется. Только существенные элементы запроса должны быть частью журнала аудита, поскольку это предоставляет доказательства, которые требуются в журнале аудита.

Мои причины: (1) Журналы аудита по определению всегда включены и не должны быть выключены. Поэтому, если мы примем решение о регистрации всего сообщения для контрольного журнала, они будут включены всегда и могут оказать огромное влияние на производительность во время производственных циклов (особенно при пиковых нагрузках). (2) Если деловое / техническое требование явно не устанавливает это как требование, это является ненужными накладными расходами. Если требуется информация, для отслеживания сообщений SOAP можно использовать возможность трассировки модулей времени выполнения.

Каковы общие мысли экспертов в этом пространстве.

Спасибо, Manglu

Ответы [ 2 ]

5 голосов
/ 27 января 2011

Не путайте аудит с ведением журнала. Если есть необходимость в аудите, вам необходимо провести аудит.

Поскольку аудит обычно требуется по юридическим или политическим причинам, вам необходимо понимать, какие действия и действия должны регистрироваться, а также какие данные должны регистрироваться. Это не техническое решение, но должно определяться бизнесом. Если у вас есть требования, вы можете спроектировать объемы аудита и спроектировать свое приложение для их учета (например, производительность, хранение и т. Д.).

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

Если у вас действительно есть требование к аудиту, вам, вероятно, следует провести аудит всего сообщения о запросе мыла, а также ответа. Это для поддержки отказа от авторства.

В качестве примера предположим, что у вас есть приложение для медицинского обслуживания, и вы проверяете только ключевую информацию: личные идентификаторы (например, SSN) и наличие у пациента аллергии на пенициллин. Но что происходит, когда пациент умирает, потому что аллергия на пенициллин была ложной, если этого не должно было быть? Журналы аудита проверяются, и вы говорите, что для этого пациента было отправлено значение false, но другая система говорит, что на самом деле вам было отправлено значение true, и у вас должна быть проблема с вашей системой. В этом сценарии вам нужно показать точное сообщение, которое было отправлено веб-службе, и что, поскольку оно было подписано потребителем службы, вы можете доказать, что оно получено от них, а также доказать, что данные в сообщении верны , Затем вы проследите эту информацию через вашу систему через журналы аудита.

Конечно, все это восходит к требованиям; если предприятие обнаружит, что только проверка x и y удовлетворяет какому-либо законодательству или политике, тогда соглашайтесь с этим.

1 голос
/ 27 января 2011

Я знаю из опыта, что регистрация всего этого может привести к довольно большим файлам или большому количеству данных, если они хранятся в базе данных. Это очень полезно во время разработки, но на производстве это становится проблемой. Я бы предложил войти, как вы сказали. Но следует помнить о ситуации, с которой я столкнулся: мы предоставляли веб-сервис для использования сторонними компаниями. Когда есть спор о том, кто виноват, это ошибка. Нам нужно было точное сообщение SOAP, чтобы доказать, что это не наша вина. Я не знаю, относится ли этот сценарий к вам.

...