Jeff Anders，是SAP AG公司的NetWeaver开发平台的技术解决方案市场部的负责人，她在这次的JavaOne会议上，为基于面向服务架构(SOA)开发标准的新NetWeaver开发平台进行了赞美。遵循着SAP的行业标准部门的副总裁，现在也是Web服务协作组织的主席Michael Bechauf的方向，指出了基于标准方法使SAP工具达到了SAP之外的领域。
Anders和Bechauf回答了为什么要有标准，包括以前的Java EE5，服务组件架构(SCA)以及现在的OASIS和与WS-I说明有关的SOA工具。Bechauf还谈到了有关最后的和最好的技术争论之上的Web服务协作及其必要性。他还说，商业人士正在网络中寻找一种独特的刻度情况，因此他们可以像在电话上一样方便的在互联网上进行业务处理。
你正在演示的组成环境到底是怎么样的一个东西呢?
Jeff Anders:这是我们SAP的NetWeaver开发平台。只是我们一个新的产品商标。我们正在使用Java EE5应用程序服务器，并将他们投入到商业上使用的产品当中。在应用程序服务器之上，我们使用一些你可能已经知道的SAP的技术。组成应用软件程序框架，引导程序，可视化设计等。而且我们还将这些放到了一起，并添加了一些新的技术，使得其成为了组成的集成包。我们现在正试图做的，是提供出一个完整的环境，在上面，我们的程序开发人员、我们的伙伴，我们的独立软件开发商等所有等级的写作都在一个集成的包里进行。我们拥有服务组成、资产组成和UI组成。我们想要做的事情是让这些企业享受品质，让那些组织中的可使用的东西实现多用户、多国家的不同的开发功能。
有很多SAP的竞争者是这样评论的，只要你使用SAP工作的话，那么你就会拥有组成的工具，但是一旦你和其他的产品进行合作的时候，就不能使用了。你如何说服人们相信即使是在使用其他的产品进行工作的时候还能使用NetWeaver开发平台进行开发呢?
Anders: 在NetWeaver开发环境的每一个部分那都是基于标准的。我们使用的结构，我们使用的接口也都是符合标准的。毫无疑问的是，这不是私有的东西。他是为任何基于标准的基于服务的环境提供的。这也是可以帮助Michael更好的解释这一点的地方。
Michael Bechauf: 在Java EE5当中，目标之一就是标准化。我们也这样描述我们对于服务组成架构(SCA)的情景。SCA的完全的目的在于支持不同的结构。我们想要保证无论是谁使用这个组成的环境，他都会通过使用我们公司服务和我们公司产品而有一种一流的感觉。但是，另一方面，因为我们支持Java EE5以及SCA，这要求开发人员能够在不同的开发环境当中集成所有的JMS产品。
基于SAP的在企业IT方面的经验，你觉得SCA是怎么传递人们真正想要的东西呢?
Bechauf:基本上说，他是将简单化介绍给多机会的开发上面。例如，一种设计的时间模型，一个组成模型，一个很多软件厂商都支持的组成集合。因此一个习惯于在一种开发环境下进行开发的程序开发人员可以转移到另一个开发环境中去，而且可以发现熟悉的工具集。因此，有效率的开发人员将找到相似的环境。对他们而言，这是很容易学习的。他们不需要再学习、
对于WS-I的文件，你支持他并准备在上面工作吗?从我们上次十二月进行谈话之后，又有什么新的进展吗?
Bechauf:是的，有很多的进展 我正在WS-I的轮值主席，而有一件事我们已经宣布的就是对于WS Basic Security 1.0 大家都可以获得。而最重要的完成之一就是对于协同工作能力的支持。WS-I概要的方法正在变得有意义，因为他们在整个行业当中都被广泛运用着。这并不是简简单单的一张纸就可以写下的。它实际上是五个能够协同工作的平台的一部分。我们和微软、IBM、SAP、Novell以及Oracle公司合作做了很多关于协同工作能力的论证。它增加了安全性。我们现在正在做的下一件事是WS-I 可靠性安全属性1.0.本质上来说，我们正在从OASIS规范中进行对Web服务可靠性信息的支持，我们还将其成为联合主席。
UDDI3.0已经出来了，你和一些分析人士谈论这点的时候他们说他们没有使用UDDI2.0，就直接使用UDDI3.0. BPEL2.0也公布出来了，SOAP是WS-I概要的下一代。那么WS-I需要赶上这些标准吗?
Bechauf:对于WS-I而言，他需要解决一些广泛范围内的协同性工作能力的问题。这也是WS-I工作的方式。有很广泛的协同工作能力的事件，通过他们，行业可以验证所有的软件厂商是不是WS-I的一部分，他们需要做些什么。从WS-I的观点来看，如果我们能够提供给那五个软件厂商能够让他们有效使用的标准，那么我们就可以从事于这件事。谈到UDDI，有很多确定的使用的案例。在案例里，客户会说：“从软件厂商A那里得到的UDDI注册和从软件厂商B那里得到的UDDI仓库需要进行协同工作。”问题是，这真的是一个行业范围的问题吗?我们从客户中听到了很多。我们也正在处理收集来的WS-I的部分的需求。坦白地说，这正是他们做到的。这是一个独特的协同工作能力问题还是一个行业范围的协同工作能力问题呢?
WSDL2.0还没有最后定下来，但是其正在进行最后的呼唤。你对于WSDL2.0是怎么看的呢?因为我们知道的原因，人们会寻求向下兼容的问题吗?他会使得人们需要做些什么吗?或者说这会让其死亡?
Bechauf: 他还没有上升到行业级别的地步。在WS-I方面，我们正在将SOAP1.2作为基本概要2.0的一部分。已经有了一些对于这件事的议论，但是公平的说，WSDL2.0还没有来临。
除了WS-I之外，向下兼容会成为一个问题吗?
Bechauf：他一定会是需要考虑的东西的。让我们从SAP的角度去看这件事。我们现在正在做的，就是企业服务结构的一部分。我们正在建立数以千计的服务。他们中有WSDL1.2的服务。在我们的开发部门当中存在着一些讨论，关于是否支持WSDL2.0的讨论。很有可能的是需要花费一段时间才可能采用它。但是从WSDL1.2到WSDL2.0的过渡一定是有工具存在的。
现在有没有什么标准能让你真正的非常的高兴的呢?
Bechauf:非常坦白地说，我对于协同工作能力非常的兴奋。协同工作能力并不总是要求最新的和最好的东西。我们来看一看行业前进的方向，而我们所说的东西之一就是商业网络。网络要像普遍存在的拨号区域一样。如果你将你的业务关系建立于很多个公司之间，而且你想要自动哈德处理公司之间的关系的话，你需要最后担心的事情就是协同工作能力。看一看通信领域吧。你拿起蜂窝电话，你可以呼叫任何人，任何世界上的角落，接着电话响了。这就是Web服务前进的方向。网络作为一个无处不在的媒介可以建立起联系。但是，对于建立起来的伙伴关系、可靠性以及安全而言，他们基本的原理是什么呢?因此如果说有一件使我现在觉得非常兴奋的话，那就是在协同工作能力上面的对话。在一周前的OASIS会议上，人们一直再说我们并不需要最新的和最好的标准。我们需要系统之间协同工作，确保我们能够使网络像拨号区域一样支持商业网络。这就是他们关心的内容。他么不管版本号是2.0，3.0还是5.0，他们只想要协同工作的能力。
Anders和Bechauf回答了为什么要有标准，包括以前的Java EE5，服务组件架构(SCA)以及现在的OASIS和与WS-I说明有关的SOA工具。Bechauf还谈到了有关最后的和最好的技术争论之上的Web服务协作及其必要性。他还说，商业人士正在网络中寻找一种独特的刻度情况，因此他们可以像在电话上一样方便的在互联网上进行业务处理。
你正在演示的组成环境到底是怎么样的一个东西呢?
Jeff Anders:这是我们SAP的NetWeaver开发平台。只是我们一个新的产品商标。我们正在使用Java EE5应用程序服务器，并将他们投入到商业上使用的产品当中。在应用程序服务器之上，我们使用一些你可能已经知道的SAP的技术。组成应用软件程序框架，引导程序，可视化设计等。而且我们还将这些放到了一起，并添加了一些新的技术，使得其成为了组成的集成包。我们现在正试图做的，是提供出一个完整的环境，在上面，我们的程序开发人员、我们的伙伴，我们的独立软件开发商等所有等级的写作都在一个集成的包里进行。我们拥有服务组成、资产组成和UI组成。我们想要做的事情是让这些企业享受品质，让那些组织中的可使用的东西实现多用户、多国家的不同的开发功能。
有很多SAP的竞争者是这样评论的，只要你使用SAP工作的话，那么你就会拥有组成的工具，但是一旦你和其他的产品进行合作的时候，就不能使用了。你如何说服人们相信即使是在使用其他的产品进行工作的时候还能使用NetWeaver开发平台进行开发呢?
Anders: 在NetWeaver开发环境的每一个部分那都是基于标准的。我们使用的结构，我们使用的接口也都是符合标准的。毫无疑问的是，这不是私有的东西。他是为任何基于标准的基于服务的环境提供的。这也是可以帮助Michael更好的解释这一点的地方。
Michael Bechauf: 在Java EE5当中，目标之一就是标准化。我们也这样描述我们对于服务组成架构(SCA)的情景。SCA的完全的目的在于支持不同的结构。我们想要保证无论是谁使用这个组成的环境，他都会通过使用我们公司服务和我们公司产品而有一种一流的感觉。但是，另一方面，因为我们支持Java EE5以及SCA，这要求开发人员能够在不同的开发环境当中集成所有的JMS产品。
基于SAP的在企业IT方面的经验，你觉得SCA是怎么传递人们真正想要的东西呢?
Bechauf:基本上说，他是将简单化介绍给多机会的开发上面。例如，一种设计的时间模型，一个组成模型，一个很多软件厂商都支持的组成集合。因此一个习惯于在一种开发环境下进行开发的程序开发人员可以转移到另一个开发环境中去，而且可以发现熟悉的工具集。因此，有效率的开发人员将找到相似的环境。对他们而言，这是很容易学习的。他们不需要再学习、
对于WS-I的文件，你支持他并准备在上面工作吗?从我们上次十二月进行谈话之后，又有什么新的进展吗?
Bechauf:是的，有很多的进展 我正在WS-I的轮值主席，而有一件事我们已经宣布的就是对于WS Basic Security 1.0 大家都可以获得。而最重要的完成之一就是对于协同工作能力的支持。WS-I概要的方法正在变得有意义，因为他们在整个行业当中都被广泛运用着。这并不是简简单单的一张纸就可以写下的。它实际上是五个能够协同工作的平台的一部分。我们和微软、IBM、SAP、Novell以及Oracle公司合作做了很多关于协同工作能力的论证。它增加了安全性。我们现在正在做的下一件事是WS-I 可靠性安全属性1.0.本质上来说，我们正在从OASIS规范中进行对Web服务可靠性信息的支持，我们还将其成为联合主席。
UDDI3.0已经出来了，你和一些分析人士谈论这点的时候他们说他们没有使用UDDI2.0，就直接使用UDDI3.0. BPEL2.0也公布出来了，SOAP是WS-I概要的下一代。那么WS-I需要赶上这些标准吗?
Bechauf:对于WS-I而言，他需要解决一些广泛范围内的协同性工作能力的问题。这也是WS-I工作的方式。有很广泛的协同工作能力的事件，通过他们，行业可以验证所有的软件厂商是不是WS-I的一部分，他们需要做些什么。从WS-I的观点来看，如果我们能够提供给那五个软件厂商能够让他们有效使用的标准，那么我们就可以从事于这件事。谈到UDDI，有很多确定的使用的案例。在案例里，客户会说：“从软件厂商A那里得到的UDDI注册和从软件厂商B那里得到的UDDI仓库需要进行协同工作。”问题是，这真的是一个行业范围的问题吗?我们从客户中听到了很多。我们也正在处理收集来的WS-I的部分的需求。坦白地说，这正是他们做到的。这是一个独特的协同工作能力问题还是一个行业范围的协同工作能力问题呢?
WSDL2.0还没有最后定下来，但是其正在进行最后的呼唤。你对于WSDL2.0是怎么看的呢?因为我们知道的原因，人们会寻求向下兼容的问题吗?他会使得人们需要做些什么吗?或者说这会让其死亡?
Bechauf: 他还没有上升到行业级别的地步。在WS-I方面，我们正在将SOAP1.2作为基本概要2.0的一部分。已经有了一些对于这件事的议论，但是公平的说，WSDL2.0还没有来临。
除了WS-I之外，向下兼容会成为一个问题吗?
Bechauf：他一定会是需要考虑的东西的。让我们从SAP的角度去看这件事。我们现在正在做的，就是企业服务结构的一部分。我们正在建立数以千计的服务。他们中有WSDL1.2的服务。在我们的开发部门当中存在着一些讨论，关于是否支持WSDL2.0的讨论。很有可能的是需要花费一段时间才可能采用它。但是从WSDL1.2到WSDL2.0的过渡一定是有工具存在的。
现在有没有什么标准能让你真正的非常的高兴的呢?
Bechauf:非常坦白地说，我对于协同工作能力非常的兴奋。协同工作能力并不总是要求最新的和最好的东西。我们来看一看行业前进的方向，而我们所说的东西之一就是商业网络。网络要像普遍存在的拨号区域一样。如果你将你的业务关系建立于很多个公司之间，而且你想要自动哈德处理公司之间的关系的话，你需要最后担心的事情就是协同工作能力。看一看通信领域吧。你拿起蜂窝电话，你可以呼叫任何人，任何世界上的角落，接着电话响了。这就是Web服务前进的方向。网络作为一个无处不在的媒介可以建立起联系。但是，对于建立起来的伙伴关系、可靠性以及安全而言，他们基本的原理是什么呢?因此如果说有一件使我现在觉得非常兴奋的话，那就是在协同工作能力上面的对话。在一周前的OASIS会议上，人们一直再说我们并不需要最新的和最好的标准。我们需要系统之间协同工作，确保我们能够使网络像拨号区域一样支持商业网络。这就是他们关心的内容。他么不管版本号是2.0，3.0还是5.0，他们只想要协同工作的能力。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9403012/viewspace-167334/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/9403012/viewspace-167334/
2093
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
