2009-04-16 4 views
3

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

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

Я провел некоторое исследование и нашел несколько статей об использовании IExtension, прикрепленных к servicehosts для хранения общих данных.

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

ответ

3

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

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

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

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

В качестве альтернативы, если данные в кеше очень тесно связаны с ОБОИХ служб, вызывающих кеш, то есть обе службы добавляют/изменяют данные в кеше и т. Д., Тогда, возможно, следует объединить две существующие службы в одну услугу.

Если то, что я говорю, имеет смысл, тогда принцип SOA, на котором я рисую, - Service Autonomy.

+0

Ну, это приложение среднего размера. Я согласен с точкой автономии службы. Первоначально данные были предназначены для чтения из БД из нескольких служб, но из-за проблем с производительностью мы хотим переместить его в кеш-память. Данные являются «основными» для многих служб, поэтому, хотя и неортодоксально, я думаю, что общий кэш делает смысл. –

+0

Спасибо за разъяснение. Лично я бы, конечно, инкапсулировал кеш в другую службу и реализовал вызовы службы-службы. Я соответствующим образом обновлю ответ. – razlebe

+1

Все правильно, но со всем уважением, это слишком схематическая точка зрения. По крайней мере, я знаю один тип взаимодействия между службами, которые должны выполняться не как «обычная услуга»: проверка маркера безопасности (если мы будем делать это на уровне приложения) между методом службы и поставщиком токенов безопасности (для этого требуется действительный список токенов). То же самое касается регистрации, регистрация - это нечто особенное. Если вы будете регистрировать один и тот же корпоративный автобус, вы можете легко его испортить. –

2

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

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

+0

Я часто использовал метод статических переменных для обычных приложений asp.net, но меня беспокоит жизненный цикл служб. Гарантируется ли инициализация кеша, если, например, служба A пытается получить доступ к кешу в службе B, которая еще не была вызвана (активирована)? –

+1

Вам нужно будет поместить код инициализации в статический метод или сам кэш-контроллер. Таким образом, он инкапсулирован как из услуг A, так и из B.Ни один из них не зависит друг от друга, чтобы инициализировать кеш, первый для доступа к нему вызывает ленивую инициализацию. –

Смежные вопросы