soa学习路线
这句话听起来很明显，但是在实践中并不总是将其考虑在内。 一些组织要么没有这样的集中式集成控制，要么因为“妨碍了一切”而停止使用它。 充其量，这意味着集成信息保存在某些关键人物的脑海中，这是有风险的。 通常，在这样的地方的团队不敢“在某些情况下仍然依赖它们”更新服务合同，而是在需要更新时随时复制它们，这与SOA背道而驰。
有时，一个好主意只需要退后几步即可正确应用。 我在这篇文章中解释了为什么我认为对SOA路线图的需求应该会激发大多数Web服务（包括非敏感服务）上存在安全访问限制。
为什么这么简单的想法很难付诸实践？
有几个因素可以促使团队跳过这一重要的文档编制步骤：
- 其他重要的短期任务的紧迫性，以及团队不断地“扑灭大火”的感觉，没有时间做其他事情
- 缺少明确标识的中央存储库，该存储库用于在何处访问和发布此类信息（例如SOA注册中心或存储库），或者缺乏对它们的使用。
- 缺乏集中式管理，无法俯瞰整合
从人为因素的角度来看，“我已经受够了”综合症会使这种情况恶化。 在复杂的多团队/多项目环境中，已经为眼前的问题所困扰的个人通常不会主动寻找其他项目难以发现（并解决）的依赖问题。 我们需要对此进行预测并积极协助这些团队，同时要记住，他们要处理的其他问题当然也很重要。
以上内容的核心根源在于，在可能的情况下，更容易跳过集成的验证/文档步骤。 我们必须通过宣传集中式集成信息的价值以及提高实现无证集成的难度来扭转这种感觉。
我们需要的
我们需要一个易于使用的过程来收集，验证和发布系统之间当前和将来的依赖关系。 一个关键方面是以“足够的治理”方式使它保持简单并与实际使用它的人保持联系。
四个主要部分似乎是：
- 一个清晰的过程，用于请求新的集成或更新现有的集成。 这包括从业务和技术角度进行验证，以确保环境尽可能保持清洁和对未来的要求。 如果执行了EA工作，那么大多数请求都来自EA团队或来自EA团队，这使得此步骤变得微不足道！ 在实践中，当项目团队在详细的设计或实施阶段确定所需的依赖关系时，也将来自项目团队。
- 一个明确标识且易于访问的存储库，可在其中查找当前和计划中的集成。 该存储库必须包括每个未来依赖项的版本控制以及弃用/停用计划。
- 负责更新中央存储库的团队，使路线图保持最新。 如果有的话，通常是EA团队。
- 在技术层面上，如果不涉及上述三个组件，则无法执行集成。 这应该避免在合同更新触发问题之前一直隐藏的“幻影依赖项”。
在实践中，该第四部分应该是企业范围内的IT原则，该原则规定每个Web Service实现必须要求调用应用程序具有安全授权。 当服务需要时，这将不会阻止其他安全机制的存在，例如，传输带有发起原始业务操作的人工用户身份的票证（REST和SOAP都允许同时存在多个安全令牌）。
通常必须通过将技术文档和代码示例附加到IT原理上来简化该原理的实现。 因为我们不希望同事之间互相攻击，所以可以采取低风险的方法，其目的只是确保让EA团队更容易建立幻影依赖。 使用SOAP时，我的建议是使用简单的WS-UsernameToken策略，并为每个客户端应用程序关联一个用户名/密码对。 使用REST时，一种众所周知的机制是使用HMAC，将请求的一部分与随机数和/或到期日期一起进行哈希处理（此机制类似于Amazon S3所使用的机制）。
结论
在本文中，我试图解释为什么我认为在每个Web服务中系统地采用简单的安全策略有助于跟踪IT领域，并确保SOA治理团队看不到“幻影依赖项”。 此安全策略的实施必须简单易行，并得到帮助文档的支持，并且不能过于强大，仅足以确保EA团队了解所有集成实施。
参考：来自Svend博客的 JCG合作伙伴 Svend Vanderveken的Web服务安全性和SOA路线图的人为因素 。
翻译自: https://www.javacodegeeks.com/2012/09/web-service-security-and-human.html
soa学习路线
