基于webservice技术的SAP接口实现.docVIP

基于webservice技术的SAP接口实现 　　摘要：不断发展的计算机技术使得传媒业发生了巨大的变化，并得以普及。World Wide Web、Java技术以及XML似乎无处不在，这些技术均得以快速应用，而且已成为企业级计算机的主要技术。本文在以上基础上对WebServices技术的SAP接口实现加以阐述。 　　关键词：接口实现WebServicesSOAP组件 　　中图分类号： TP334.7 文献标识码： A 　　尽管Web服务还没有充分发挥所有潜力，但已经对业务通信带来了变革。在教学、制造、财务服务与旅游等等行业中得以广泛的使用。 　　#65279;Webservice作为一项新的技术出现在我们面前，它的出世是用于解决在不同的平台下的应用的协同的。目前几乎每家厂商都要去开发Webservice应用，然而如果缺乏对Webservice更深的了解，不能很好的在设计阶段处理好一些重要的问题，那么最终完成的系统必然是效率低下，没有可靠性的产品。 　　在设计Webservice 应用时，以下几点务必要考虑到： 　　1、管理好与外系统的协同关系 　　2、掌握底层的传输模型 　　3、提供与应用相适应的安全策略 　　4、计划好部署的相关事项 　　以下，将就这几条相关的设计需求和一些常用模式是如何应用于Webservice模型展开详细讨论。在讨论中，你会发现Webservice这项新的技术是如何与我们在以往的软件开发相结合的。 　　 一、标准提供了协同的能力 　　Webservice的一个最基本的目的就是提供在各个不同平台的不同应用系统的协同工作能力。 　　WSDL是实现协同能力的关键，它提供了一份契约用于与新老的应用之间交互。这项技术使得各个组织可以将标准的制定集中在Service的外部接口，而不用考虑各组织的具体实现。简而言之，它实现了Webservice的接口与实现的分离。从而使得标准的制定，更加容易。并且，基于这份接口描述，很多工具可以从中自动生成客户端代码，减少了开发者的工作量，并使得大部分开发者摆脱了编写SOAP消息传递代码过程。 　　SOAP是实现在各个Webservice组件之间传递消息的传输层。因此，SOAP应该是一项透明的协同技术。基于这种情况，当开发者需要Webservice运行在不同平台上时，就要对具体情况加以了解并相应的编码以解决这种不一致性。如果所有的SOAP实现组织都能够遵循标准的话，那么Webservice的开发者就不需要考虑使用该Webservice的底层平台了。 　　在开发Webservice的接口的时候，不要以为使用XML技术，协作性的问题就迎刃而解了，XML并不是解决集成问题的灵丹妙药。这里同样需要标准的制定，需要一个在业界公认的词汇表。仅仅在你的设计框架中引入XML技术并不能保证系统具有协同性，XML仅仅是用来描述数据的语言，XML自己并不提供语义去理解数据。就如同英语和德语都使用拉丁字母，但是他们的语义却并不相同。 　　二、DOM vs. SAX 　　许多的Webservice开发环境，将开发者从底层的XML文档的解析和处理中解放出来，他们提供了自动化或者很方便的工具，使得这一过程变得很简单。但是对于一些有特殊要求的Webservice应用，比如需要更好的柔性或者对速度要求特别高的应用，就需要手工处理XML文档。这时候两种XML解析的模型－DOM 和SAX的选择，将成为重要的问题。 　　DOM先将XML文档映射成一颗树，然后通过采用一系列与树相关的操作去处理这份文档。这种方法有很多的好处，首先开发者很容易理解，使用一颗树这对于开发者来说是最常见不过的了。DOM最常用于XML在Service中需要频繁修改的场合。当然DOM也有它的缺点，在处理XML文档的时候，它需要载入整个文档，而不管你需要修改的是否只是其中的一小部分。因此它的运行效率以及对内存的使用显然是不能接受的，尤其是面对很大的XML文档。 　　SAX使用事件驱动的模型来处理XML文档。通过一系列事件的触发，来完成对XML的解析，你可以只关心你所要处理的事件，当这些事件发生时，会调用到相应的回调函数来通知到你。采用这种方式就可以在很大程度上提高XML文档解析的效率。但是它的缺点在于难于使用，以及对同一文档的多次处理会存在一些问题。 　　三、文档交换vs. RPC模型 　　这两种交互方式应该在应用架构的设计初始就应该详加考虑，因为它将在很大程度上决定系统的耦合程度。 　　RPC（Remote Procedure Call）本质上就是远程方法的调用。尽管Webservice是基于XML的但是你仍然可以使用远程方法调用这种模式来进行Webservice的实现，尤其是在那种简单的请求相应的模型