我们需要治理吗？

　　我的确同意，我们需要一些监督来令用户满意。你喜欢的话可以把它称为治理，但那仅是用户和IT之间的管理。如果你的IT已经是一幅支离破碎的景象，拥有了太多的外包和外部顾问，也许你的确需要进行治理来度过难关。

　　SOA还是变更管理？

　　IT的核心问题是变更管理。变更管理与元数据有关：有关数据的结构化数据，“描述、解释、定位信息源或令其更易于获取、使用或管理”。

　　我被告知：你说得对，但这些我们都是通过XML完成的。听着，供SOAP使用的WSDL元数据，以及供WSDL使用的UDDI元数据还是不够的，因为这两者都没有跟用户界面和流程关联起来。你还需要DTD、XSL、XSLT、XPATH、BPML以及BPEL和大量Java代码区验证数据是否合法，并把它用到硬编码的决策模块中去。

　　在《SOA傻瓜教程》中，偏向BEA的作者因此建议提供为Java程序一个容器（repository），同时提供一个注册表项（registry）用于动态地跟SOA服务关联。鉴于BEA产品领域拥有Tuxedo这个老产品，以及可编程Java产品Weblogic和收购的Aqualogic工作流，其两个管理产品的理由是可以理解的。

　　然而，服务接口中元数据的变更并不会自动传播到所有的用户界面、java模块、流程定义、XML transform以及所有的数据库上去。用户自己没有手段快速简便地进行变更。由于不存在通用的版本管理和部署管理，我们还是在原地踏步——深陷于一个“大泥球”里，只不过更加复杂了。

　　标准——你在哪里？

　　有些人相信标准是救世主。Open Group、Oasis、 OMG等等，各不相同的组织制定许多SOA的定义。在关键问题上，大部分定义仍存缺失，比如全球交易、安全及事件处理。因此，仍然没有实现SOA的标准方式。

　　若干供应商提供了SOA变更管理工具，如HP-Mercury、IBM Tivoli等。这些巨大的投资是用于处理SOA基础设施和网络的， 不能用于处理用户所需的前端的业务服务。

　　如你所见，沧海横流，这个世界是一整个杂乱无章。我见到的投标申请书（RFP）里，在要求SOA兼容的同时还要具备“全功能API”。有投标申请书中要求XML和Java标准这样的空中楼阁。（不过）在投标申请书里你只需简单地回答“满足”即可。许多IT人士似乎认为SOA是解决Java、XML无标准现状的灵丹妙药，而它至多仅是将部分问题掩盖了起来。