简单应用的复杂架构

Question

作为顾问，我负责为外部公司设计应用程序的体系结构。这个应用程序的要求非常简单，整个过程可以通过基本的Web应用程序，一个或两个传入的Web服务和一些传出的文档通道轻松解决。

由于两个非功能性要求，事情变得更加复杂：

1. 公司要求所有内部应用程序都通过企业门户提供（用于UI，安全性和技术统一性）
2. 公司要求所有应用程序都是使用SOA原则构建的，这样服务最终可以在ESB上发布并重用。

架构可以轻松地适应门户网站的要求。演示文稿将使用portlet构建并集成到门户主题中，并且将重用门户网站安全性。没什么大不了的。

SOA要求是另一个故事。尚未确定可重用服务。我看到它的方式，有几个选择：

1. 业务逻辑部署在门户网站上，与表示层位于同一位置。没有任何服务暴露，这个决定被推迟。
2. 业务逻辑部署在单独的服务器上。设计API并使用封闭协议（例如RMI或Hessian）公开所有服务。对于需要最终重用的服务，可以在这些服务之上添加SOAP API。
3. 业务逻辑部署在单独的服务器上。设计了SOAP API，并使用此机制公开了所有服务。

我想避免构建太复杂的东西。我经历过与业务代表，远程外观和DTO的项目，每个变更都需要修改几个层。然而，感觉好像这个SOA要求强行推动我朝这个方向发展。

更新：我越是想到它，我越发现设计远程API需要复杂性。当然这需要为服务创建接口，但是交换的实体呢？要么我采用DTO方式并最终得到两个并行对象层次结构（一个用于DTO，一个用于实际实体），或者我采用接口方式并为需要跨服务器传输的所有实体声明接口。无论哪种方式，这都会带来一系列全新的问题，最终我们将编写大量的样板代码。而且我认为我们已经度过了那个时代......

设计此方法的最佳（或最差）方法是什么？

谢谢大家。

Answer 1

我很高兴看到您在构建企业架构和理解不同架构的后果方面拥有一些实际经验。我见过很多顾问刚刚读过一本关于一些新时尚技术的书......

选项1肯定是最务实和最实惠的。您将构建一个现在需要的应用程序，而不是投资于将来可能使用或可能不会使用的服务。但正如我从您的描述中理解的那样，这可能很难卖给客户。

如果你必须使用分布式架构（选项2或3），我仍然会尝试尽可能多地放在门户服务器上。为此，必须以非常狭窄的方式定义术语业务逻辑。与演示文稿甚至远程相关的所有内容（用户设置，用于演示目的的数据结构，已生成的报告等）都声明为表示逻辑，因此可以在门户网站服务器上实现。因此，即使您无法避免远程处理带来的重复和复杂性，也可以将其限制在更少的区域。 （根据手头的问题，你可能最终得到门户服务器上的数据库和业务逻辑服务器上的数据库，这些数据库更好地合并为一个，因为它们之间有太多的数据引用。希望不是这种情况此处。）

根据我的经验，只考虑一个应用程序编写可重用的服务是浪费的投资。对于这个单独的应用程序，servcie接口将变得更加复杂，接口的一部分将永远不会被使用并且几乎不会被测试（因为它是为某些想象的未来应用而构建的），并且当第二个应用程序最终到达时，人们意识到它具有与可以预见的。因此，需要重新设计服务并修改现有的应用程序。因此，除非您至少有两个（更好的三个）应用程序存在或正在实施，否则不要开始构建服务。它在服务界面的金钱和质量方面得到了回报。

此建议不是非常具体，但您对应用程序业务要求的描述也是如此。由于您签署了保密协议，您可能无法提供更多信息。但我经常发现业务需求有助于争论或反对某个选项。例如。需求，相关数据，数据所有权和涉及的流程可能更好地划分系统然后划分技术考虑因素。

Answer 2

我选择第一个选项，标记小心地创建业务层接口的服务，然后禁止从表示层调用此接口后面的任何内容。这使您可以在以后以合理的低成本和可预测的成本切换到具有远程处理的选项（无论您选择第二个还是三个）。

如果无法做到这一点，则选项二承诺更有效地使用资源。

在将业务逻辑划分为业务逻辑时尚未提及一个有趣的部分 - 这是当您必须基于仅存在于表示层中的数据来过滤来自业务逻辑的数据时，例如，用户和他/她的许可。 ：）

Answer 3

WSO2 SOA堆栈提供适合您的架构的各种解决方案。请查看http://wso2.org/以了解相关信息。毕竟它的免费和开源：）