понедельник, 30 августа 2010 г.

.NET 4.0. Кешируем данные в памяти.

Ждете что я начну писать про System.Web.Cache? Вы одновременно правы и не правы.

ASP.NET программисты уже давно пользуются очень удобным средством для кэширования данных, из пространства имен System.Web.Cache. Он самостоятельно управляет жизнью объектов в себе, самостоятельно удаляет элементы из кеша по наступлению событий каких бы то ни было зависимостей, например изменении файла, или таблицы базы данных. Тем, кому стало интересно, отправляю к статье на MSDN.

Осталось только сказать об одном его достаточно большом недостатке – этот кеш нельзя использовать вне ASP.NET, потому что все свои данные он хранит в текущем контексте HttpContext.Current. Если у вас не ASP.NET приложение – этот объект будет недоступен.

Однако, сегодня .NET 4 меня удивил – я наткнулся на другой класс, который предназначен решить эту проблему – System.Runtime.Caching.MemoryCache.

Кроме того, что этот кеш больше не зависит от сборки System.Web, можно создавать несколько экземпляров данного класса. Есть и недостатки – не поддерживаются регионы. Хотя они и есть в базовом классе, однако сам кеш в памяти возвращает null для всех вызовов перегруженных методов с указанием параметра regionName.

В MSDN приведен такой пример использования MemoryCache:

ObjectCache cache = MemoryCache.Default;
string fileContents = cache["filecontents"as string;

if (fileContents == null)
{
         CacheItemPolicy policy = new CacheItemPolicy();
 
         List<string> filePaths = new List<string>();
         filePaths.Add("c:\\cache\\example.txt");
 
         policy.ChangeMonitors.Add(new
         HostFileChangeMonitor(filePaths));
 
         // Fetch the file contents.fileContents = 
         File.ReadAllText("c:\\cache\\example.txt");
 
         cache.Set("filecontents", fileContents, policy);
}

Судя по этому куску кода, MemoryCache, как и Web.Cache поддерживает различные события на обновления. Например в этом куске кода создается событие на изменение файла. Из коробки доступны мониторы на изменение данных в самом кеше, изменение в файловой системе, изменений на SQL Server.

Очень интересен для рассмотрения также бызовый объект ObjectCache. Он предоставляет базовую логику кеша и представляет возможности для дальнейшего расширения поставщиков кеша. Это означает, что можно писать свой собственный кеш на стандартных интерфейсах и использовать его как стандартный кеш.

Posted via email from Комуникликабельность

пятница, 27 августа 2010 г.

WCF. BasicHttpBinding, аутентификация и Streamed режим

Если вы хотите приготовить дрожжевое тесто, а дрожжей у вас нет

… то ни хрена у вас не получится.

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

Исходная задачка была достаточно простой с точки зрения Enterprise приложения: обеспечить для WCF сервиса передачу больших данных с учетом аутентификации.

WCF использует два режима для передачи данных: Buffered и Streamed. Buffered режим соответствует первоначальной сериализации всего пакета данных в память с последующей передачей клиенту. Соответственно передача в Buffered режиме определяет несколько ограничений, как то ограничение на размер передаваемых данных. Buffered режим также не оптимален с точки зрения использования памяти (ну тут все понятно из описания).

Streamed режим предназначен для передачи данных потоком, без занесения всех их в память. Данный режим также накладывает ряд ограничений, но в общем случае это касается контракта данных. Так, тип возвращаемого параметра должен быть Stream или его наследником, тип параметра метода сервиса также должен быть потоком. Данное ограничение можно снять, если использовать контракты сообщений (MessageContracts).

Остальные ограничения Streamed режима можно понять, если учесть одно обстоятельство – ни принимающая, ни отправляющая сторона не знают размер потока. Если учесть этот факт, то понятны ограничении, означенные в статье Large Data and Streaming:

You cannot use a significant number of WCF features when streaming is enabled:

·         Digital signatures for the message body cannot be performed because they require computing a hash over the entire message contents. With streaming, the content is not fully available when the message headers are constructed and sent and, therefore, a digital signature cannot be computed.

·         Encryption depends on digital signatures to verify that the data has been reconstructed correctly.

·         Reliable sessions must buffer sent messages on the client for redelivery if a message gets lost in transfer and must hold messages on the service before handing them to the service implementation to preserve message order in case messages are received out-of-sequence.

Because of these functional constraints, you can use only transport-level security options for streaming and you cannot turn on reliable sessions. Streaming is only available with the following system-defined bindings:

·         BasicHttpBinding

·         NetTcpBinding

·         NetNamedPipeBinding

·         WebHttpBinding


Вы не можете использовать некоторое число возможностей WCF при использовании Streaming режима:

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

·         Шифрование связано с цифровой подписью для проверки корректности дешифрации данных.

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

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

·         BasicHttpBinding

·         NetTcpBinding

·         NetNamedPipeBinding

·         WebHttpBinding

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

PS: Попробую еще поковырять WCF, может быть что то выгорит с кастомными биндингами, но я сомневаюсь.

PSPS: У меня на очереди еще статья на тему WCF, а конкретно о некоторой особенности его поведения при хостинге на IIS.

Posted via email from Комуникликабельность