SOA设计时间治理时代可能结束
2008-09-22 10:20
253 查看
治理是SOA明确的一个要求,你需要一个能够跟踪、安全、界定和维护服务的地方。于是出现了两种截然不同的SOA治理方法:设计时间治理和运行时间治理。
多数SOA技术在SOA范围内都具有一定的价值,但随着我们越来越了解SOA实施和其成功的需要,许多现存的技术似乎都没有带来很大的作用。这是一个在任何技术趋势中都会产生的自然的技术正常化过程,SOA也不例外。
治理是SOA明确的一个要求,你需要一个能够跟踪、安全、界定和维护服务的地方。于是出现了两种截然不同的SOA治理方法:设计时间治理和运行时间治理。
运行时间SOA治理,顾名思义更多的是关于运营要求的,包括实践服务水平协议(SLA)的能力,执行围绕服务的政策,确保服务共同协作支持
SOA,由此支持业务运转。这个价值是清楚而明确的,因此多数运行时间SOA治理产品很是畅销,我将此技术看作是SOA成功之关键。
设计时间SOA治理,顾名思义通常提供一个集成的注册表或存储器,试图从服务设计到部署阶段而不是在服务运行时间对其进行管理。SOA设计时间治理的关键组件大体来说包括:
注册表和/或存储器,跟踪服务设计、管理、政策和安全,并测试伪冒品
设计工具,包括服务建模、从属跟踪、政策建立和管理以及辅助服务设计的其他工具
部署配置工具,包括服务配置,通常是通过与外部开发环境捆绑来实现
与测试工具和服务的链接,让开发者或设计者建立一个测试计划和测试情境,而后利用服务测试技术
从本质上说,设计时间SOA治理参与了从数据到服务的过程,收集关键信息。因此你一般都从界定基本的数据架构和转变为元数据的转折点(或者是数
据提取)开始。进一步你会界定与数据和数据服务互动的服务,而后是更高一层的交易服务,你可以继续定义流程或编排。所有的一切都在设计时间信息的帮助下完
成,也就是在设计时间SOA治理系统中发生。
问题在于设计时间SOA治理技术能够从何种程度上为上述真正的“设计”概念服务。多数是达不到这个程度的,因此许多SOA设计师缺少更强大的特
色和只能,包括在SOA设计和开发最佳实践基础上的真正建模和模拟能力。因此,多数都绕过设计时间治理直接进入运行时间这是有理由的。
像多数SOA技术一样,另一个问题就是缺少设计时间SOA治理的标准方法。当一些新的标准出现时,许多SOA治理技术已经以自己的方式走上了各
自的方向,找不出两个是相似的。因此,你不仅要挑选一个工具,你还要选择设计方式,而这个方式还不一定适合你的架构。我见过的多数SOA项目都被设计来最
好利用传统办公司自动化工具,而这些项目似乎都还运作的不错。这对于利用良好设计环境来说是件坏事。不过,好的环境也似乎不存在于现有设计时间SOA治理
工具之中。
除此以外,大部分设计时间SOA治理工具将大量的时间花在了对于运行时间问题的担忧上,如服务水平协议(SLAs),而绝少解决关键的设计时间问题。许多SOA架构师对现有的设计时间选择很失望,转而采取电子数据表作为他们的设计时间工具。很明显今天的设计时间SOA治理厂商在这方面的理解和表现都非常不足。
那么你要怎样解决现有设计时间SOA治理工具的问题呢?
首先,你应该得出一个有意义的高水平方法,再解决如何将这个方法融合到一个更大的SOA设计和配置方法论中去。现有的工具基本上不存在背景,也就更谈不上价值了。
第二,要么是运行时间工具要么就不是,因此你要了解你的工具需要进入到架构哪一个部分。我的建议是选择一部分做好而不要所有的涉及,因为已经有许多不错的运行时间SOA治理工具了。
最后,收集并创建工具间一致的标准、技术和方法。目前这些标准、技术和方法是不一样并且具有版权的,但在人们寻找长期战略持久标准技术的今天这些是难以销售的。
多数SOA技术在SOA范围内都具有一定的价值,但随着我们越来越了解SOA实施和其成功的需要,许多现存的技术似乎都没有带来很大的作用。这是一个在任何技术趋势中都会产生的自然的技术正常化过程,SOA也不例外。
治理是SOA明确的一个要求,你需要一个能够跟踪、安全、界定和维护服务的地方。于是出现了两种截然不同的SOA治理方法:设计时间治理和运行时间治理。
运行时间SOA治理,顾名思义更多的是关于运营要求的,包括实践服务水平协议(SLA)的能力,执行围绕服务的政策,确保服务共同协作支持
SOA,由此支持业务运转。这个价值是清楚而明确的,因此多数运行时间SOA治理产品很是畅销,我将此技术看作是SOA成功之关键。
设计时间SOA治理,顾名思义通常提供一个集成的注册表或存储器,试图从服务设计到部署阶段而不是在服务运行时间对其进行管理。SOA设计时间治理的关键组件大体来说包括:
注册表和/或存储器,跟踪服务设计、管理、政策和安全,并测试伪冒品
设计工具,包括服务建模、从属跟踪、政策建立和管理以及辅助服务设计的其他工具
部署配置工具,包括服务配置,通常是通过与外部开发环境捆绑来实现
与测试工具和服务的链接,让开发者或设计者建立一个测试计划和测试情境,而后利用服务测试技术
从本质上说,设计时间SOA治理参与了从数据到服务的过程,收集关键信息。因此你一般都从界定基本的数据架构和转变为元数据的转折点(或者是数
据提取)开始。进一步你会界定与数据和数据服务互动的服务,而后是更高一层的交易服务,你可以继续定义流程或编排。所有的一切都在设计时间信息的帮助下完
成,也就是在设计时间SOA治理系统中发生。
问题在于设计时间SOA治理技术能够从何种程度上为上述真正的“设计”概念服务。多数是达不到这个程度的,因此许多SOA设计师缺少更强大的特
色和只能,包括在SOA设计和开发最佳实践基础上的真正建模和模拟能力。因此,多数都绕过设计时间治理直接进入运行时间这是有理由的。
像多数SOA技术一样,另一个问题就是缺少设计时间SOA治理的标准方法。当一些新的标准出现时,许多SOA治理技术已经以自己的方式走上了各
自的方向,找不出两个是相似的。因此,你不仅要挑选一个工具,你还要选择设计方式,而这个方式还不一定适合你的架构。我见过的多数SOA项目都被设计来最
好利用传统办公司自动化工具,而这些项目似乎都还运作的不错。这对于利用良好设计环境来说是件坏事。不过,好的环境也似乎不存在于现有设计时间SOA治理
工具之中。
除此以外,大部分设计时间SOA治理工具将大量的时间花在了对于运行时间问题的担忧上,如服务水平协议(SLAs),而绝少解决关键的设计时间问题。许多SOA架构师对现有的设计时间选择很失望,转而采取电子数据表作为他们的设计时间工具。很明显今天的设计时间SOA治理厂商在这方面的理解和表现都非常不足。
那么你要怎样解决现有设计时间SOA治理工具的问题呢?
首先,你应该得出一个有意义的高水平方法,再解决如何将这个方法融合到一个更大的SOA设计和配置方法论中去。现有的工具基本上不存在背景,也就更谈不上价值了。
第二,要么是运行时间工具要么就不是,因此你要了解你的工具需要进入到架构哪一个部分。我的建议是选择一部分做好而不要所有的涉及,因为已经有许多不错的运行时间SOA治理工具了。
最后,收集并创建工具间一致的标准、技术和方法。目前这些标准、技术和方法是不一样并且具有版权的,但在人们寻找长期战略持久标准技术的今天这些是难以销售的。
相关文章推荐
- 给定一个单向链表(长度未知),请设计一个既节省时间又节省空间的算法来找出该链表中的倒数第m个元素。实现这个算法,并为可能出现的特例情况安排好处理措施。“倒数第m个元素”是这样规定的:当m=0时,链表的
- 开始时间和结束时间,用例设计
- 本人大一的课程设计,时间太长,代码可能有些许丢失,欢迎纠错
- 响应式设计就是这个时代最值得学习、时间的趋势
- 新书——《“互联网+”时代的IT战略、架构与治理 传统企业信息化转型的顶层设计》
- windows无法结束这个程序,要完成操作可能需要更多时间??
- IT治理延续到SOA时代
- 转-WEB2.0时代活动类网页我们该如何设计
- 基于组的策略(GBP)开启新型网络设计时代
- 可能java设计缺陷、希望高手指正错误
- 超时时间已到。超时时间已到,但是尚未从池中获取连接。出现这种情况可能是因为所有池连接均在使用,并且达到了最大池大小。
- Oracle修改时间报:ORA-01830: 日期格式图片在转换整个输入字符串之前结束的解决办法
- MuleSource推出开源SOA治理平台
- NanUI for Winform发布,让Winform界面设计拥有无限可能
- 关于设计:Actionscript 有关键盘事件、处理日期时间、文字与数字处理笔记
- 设计模式——职责链模式实现消费时间计算
- 数据结构---设计一个栈,push, pop, min 时间复杂度都是 O(1)
- 最近要准备讲送别诗 还要学一下微积分 还要准备会考 可能没大有时间做题了
- java第二周---.用线程设计一个时间类,并显示时间
- 一个网站优秀的登录验证设计方案(登录页面的超时以及密码加上时间戳)