Является ли WCF хорошим вариантом для предоставления услуг Oracle Service Bus - PullRequest
2 голосов
/ 13 апреля 2011

Наша компания имеет Oracle Service Bus Architecture (OSB).Моему отделу нужно предоставить немного сервисов этой OSB, которые впоследствии будут использоваться различными приложениями в разных отделах и технологиях.У меня есть 7-8 приложений, и все они на основе Microsoft (VB6, C #, SQL Server).Мой вопрос заключается в том, является ли WCF хорошим вариантом для развития наших услуг на основе данных?Хорошо ли он интегрируется с OSB?Есть ли проблемы с интеграцией?Какова лучшая практика и какой транспортный протокол для wcf следует использовать в этом сценарии?

Ответы [ 2 ]

4 голосов
/ 13 апреля 2011

Я принимал участие в успешных проектах, в которых WCF был интегрирован с OSB с использованием SOAP / HTTP в качестве транспортного протокола.

Из предыдущего опыта следует избегать двух ключевых рисков:

  1. Архитектурное разграничение - вам нужно разобраться, где будет жить оркестровка, учитывая, что обе платформы поддерживают ее, а WCF имеет все виды странных и причудливых функций, которые могут обеспечить выигрыш в производительности.
  2. Интеграция безопасности - хотя обе инфраструктуры предоставляют реализации общих стандартов безопасности, мой опыт пару лет назад заключался в том, что они НЕ очень хорошо играли вместе.

Если подход заключается в WCF для обеспечения интеграции данных,и OSB, чтобы обеспечить центральную точку доступа и правоприменения (наряду с интеграцией, возможно), то фантастически.Это четкая линия на песке.

1 голос
/ 14 апреля 2011

Я бы согласился с ответом Кевина. Из того, что я видел, WCF очень хорошо играет с продуктами Microsoft, но не так хорошо с другими. Если вы сохраняете свою реализацию службы WCF довольно ванильной и оставляете всю тяжелую работу на OSB (например, безопасность, политика, адресация), тогда вы можете быть в порядке.

Еще одна ловушка, о которой следует помнить, это то, что WCF, по-видимому, связывает типы XML с нативными типами .NET. Хотя это нормально для большинства типов, одной из причин, по которой мы испытывали головную боль, были даты. В XML вы можете иметь нулевую дату, но в .NET дата является примитивным типом, а не объектом, и поэтому умирает, когда вы пытаетесь сделать ее нулевой. Вы можете обойти это, обработав их как строки (yuk) и преобразовав в / из приложения, или, я полагаю, вы также можете создать пользовательскую привязку, в которую можно было бы обернуть тип даты в объект DateWrapper, чтобы обрабатывать нули .

Лично мне нравится, что модель служебной шины является просто фасадом для реализации, размещенной в другом месте, поэтому с этой точки зрения я не думаю, что имеет значение, какая технология используется за прикрытием предоставляемой OSB службы.

  • Если вы хотите использовать WCF, потому что вам нравятся его функции и он прекрасно интегрируется с вашими приложениями, сделайте это.
  • Если вы выбираете его только потому, что все дело в услугах и кажется, что он хорошо подходит для OSB, возможно, посмотрите, есть ли другие альтернативы, которые имеют меньшие накладные расходы для вас и вашей команды разработчиков.

С точки зрения транспорта, если ваши службы данных предназначены для доступа к данным нетранзакционным способом (например, для получения информации о клиенте), тогда SOAP / HTTP подойдет. Если вы имеете дело с транзакционными данными, возможно, стоит рассмотреть транспорт на основе обмена сообщениями, такой как JMS или MQ, так как опыт WS-ReliableMessaging пока не повсеместен и не является единообразным.

Надеюсь, это поможет.

...