Я бы согласился с ответом Кевина. Из того, что я видел, WCF очень хорошо играет с продуктами Microsoft, но не так хорошо с другими. Если вы сохраняете свою реализацию службы WCF довольно ванильной и оставляете всю тяжелую работу на OSB (например, безопасность, политика, адресация), тогда вы можете быть в порядке.
Еще одна ловушка, о которой следует помнить, это то, что WCF, по-видимому, связывает типы XML с нативными типами .NET. Хотя это нормально для большинства типов, одной из причин, по которой мы испытывали головную боль, были даты. В XML вы можете иметь нулевую дату, но в .NET дата является примитивным типом, а не объектом, и поэтому умирает, когда вы пытаетесь сделать ее нулевой. Вы можете обойти это, обработав их как строки (yuk) и преобразовав в / из приложения, или, я полагаю, вы также можете создать пользовательскую привязку, в которую можно было бы обернуть тип даты в объект DateWrapper, чтобы обрабатывать нули .
Лично мне нравится, что модель служебной шины является просто фасадом для реализации, размещенной в другом месте, поэтому с этой точки зрения я не думаю, что имеет значение, какая технология используется за прикрытием предоставляемой OSB службы.
- Если вы хотите использовать WCF, потому что вам нравятся его функции и он прекрасно интегрируется с вашими приложениями, сделайте это.
- Если вы выбираете его только потому, что все дело в услугах и кажется, что он хорошо подходит для OSB, возможно, посмотрите, есть ли другие альтернативы, которые имеют меньшие накладные расходы для вас и вашей команды разработчиков.
С точки зрения транспорта, если ваши службы данных предназначены для доступа к данным нетранзакционным способом (например, для получения информации о клиенте), тогда SOAP / HTTP подойдет. Если вы имеете дело с транзакционными данными, возможно, стоит рассмотреть транспорт на основе обмена сообщениями, такой как JMS или MQ, так как опыт WS-ReliableMessaging пока не повсеместен и не является единообразным.
Надеюсь, это поможет.