在OASIS标准起草委员会负责人James Bryce Clark访谈中，他谈到随着科技的进步，人们不再一味地专注于消息、安全等管道问题，大家开始关注更高层次的业务问题，如业务内容的语义。他谈到新的一年将会出现的面向服务架构的转折点，以及相关标准问题。

问：在过去的一年中，影响SOA标准的最大变化是什么?

　　James Bryce Clark: 在2006年，我们不再集中精力研究管道层的问题。我们开始关注标准、电子商务方法以及内容的数据表示问题。在过去的五、六年间，该领域的工作人员 ――Web服务工作人员，之前是开放性电子商务建构标准ebXML (Electronic Business using eXtensible Markup Language) 工作人员――总是专注于旧的ISO模型功能服务视图(Functional Service View, FSV )，fsv 主要关注功能性、服务界面以及协议方面的信息技术，主要包括实施、发现、部署和运行时态的能力; 用户应用程序界面; 数据传输的基础架构界面; 在不同的组织机构间，互操作xml词汇集的部署协议。

　　我们从不接触语义学，也不接触商务信息内容。健全的电子商务需要大量的再利用和多种不协调实体间的交换。你不仅需要发送消息、进行安全控制，还需要理解发送的消息内容。现在, 我们终于开始看到一些相当智能的、知名的注册、通讯录、信息和安全方法。

　　问：这些标准成熟吗?

　　James Bryce Clark: 每个领域都有一个赢家，而且它几乎完美。我想这基本不可能，也不是标准可以做到的。标准是从大量备选选项中挑选出的少数相对合理的、并得到大家一致通过的 方法。当然，在标准产生的过程中也会考虑市场因素。OASIS标准起草委员会或其他地方的标准组织能够提出标准建议，并通过一系列方法维护标准。但是，如 果人们不使用这些标准呢?当我们做好一切的时候，市场并没有做好准备。

　　不过，现在还是有几个相当成功、相当稳定且被广泛认可的标准存在。比如通用描述发现和集成规范 (Universal Description Discovery and Integration，UDDI)。我们知道开源数据库互连 (Open Database Connectivity , ODBC)和Java数据库互连(Java Database Connectivity ，JDBC)，所以我们才知道怎么从数据库中获取东西。现在我们有大量表现方法，这些方法恰巧都与Ajax有关。我们大概了解如何从交易系统中提取数据到 人们可以读取的地方。同时，在安全方面也有很多进步，如安全断言标记语言(SAML)，它是一个XML框架，也就是一组协议，可以用来传输安全申明。由于 证书的广泛使用，使安全领域更智能。安全问题可以可靠地解决。

　　问：对商务来讲，这些意味着什么?

　　James Bryce Clark: 如果你在尝试一些现在的商务活动，事实上，你是在进行一些几年前，甚至是今年年初都不能进行的商业操作。你可以说“我想让这些人在互联网上能够使用这种信 息，进行这种商务活动。我知道来来回回怎样得到消息。我知道怎么进行复制。我知道怎么得到确认，并在动态过程中解决确认问题。我可以购买软件。有许多开放 源代码选择。即使它们都还没有成为标准，如果我选择使用Java消息服务(JMS)或MQSeries通信系统，那么就不需要开源类产品，因为它们已经包 含这些功能。

　　我知道怎么进出数据库。我知道怎样在数据库中应用证书。我知道怎样描述发送或接受消息个体的属性，所以这很安全。我有访问控制。所有问题都已经 解决了，并没有什么好担心的。” 在2006年年底的时候，这就是我最开心的事，我们的用户不需要再问沟通管道问题烦恼，因为已经开发出一些商务产品，同时，开源也解决了这些问题。现在， 我们前进一步，开始关注商务内容层的活动。

问：哪些标准引起了2006的这些变化?

　　James Bryce Clark: 在数据库操作领域，有通用描述发现和集成规范 (Universal Description Discovery and Integration，UDDI)和ebXML注册。尽管这两个标准完全不同，但是它们都非常实用。

　　在通信领域有大量标准，如处理Web服务可靠性问题的WS-Reliability。 ebXML Messaging在欧洲、亚洲广泛应用。OASIS标准组织也一致观察WS-Reliability Messaging。它是由IBM和微软公司推荐。WS-Reliability Messaging的标准工作正在进行中，预计将要结束。由于人们都希望它能尽快成为解决讯息问题的标准，目前OASIS已将WS- Reliability Messaging审核放入快速程序。

