集成两个系统以相互对话-Web服务如何将集成分离?

创建Web服务不会自动分离技术,也不会消除引用TFS和SVN的程序集和类型库的需要,除非您选择编写自己的包装器。引用这些文件也不一定会创建耦合。建立一个Web服务来与合作伙伴或客户机共享数据通常非常简单;围绕Web服务创建一个架构是一个更复杂的主题。

要回答“Web服务如何提供帮助”的问题,我不确定他们 将 在这里帮你,说实话。Web服务的常见用例有:

• 分布式系统/应用程序;
• 面向公众的API(即PayPal、Flickr、Twitter);
• 为大型项目创建丰富的独立“业务层”;
• 复杂的自定义安全规则;
• 跨平台的互操作性(Java、JavaScript、C++、Delphi等)
• 在遗留系统或不稳定系统上提供抽象,以实现平稳过渡或并行生产。

…除其他外,共同的主题是,它们最常被用于解决复杂问题或实现复杂系统。有一些例外,如ADO.NET数据服务,但我将在这里手工挥动它们,以避免问题进一步复杂化。

相对而言,你所拥有的是一个相当简单的问题,你只有一个任务要执行,而且只涉及两个系统,这两个系统都是相当知名和有良好文档记录的,两者都不可能以任何显著的方式发生变化。因此,Web服务的好处很难证明。

当然,Web服务可以帮助您在VCS上提供一个通用的抽象。但是,一个设计良好的接口集和类库也可以放在一个小的库中。在后一个版本中,您将拥有这样的体系结构:

Sync Application
       |
       +-----> VcsFactory
       |           |
       |           |
    Checkins <==== + ----> ICheckinRepository Source (TFS)
       |           |
    Checkins ====> | ----> ICheckinRepository Destination (SVN)

换言之,您用一个通用的概念来设计这个 ICheckinRepository 那可以给你 Checkins (您创建的模型类),并使用工厂创建其中的两个,源(类似 TfsCheckinRepository )和目的地( SvnCheckinRepository ,两者都包装各自的DLL并实现通用的 ICheckinrepository公司 .

然后你只需检索新的 Checkin 来自源的实例并将其保存到目标。这确实是一个非常简单但仍然有效的设计,仍然给你松耦合-你可以换一个。 ICheckinrepository公司 在任何给定点为另一个键入。

有了SOA(或者我们可以称之为Web服务),您实际上拥有一个 服务端点 那工具 ICheckinrepository公司 与类相反(服务内部使用类,但客户端不知道这一点)。因此,为了支持上面描述的场景,您将创建一个实现TFS存储库的服务实例,另一个实现SVN存储库的服务实例,并让同步应用程序简单地指向源/目标的两个不同的URL,每个URL使用相同的接口。

听起来有点酷,但请记住,现在您必须维护3个完全独立且不同的应用程序。你可以把它降到2级——你可以在一个WCF项目中实现TFS和SVN端点——但是你仍然需要维护 至少 两个应用程序,客户端始终是独立的。因此,如果对接口进行任何更改,则必须重新构建并重新测试这两个应用程序。

然后,您必须担心如何实现安全性、可靠的消息传递、故障契约、警报等,所有在单个应用程序体系结构中您不会真正关心的事情。

维护这个SOA版本需要很大的开销,而且所有这些都需要执行一个真正不那么复杂的任务——从源代码读取签入,将签入写入目标。我觉得这不值得。

现在,我将使用源代码管理示例添加一件事。那里 是 这个问题的变种 将 简化你的生活来创建一个Web服务,也就是当你需要使用VCS A(比如TFS)来 一些 项目和VCS B(比如SVN) 其他 项目。

在这个场景中,您希望提供一个统一的“版本控制”接口,客户机可以使用它,而不必担心哪个项目是哪个VCS。使用传统方法来解决这是一个恼人的问题;您可以构建自己的定制SC插件或shell扩展来完成这项工作,但这需要处理大量的部署和维护。如果有任何独立的应用程序依赖于它,那么问题会变得更严重。

这就是Web服务变得非常有用的地方。您可以创建一个 隐藏真正的VCS实现 并提供一个根据项目或项目类型自动更新或提交到正确VCS的接口。而不是像这样的架构:

                                       +-----> SVN
+-------------------------------+      |
| Application -----> VC Library-|------+
+-------------------------------+      |
              CLIENT                   +-----> TFS

您有一个如下所示:

                                       +-----> SVN
+-------------+       +------------+   |
| Application-|-----> | VC Service-|---+
+-------------+       +------------+   |
     CLIENT               SERVER       +-----> TFS

有什么不同?嗯,“VC服务”是集中的。在顶级版本中,我们必须将VC库与应用程序的每个实例打包在一起,这意味着当需要更改时会很头疼。在第二个版本中,我们只需要在服务器上进行一次更改。我们可以完全将tfs改为,我不知道,理性的或者其他什么东西,而不需要任何客户知道它。

这与原始示例的区别在于,在这种情况下,可能有多个客户机都使用相同的服务。在这个问题所提出的场景中,实际上只有一个Web服务的“使用者”——可能仍然作为Windows服务或计划任务运行的同步应用程序。这样做的好处充其量是微乎其微的。第二个例子中的好处更为明显。你可以设计一个 单一的 应用程序与 单一的 VC服务并让服务整理实现细节,如果您更改了VC,就不必更新或重新部署应用程序。

我希望这是一个很好的解释,说明您何时以及为什么会使用或不使用Web服务来解决一个特定的问题,即它们在现实世界中最有用的地方。我不认为成本大于收益,但当然有很多情况下它会。