Решил разработать Web-сервис (WS) как уровень бизнес логики для интернет клиентов (есть “тонкие” IE клиенты и “толстые” Win32GUI) и появился ряд вопросов:
1. Как WS соотноситься с COM+? Есть ли возможность поместить WS в контекст COM+?
2. Второй вопрос натолкнул меня на предыдущий. Удаленный клиент вызывает метод WS int AddDocument(…), WS выполняет запросы к SQL серверу (а может быть и к нескольким серверам) и в этот момент связь с клиентом “падает”, а WS уже добавил запись в базу и возвращает ID документа клиенту, который уже не доступен. Получается ситуация, что клиент не получил ID документа и считает, что документ не был добавлен (что неверно). Короче нарушена целостность. Здесь явно напрашивается транзакция COM+, но как ее описать? И как удостовериться, что клиент получил уведомление (ID документа) от WS что документ добавлен и только в этом случае подтверждать транзакцию?

Здравствуйте Valentin, Вы писали:

V>1. Как WS соотноситься с COM+?
По большому счету никак.
V>Есть ли возможность поместить WS в контекст COM+?
Теоретически да.

V>>Есть ли возможность поместить WS в контекст COM+?
AVK>Теоретически да.

А я вот читал на DevelopMentore, что вопрос с транзакиями под WebService один из самых больших и нерешенных ))))
Были проекты под джава, но загнулись из-за финансовых сложностей

Так что полагаю, что транзакции сделать пока нельзя

Здравствуйте Valentin, Вы писали:

V>2. Второй вопрос натолкнул меня на предыдущий. Удаленный клиент вызывает метод WS int AddDocument(…), WS выполняет запросы к SQL серверу (а может быть и к нескольким серверам) и в этот момент связь с клиентом “падает”, а WS уже добавил запись в базу и возвращает ID документа клиенту, который уже не доступен. Получается ситуация, что клиент не получил ID документа и считает, что документ не был добавлен (что неверно). Короче нарушена целостность. Здесь явно напрашивается транзакция COM+, но как ее описать? И как удостовериться, что клиент получил уведомление (ID документа) от WS что документ добавлен и только в этом случае подтверждать транзакцию?

1. Если клиент упал, значит повторный вход в систему.
2. После входа запрос на документы /если хотим продолжить работу ииенно с доками./ Сервер возвращает список всех ID и клиенту не важно новый этот ID или нет.

Получается, что Web-сервисы (WS) не стоит использовать как уровень бизнес логики, и они представляют из себя просто промежуточное звено между клиентом и сервером приложений, т.е. что-то типа Клиент<->IIS<->WS<->COM+<->СУБД. Цепочка конечно впечатляет... :-\
Внутри-корпоративная система будет работать с темже COM+ по такой схеме: Корпоративный_клиент<->COM+<->СУБД, но как быть с филиалами, ведь COM+ расчитан на работу только в пределах локальной сети? Вроде бы казалось есть решение — SOAP, но он не ориентирован на соединение, накладывает ограничения на использование некоторых сервисов COM+ и объем сериализованного DataSet'а из ADO.NET просто ужасает (проверено на реальных тестах). По своей сути, зачем нужун такой сервис COM+ как асинхронное взаимодействие посредствам MSMQ (QC) в локальной сети? Как использовать события (издатель-подписчик) внешними корпоративными клиентами, работающими через интернет??? У MS на сегодня нет решения подобной проблемы? Корпоративный клиент должен в реальном времени видеть меняющийся курс акций или движение по его счету и это проблему якобы решает COM+, но только в локальной сети. Т.е. COM+ ориентирован на небольшие компании, не имеющие филиалов? Есть ли решение подобной проблемы?

Здравствуйте Valentin, Вы писали:

> Как использовать события (издатель-подписчик) внешними корпоративными клиентами, работающими через интернет??? У MS на сегодня нет решения подобной проблемы? Корпоративный клиент должен в реальном времени видеть меняющийся курс акций или движение по его счету и это проблему якобы решает COM+, но только в локальной сети. Т.е. COM+ ориентирован на небольшие компании, не имеющие филиалов? Есть ли решение подобной проблемы?

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

