1、1基于 webservice 技术的 SAP 接口实现摘要：不断发展的计算机技术使得传媒业发生了巨大的变化，并得以普及。World Wide Web、Java 技术以及 XML 似乎无处不在，这些技术均得以快速应用，而且已成为企业级计算机的主要技术。本文在以上基础上对 WebServices 技术的 SAP 接口实现加以阐述。 关键词：接口实现 WebServicesSOAP 组件 中图分类号： TP334.7 文献标识码： A 尽管 Web 服务还没有充分发挥所有潜力，但已经对业务通信带来了变革。在教学、制造、财务服务与旅游等等行业中得以广泛的使用。 Webservice 作为一项新的技术出
2、现在我们面前，它的出世是用于解决在不同的平台下的应用的协同的。目前几乎每家厂商都要去开发 Webservice 应用，然而如果缺乏对 Webservice 更深的了解，不能很好的在设计阶段处理好一些重要的问题，那么最终完成的系统必然是效率低下，没有可靠性的产品。 在设计 Webservice 应用时，以下几点务必要考虑到： 1、管理好与外系统的协同关系 2、掌握底层的传输模型 3、提供与应用相适应的安全策略 4、计划好部署的相关事项 以下，将就这几条相关的设计需求和一些常用模式是如何应用于2Webservice 模型展开详细讨论。在讨论中，你会发现 Webservice 这项新的技术是如何与我
3、们在以往的软件开发相结合的。 一、标准提供了协同的能力 Webservice 的一个最基本的目的就是提供在各个不同平台的不同应用系统的协同工作能力。 WSDL 是实现协同能力的关键，它提供了一份契约用于与新老的应用之间交互。这项技术使得各个组织可以将标准的制定集中在 Service 的外部接口，而不用考虑各组织的具体实现。简而言之，它实现了Webservice 的接口与实现的分离。从而使得标准的制定，更加容易。并且，基于这份接口描述，很多工具可以从中自动生成客户端代码，减少了开发者的工作量，并使得大部分开发者摆脱了编写 SOAP 消息传递代码过程。 SOAP 是实现在各个 Webservice
4、 组件之间传递消息的传输层。因此，SOAP 应该是一项透明的协同技术。基于这种情况，当开发者需要Webservice 运行在不同平台上时，就要对具体情况加以了解并相应的编码以解决这种不一致性。如果所有的 SOAP 实现组织都能够遵循标准的话，那么 Webservice 的开发者就不需要考虑使用该 Webservice 的底层平台了。 在开发 Webservice 的接口的时候，不要以为使用 XML 技术，协作性的问题就迎刃而解了，XML 并不是解决集成问题的灵丹妙药。这里同样需要标准的制定，需要一个在业界公认的词汇表。仅仅在你的设计框架中引入 XML 技术并不能保证系统具有协同性，XML 仅仅
5、是用来描述数据的语3言，XML 自己并不提供语义去理解数据。就如同英语和德语都使用拉丁字母，但是他们的语义却并不相同。 二、DOM vs. SAX 许多的 Webservice 开发环境，将开发者从底层的 XML 文档的解析和处理中解放出来，他们提供了自动化或者很方便的工具，使得这一过程变得很简单。但是对于一些有特殊要求的 Webservice 应用，比如需要更好的柔性或者对速度要求特别高的应用，就需要手工处理 XML 文档。这时候两种 XML 解析的模型DOM 和 SAX 的选择，将成为重要的问题。 DOM 先将 XML 文档映射成一颗树，然后通过采用一系列与树相关的操作去处理这份文档。这种
6、方法有很多的好处，首先开发者很容易理解，使用一颗树这对于开发者来说是最常见不过的了。DOM 最常用于 XML 在Service 中需要频繁修改的场合。当然 DOM 也有它的缺点，在处理 XML 文档的时候，它需要载入整个文档，而不管你需要修改的是否只是其中的一小部分。因此它的运行效率以及对内存的使用显然是不能接受的，尤其是面对很大的 XML 文档。 SAX 使用事件驱动的模型来处理 XML 文档。通过一系列事件的触发，来完成对 XML 的解析，你可以只关心你所要处理的事件，当这些事件发生时，会调用到相应的回调函数来通知到你。采用这种方式就可以在很大程度上提高 XML 文档解析的效率。但是它的缺
7、点在于难于使用，以及对同一文档的多次处理会存在一些问题。 三、文档交换 vs. RPC 模型 这两种交互方式应该在应用架构的设计初始就应该详加考虑，因为4它将在很大程度上决定系统的耦合程度。 RPC（Remote Procedure Call）本质上就是远程方法的调用。尽管Webservice 是基于 XML 的但是你仍然可以使用远程方法调用这种模式来进行 Webservice 的实现，尤其是在那种简单的请求相应的模型中。在这个过程中，传输中的 XML 文件所描述的更多是有关远程方法的信息，比如方法名，方法参数等等。 由于业务数据是自包含的，显然文档模型更利于采用异步处理。 四、 利用设计模式
8、 设计模式在设计 Webservice 的时候显然可以起到相当大的作用。设计模式的主要目的就是为解决某些在类似环境下的相像问题提供已有的较为成熟的设计方案。在这里，只简单的提及一些很常用的模式，让我们了解到模式在 Webservice 中可以起到的作用。 Adapter ：为内部系统提供一个不同的接口 Faade： 封装复杂的内部实现，提供一系列简单的接口 Proxy： 作为其他对象的代理，代替它提供服务 五、安全 Webservice 为作为方便的服务被用广大领域使用的同时，也成为了黑客们的美食。在这里，本文将就目前对 Webservice 安全所能做的改进做简单介绍。 在 Webservi
9、ce 中的安全主要分为以下三个方面。 传输 SSL/HTTPS 对连接加密，而不是传输数据 消息数据加密(XML Encryption) 数字签名(XML-DSIG) 5底层架构利用应用服务安全机制 传输时的安全是最容易被加入到你的 Webservice 应用中的，利用现有的 SSL 和 HTTPS 协议，就可以很容易的获得连接过程中的安全。 然而这种安全实现方法有两个弱点。一是它只能保证数据传输的安全，而不是数据本身的安全，数据一旦到达某地，那么就可以被任何人所查看。而在 Webservice 中，一份数据可能到达多个地方，而这份数据却不该被所有的接受者所查看。二是它提供的是要么全有要么全无
10、的保护，你不能选择哪部分数据要被保护，而这种可选择性也是在Webservice 中所常要用到的。 第二层的保护是对于消息本身的保护。你可以使用已有的 XML 安全扩展标准，实现数字签名的功能，从而保证你的消息是来自特定方并没有被修改过。XML 文件的加密技术从更大程度上加强了 Webservice 的安全，它能够定制数据传输到后，能否被接受者所查看，进一步完善了传输后的安全，业界也在不断的制定 Webservice 的安全标准，比如 SAML 和 WS-Security。 最后一层保护就是依靠底层架构的安全，这更多的来自于操作系统和某些中间件的保护。比如在 J2EE 中，主持 Webservi
11、ce 的应用服务器。目前很多的 J2EE 应用服务器都支持 Java Authentication and Authorization Service (JAAS)，这是最近被加入到 J2SE 1.4 当中的。利用主持 Webservice 的服务器，实现一些安全机制这是很自然的做法。另一种利用底层架构的安全方法就是，做一个独立的负责安全的服务器，Webservice 的使用者和创建者都需要与之取得安全信任。 6系统架构模式采用 Browser-server 模式，使用 SQLServer 数据库，服务器及周边硬件设备、网络环境由华星石化自主承担；服务器配置由双方共同协作完成。 SAP 系统与 SQLServer 之间通过 WEBService 进行通信，地磅系统与SQLServer 之间通过 ODBC 进行通信。 通过以上构架模式实现 SAP ECC 通过 webservice 与第三方系统完成系统集成，资源共享。
