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

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

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

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

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

1. 我们该如何解决这个问题

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

3. 您对处理此类问题有什么好的文章建议吗？

注意：这里计划使用 WCF 来实现 SOA。

EDIT：虽然标题提到了商业智能，但我正在寻找一个主要不涉及数据集市/数据仓库的答案。数据仓库的答案也很受欢迎 - 但主要目标是没有数据仓库。

READING:

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

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

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

4. Microsoft 的企业服务总线 (ESB)http://msdn.microsoft.com/en-us/library/aa475433(v=bts.10).aspx http://msdn.microsoft.com/en-us/library/aa475433(v=bts.10).aspx

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

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

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

这将比基于 SSRS 的报告慢，但您可以自由地更改旅行和员工服务的底层实现，只要您不更改服务合同。

我有点假设您正在使用 SOAP，这是上面答案所基于的，但是如果可以选择 RESTful 服务，那么我会推荐以下内容。而不是暴露数字TravelIDs and EmployeeIDs，而不是use URIs http://www.soapatterns.org/entity_linking.php。例如，旅行服务将为员工 URI 创建旅行资源Travel数据库。然后创建一个原子饲料 https://www.rfc-editor.org/rfc/rfc5005旅行请求。您可以到此为止，并且报表用户需要员工详细信息时，他们可以点击员工 URI 链接。否则，您可以使用员工 URI 创建一个组合 Atom 源，其中包含每个差旅请求的员工详细信息。

后一种方法的主要优点是通过使用 HTTP 缓存减少数据库负载； HTTP GET 是世界上最优化的操作。您的报告现在是实时报告，而不仅仅是上次生成时的最新报告，可能是每天一次或每月一次，如果您正确构建提要，那么非标题页面永远不会更改并且可以缓存一年或更长时间。如果您假设员工详细信息很少更改，则可以将 max-age 设置为 1 天，在这种情况下，对特定员工详细信息的查询每天只会访问数据库一次。

最后，另一个好处是，添加一个TravelRequests采集资源到Employee资源，其中包含该员工的所有旅行请求的基于 Atom 的分页列表。