问SOA中的报表(业务智能和面向服务的体系结构)

EN

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

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/

您考虑过用于SOA的ESB吗？它可以使数据集市更容易集成到SOA中。参见本文：http://www.b-eye-network.com/view/3018

是ESB的潜在用户之一，它是一个数据集成服务。事实上，一些供应商已经修改了他们的数据集成和ETL (提取、转换和加载)工具，使它们能够使用来自ESB的事件消息。这些事件可以携带有关源数据更改的信息，数据集成服务可以使用这些信息逐步更新操作数据存储(ODS)或数据仓库。这种方法对于需要日内数据的业务BI应用程序尤其有用。

这是一个很好的例子，说明当你不清楚你的设计优先级时可能会产生的混乱。特别是，就我的口味而言，对技术问题的关注太多，对用户需求的关注不够。

首先，我将与利益相关者合作，构建一组足以确定项目范围的良好用户故事，并列出用于第一阶段验收测试的功能。您成功项目的机会，以及降低以后重新设计的可能性的机会，是商定一个完整的可交付产品的描述，一旦第一阶段完成，该描述将立即有用并提供明显的价值。

它应该完全从用户的角度出发，甚至不使用“数据库”、"SOA“、"web服务”、"API“等词。

你要建立的是你和客户之间的一种对他们有价值的服务的合同协议；一旦达成协议，它就不应该改变，除非用他/她的话来增加它对客户的价值。因此，你最好的选择是尽量推迟对“如何”问题的考虑，直到你牢牢把握住“什么”。

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

在我的经验中，如果你把你的第一个注意力放在能够对用户的期望做出反应上(当每个人都从过程中学习)，而不是预先优化技术，那么每个人都会更快乐。Microsoft为您提供了多种方法来混合、匹配和发展企业设计。如果您对敏捷感兴趣，请记住从最不成功的开发开始，然后像mad一样迭代。

从设计中我看不出旅行社不需要以某种方式、形状或形式访问员工服务。如果它们是在虚拟隔离条件下操作的，那么您就会遇到一个主数据管理问题，只需等待处理。

最近，我设计了一个T&E系统的体系结构，其中包含企业基础结构中的人力资源数据，以及托管为SaaS的T&E前端。

在这种情况下，T&E系统需要一个基本的人力资源数据级别，主要是为了确保对员工进行验证。它还被要求允许系统正确处理旅行预订，而不要求员工重新输入关键数据。

这是通过将基本员工数据传递到旅行系统来实现的，首先是作为大容量装载，然后是在员工数据更改时进行更新。在传输一些PII数据时，这确实需要仔细的设计，但是安全的传输协议和源与目的地之间的良好加密可以缓解这种情况。

因此，关于旅行预订和活动的报告完全在旅行系统内。它们需要处于半仓库状态，以确保基本员工记录的更改不会污染历史旅行记录。这些都是“事务”，需要以这样的方式存储。

考虑到这一点，虽然你的设计不是完全错误的，但它并不是完全正确的。您很快就会遇到需要重新考虑设计才能解决的问题。我最重要的建议是遵循@le dorfier的建议，回到起点。设计以满足所有的用户需求，确保它们是真正的需求，而不仅仅是“想要”(也就是很好地拥有)。然后，自然设计将不仅包括外部托管前端的需求，还包括满足后端所需的报告。

实际上，我们今天设计的一切都必须考虑到互操作性，我们使用提供松散耦合的组件和模式构建模块化软件。这种灵活性为我们以后节省了数不清的精力，尽管设计需要更长的时间，但这是非常值得的。