我有一个带有员工服务和旅行服务的SOA。旅行服务将在[Travel]数据库中为employeeId创建travelID条目。员工将使用“TravelUI”网站（称旅游服务将详细信息存储在DB中）来申请旅行。管理员将使用“ManagerUI”网站批准旅行请求。 “ManagerUI”网站使用Travel服务以及Employee Service来获取详细信息。当经理批准旅行时，旅行记录（在[旅行]数据库中通过旅行服务中的操作获得批准。
注意：员工详细信息存储在[Employee]数据库中，Employee服务使用此数据。
现在，我们需要使用TravelID，旅行请求日期，员工ID，员工姓名，员工电话生成报告。前三个信息来自[Travel]数据库，剩余的来自[Employee]数据库。该报告将使用SSRS生成。
这里的问题不在于是否可以通过合并两个数据库来生成报告;但由于SOA的引入，它成为一个复杂的问题。
我们如何解决问题
我的设计中有哪些错误导致问题复杂化？
对于处理此类问题的任何好文章，您有什么建议吗？
注意：此处使用WCF计划SOA。
编辑：虽然标题提及商业智能，但我正在寻找一个主要不涉及datamart / datawarehouse的答案。 Datawarehouse的回答也很受欢迎 - 但主要目标是没有数据仓库。
读：
面向服务的商业智能 http://msdn.microsoft.com/en-us/library/bb245659.aspx
面向服务的商业智能架构 http://www.hpl.hp.com/personal/Claudio_Bartolini/download/soca07.pdf
面向服务的架构和商业智能 http://www.servicetechmag.com/I53/0811-2
Microsoft企业服务总线（ESB） http://msdn.microsoft.com/en-us/library/aa475433(v=bts.10).aspx
https://stackoverflow.com/questions/41353/net-esbs-out-there
答案 0 :(得分：2)
我可以看到的问题是SSRS违反了Contract Centralisation Pattern。相反，您的报告应该从您创建的服务生成，或者通过扩展这些服务生成。否则，您会在报表和数据库之间创建基于技术的紧密耦合，这将使得在需要时修改，迁移或重新实施您的旅行和员工系统变得更加困难。您以这种方式添加的报告越多，改变您的旅行和员工实施就越困难。
如果您还没有，我会在旅行服务上创建报告操作，例如，如果您使用的是基于SOAP的服务，请添加GetTravelRequests操作，该操作接受某种查询和分页参数，只返回匹配记录的TravelID，旅行请求日期，EmployeeID。然后创建一个GetEmployeeTravelRequests，它使用Employee服务中的GetTravelRequests操作组合GetEmployeeDetails。
这比基于SSRS的报告要慢，但只要您不更改服务合同，您就可以随时更改Travel和Employee服务的基础实施。
我有点假设您正在使用SOAP，这是上面的答案所基于的，但是如果RESTful服务是一个选项，那么我会推荐以下内容。而不是公开数字TravelID和EmployeeID，而是公开use URIs。例如，旅行服务将为Travel数据库中的员工URI创建旅行资源。然后创建Atom based feed个旅行请求。您可以停在那里以及报表用户需要员工详细信息的位置，他们可以遵循员工URI链接。否则，您可以使用员工URI创建一个包含每个旅行请求的员工详细信息的组合Atom订阅源。
后一种方法的主要优点是通过使用HTTP缓存减少了DB负载; HTTP GET是世界上最优化的操作。您的报告现在是一个实时报告，而不仅仅是当前报告的最新报告，可能是一天一次或每月一次，如果您正确构建了Feed，那么非头页永远不会更改并且可以缓存一年或更长时间。如果您认为员工详细信息不经常更改，那么您可以将max-age设置为1天，在这种情况下，对特定员工详细信息的查询只会每天访问数据库一次。
最后，另一个好处是，将TravelRequests集合资源添加到Employee资源变得非常简单，该资源包含基于Atom的分组列表，其中列出了该员工的所有旅行请求。
答案 1 :(得分：1)
我不认为你的设计是错的。除了事务处理之外，您的体系结构似乎缺少数据集市或仓库或某种支持商业智能的方式。
SOA中的BI是一个复杂的主题，如果不了解有关您的架构的一些细节，就无法提供建议。但是这里有一些文章可以帮助你入门：
您是否考虑过针对您的SOA的ESB？它可以使数据集市更容易集成到您的SOA中。请参阅此文章：http://www.b-eye-network.com/view/3018
ESB的潜在用户之一是数据集成服务。在 事实上，一些供应商已经修改了他们的数据集成和ETL （提取，转换和加载）工具是事件驱动的，以便它们 可以使用来自ESB的事件消息。这些事件可以携带 有关源数据更改的信息，可供数据使用 集成服务以逐步更新操作数据存储 （ODS）或数据仓库。这种方法特别有用 需要日内数据的可操作BI应用程序。
答案 2 :(得分：1)
这是一个很好的例子，说明当您不清楚您的设计优先级时可能会产生的混淆。特别是，根据我的口味，对技术问题的关注太多，而对用户的要求则不够。
我首先要与利益相关方合作，建立一套足以识别项目范围的良好用户故事，并列出将用于第一阶段验收测试的功能。您获得成功项目的机会，以及为了降低以后重新设计的可能性，就是就完整的可交付成果达成一致意见，该描述立即有用，并在第一阶段完成后提供明显的价值。
它应该完全从用户的角度构成，甚至不使用“数据库”，“SOA”，“Web服务”，“API”等词语。
您将建立的将是您与客户之间的一种合同协议，为他们提供有价值的服务;一旦达成一致，除非以他/她的条件增加对客户的价值，否则不应改变。因此，最好的办法是尝试推迟考虑“如何”问题，直到你确定“确定”为止。
然后，您可以自由地考虑可能用于提供相同结果的各种技术选项。通常，第一阶段的设计只能提供足够的功能以使其发挥作用;并且只要概念合同/逻辑设计不变，您就希望保持以任何您认为合适的方式学习和调整后端的灵活性。
根据我的经验，如果您首先关注能够对用户期望作出反应（这将在每个人都从过程中学习时填写）而不是预先优化技术，那么每个人都会更开心。 Microsoft为您提供了许多混合和匹配以及发展企业设计的方法。如果你正处于敏捷状态，请记住从最少开发的工作开始，然后像疯了一样迭代。
答案 3 :(得分：1)
我无法从设计中看到Travel服务不需要以某种方式，形状或形式访问Employee服务。如果它们在虚拟隔离中运行，那么您将遇到主数据管理问题，等待咬人。
我最近为T＆amp; E系统设计了架构，其中公司基础架构中的HR数据和作为SaaS托管的T＆amp; E前端。
在这种情况下，T＆amp; E系统需要基本级别的人力资源数据，主要是为了确保员工得到验证。还需要允许系统正确处理旅行预订，而无需员工重新输入关键数据。
这是通过将基本员工数据提供给旅行系统来实现的，首先是批量加载，然后是员工数据更改时的更新。这需要仔细设计，因为您正在传输一些PII数据，但安全传输协议和源和目标缓冲区之间的良好加密。
旅行预订和活动的报告完全在旅行系统内。他们需要处于半仓库状态，以确保基本员工记录的变化不会污染历史旅行记录。这些是“交易”，需要存储。
考虑到这一点，虽然你的设计并非完全错误，但它并不完全正确。您很快就会遇到需要重新访问设计才能解决的问题。我的首要建议是遵循@le dorfier的建议并回到起点。设计满足所有用户要求，确保它们不仅仅是“想要”的真正要求（即很高兴）。然后，自然设计将不仅包括外部托管前端的要求，还包括满足后端所需的报告要求。
我们今天设计的所有内容都必须在考虑到互操作性的情况下完成，我们使用提供松散耦合的组件和模式来构建模块化软件。这种灵活性为我们以后节省了不必要的努力，虽然设计需要更长的时间，但这是值得的。