利用SoapUI测试Webservice的方法介绍

 　大企业的软件架构所面的挑战不但与技术有关，还与企业的组织结构有关。Dan Greenblog最近在一篇博客里分析了软件架构与高效的组织结构在原则上的相似性，以之回答下面的问题：
　　企业结构与软件相似在哪里？对于两者的设计，有哪些实践是共通的？ 作者特意从一个技术视角的、受环境影响的、特殊的观点入手去逼近所讨论的主题，使这篇文章更切合软件架构。他是这样立论的：
　　一家组织良好的企业，就像良好架构的软件，被分成一套规整的功能组件，分别承担各不相同的、预先定义的、清楚描述的角色。所有组件都能通过一种共同的、全体约定好的协议互相交流。最后，所有组件都被监控、维护、升级以及必要时被重构或者逐步淘汰。乍看起来读者似乎只好祈愿自己所在的组织也能像上面说的那样定义良好而且高效。不过上面的一番比较其实是颇有帮助的，因为它阐述了一个威胁到大多数软件架构师的题目--对组织的管理，还点明了一个事实--其实架构师的工具箱里已经有了很多工具可以帮助他们把工作做好。Greenblog从模块性开始阐述他的四大观点：
　　模块性可能是一家企业或者一个软件应该具备的最重要的性质。每个节点，不管是软件模块还是一队员工，得到的指令都是在一个大的背景下执行一项非常专门的任务；如果每个节点都能彼此协调，那么整体就能顺畅地运行。 接着谈到契约式设计（Design by Contract）原则和需求管理：
　　在软件开发里，程序员编写前置和后置条件来确立特定软件组件的角色。有了这些在设计时明确定义的界限，程序员就不太可能在代码里偷偷塞进不符合设计的额外功能。对于企业组织来说也一样，如果团队的使命定义明确，又符合团队成员所具有的技能，那么这个团队就很可能表现出色。如果团队的使命变了，那就要有一些检查取保证团队在新的定义下仍然能够正确地执行其职责。 当然也少不了消息模式：
　　在一行代码都没写的时候就把通信范式预先筹划好，并且在整个程序中都保持一致，程序员就能在增加新模块的时候给自己省下许多发明新消息系统的麻烦。
　　通信的概念对模块和团队都适用，团队和模块都会频繁地彼此互动，并且在互动中都要求为异步的、中断驱动的消息定义一套严密的API，最好还要有一套基于事件的通知系统来处理这些消息。
　　接下来他谈到了一个严峻而真实的方面--软件和组织都需要重构：
　　一家公司，或者一个软件，就像任何有生命体一样受到生存法则的支配：适应或者灭绝。市场总是优胜劣汰的，要想始终站在高处就不能静止，只能去拥抱变化。如果大公司里的软件架构师在求解架构的发展方向时能把网撒得更宽些，把组织的变化也包含在内，把在软件上运用原则也用来管理组织的变化，那么整个系统（包括程序和用户在内）都能取得更大的成功。
　　推荐: