Производительность - TCP, вполне хорошая скорость и универсальность - HTTP, с которым дружат все.
Я бы рекомендовал HTTP привязки. Для WCF - BasicHttpBinding или WSHttpBinding.

P.S. Про сокеты и ремоутинг забудь. От asmx тоже нужно постепенно отходить в сторону wcf.

ShSerge, может проблема в том, что ты не разобрался с веб-сервисами?
Хендлеры и рядом не валялись с веб-сервисами по возможностям. Одна генерация прокси по wsdl чего стоит.

ShSerge Хендлеры + передача данных из базы в XML (иногда, JSON) - наше всё.
Кстати, хендлеры прошлый век. WebAPI если на то прошло.

ShSergeЯ не генерил прокси. Мне это и нафиг не нужно.
Ну вот плохо, что я могу сказать. Вот боевой вебсервис центробанка, расскажи нам, чем он плох?
http://www.cbr.ru/dailyinfowebserv/dailyinfo.asmx
Автодокументация, автопрокси, типизация. Зло?

ShSergeМне надо было с одной базы на одном сервере вытащить данные для обработки в другой базе, на другом сервере. С одной и с другой стороны это дело пишется за 15 минут. Так и было.
И чем не устраивает asmx?

ShSergeА сейчас у меня (уже месяц) проблема с прикруткой, раскруткой и наладкой вэбсервиса (не я писал, человек уволился), который ещё более простую работу делает.
Ну вот я и говорю, просто не разобрался. Или тот чел написал какую-то жуть. Причем тут asmx-то?

ShSergeКстати, пару лет тому назад, я использовал данные из ЦБР. Но было это так:
1. Данные брал в формате XML.
2. В приложении аспнет преобразовывал их в JSON (стандартным способом).
3. JSON получал через JSONP, и прикручивал данные, куда было надо на страничке.
Не совсем хорошая архитектура налету мусолить цбр-овские вненшние ресурсы. Тру подходом является периодическое обновление данных (по шедулеру) с внешних SOA к себе в БД. А уж своим клиентам отдавать свои честные данные.

ShSergeА долго потому, что список урлов вэб-сервисов хранится в базе. У меня - один, у тестировщиков - другой, а у клиента -третьий.
Да и в интернет ходят все по разному. Я - напрямую, тестировщики через свой прокси, заказчик - через свой.
Ну точно так же у тебя и список урлов ashx хранится в базе. В чем смысл сказанного, не понимаю.

skyANAТема сисек урлов не раскрыта.
Я тоже не понимаю наезда на asmx. Если Серж заберёт слова обратно, отцеплюсь от него, так и быть

EDUARD SAPOTSKI+1 Я ваще сча на Workflow с WCF подсел. Команду на сервак послал, он там несколько часов мусолит, результат готов, лепота. Да и кубики складывать прикольно
Да, Workflow офигенная тема. В шарепоинте с ними пересекаюсь. Но чисто с нуля чтоб WF покурить, рука не поднимается :)

МСУЯ тоже не понимаю наезда на asmx. Если Серж заберёт слова обратно, отцеплюсь от него, так и быть
?

ShSergeЯ не наезжал. Хочется - пользуйся.
Хм...



То ли я дурак, то ли лыжи не едут (с)

ShSerge, говоришь загадками и елозишь на ровном месте, как егоза )
Определись, наконец, и дай резюмирующее заключение по SOA.

ShSergeЕсли хотите подключаться в "чужим" вэб-серверам, то очень удобная и полезная штука. Или писать свою общедоступную универсальную штуку.
А почему именно к чужим? Почему я не могу в своей компании развернуть честный SOA плацдарм, в котором все системы, учавствующие в интеграции, будут хоть по указанным шлюзам? Или ты предлагаешь интегрировать системы "на хендлерах"?

ShSergeА если Вы делаете "свой" проект на обеих сторонах, то это - просто ошибка проектирования.
На аргументы ты скуп...

ShSergeДля публичных и общедоступных фишек - очень полезно. Здесь никаких сомнений быть не может.
Я так и не понял, почему SOA должен классифицироваться на "публичность" и "непубличность". Сегодня публично, завтра непублично... Какая, вообще, разница?

ShSergeМСУА почему именно к чужим?
Это означает, что вопрос и ответ одновременно пишешь не ты, или кто-то из твоих респондентов недоступен в реале, поэтому тебе надо использовать стандартный протокол, а не то, что просто и естественно.
Нихрена не понял.

1. Почему меня и мой сервис должна заботить недоступность "респондентов"?
2. http - это уже не стандартный протокол?

Antonariy, всё верно говоришь, но позволю себе небольшой оффтоп: 14055386
Что скажешь?

ShSerge, по поводу хендлеров.

Более, чем ad hoc отдать статичный ресурсишко сайта (images, scripts, styles) - хендлеры ни на что не годятся. Строить какую-то там фундаментальную архитектуру (а-ля SOA) на хендлерах для транспорта объектов с сервера на клиент и обратно - это просто шизофрения, прости. Другого слова не подобралось.

AntonariyОк. Надо было в МСДН прямо в справке по свойству и написать, что ин мемори означает в temp.
Я тоже склоняюсь к точке зрения, что в справке хрень написана. Да и свойство по-идиотски названо, если на то пошло. Видно, когда-то хотели сделать действительно ин мемори, заготовили классы, написали доку. Но реализация оказалась слишком дорогой, решили не париться и сделали тяп-ляп.