网站推广的工作内容,专业微信网站建设,友情链接平台赚钱吗,永嘉专业网站建设团队在大多数非平凡的SOA环境中#xff0c;很难跟踪系统之间不断发展的集成#xff0c;除非有明确的发布和查找适当信息的方法。 概述IT环境#xff0c;定义当前或将要连接的内容#xff0c;是维护环境的先决条件。 缺少这种情况通常会导致“面向意大利面条的环境”的感觉… 在大多数非平凡的SOA环境中很难跟踪系统之间不断发展的集成除非有明确的发布和查找适当信息的方法。 概述IT环境定义当前或将要连接的内容是维护环境的先决条件。 缺少这种情况通常会导致“面向意大利面条的环境”的感觉并且不愿大胆尝试。 这句话听起来很明显但实际上并不总是考虑在内。 一些组织要么没有这样的集中式集成控制要么因为“妨碍了一切”而停止使用它。 充其量这意味着集成信息被保存在某些关键人物的头上这很冒险。 通常在这样的地方的团队不敢“在某些情况下仍然依赖它们”更新服务合同而是在需要更新时随时复制它们这与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