　　问：那安全标准方面呢?

　　James Bryce Clark: 在安全方面，希望使用简单对象访问协议(SOAP)的人们，我们有几年前就已提出的OASIS网络服务安全规范。事实上，网络服务安全规范委员会现在已经 不存在。当委员会说“我们的工作已经完成”，这是一件令人高兴的事。网络服务安全(WS-Security)规范来配置服务集成技术,以使用令牌、密钥、 签名和加密来安全地传输 SOAP 消息。

　　另一个著名的安全标准就是安全断言标记语言(Security Assertion Markup Language, SAML)，它允许企业发布在整个企业范围有效的用户身份认证和授权证书。OASIS在经过近一年半的努力后，批准了期待已久的安全确证标记语言 (SAML)2.0版，它增加了账目链接、全球注销、带隐私功能的属性交换和同Shibboleth和自由联盟的互操作等功能，SAML Assertion元素可以原始形式插入到Security元素中。

　　Web服务安全(WS-Security)规范告诉你怎样进行安全规范。我们现在注意到，需要安全标记推进商务运行的用户数量不断增加。Web 服务安全(WS-Security)规范使用简单的方法将安全信息与消息粘在一起。安全断言标记语言是说明哪些内容必须沟通，谁来沟通，最终实现安全沟通 的规范。为了真正有效地使用它们，你需要有一鉴别清单，说明谁可以看哪些内容。你需要有一组信息，所以你可以知道应用访问控制和安全标准的间隔。

　　为了使用安全断言标记语言和相关的可扩展的访问控制高标识语言(eXtensive Access Control Markup Language ，XACML)，你需要有健全的架构以保证可以实施安全和可用性规范。三年前，我想没有多少人会使用这些安全规范，但是现在，有非常多人要求使用它们。

　　所以，在安全领域，我们不仅要求标准性能良好、稳定、可靠，更希望用户能够喜欢使用这些标准。我们有许多使用这些安全规范功能的复杂案例。

问：如果正如您所说的，在我们解决了关于SOA安全和其他标准的问题之后，在2007年我们将着重解决哪方面问题?

　　James Bryce Clark: 如果我们可以顺利解决SOA安全等方面的标准问题，接下来我们将把工作重点转移到业务信息方面。想一想最近发生的事。在OASIS，你看到 OpenDocument技术委员会，主要为office应用程序创建一个开发的、基于XML的文件格式。通用商业语言(Universal Business Language，UBL)已经推出2.0版本。还有使用通用商业语言进行电子交易各种案例。

　　我们研究了一下丹麦政府的案例，丹麦政府计划在2007年底创建一个大型的面向服务的电子商务网，该电子商务网主要生成通用商业语言2.0 (Universal Business Language ， UBL)的商业文档，如采购定单和为公共和私营机构交易开具的发票。还有很多这样的商业案例。再比如，涉及资金转让的银行也正在使用数据通用化模型，将大 量电子交易转换为任何人都可读的格式。现在数据信息的通用可读性是一项艰巨的工作，非常需要知识表示。

　　问：知识表示领域有什么动态?

　　James Bryce Clark: 刚刚谈到的问题将知识表示(knowledge representation, KR)引入IT领域，而关于知识表示现在主要都是一些分类法和本体论项目。也有三个商务规则项目。语义研究人员做了大量工作。有几位候选人，但是很难说他 们谁会胜出，因为他们有不同的模型。但是当OASIS标准组织工作人员希望在他们的模型上增加语义信息时，总是有很多方法。而且，增加这些功能非常重要。 同时，还需要增加语义内容，这样可以使商务文件更有价值，不过这部分工作不需要在复杂的理论演习中进行。

　　还有许多添加信息的简易方法。因为并不是所有人都愿意雇用四个博士进行本体论研究，并把所有的商业信息重新编写一遍，以使商务文件更有价值。有时候，他们只是需要更多的元数据或希望数据更结构化。现在有许多成熟的、简便的方法可以满足他们的需求。

　　问：都有哪些方法呢?

　　James Bryce Clark: 其中一种就是OASIS DITA 技术委员会管理的一种面向主题的体系结构――达尔文信息类型化体系结构(Darwin Information Typing Architecture，DITA)。还有广泛使用的业务流程执行语言 (Business Process Execution Language ，BPEL)。许多复杂的交易引擎和商业规则引擎都有自己的模型。然而，他们都使用BPEL，将BPEL作为转换格式。使用自己引擎进行编制和进行交易的 系统提供商现在不需要进行标准化，他们现在大都支持BPEL格式。

