Создание веб-сервисов не приведет к автоматическому разъединению технологий и устранению необходимости ссылаться на сборки и библиотеки типов для TFS и SVN, если вы не решите написать свои собственные оболочки. Простая ссылка на эти файлы не обязательно создает связь. Создание веб-службы для обмена данными с партнерами или клиентами обычно довольно просто; Создание архитектуры вокруг веб-сервисов - более сложная тема.
Чтобы ответить на вопрос «как могли бы помочь веб-сервисы», я не уверен, что они будут помогать вам здесь, если честно. Типичные случаи использования веб-сервисов:
- Распределенные системы / приложения;
- открытые API (т. Е. PayPal, flickr, twitter);
- Создание богатого автономного «бизнес-уровня» для крупномасштабного проекта;
- Сложные пользовательские правила безопасности;
- Взаимодействие через платформы (Java, JavaScript, C ++, Delphi и т. Д.)
- Предоставление абстракций для устаревших или нестабильных систем с целью плавного перехода или одновременного производства.
... между прочим, но общая тема в том, что они чаще всего используются для решения сложных проблем или внедрения сложных систем. Есть некоторые исключения, такие как ADO.NET Data Services, но я собираюсь отмахнуться от них здесь, чтобы избежать дальнейшего усложнения проблемы.
Что у вас есть - в относительном выражении - довольно простая проблема, у вас есть только одна задача для выполнения и только две задействованные системы, обе из которых достаточно хорошо известны и хорошо документированы, ни одна из которых не является может измениться каким-либо существенным образом. Так что преимущества веб-сервисов здесь трудно доказать.
Веб-сервис может помочь вам обеспечить общую абстракцию над VCS, безусловно. Но так может хорошо продуманный набор интерфейсов и библиотек классов, содержащихся в небольшой библиотеке. В последней версии у вас будет такая архитектура:
Sync Application
|
+-----> VcsFactory
| |
| |
Checkins <==== + ----> ICheckinRepository Source (TFS)
| |
Checkins ====> | ----> ICheckinRepository Destination (SVN)
Другими словами, вы разрабатываете это с идеей общего ICheckinRepository, который может дать вам Checkins (класс модели, который вы создаете), и вы используете фабрику для создания двух из них, источника (экземпляра) что-то вроде TfsCheckinRepository) и место назначения (SvnCheckinRepository), оба из которых обертывают свои соответствующие DLL и реализуют универсальный ICheckinRepository.
Затем вы просто извлекаете новые экземпляры Checkin из источника и сохраняете их в месте назначения. Это действительно очень простой, но, тем не менее, эффективный дизайн, который все еще дает вам слабую связь - вы можете поменять один тип ICheckinRepository на другой в любой заданной точке.
С помощью SOA (или мы можем просто назвать его веб-службами) у вас фактически есть физическая конечная точка службы , которая реализует ICheckinRepository в отличие от класса (служба внутренне использует класс, но клиент не знает об этом). Таким образом, чтобы поддержать описанный выше сценарий, вы должны создать один экземпляр службы, который реализует репозиторий TFS, второй, который реализует репозиторий SVN, и ваше приложение синхронизации просто указывает на два разных URL-адреса для источника / назначения, используя тот же интерфейс для каждый.
Звучит круто, но имейте в виду, что теперь вам нужно поддерживать 3 совершенно разных приложения. Вы можете уменьшить его до 2 - вы можете реализовать конечные точки TFS и SVN в одном проекте WCF - но все же вам нужно поддерживать как минимум двух приложений, клиент всегда будет разделен. Поэтому, если вы вносите какие-либо изменения в интерфейс, вам необходимо пересобрать и повторно протестировать оба приложения.
И затем вам нужно беспокоиться о том, как реализовать безопасность, надежную передачу сообщений, договоры о сбоях, оповещения и т. Д. Все, что вас не особо волнует в архитектуре с одним приложением.
Существуют значительные накладные расходы, связанные с поддержкой этой версии SOA, и все это для выполнения задачи, которая на самом деле не так уж и сложна - считывать проверки из источника, записывать проверки в место назначения. Я не думаю, что это того стоит.
Теперь я добавлю одну вещь, используя пример Source Control. - это вариант этой проблемы, где он может упростить вашу жизнь для создания веб-службы, и именно тогда вам нужно использовать VCS A (скажем, TFS) для некоторые проектов и VCS B (скажем, SVN) для других проектов.
В этом сценарии вы хотите предоставить единый унифицированный интерфейс «Контроль версий», который клиенты могут использовать, не беспокоясь о том, какой проект в какой VCS. Это надоедливая проблема для решения с использованием традиционных подходов; Вы могли бы создать свою собственную пользовательскую надстройку SC или расширение оболочки для выполнения этой работы, но это требует большого количества развертывания и обслуживания. Если от этого зависят какие-либо автономные приложения, проблема усугубляется.
Вот где веб-сервис становится невероятно полезным. Вы можете создать единый сервис, который скрывает реальные реализации VCS и предоставляет один интерфейс, который автоматически обновляется или фиксирует правильную VCS на основе проекта или типа проекта. Вместо того, чтобы иметь архитектуру, которая выглядит так:
+-----> SVN
+-------------------------------+ |
| Application -----> VC Library-|------+
+-------------------------------+ |
CLIENT +-----> TFS
У вас есть такой, который выглядит следующим образом:
+-----> SVN
+-------------+ +------------+ |
| Application-|-----> | VC Service-|---+
+-------------+ +------------+ |
CLIENT SERVER +-----> TFS
Что отличается? Ну, «ВК Сервис» централизован. В топовой версии мы должны упаковать VC-библиотеку с каждым экземпляром приложения, что означает головную боль при необходимости ее изменения. Во второй версии нам нужно всего лишь сделать одно изменение на сервере. Мы можем полностью изменить TFS на, я не знаю, на Rational или что-то подобное, даже если никто из клиентов даже не узнает об этом.
Разница между этим и исходным примером заключается в том, что в этом случае может быть несколько клиентов, которые используют одну и ту же услугу. В сценарии, поставленном этим вопросом, действительно будет только один «потребитель» веб-службы - приложение синхронизации, которое, вероятно, все еще будет работать как служба Windows или запланированная задача. Польза от этого невелика в лучшем случае. Выгода во втором примере здесь гораздо понятнее. Вы можете спроектировать приложение single для взаимодействия с single VC сервисом и позволить сервису разобраться в деталях реализации, и если вы меняете VC, вам не нужно обновлять или повторно разверните приложение.
Я надеюсь, что это хорошее объяснение того, когда и почему вы будете или не хотите использовать веб-сервисы для решения конкретной проблемы, где они, как правило, наиболее полезны в реальном мире. Я не думаю, что цена перевешивает выгоду здесь, но есть, конечно, много случаев, когда это будет.