SOA（面向商业智能和服务的体系结构）中的报告

Question

我的SOA具有员工服务和旅行服务。 旅行服务将在[旅行]数据库中为employeeId创建一个travelID条目。 员工将使用“ TravelUI”网站（该网站将调用Travel Service在DB中存储详细信息）来请求旅行。 有一个“ ManagerUI”网站，经理将使用它来批准旅行请求。 “ ManagerUI”网站使用差旅服务以及员工服务来获取详细信息。 当经理批准旅行时，旅行记录（在[旅行]数据库中）将通过使用旅行服务中的操作得到批准。

注意：员工详细信息存储在[Employee]数据库中，并且Employee服务使用此数据。

现在，我们需要生成一个包含TravelID，旅行请求日期，EmployeeID，EmployeeName，EmployeePhone的报告。 前三个信息来自[旅行]数据库，其余信息来自[员工]数据库。 该报告将使用SSRS生成。

这里的问题不是关于是否可以通过合并两个数据库来生成报告。 但是由于引入了SOA，这成为一个复杂的问题。

1. 我们如何解决问题

2. 我的设计中有哪些错误使问题变得复杂？

3. 您是否对处理此类问题的任何好的文章有任何建议？

注意：此处计划使用WCF计划SOA。

编辑 ：尽管标题提到了有关商业智能的问题，但我正在寻找一个主要不涉及datamart / datawarehouse的答案。 数据仓库的答案也很受欢迎-但主要目的是没有数据仓库。

读：

1. 面向服务的商业智能http://msdn.microsoft.com/en-us/library/bb245659.aspx

2. 商业智能的面向服务的体系结构http://www.hpl.hp.com/personal/Claudio_Bartolini/download/soca07.pdf

3. 面向服务的体系结构和商业智能http://www.servicetechmag.com/I53/0811-2

4. Microsoft在企业服务总线（ESB）上http://msdn.microsoft.com/zh-cn/library/aa475433(v=bts.10).aspx

5. https://stackoverflow.com/questions/41353/net-esbs-out-there

Answer 1

从我看到的问题是，SSRS违反了合同集中化模式 。 相反，您应该通过已创建的服务或通过扩展这些服务来生成报告。 否则，您将在报表和数据库之间建立基于紧密技术的耦合，这将使在需要时修改，迁移或重新实现差旅和员工系统变得更加困难。 通过这种方式添加的报告越多，更改差旅和员工实施的难度就越大。

如果还没有，我将在旅行服务上创建报告操作，例如，如果您正在使用基于SOAP的服务，则添加GetTravelRequests操作，该操作接受某种查询和分页参数，该操作仅返回TravelID，旅行请求日期，匹配记录的EmployeeID。 然后创建一个GetEmployeeTravelRequests ，它由Employee服务中的GetTravelRequests与GetEmployeeDetails操作组成。

这将比基于SSRS的报告要慢，但是只要您不更改服务合同，就可以随意更改差旅和员工服务的基础实现。

我有点假设您使用的是SOAP，这就是上面的答案所基于的，但是，如果可以选择RESTful服务，那么我将建议以下内容。 与其公开数字TravelID和EmployeeID ， TravelID 使用URIs 。 例如，旅行服务将在Travel数据库中为员工URI创建旅行资源。 然后创建基于Atom的旅行请求提要 。 您可以在此处停下来，报表用户需要员工详细信息的地方，他们可以点击员工URI链接。 否则，您可以使用员工URI创建组合的Atom提要，其中包括每个差旅请求的员工详细信息。

后一种方法的主要优点是通过使用HTTP缓存减少了数据库负载。 HTTP GET是世界上最优化的操作。 您的报告现在是实时报告，而不是最新的报告，它可能是每天一次或每月一次，并且如果您正确地构造了Feed，则非首页不会更改并且可以被缓存一年或更长时间。 如果您假设员工详细信息很少更改，则可以将最大年龄设置为1天，在这种情况下，对特定员工详细信息的查询每天只会在数据库中进行一次。

最后，另一个不错的好处是，将TravelRequests集合资源添加到Employee资源变得非常容易，该资源包含该Employee的所有旅行请求的基于Atom的分页列表。

Answer 2

