Выбираю способ реализации темы. Нашел интересный материал здесь
ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_fxremoting/html/4388cd77-459b-4c82-adbf-7bee9e567c4e.htm (MSDN для VS2005 Beta2). Статья называется
ASP.NET, Enterprise Services, or .NET Remoting? С точки зрения производительности в данной статье рекомендуют Enterprise Services (это .NET обертка на COM+). О .NET Remoting информации довольно много. Хочется узнать подробнее именно о Enterprise Services, кто-нибудь их использовал, насколько это сложнее/проще чем Remoting? В MSDN только общая информация по пространству имен, классам и т.п. Буду благодарен за любые ссылки на материалы, статьи о использовании/применении данной технологии.
Hello, "IDeal"
> Хочется узнать подробнее именно о Enterprise Services, кто-нибудь их
> использовал, насколько это сложнее/проще чем Remoting? В MSDN только общая
> информация по пространству имен, классам и т.п. Буду благодарен за любые
> ссылки на материалы, статьи о использовании/применении данной технологии.
>
Enterprise Services в отличии от remoting предлагает массу сервисов
облегчающих разработку enterprise приложений. Из основного:
1. Лучше security модель (в remoting этого фактически нет). Безопасность
основана на NT Security (будет работать только по windows) и позволяет
разграничивать доступ к интерфейсам/методам на уровне ролей. Есть
возможности по имперсонации текущего пользователя.
2. Load Balancing. В Remoting этого просто нет.
3. Транзакции. Можно использовать как автоматические так и распределенные. В
Remoting этого тоже нет.
4. Пулы объектов — может помочь при масштабировании нагрузки. В Remoting
этого тоже нет.
5. Синхронизация. Несколько объектов можно поместить в так называемый
Synchronization Domain в результате с объектами можно будет работать только
из одного логического потока — все остальные будут просто ждать. В Remoting
есть жалкое подобие
6. Loosely Coupled Events — есть возможность распределять события по
множеству подписчиков. Чем это отличается от tightly coupled events из
Remoting это есть в MSDN
7. Поддержка MSMQ. Любой ServicedComponent можно вызывать через очередь
сообщений (MSMQ) — это хорошо помогает в масштабировании и надежности. В
Remoting этого тоже нет.
8. Application Recycling. У ServicedComponents есть возможность настроить
переодический recycle приложения (все происходит прозрачно и не заметно для
клиентов) — помогает восстанавливаться после сбоев и уменьшает возможный
demage от багов в реализации объектов. Понятно, что в Remoting этого тоже
нет
9. У EnterpriseServices есть еще куча сервисов которые просто лень
описывать — есть в MSDN
Из минусов EnterpriseServices — это как ни крути COM. Со своим собственным
репозтарием для регистрации/настройки приложений, возможными проблемами при
деплойменте приложений, работе только в Windows среде и ограниченной работе
в internet.
Posted via RSDN NNTP Server 1.9
Здравствуйте, TK, Вы писали:
Спасибо за такой обстоятельный ответ.
А печатная литература по Enterprise Services не попадалась? Не знаете, что-нибудь издавалось?
Hello, "IDeal"
>
> Спасибо за такой обстоятельный ответ.
> А печатная литература по Enterprise Services не попадалась? Не знаете,
> что-нибудь издавалось?
Точно знаю, что есть литература по COM+. Можно почитать ее — по сути .NET
это всего лишь тонкая надстройка.
Posted via RSDN NNTP Server 1.9