　　这是我不想看到的情况。业务流程执行语言成为一种重要的转换格式。当某个客户使用Foo公司的方法进行交易，如果客户想把交易从Foo公司转出，他们可以使用业务流程执行语言帮助他们将数据转为标准格式。

问：语义技术最先应用在哪些地方?

　　James Bryce Clark: 随意语义技术的发展，会产生更多有价值的信息。我个人认为医学诊断类信息会是最先应用语义技术的领域。医学诊断类信息数量庞大，如果只是将这些信息存放在 文件夹或文件袋中，它们将毫无意义，因为我们需要能够质询、查找、研究、使用这些不断增多的医学资料。每年医学都在发展，所以我们也要更改我们的分类法。 这是一个广泛使用电子信息的案例，电子形式的信息可检索、可再利用、可组织，所以信息可以替换。我们需要用更智能的语义表达方式表达信息。

　　问：下一步的发展会怎样?

　　James Bryce Clark: 我们正在进行一些使用达尔文信息类型化体系结构(Darwin Information Typing Architecture，DITA)、XML主题地图(XML Topic Maps)和资源描述框架(Research Description Framework，RDF)的实验。使用这些方法论的方法有很多种，通过它们可以使数据灵活、智能、可用。这是静态电子文件发展的新方向。

　　问：像OASIS这样的标准组织在语义领域都做了什么?

　　James Bryce Clark: 在OASIS标准组织，我们有几个直接创建语义方法的项目，也有正在使用的、现有的Open Document和ebXML技术标准。你可以使用这些标准，举个例子，你想使用本体信息，因为你是在飞机上确认了交易。我们需要确认我们是否自愿进行交 易的本体信息。在很多情况下都会使用这些方法。OASIS国际标准委员会成员组建了一个新的语义执行环境技术委员会(SEE，Semantic Execution Environment)，该技术委员会负责定义一个体系来将语义学应用集成到面向服务的系统中，并提供了使用语义web服务的智能机制。换句话说，我们 希望我们不仅可以提供服务。

　　我们希望可以进入Web服务器描述语言(WSDL)空间。WSDL是 Web服务的接口定义语言。你可以想象自己就是某个在互联网上运行的消费者，不停地从一个结点到另一个结点寻找服务描述，这就是WSDL空间。

　　但是WSDL空间的组织性差。语义执行环境技术委员会(SEE)成员正在描述一个框架，来解决如何弄清并使用Web服务器描述语言的问题，以及 判断哪种信息是可靠的问题。Web服务分布式管理 (WSDM)规范组对网络服务管理还有许多希望。同时，达尔文信息类型化体系结构(DITA)小组进行语义内容研究。DITA 是 OASIS DITA 技术委员会管理的一种面向主题的体系结构。

　　使用 DITA 可以在较小的独立单元中编辑内容然后组装成产品，如在线帮助、图书或课程。这是不能作为语义作用层的一个实例。同时，也有大量规则项目在各地展开，包括一 些专业研究所、政府研究以及万维联盟W3C和对象管理组织OMG。有很多商务规则项目将很快进入具体事宜阶段。这也与信息语义内容有关，因为不直接接触内 容，规则会降低符号组的操作数。

　　我们已经开始注意一些OASIS标准组织的标准，如资源描述框架(Resource Description Framework, 简称 RDF)。当然RDF是万维网联盟w3c的规范。最初RDF仅仅被一部分人在一些情况下使用。但是发现这些没有试图解决语义问题的技术专家非常有意义，他 们认为“我可以看出利用RDF我能做的东西”包括在架构中。对我来讲，这是一个转折点。我一直在等待着看会发生什么。在2006年，我们已经有一些利用资 源描述框架的重要实验。

　“面向服务的架构”(service-oriented architecture, SOA)到底是什么呢?对于那些存此疑问的人们以及那些试图找寻答案的人们, 负责制定标准的OASIS 负责人James Bryce Clark给出的答案是: 于2006底完成并被采纳的“SOA参考模型”(SOA Reference Model)为此提供了标准定义。

　　问：被OASIS作为“面向服务架构”(SOA) 的标准定义的“SOA参考模型”(SOA Reference Model)有何重要意义?