Здравствуйте Erley, Вы писали:

E>Здравствуйте Valentin, Вы писали:

>> Как использовать события (издатель-подписчик) внешними корпоративными клиентами, работающими через интернет??? У MS на сегодня нет решения подобной проблемы? Корпоративный клиент должен в реальном времени видеть меняющийся курс акций или движение по его счету и это проблему якобы решает COM+, но только в локальной сети. Т.е. COM+ ориентирован на небольшие компании, не имеющие филиалов? Есть ли решение подобной проблемы?

E>Первое, что приходит в голову — а почему бы не передавать удалённым клиентам не все данные а лишь их изменения ? можно реализовать протокол, по которому это будет осуществляться. На клиенте можно хранить некоторую информацию о тех данных, которые уже отреплицировались и при установлении соединения с сервером запрашивать только недостающие данные.
E>Для реализации же протокола можно использовать тот транспорт, который отвечает специфике вашей задачи. Вот и весь онлайн...

Это в некотором смысле решает проблему уменьшения трафика, но речь идет именно о немедленном получении обновленных данных с сервера как только прошли изменения.

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте Valentin, Вы писали:

V>>1. Как WS соотноситься с COM+?
AVK>По большому счету никак.
V>>Есть ли возможность поместить WS в контекст COM+?
AVK>Теоретически да.

Зато COM+ соотносится.
Приложение COM+ можно сделать доступным через SOAP и использовать как WS

Здравствуйте Valentin, Вы писали:

E>>Первое, что приходит в голову — а почему бы не передавать удалённым клиентам не все данные а лишь их изменения ? можно реализовать протокол, по которому это будет осуществляться. На клиенте можно хранить некоторую информацию о тех данных, которые уже отреплицировались и при установлении соединения с сервером запрашивать только недостающие данные.
E>>Для реализации же протокола можно использовать тот транспорт, который отвечает специфике вашей задачи. Вот и весь онлайн...

V>Это в некотором смысле решает проблему уменьшения трафика, но речь идет именно о немедленном получении обновленных данных с сервера как только прошли изменения.

Вот тут и можно использовать COM+ events & MSMQ.
Хотя я в своё время пользовался сокетами — регистрировал callback и меня сервер уведомлял, что появились новые данные. Есть две фазы работы — первичная синхронизация и обновления по ходу работы. Тогда ещё COM+ не было :)

А ремоутинг чем не устраивает?

E>Вот тут и можно использовать COM+ events & MSMQ.
E>Хотя я в своё время пользовался сокетами — регистрировал callback и меня сервер уведомлял, что появились новые данные. Есть две фазы работы — первичная синхронизация и обновления по ходу работы. Тогда ещё COM+ не было

Так вот я и говрю (в моем вопросе) что это связка работает только внутри локальной сети, за фаирволом. Разве можно интернетовским клиентам цепляться к событиям? Разве они не по RPC взаимодействуют?

Здравствуйте Roman Avramov, Вы писали:

RA>А ремоутинг чем не устраивает?

Можно поподробней? Как он решает такую проблему? Т.е. он позволяет держеть постоянное соединение и привязываться к событиям COM+ компонента? Или каким-то бругим образом?
Просто я еще не изучал этот вопрос

Здравствуйте Valentin, Вы писали:

V>Здравствуйте Roman Avramov, Вы писали:

RA>>А ремоутинг чем не устраивает?

V>Можно поподробней? Как он решает такую проблему? Т.е. он позволяет держеть постоянное соединение и привязываться к событиям COM+ компонента? Или каким-то бругим образом?

Зайди на codeproject.com и поищи слово "kiss" по фамилиям авторов.
Этот человек написал кучу статей на подобные темы, может быть что-нибудь тебе подойдет.

По поводу транзакций в web-services.

Какие ты хочешь транзакции?

Если внутри одного вебметода, то у атрибута WebMethod есть параметр Transaction (кажется так).
Ставишь его Required или как тебе надо, у него появляется COM+ контекст и вообще вебсервис начинает вести себя как configured component.