我认为您的设计没有错。 除了事务处理之外，您的体系结构似乎还缺少数据集市或仓库或某种支持商业智能的方式。

SOA中的BI是一个复杂的主题，如果不了解有关体系结构的一些细节，就不可能给出建议。 但是这里有一些入门指南：

• http://www.infoq.com/articles/BI-and-SOA
• http://blogs.informatica.com/perspectives/index.php/2008/09/30/how-soa-enhances-data-warehousing-and-business-intelligence/

您是否考虑过将ESB用于您的SOA？ 它可以使将数据集市轻松集成到您的SOA中。 看到这篇文章： http : //www.b-eye-network.com/view/3018

ESB的潜在用户之一是数据集成服务。 实际上，一些供应商已将其数据集成和ETL（提取，转换和加载）工具修改为事件驱动的，以便他们可以使用来自ESB的事件消息。 这些事件可以携带有关源数据更改的信息，数据集成服务可以使用这些信息来增量更新操作数据存储（ODS）或数据仓库。 对于需要日间数据的可操作BI应用程序，此方法特别有用。

Answer 3

这是当您不清楚设计优先级时可能导致的混淆的一个很好的例子。 特别是，就我的口味而言，对技术问题的关注过多，而对用户要求的关注却不够。

首先，我将与利益相关者合作，建立一套足以确定项目范围并列出将用于第一阶段验收测试的功能的用户故事。 一个成功项目的机会，以及减少以后重新设计的可能性，是要达成一个完整交付物的描述，该交付物将立即有用并在第一阶段完成后提供明显的价值。

它应该完全从用户的角度组成，甚至不使用单词“数据库”，“ SOA”，“ Web服务”，“ API”等。

您将要建立的将是您与客户之间的一种合同协议，旨在为他们提供有价值的服务； 并且一旦达成协议，就不应更改它，除非以他/她的名义增加对客户的价值。 因此，最好的选择是尝试推迟对“如何”问题的考虑，直到您牢牢确定了“什么”。

然后，您可以自由考虑可能用于获得相同结果的各种技术选择。 通常，有一个第一阶段设计可以提供足够的功能来使它工作。 并且您希望保留只要您认为合适的任何方式来学习和调整后端的灵活性，只要概念合同/逻辑设计不变即可。

以我的经验，如果您首先关注能够对用户期望做出反应（随着每个人从过程中学习而来的话），而不是预先优化技术，那么每个人都会更快乐。 Microsoft为您提供了多种混合，匹配和改进企业设计的方法。 如果您喜欢敏捷，请记住从最有效的开发开始，然后疯狂地迭代。

Answer 4

从设计中我无法看到Travel服务不需要以某种方式，形状或形式访问Employee服务。 如果它们是在虚拟隔离中运行的，那么您将有一个主数据管理问题，只是要等待一下。

我最近为T＆E系统设计了体系结构，并在公司基础结构中使用了HR数据，而将T＆E前端托管为SaaS。

在那种情况下，T＆E系统需要基本水平的HR数据，主要是为了确保对员工进行验证。 还需要允许系统正确处理旅行预订，而无需员工重新输入关键数据。

这是通过以下方式实现的：首先将基本员工数据提供给差旅系统，然后将其作为批量加​​载，然后通过更新员工数据来进行更新。 在传输某些PII数据时，这确实需要进行仔细的设计，但是源和目标之间的安全传输协议和良好的加密会减轻这种情况。

这样，关于旅行预订和活动的报告就完全在旅行系统中了。 必须将它们保存在半仓库状态，以确保基本员工记录中的更改不会污染历史旅行记录。 这些是“交易”，需要照此存储。

考虑到这一点，虽然您的设计并非完全错误，但并非完全正确。 您很快就会遇到需要重新设计以解决的问题。 我的总体建议是遵循@le dorfier的建议，然后重新开始。 设计满足所有用户要求，确保它们是真实的要求，而不仅仅是“想要”（即很高兴）。 自然的设计将不仅包括对外部托管前端的要求，而且还包括满足后端要求的报告的要求。

实际上，我们今天设计的所有内容都必须做到互操作性，我们使用提供松散耦合的组件和模式来构建模块化软件。 这种灵活性为我们节省了后来的大量工作，尽管设计花费了更长的时间，但这样做还是值得的。