　　答：2006年的一个里程碑事件就是“SOA参考模型”委员会制定了这一标准。事实证明这是一项非常有意义的成果。但值得注意的是它并不是一个 “架构(architecture)”，也不是一系列标准。SOA很容易夸耀为下列的被一起使用的6个工具或4个标准，因为这样可以大大促销这个软件，但 问题是实际情况并非如此。

　　问：那么SOA到底是什么呢?

　　答：“面向服务(Service orientation)”是一门方法学。它是一种组织信息的方式。一个企业的“面向服务”通常把它自己表述为“建议书邀请函(Request for proposal, RFP)”的核心部件。当你决定采用“面向服务”时，你实际上所做的是你正在考虑当你把信息透漏给你的合作者时你需要提出哪些要求或设定哪些限制来保护这 些信息。

　　你可以使用很多种方式来实现这个目的，有多种不同的方法和多种不同的表达模式，你也有多种软件可以选择。这并不意味着这是一系列标准或者一个厂 商的产品， 而是一个决定以使得你手头的所有事情按照你的预期发生。所以，这限定了你对方法、厂商、甚至有时对合作伙伴的选择。

　　问：人们总是不能准确理解SOA，实际情况是这样吗?

　　答：世界上有趣的挑战之一就是帮助人们了解他们面临什么样的任务，并且在面向服务和网络服务中什么部件可能be on the playing board. 它不是XML(可扩展置标语言，可扩展标记语言或可延伸标示语言)。虽然现在我们已经从EDI(电子数据交换)走向XML，但是总有一天我们会做一些除了 XML之外的事情。面向服务涵盖了所有这些，但并不依赖他们中的任何一个。

　　它的理念是：你会得到你的乘积计算函数并表示一个适合于他们的有用的节点或终点。这个节点或终点是以某种形式被描述，进行通话和其他功能。这样即使是不认识你的人也就能够重新利用它。这是一个基本的结构概念以及有它得出的许多约束和机会。

　　问：该参考模型项目是怎样在OASIS开始的?

　　答：关于SOA参考模型最有趣的事情是：这个项目是由于一群致力于XML、网络服务以及SOA方法的人们尝试定义面向服务的失败而开始的。它实 际上是作为一个命名一系列标准的项目开始的。他们认为或许我们可以用有关“层(layer)”的术语来解释这个问题。你必须有一个注册层、一个信息层以及 一个内容层。一些人们曾试图朝这个方向努力，但是他们很快就意识到为了更贴切的描述那些事物，掌握更多的基本概念是必要的，比如说：什么是服务?什么是服 务现象，而非服务的属性或特征?能够抽象地描述服务有何意义?我们应该做何努力来为服务下一个准确的定义，从这个定义我们能得出什么结论?只有进一步充实 这些基本概念，架构才有可能被创建出来。

　　因此，“SOA参考模型”实际上是对统一那些抽象的基本概念的定义的一种尝试， 这些基本概念可被进一步应用于多种架构体系。这个模型的构建是一项非常伟大的工作。参与这项工作的人们对这些理念非常满意，因为这有助于他们组织他们自己的“架构”计划。

　　问：构建“参考模型”的下一步的工作是什么?

　　答：现在，SOA-RM技术委员会将进行第二个阶段。SOA-RA小组委员会将在SOA-RM规格的基础上发展SOA-RA。

问：SOA-RA包括些什么?

　　答：已经产生的这个参考模型试图去回答什么是SOA的问题。这个部件是什么?当在一堆杂乱的东西中看到它，你怎样才能认出它?它帮助人们思考是 否想要一个这样的部件。一旦你解决了这个问题，你就有了另一个问题。当你确定你的确需要它的时候，你要用它做什么，怎样建立它? 怎样使用它?怎样拥有它?这是一系列不同的问题。

　　参考架构技术委员会成员正在安装上述的一系列元件，包括服务、说明、合同以及政策。他们会记录每个部件的基本外形，并且更详细地描述每一个部件 可以做什么。 SOA-RA的必要条件是什么?如果想要一份服务说明，你需要做什么?无疑在此架构中会有列出一些可能性作为例子。但他们还没有建立那些你必须使用某些东 西的标准化命令。

　　问：那么SOA-RA会更多地是一种指导方针的形式，而不是一种标准?

　　答：是的。以服务说明为例，SOA-RA之外有许多服务并且许多是通过WSDL(Web 服务描述语言)描述的。如果你想要一份服务说明，那么实用性的问题就是这项服务必须做的事情是什么?然后你可以根据那些要求，用WSDL去查询。