Если ты хочешь распределенную транзакцию между несколькими вебсервисами, то опаньки.
Пока такого нет, и я где-то читал (может в MSDN или DevelopMentor), что MS вроде подумывает об этом на будущее.

V>Можно поподробней? Как он решает такую проблему? Т.е. он позволяет держеть постоянное соединение и привязываться к событиям COM+ компонента? Или каким-то бругим образом?


да, в Remoting можно делать как стейтлесс объекты (SingleCall), так и стейтфул (Singleton и CAO), причем в случае стейтфул это не есть постоянное соединение, используется неколько другая модель. эвенты вроде тоже делать можно, хотя я не пробовал. см. \FrameworkSDK\Samples\Technologies\Remoting\Basic\RemotingEvents
с COM+ это никак не связано. ты можешь хостить объекты либо в IIS, либо написать свой хост (это одна строчка кода).
поподробнее — в MSDN

Здравствуйте Roman Avramov, Вы писали:

V>>Можно поподробней? Как он решает такую проблему? Т.е. он позволяет держеть постоянное соединение и привязываться к событиям COM+ компонента? Или каким-то бругим образом?


RA>да, в Remoting можно делать как стейтлесс объекты (SingleCall), так и стейтфул (Singleton и CAO), причем в случае стейтфул это не есть постоянное соединение, используется неколько другая модель. эвенты вроде тоже делать можно, хотя я не пробовал. см. \FrameworkSDK\Samples\Technologies\Remoting\Basic\RemotingEvents
RA>с COM+ это никак не связано. ты можешь хостить объекты либо в IIS, либо написать свой хост (это одна строчка кода).
RA>поподробнее — в MSDN
Этот Remoting всё-таки не панацея, хотя и придумано красиво, но реально так тормозит. И столько ресурсов жрёт. Нормально примерно клиентов на 30-50 по tcp каналу, если больше то можно даже про него и не думать, А если ещё надо по http каналу, то полный абзац вообще.

Здравствуйте Lisovsky, Вы писали:

L>Этот Remoting всё-таки не панацея, хотя и придумано красиво, но реально так тормозит. И столько ресурсов жрёт. Нормально примерно клиентов на 30-50 по tcp каналу, если больше то можно даже про него и не думать, А если ещё надо по http каналу, то полный абзац вообще.
Http как раз лучше масштабируем нежели постоянное tcp соединение.

L>Этот Remoting всё-таки не панацея, хотя и придумано красиво, но реально так тормозит. И столько ресурсов жрёт. Нормально примерно клиентов на 30-50 по tcp каналу, если больше то можно даже про него и не думать, А если ещё надо по http каналу, то полный абзац вообще. :crash:

Если придерживаться правила "chunky not chatty" (к примеру, пользовать паттерн business facade, пользовать датасеты, и т.п.), то с производительностью все в порядке. Хотя, признаться, с 50 юзерами я не пробовал.

Здравствуйте Roman Avramov, Вы писали:

L>>Этот Remoting всё-таки не панацея, хотя и придумано красиво, но реально так тормозит. И столько ресурсов жрёт. Нормально примерно клиентов на 30-50 по tcp каналу, если больше то можно даже про него и не думать, А если ещё надо по http каналу, то полный абзац вообще.

RA>Если придерживаться правила "chunky not chatty" (к примеру, пользовать паттерн business facade, пользовать датасеты, и т.п.), то с производительностью все в порядке. Хотя, признаться, с 50 юзерами я не пробовал.

Просто по моему скромному мнению, для систем реального времени .Net Remoting НЕ подходит.

Здравствуйте Lisovsky, Вы писали:

L>Просто по моему скромному мнению, для систем реального времени .Net Remoting НЕ подходит.
Для систем реального времени весь .Net не подходит совершенно.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте Lisovsky, Вы писали:

L>>Просто по моему скромному мнению, для систем реального времени .Net Remoting НЕ подходит.
AVK>Для систем реального времени весь .Net не подходит совершенно.

и Windows не подходит!