Здравствуйте, Аноним, Вы писали:
А>Не пойдет, нужна 3-х уровневая архитектура
Remoting или WebServices реально существуют в отличии от Indigo. В остальном выбор Remoting vs Indigo это выбор Объекты vs Сервисы
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[4]: Remoting vs Indigo
От:
Аноним
Дата:
22.01.06 13:19
Оценка:
Здравствуйте, TK, Вы писали:
TK>Remoting или WebServices реально существуют в отличии от Indigo. В остальном выбор Remoting vs Indigo это выбор Объекты vs Сервисы
Вообще-то я думал, что Indigo тоже предоставляет доступ к серверным объектам....
Ошибаюсь?
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, Аноним, Вы писали:
А>>Не пойдет, нужна 3-х уровневая архитектура
TK>Remoting или WebServices реально существуют в отличии от Indigo. В остальном выбор Remoting vs Indigo это выбор Объекты vs Сервисы
Если использовать ремотинг в режиме Singleton то их разница сокращается тока до разницы в названиях.
Вобщемто я сейчас использую стателесс Ремотинг(Singleton), а клиентам говорю что если им захочится юзать индиго, то для порта надо будет добавить дополнительные атрибуты в контакторе и все. А вот недавно Олег Михайлик приводил статью как это все дело подружить еще и с веб сервисами. Так что вообще ничего выбирать не надо .
MC>Если использовать ремотинг в режиме Singleton то их разница сокращается тока до разницы в названиях.
Разница кардинальная. В веб-сервисах enpoint строго зафиксирован. Удалённо вызываются только те методы, которые прописаны в WSDL.
Через Remoting удалённо вызываются любые методы наследников MBR, стоит случайно его передать.
MC>Вобщемто я сейчас использую стателесс Ремотинг(Singleton)
Похоже, ты имел в виду Singlecall
Во всяком случае, модель веб-сервисов ближе к Singlecall
MC> а клиентам говорю что если им захочится юзать индиго, то для порта надо будет добавить дополнительные атрибуты в контакторе и все.
Вообще-то Microsoft официально говорит, что Indigo/WCF несовместимо с Remoting по протоколу.
Если код написан "в стиле SOA", то переделать его под WCF/Indigo будет несложно.
Здравствуйте, mihailik, Вы писали:
MC>>Если использовать ремотинг в режиме Singleton то их разница сокращается тока до разницы в названиях.
M>Разница кардинальная. В веб-сервисах enpoint строго зафиксирован. Удалённо вызываются только те методы, которые прописаны в WSDL.
Разница, не в техническом плане, а в идеологическом. Не существенно какой протокол, а что я могу с ним сделать и сколько кода мне придется переделать на клиенте и сервере. Если бы задача стояла четче, ну например четко надо дистнциировать типы и их состояния, то тогда да.
M>Через Remoting удалённо вызываются любые методы наследников MBR, стоит случайно его передать.
MC>>Вобщемто я сейчас использую стателесс Ремотинг(Singleton)
M>Похоже, ты имел в виду Singlecall
M>Во всяком случае, модель веб-сервисов ближе к Singlecall
Лично я использую синглтон, для меня это урощенный кеш . Так что именно сиглтон . Хотя для текщей постановки это не сущетвенно, главное чтобы состояния небыло.
MC>> а клиентам говорю что если им захочится юзать индиго, то для порта надо будет добавить дополнительные атрибуты в контакторе и все.
M>Вообще-то Microsoft официально говорит, что Indigo/WCF несовместимо с Remoting по протоколу.
См. п 1.
M>Если код написан "в стиле SOA", то переделать его под WCF/Indigo будет несложно.
Во-во и я про тоже. Хотя в следующий раз буду оперировать понятием SOA, а не доморощенными описаниями .
M>>Разница кардинальная. В веб-сервисах enpoint строго зафиксирован. Удалённо вызываются только те методы, которые прописаны в WSDL.
MC>Разница, не в техническом плане, а в идеологическом. Не существенно какой протокол, а что я могу с ним сделать и сколько кода мне придется переделать на клиенте и сервере. Если бы задача стояла четче, ну например четко надо дистнциировать типы и их состояния, то тогда да.
Хм, не очень понимаю, что ты в данном случае имеешь в виду.
Есть большая разница и идеологическая, и техническая. Идеологическую хорошо выразил TK: объекты vs. сервисы [SOA].
Техническую тоже сложно не заметить, isn't it?
Другие протоколы, механизмы управления, модель расширения, совместимость.
Я к тому, что эти детали важны на раннем этапе. Нельзя просто сказать: тут мелкие несущественные различия.
M>Есть большая разница и идеологическая, и техническая. Идеологическую хорошо выразил TK: объекты vs. сервисы [SOA]. M>Техническую тоже сложно не заметить, isn't it? M>Другие протоколы, механизмы управления, модель расширения, совместимость.
Он имеет в виду, что если на базе remoting'а строится stateless сервер приложений, то получаются, фактически те же сервисы, ну и что, что адресуются они ObjRef'ами?
При переходе к вебсервисам или индиге потребуется только слой прокси подменить — прикладной код останется тем же.
iT>Он имеет в виду, что если на базе remoting'а строится stateless сервер приложений, то получаются, фактически те же сервисы, ну и что, что адресуются они ObjRef'ами?
Ну как то есть какая разница! Ну как то есть ну и что!
Чтобы Remoting был сервисами нужна вдумчивая внутренняя работа, самоограничение и высокая степень концентрации. Одно неаккуратное движение — и вы отец
iT>При переходе к вебсервисам или индиге потребуется только слой прокси подменить — прикладной код останется тем же.
Если типы данных передаются только примитивные, то ты прав.
Здравствуйте, <Аноним>, Вы писали:
А>Не пойдет, нужна 3-х уровневая архитектура
Тогда БД здесь не причем...
Технически и идеологически все более-менее описали, а с точки зрения мировой революции — индига (правильное имя WCF) это наше всё, то есть будущее, но вот на сколько светлым оное будущее окажется, сие тайна великая есть. (хотя обещают горы златые)
С другой стороны, remoting технология проверенная, заработавшая определенную репутацию, с кучей примеров использования и умудренных опытом краеведов под рукой, но MS считает remoting не самой лучшей идеей и потихоньку от нее отпинывается...
Так что выбирай, но осторожно, но выбирай.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[4]: Remoting vs Indigo
От:
Аноним
Дата:
23.01.06 08:08
Оценка:
Здравствуйте, Merle, Вы писали:
M>Технически и идеологически все более-менее описали, а с точки зрения мировой революции — индига (правильное имя WCF) это наше всё, то есть будущее, но вот на сколько светлым оное будущее окажется, сие тайна великая есть. (хотя обещают горы златые)
... M>но MS считает remoting не самой лучшей идеей и потихоньку от нее отпинывается...
Интересно, откуда такие сведения. Может есть какие-то источники для таких посылов? Если есть, то можно ли получить на них ссылку?
Здравствуйте, <Аноним>, Вы писали:
А>Интересно, откуда такие сведения. Может есть какие-то источники для таких посылов? Если есть, то можно ли получить на них ссылку?
Сведения о чем? О том что WCF наше все или о том, что MS не очень рекомендует использовать ремотинг?
В любом случае сведения от сотрудников MS, да и вот одна из первых попавшихся цитат по этому поводу:
Из форумов на MSDN:
Current recommendations from Microsoft around Web Services vs. Remoting is that Web Services are a more viable long-term solution. Microsoft's Distributed Computing Group, which owns Web Services, .NET Remoting, WSE, DCOM, COM+, Enterprise Services, MSMQ, and Indigo, is encouraging a move toward Web Services and recommends avoiding implementations using .NET Remoting. Information can be found here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/introindigov1-0.asp
Windows Vista FAQ:
Q:What should I do to be ready to exploit Windows Communication Foundation when it ships?
A: ... NET Remoting-avoid or abstract using low-level extensibility such as .NET Remoting sinks and channels. ...
При этом они совершенно четко говорят, что если уж используете ремотинг, то делайте это исключительно для междоменного взаимодействия в рамках одного процесса.
Вообще у ребят какие-то странные метания по этому поводу. Очевидно, они хотят, чтобы WCF заменило весь зоопарк средств по Distributed Computing Technologies, начиная с веб-сервисов и заканчивая MSMQ, но что-то им мешает...
Понятно, что совсем Remoting они не выкинут, но вот что они его дальше развивать не будут — можно утвержать довольно уверенно.
M>Понятно, что совсем Remoting они не выкинут, но вот что они его дальше развивать не будут — можно утвержать довольно уверенно.
Вопрос спорный. Это зависит от того, как пойдет то, что они двигают сейчас. Правда, двигать они умеют
Но Remoting сейчас уникален как .net-based технология распределенного взаимодействия объектов.
И приверженцы этого подхода быстро никуда не денутся...
Здравствуйте, Igor Trofimov, Вы писали:
iT>Но Remoting сейчас уникален как .net-based технология распределенного взаимодействия объектов. iT>И приверженцы этого подхода быстро никуда не денутся...
Ну WCF и так будет уметь все то, что умеет Remoting и даже немножко больше... Плюс к этому, MS в принципе не очень приветствует именно такой подход, сколько бы приверженцев у него не было, сейчас рулят SOA и ковровое бомбометание...
M>>А если Hashtable? А если объект с событиями?
iT>Hashtable — это не страшно. А если объект с событиями — то это уже никаким боком не сервис-ориентировано...
Но и Hashtable в веб-сервис не пролезет. Тонкостей куча
Hello, "mihailik"
> iT>И приверженцы этого подхода быстро никуда не денутся... > Ну делись же куда-то приверженцы структурного программирования.
Так никуда они и не делись.
структурное <br />
программирование — методология разработки программного
обеспечения, предложенная в 70-х года XX века Дейкстрой и разработанная и
дополненная Виртом.
В соответствии с данной методологией любая программа представляет собой
структуру, построенную из трёх типов базовых конструкций:
последовательного исполнение — однократное выполнение операций в том
порядке, в котором они записаны в тексте программы;
ветвление — однократное выполнение одной из двух или более операций, в
зависимости от выполнения некоторого заданного условия;
цикл — многократное исполнение одной и той же операции до тех пор, пока
выполняется некоторое заданное условие (условие продолжения цикла.
Убери из C# последовательное исполнение, ветвления и циклы. Попробуй
что-нибудь написать
Posted via RSDN NNTP Server 2.0
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, mihailik, Вы писали:
M>Есть большая разница и идеологическая, и техническая. Идеологическую хорошо выразил TK: объекты vs. сервисы [SOA].
А кто собственно мешает сделать из объектов сервисы?
M>>Есть большая разница и идеологическая, и техническая. Идеологическую хорошо выразил TK: объекты vs. сервисы [SOA].
ВВ>А кто собственно мешает сделать из объектов сервисы?
Сила тяготения мешает
Теоретически можно и жигуль-копейку заставить летать. Поменять подвеску, трамблёр. Резину новую поставить. Вертолётный винт...
Здравствуйте, mihailik, Вы писали:
M>>>Есть большая разница и идеологическая, и техническая. Идеологическую хорошо выразил TK: объекты vs. сервисы [SOA].
ВВ>>А кто собственно мешает сделать из объектов сервисы?
ВВ>>>А кто собственно мешает сделать из объектов сервисы?
ВВ>Ну и какие ты здесь проблемы видишь?
Кгм!
Просто совершенно разные подходы. Сериализация — разная. Endpoint'ы там фиксированные, а там любой MBR. Обратные вызовы туда же. Exception'ы вон в сервисах никак не передаётся.
В общем, задача выполнимая, но нетривиальная. А в некоторых случаях — очень непростая.
Здравствуйте, mihailik, Вы писали:
M>Просто совершенно разные подходы. Сериализация — разная. Endpoint'ы там фиксированные, а там любой MBR. Обратные вызовы туда же. Exception'ы вон в сервисах никак не передаётся.
Ну так это все технические аспекты, мы же вроде не о технических говорим
Мне как-то казалось, что SOA — это все-таки набор требований к архитектуре
Здравствуйте, mihailik, Вы писали:
M>Просто совершенно разные подходы. Сериализация — разная. Endpoint'ы там фиксированные, а там любой MBR.
Не любой, а только тот, который ты передаешь. Кроме того можно повесить фильтр, хоть через синку, хоть через TrackingServices.
M> Обратные вызовы туда же.
А это вобще элементарно отрубается отсутствием обратного канала.
Здравствуйте, Merle, Вы писали:
M>Ну WCF и так будет уметь все то, что умеет Remoting и даже немножко больше...
Неа. Lifetime management там существенно более куцый. Ну и еще кое какие мелочи.
M> Плюс к этому, MS в принципе не очень приветствует именно такой подход, сколько бы приверженцев у него не было, сейчас рулят SOA и ковровое бомбометание...
Отмаза при этом ровно одна — безрукие программеры в случае SOA менше безрукостью напортят.
Здравствуйте, AndrewVK, Вы писали:
AVK>Неа. Lifetime management там существенно более куцый. Ну и еще кое какие мелочи.
Да вроде обещают в полный рост, правда я не смотрел давно...
AVK>Отмаза при этом ровно одна — безрукие программеры в случае SOA менше безрукостью напортят.
Ну это уже дело десятое... Генеральная линия партии, онаж как рельс. Командир сказал "бурундучек — птичка",- и никаких зверьков.
Здравствуйте, mihailik, Вы писали:
M>Архитектура SOA сразу ложится на ASMX, WSE, WCF. M>И плохо, через пень-колоду ложится на Remoting, COM, CORBA и ассемблер токарного станка с ЧПУ.
Здравствуйте, mihailik, Вы писали:
M>Да любой гуру решит вам эту задачу за пять минут! M>А обычный смертный просидит всю ночь и до рассвета трижды отречётся от Билла Гейтса.
Все это конечно очень хорошо, но что делать если мне нужно использовать собственный транспорт или обращаться к клиентам с непрямым IP? Признать эти задачи еретическими/нерешаемыми?
ВВ>Все это конечно очень хорошо, но что делать если мне нужно использовать собственный транспорт
Вариантов много. Транспорты можно прикручивать как к сервисам, так и к Remoting. Нельзя — разве что к DCOM и IIS/ASMX. И то, в WSE3 можно уже ASMX гонять по кустомным шнуркам.
ВВ>или обращаться к клиентам с непрямым IP?
А это что за зверюга? Если Intellectual Property, то тут я пас. А если Internet Protocol address, то как он может быть непрямой? Положено 4 циферки, и баста.
ВВ> Признать эти задачи еретическими/нерешаемыми?
Почему, решаемыми. Но мы же говорили о том, насколько хорошо, удобно и разумно применять Remoting в связке с SOA.
Наверняка есть задачи, где даже SOA лучше делать на Remoting. Например, CrossDomain-вызовы, или даже CrossProcess. Но продвигать Remoting как приличную платформу для SOA вообще — это перебор.
Здравствуйте, Merle, Вы писали:
AVK>>Неа. Lifetime management там существенно более куцый. Ну и еще кое какие мелочи. M>Да вроде обещают в полный рост, правда я не смотрел давно...
Вопрос только какой он, этот рост. А то ведь и полного может оказаться меньше, чем у ремоутинга на корточках.
>> И плохо, через пень-колоду ложится на Remoting, COM
TK>Давай проще. Возьмем COM или Remoting... Что именно не ложится, какие TK>барьеры к этому?
Самый ключевой-философский...
{ кстати, а нас не перенесут за оффтопик в "Философию"? }
..ну да. Самый ключевой барьер — в Remoting и COM есть вызовы по ссылке.
То есть нарушается "контракт сервиса"
Помимо методов, зафиксированных в контракте, можно вызвать ещё какие-то "левые" методы. В рамках Remoting, в рамках OO-RPC это нормально, там это никакие не "левые" методы. Но в рамках SOA такие побочные вызовы — чистой воды ересь.
Остальные технические детали-несуразности (несуразности, если смотреть с колокольник SOA) — остальные несуразности уже не так значительны. Их тоже можно обсуждать до двадцатой ветки вложенности, но главное вот выше.
Лирическое отступление
Так получается, что Remoting относится к SOA примерно как JavaScript к OOP. Вроде и в JavaScript'е есть объекты, и наследование можно устроить. А вот инкапсуляции нет, полиморфизм дурацкий, типизация мягкотелая. В итоге назвать JavaScript подходящей платформой для OOP может разве что фанатик какой-нибудь, с подозрением на PHP.
Хотя факт, можно и на JavaScript'е писать сложный OOP-like код. И иногда даже НУЖНО писать на JavaScript'е сложный OOP-like код. Но что это меняет?
M>>Да любой гуру решит вам эту задачу за пять минут!
AVK>Да, чтобы воспользоваться TrackingServices, нужен конечно гуру. Нужно ведь реализовать интерфейс, в котором целых три метода!
Это ты так легко говоришь, потому что ты гуру.
Обычный человек в глаза этих сервисов не видел, и не увидит никогда, надеюсь
Здравствуйте, mihailik, Вы писали:
AVK>>Да, чтобы воспользоваться TrackingServices, нужен конечно гуру. Нужно ведь реализовать интерфейс, в котором целых три метода!
M>Это ты так легко говоришь, потому что ты гуру.
А ты попробуй. Глядишь и ремоутинг не таким ужасным казаться будет.
M>Обычный человек в глаза этих сервисов не видел, и не увидит никогда, надеюсь
Ты чего думаешь, WCF проще? Наивный. Сложные проблемы не могут решаться примитивными методами. Веб-сервисы это в очередной раз доказали. Вместо вундерваффе получили малополезную вещь.
AVK>>>Да, чтобы воспользоваться TrackingServices, нужен конечно гуру. Нужно ведь реализовать интерфейс, в котором целых три метода! M>>Это ты так легко говоришь, потому что ты гуру. AVK>А ты попробуй. Глядишь и ремоутинг не таким ужасным казаться будет.
Ну да, это как в рекламе. Ходят по городу: "Вы ещё не пробовали Тайд! Тогда мы идём к вам!" Чур, чур.
В общем, ключевое слово запомнил, спасибо. Авось, не пригодится
M>>Обычный человек в глаза этих сервисов не видел, и не увидит никогда, надеюсь
AVK>Ты чего думаешь, WCF проще? Наивный.
В данном случае WCF стопудово проще. И ASMX, и WSE проще.
Там фиксированность контрактов поддерживается самой инфраструктурой. Никаких TrackingServices из всего трёх методов не нужно.
Здравствуйте, mihailik, Вы писали:
ВВ>>Все это конечно очень хорошо, но что делать если мне нужно использовать собственный транспорт M>Вариантов много. Транспорты можно прикручивать как к сервисам, так и к Remoting. Нельзя — разве что к DCOM и IIS/ASMX. И то, в WSE3 можно уже ASMX гонять по кустомным шнуркам.
Т.е. я могу заставить два веб-сервиса общаться друг с другом через пайпы напрмер? Или написать свою реализацию протокола tcp?
ВВ>>или обращаться к клиентам с непрямым IP? M>А это что за зверюга? Если Intellectual Property, то тут я пас. А если Internet Protocol address, то как он может быть непрямой? Положено 4 циферки, и баста.
Вместо реально адреса клиента будет адрес раутера например, а так как tcp всегда при обращении открывает соединение заново, то мы садимся в лужу.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вопрос только какой он, этот рост. А то ведь и полного может оказаться меньше, чем у ремоутинга на корточках.
Ну, за что купил.. Дословно пару-тройку месяцев назад звучало как "точно не хуже".
Впрочем чего это мы? У меня контакты завалялись, как время появится — спрошу из первых рук.
Здравствуйте, mihailik, Вы писали:
M>Ну да, это как в рекламе. Ходят по городу: "Вы ещё не пробовали Тайд! Тогда мы идём к вам!" Чур, чур.
Мы о технологиях говорим, а не о стиральных порошках. И программисты несколько более образованы, нежели домохозяйки.
AVK>>Ты чего думаешь, WCF проще? Наивный.
M>В данном случае WCF стопудово проще.
Очень в этом сомневаюсь. С каждым билдом там все становится сложнее и сложнее. Xml-конфиг в январском билде на пару простеньких сервисов уже несколько кил размером. Ремоутингу такое и не снилось.
M>>Нельзя — разве что к DCOM и IIS/ASMX. И то, в WSE3 можно уже ASMX гонять по кустомным шнуркам.
ВВ>Т.е. я могу заставить два веб-сервиса общаться друг с другом через пайпы напрмер? Или написать свою реализацию протокола tcp?
AVK>>>Ты чего думаешь, WCF проще? Наивный. M>>В данном случае WCF стопудово проще. AVK>Очень в этом сомневаюсь. С каждым билдом там все становится сложнее и сложнее. Xml-конфиг в январском билде
Возвращаясь к теме. Мы говорим о том, что для применения SOA проще та или иная технология. Не проще вообще, и не проще в части расширений или конфигураций.
Для веб-сервисов, вообще для сервисов, SOA — проще применять свои нормальные технологии. ASMX, WSE, WCF и аналоги в других системах.
Использовать OO-RPC в стиле "не-объекты", в стиле SOA — можно.
Ты утверждаешь, что проще? Давай спорить. Если хочешь.
Service Oriented Architectures
One of the current industry buzzwords is the "Service Oriented Architecture" (SOA) which provides platform independent, message oriented, and loosely coupled services in enterprise environments. You might already guess: Remoting is not the right choice for these. Think about going ASMX + WSE here as well.
Здравствуйте, AndrewVK, Вы писали:
M>>В данном случае WCF стопудово проще.
AVK>Очень в этом сомневаюсь. С каждым билдом там все становится сложнее и сложнее. Xml-конфиг в январском билде на пару простеньких сервисов уже несколько кил размером. Ремоутингу такое и не снилось.
Здравствуйте, Юнусов Булат, Вы писали:
ЮБ>Имхо, при наличии SvcConfigEditor-а это не большая проблема.
Я не о проблемах (все равно этот конфиг проксигеном генерится), а о том, что полноценный RPC простым в обозримом будущем не станет. Это первые превьюхи индиги были простые как три пальца. А сейчас там наворотом куда больше ремоутинга.
Мы уже победили, просто это еще не так заметно...
.
Если нам не помогут, то мы тоже никого не пощадим.