　　问：OASIS SOA Adoption Blueprints在该参考架构的发展中会起什么作用?

　　答：如你所知道的，SOA Blueprint是一个正在运作的技术委员会，它努力描述那些能够成为SOA实例的商业过程的模型。比如，我想要运作一个拍卖场所，或者想要自动操作我 的CRM(客户关系管理)。SOA Blueprints项目正在建立一个开放的但并不嵌入许多竞争信息的实例。很多商业过程的自动操作嵌入了大量的竞争利益是许多存在的问题之一。

　　比如，两大电子贸易商Boeing and Lockheed彼此之间都不愿意让另一方共享他们的方法，因为各个公司都拥有属于他们自己的商业规则而且不肯传授于他方。因此，SOA Blueprints技术委员会正努力使这些事物标准化，他们制定了可以在开放的空间里执行的一些基本的程序。他们的成果并不是XML形式的，而是关于你 如何实现某一特定目标的实例。

　　我预期“参考架构”最终将会是提供一些相关实例的一套准则，就像SOA Blueprints一样。任何一家试图向你展示如何把“参考架构”与网络服务结合使用的企业或政府可能都会说：“既然我们已经有所收获，我们愿意尝试 ‘参考架构模型’，来看看它是否像我们想象的那样”。这样的话，这些企业或政府机构可能会成为更多的实例，甚至好的范例。但是SOA Blueprints和“参考架构”在抽象水平上是相关的。它们之间并不直接吻合。

　　问：“参考架构”将会与“网络服务I(WS-I)”的基本表征有何不同?

　　答：从事于WS-I的人们致力于解决以下问题：假设你想使用WSDL，UDDI和SOAP，你该如何进行综合设置使得所有的厂商确信他们支持这 些标准?我们都会认可他们正在为我们铺设一个通用之路，这有助于为那些刚刚涉足此领域但还没摸出门道的人们解决一些实际问题。这就是所谓的参数。因此， WS-I的基本表征就是一系列标准的一个实例，你可以将其应用于“参考模型”和“参考架构”的功能需求。

　　它们并不彼此相互依赖。如果你正试图从某个主要的中间设备供货商那里购买转换产品时，WS-I模型会是你明白对大家都奏效的一系列设置方式是存 在的。当你使用了“参考架构”后，你就会明白你所需要的东西都已经包含在我们的架构和软件里了。我们该如何确认我们的厂商正竭力去满足我们的需求，我们是 否遗漏了某些东西呢?

　　问：什么时候我们有可能看到这个参考架构的草案初稿?

　　答：他们预期会在2007内完成。

　　问：我们已经探讨了SOA的定义以及向“参考架构”的发展，那么你能总结一下OASIS当前的进展吗?

　　答：我们的成员愿意花费额外的时间共享他们的模型，贡献他们的信息，共同提供给人们去做这些事情的最好方式以及他们目前所知道的一切,我们从中 获益匪浅。标准化是处于竞争中的人们共同做某些对大家都更好的事情的领域。对于理解标准化世界中的“SOA”来说，更重要的是标准化的专用信息是现实。只 有相互交流后，我们才能提出模型。但是人们正在做的事情是真正重要的。

　　决策者们在哪儿遇到了问题?当厂商们努力完成一些事情但是由于一些现实的问题他们无法用我们的理论模型所描述的方式来实现的时候，那是非常重要 的信息。当着力于创建他们自己的企业架构的决策者安装了提供商要求他们安装的所有东西后，他们的需求并没有被满足，这是因为他们的实际商业需求与厂商的计 划不符，这一点是很重要的。因此，这些问题并不是一成不变的。这些模型是在从实践中获得更多的反馈信息的基础上不断地被更新的。当我们发布了产品后，人们 把现实情况告诉我们并提出各种批评意见以改进我们的产品，这使得我们的工作成效显著。

　　我们会从某些大型零售商、电子商贸公司以及拥有庞大供给线的制造商那里获得一些信息。他们会对我们说“这个模型的确很有用，我们学到了很多东 西。但是我们在协调一个包括24000个汽车零件厂商的供应链的时候，你会发现你在这部分出了差错。”所以这不是我们要去解决并最终解决了的问题。它是一 个随着时间增长的知识的集合体。在标准化过程中，我们正看到越来越多的关于待商谈问题的列表被提出和使用。这些都是实用的信息。我们正处于企业使用面向服 务体验的初级阶段，这意味着在一年之内我们将比现在了解更多的东西。