|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Максим Н, ну это какая то новогодняя сказка, жили были 30 серверов, и вот однажды ночью, когда все пользователи уснули, эти сайты проснулись, и начали вести беседу между собой, один рассказал, кто заходил к нему в течении суток, другой рассказал что пользователь Иванов хотел подломить его. - Угу возмутились сервера, и сообща решили забанить Васю из Иваново.. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 11:58 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Максим НВариант с мессадж брокером выглядит заманчиво,но придется его отдельно где то разворачивать, обдумывать как к нему конектится, как логиниться и тд. У вас сайты все на IIS, зачем придумывать, используйте MSMQ 1) Это компонент сервера, ставится легко 2) Для использования сервиса нужно всего лишь быть авторизованным в домене, да и то, для использования списков рассылки в Active Directory 3) Использовать также очень просто - Message, MessageQueue - смотрите MSDN, примеры простейшие. Соответствующий биндинг есть и в WCF 4) при необходимости обеспечивается гарантированная доставка сообщений У вас будут плюсы децентрализованной архитектуры с администрированием транспорта системными администраторами. Всяко лучше самописных поделок. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 11:59 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Где-то в степивот однажды ночью, когда все пользователи уснули, эти сайты проснулись, и начали вести беседу между собой +1 Придется на каждый сервер ставить свой win-сервис, обрабатывающий web-сервис :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 12:01 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Где-то в степиМаксим Н, ну это какая то новогодняя сказка, жили были 30 серверов, и вот однажды ночью, когда все пользователи уснули, эти сайты проснулись, и начали вести беседу между собой, один рассказал, кто заходил к нему в течении суток, другой рассказал что пользователь Иванов хотел подломить его. - Угу возмутились сервера, и сообща решили забанить Васю из Иваново.. Есть центральный сервер, вот он время от времени и раздает сообщения свои подчиненным. Они (подчиненные) в свою очередь ему могут отвечать, между собой не общаются. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 12:02 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Arm79Максим НВариант с мессадж брокером выглядит заманчиво,но придется его отдельно где то разворачивать, обдумывать как к нему конектится, как логиниться и тд. У вас сайты все на IIS, зачем придумывать, используйте MSMQ 1) Это компонент сервера, ставится легко 2) Для использования сервиса нужно всего лишь быть авторизованным в домене, да и то, для использования списков рассылки в Active Directory 3) Использовать также очень просто - Message, MessageQueue - смотрите MSDN, примеры простейшие. Соответствующий биндинг есть и в WCF 4) при необходимости обеспечивается гарантированная доставка сообщений У вас будут плюсы децентрализованной архитектуры с администрированием транспорта системными администраторами. Всяко лучше самописных поделок. Зувчит заманчиво, надо обдумать. Но ведь в любом случае нужен будет клиент, который будет отправлять сообщения в очередь и читать их от туда? Поправьте пожалуйста если не прав. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 12:07 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Максим Н, авторЕсть центральный сервер, вот он время от времени и раздает сообщения свои подчиненным. Они (подчиненные) в свою очередь ему могут отвечать, между собой не общаются. Так это обыкновенная трехзвенка, ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 12:11 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Максим ННо ведь в любом случае нужен будет клиент, который будет отправлять сообщения в очередь и читать их от туда? Не обязательно. Это уже зависит от вас. На MSMQ есть такое понятие как триггеры и правила. По приходу сообщения можно настроить фильтры и так далее, и тому подобное. Далее, запускается либо Com+ компонента (смотрите Enterprise Services ) либо экзешник, которым на вход подается сообщение ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 12:17 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Всем спасибо, смотрю в сторону MSMQ. Думаю как бы это могло выглядеть, пока представляю так: например машине А нужно доставить несколько сообщений машине Б. А формирует сообщения и ломится в MSMQ, работающий на Б, по HTTP. Сообщения оказываются в очереди на Б, дальше отрабатываются машиной Б, например по триггеру. Так? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 16:04 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Максим НА формирует сообщения и ломится в MSMQ, работающий на Б, по HTTP. Зачем по Http? Вы комсомолец? Любите трудности? Сервер A пишет в очередь B\private$\queue1 Это все. Далее, сама MSMQ берет на себя отправку сообщения на сервер В в очередь private$\queue1 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 16:26 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Arm79Максим НА формирует сообщения и ломится в MSMQ, работающий на Б, по HTTP. Зачем по Http? Вы комсомолец? Любите трудности? Сервер A пишет в очередь B\private$\queue1 Это все. Далее, сама MSMQ берет на себя отправку сообщения на сервер В в очередь private$\queue1 Т.е. сообщение попадает из одной очереди в другую? Как? Между серверами открыт только 80-й порт. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 16:30 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
круто, ТС сознался в распределённой системе никак не связанных между собой веб-серверов только на второй странице обсуждения =) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 16:35 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Konst_Oneкруто, ТС сознался в распределённой системе никак не связанных между собой веб-серверов только на второй странице обсуждения =) Сам в шоке :-) Максим Н, Вы же говорили, что у вас сеть из 30 серверов? Сейчас выясняется, что они практически друг с другом не связаны? Что мешает открыть еще несколько портов? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 16:41 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Снова извиняюсь, что ввел в заблуждение. Arm79Konst_Oneкруто, ТС сознался в распределённой системе никак не связанных между собой веб-серверов только на второй странице обсуждения =) Сам в шоке :-) Максим Н, Вы же говорили, что у вас сеть из 30 серверов? Сейчас выясняется, что они практически друг с другом не связаны? Говорил, и что работают они в интрасети тоже помоему говорил. Arm79 Что мешает открыть еще несколько портов? Безопасность и немного здоровой бюрократии. Что можете предложить? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 17:00 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Максим НГоворил, и что работают они в интрасети тоже помоему говорил. Ну да. Обычно в ИНТРАСЕТИ между серверами файерволов не ставят. Между сегментами обычно есть, а внутри - нет. В принципе, это ваше дело, но для функционирования MSMQ нужен как минимум порт 1801/tcp. Очередь сообщений Системная служба очереди сообщений представляет собой инфраструктуру и средство разработки распределенных программ для обмена сообщениями в Windows. Такие программы способны осуществлять обмен данными между неоднородными сетями и отправлять сообщения между компьютерами, которые временно не могут установить подключение друг к другу. Служба очереди сообщений обеспечивает безопасность, эффективную маршрутизацию, поддержку отправки сообщений внутри транзакций, приоритетную отправку, а также гарантированную доставку сообщений. Имя системной службы: MSMQ Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2013, 17:09 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Arm79Максим НГоворил, и что работают они в интрасети тоже помоему говорил. Ну да. Обычно в ИНТРАСЕТИ между серверами файерволов не ставят. Между сегментами обычно есть, а внутри - нет. В принципе, это ваше дело, но для функционирования MSMQ нужен как минимум порт 1801/tcp. Очередь сообщений Системная служба очереди сообщений представляет собой инфраструктуру и средство разработки распределенных программ для обмена сообщениями в Windows. Такие программы способны осуществлять обмен данными между неоднородными сетями и отправлять сообщения между компьютерами, которые временно не могут установить подключение друг к другу. Служба очереди сообщений обеспечивает безопасность, эффективную маршрутизацию, поддержку отправки сообщений внутри транзакций, приоритетную отправку, а также гарантированную доставку сообщений. Имя системной службы: MSMQ Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
Интрасеть есть, но достаточно большая, со своими правилами и заморочками. 30 серверов - это 30 различных организаций (клиентов) и открывать порты придется в кажодй из них (где согласятся, где то откажутся, я бы на их месте сам наверное был против). А 80-й (443) порт открыт везде. Какие возможны проблемы если организовать очередь на http? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2013, 10:21 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Максим НКакие возможны проблемы если организовать очередь на http? Придется а) на каждом сервере IIS иметь б) так как MSMQ over HTTP использует SOAP, имеет ли смысл уже использование MSMQ? В итоге что остается? Сеть, объединяющая 30 серверов разных организаций, которые не доверяют друг другу. Значит и домена никакого нет. Почему она интрасетью называется, непонятно. Раз общение между ними возможно ТОЛЬКО с помощью Http(s), то остаётся только простенький Win-сервис написать, который умеет обращаться к Web-сервисам. Зачем вам много инсталляций этого сервиса? Разве одного не достаточно, который будет иметь возможность опрашивать ВСЕ Web-сервисы? Писать win-сервисы очень просто. Штатная заготовка в VS достаточно хороша. Я лично написал для себя проект, который работает как консоль (удобно отлаживать), но имеет возможность регистрировать себя в системе как сервис (имя_программы.exe -install имя_сервиса). Пришлось заморочиться, чтобы не зависеть от InstallUtil и иметь возможность регистрировать один и тот же код под разными именами служб. Консоль и сервис в одном флаконе Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2013, 11:15 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Код: c# 1.
Жестокая проектировка класса... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2013, 11:20 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
МСУ Код: c# 1.
Жестокая проектировка класса... Ерунда. Исторически так сложилось, я и не стал править. В шаблоне проекта лежит, кушать не просит. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2013, 11:26 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Arm79кушать не просит. Ок, фиг бы с ним. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2013, 12:22 |
|
Клиент для restful WEB-сервиса
|
|||
---|---|---|---|
#18+
Arm79Максим НКакие возможны проблемы если организовать очередь на http? Придется а) на каждом сервере IIS иметь б) так как MSMQ over HTTP использует SOAP, имеет ли смысл уже использование MSMQ? В итоге что остается? Сеть, объединяющая 30 серверов разных организаций, которые не доверяют друг другу. Значит и домена никакого нет. Почему она интрасетью называется, непонятно. Раз общение между ними возможно ТОЛЬКО с помощью Http(s), то остаётся только простенький Win-сервис написать, который умеет обращаться к Web-сервисам. Зачем вам много инсталляций этого сервиса? Разве одного не достаточно, который будет иметь возможность опрашивать ВСЕ Web-сервисы? Писать win-сервисы очень просто. Штатная заготовка в VS достаточно хороша. Я лично написал для себя проект, который работает как консоль (удобно отлаживать), но имеет возможность регистрировать себя в системе как сервис (имя_программы.exe -install имя_сервиса). Пришлось заморочиться, чтобы не зависеть от InstallUtil и иметь возможность регистрировать один и тот же код под разными именами служб. Консоль и сервис в одном флаконе Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128.
Да, с "интрасетью"я погорячился. Идея с web-сервисами и одной управляющей виндовой службой интересная - не додумался до этого... С IIS не проблема, т.к. он и так везде настроен и работает, web-сервис для него будет очередным web-приложением, которое он будет "показывать". Есть еще один вопрос (правда наверное не со всем по теме...), было бы здорово услышать мнение: помимо небольших сообщений (в большом количестве), которые можно легко обернуть в json(xml), а потом достать от туда, предполагается транспортировка файлов (причем довольно больших - до 100 Мб легко), с главного сервака на дочерние и обратно. Была идея такая - захостить файлы на главном web-сервере, чтобы они были доступны по http(s), что то типа хостера файлов. Дальше передавать web-сервису дочернего сервера только описание такого файла(файлов) (имя файла, где на хостере можно забрать, куда у себя положить и т.д.). При обработке такого запроса дочерний сервак сам скачает его с хостера. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2013, 12:43 |
|
|
start [/forum/topic.php?fid=20&msg=38493858&tid=1403543]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 328ms |
total: | 484ms |
0 / 0 |