出于个人和大学研究的原因，我正在考虑使用面向服务的架构构建一个简单的 CRM。其意义只是解释架构本身，并非商业用途。
我正在考虑实施一个 CRM，提供简单的分析服务和客户服务（用户存储、个人评论和其他一些东西）。
我正在设计的架构定义了： - WebGUI（其他服务的客户端） - AnalyticsService（接收数据、分析和收集数据的服务） - CustomerCareService（使用 RESTful API 来应用 CRUD 操作的服务）。
每个服务都有自己的数据库，完全独立于其他服务。他们公开了一个公共接口。当然，接口必须提供某种身份验证，以拒绝未经授权的请求。
我想解释这种架构的优点是可以让所有事物独立，并且能够将它们组合起来提供新服务（例如，如果有一个 OrderService 来处理订单，那么很容易将其组合起来）与使用公共 API 的客户）。对我来说最大的优势是可以很容易地构建使用这些服务的其他客户端。
我不知道什么是一些好的身份验证方法，可以很容易实现，我也不确定如何制作这个 API（使用 XML 或带有 GET/POST 数据的普通 REST API）。我曾与 Amazon、PayPal 和其他公司 API 合作过，他们似乎使用 REST 服务（paypal 使用丑陋的 _cmd GET 参数，而 Amazon 使用更好的 URI）来了解该做什么，但是阅读有关 SOA 的内容后，人们似乎也使用XML。当然，我还需要考虑到 Web 界面必须能够识别登录的用户，获取权限（令牌或其他）并将其与服务一起使用来显示信息。 所以我不确定 SOA 是我真正构建的那种架构……它是 SaaS 而不是 SOA 吗？ 我认为最好使用 RESTful 应用程序，使用 JSON 或类似的东西来实现它（我不是 XML 的忠实粉丝，我发现它太冗长了）。
为了清楚起见，我在这里列出我的问题：
我大约有 3 个月的时间来做这件事，所以我无法做一些真正复杂的事情（除此之外，这对于单个程序员来说是不现实的）。
我了解Python（WSGI框架）、Ruby on Rails、C/C++和其他语言（.net除外），我想在Linux环境下开发它（MySQL或Postgres，甚至NoSQL，如果你有任何建议）为了正确的选择），我还可以将多种语言结合起来作为这些服务独立的程序。
我想在这里得到一些好的观点和一些好的建议。
谢谢！
我将 SaaS 定义为一种商业模式，而不是一种架构。与所有业务领域需求一样，SaaS 影响系统架构，但就其本身而言，它不是一种架构。
您定义的本质上是面向服务的架构。
您的陈述“独立且能够将它们组合起来提供新服务”是建议 SOA 的基本非功能性设计要求。
SOA 的良好实现是具有定义明确且灵活的接口，以及非常明确的职责划分。 然而，很难对此做出规定。证据就在吃中；它是否提供灵活的重用。
我的建议是花时间阅读 SOA 设计模式资源，并了解有关适当使用上下文的定义特征。 然后应用单一职责原则适当的抽象级别。参见（域）基于空间的架构 是一种 SOA 元模式。
关于授权，我建议遵循服务方法：使用分布式目录服务系统，例如开放LDAP，并注意，对于服务提供者和用户来说，拥有自己的凭据是完全合理的，并且您可以使用公钥-私钥来签名消息.
主要建议是学习和借鉴别人的经验：
SOA 并不强制使用 XML。
当前网络技术占据主导地位，并定义未来。 所以我们公司选择 JSON RESTful 服务作为基础。以 SOA 为原则。
建议语言是没有意义的，因为 SOA 和良好实现的目的是 - 允许使用任何语言或框架
（仅供参考，我们使用 Java 和基于 Spring MVC 的 Web 服务、Node.js、PHP）