NetWeaver ABAP Basis和J2EE提供的中间件服务的比较

企业级应用程序，理论上用任何语言都可以编写，在任何环境下都可以实现。但在现实中，几乎所有的企业级应用程序都运行在中间件平台上。这是因为，企业所使用的应用程序，需要底层环境提供多种功能，而这些功能是一般操作系统所不具备的。于是中间件平台应运而生，作为操作系统和企业级应用程序之间的桥梁，起着承上启下的作用。

中间件提供了哪些功能？按照中文Wiki的说法，中间件的服务主要有“过程调用、分布式组件、消息队列、事务、安全、连结器、商业流程、网络并发、HTTP服务器、Web Service”等。

目前比较流行的中间件分成三大阵营：微软的.NET平台，开放标准的J2EE平台，还有SAP的ABAP Basis平台。这三个平台作为应用程序的载体，具有相当多的共性，提供了许多本质类似的中间件服务。比较它们的异同，有助于我们从体系结构的角度理解中间件设计的思想。

关于.NET平台和J2EE平台的比较，用Google可以搜出来成百上千的文章，没出校门的学生里都有不少高手，就不多赘述了。这里要谈的是SAP平台和J2EE平台的异同，这个问题还很少有人论及。呵呵，可能相对于J2EE从业人员，本来搞SAP的人就不多，两方面经验都有的人就更少了。我从读书时起，有幸在国家863计划和973计划下，参与中国科学院自主知识产权的J2EE应用服务器研发，接触了不少J2EE底层服务的实现，如EJB Container、Web Container、Web Service Infrastructure、集群等。进入SAP后又长期从事NetWeaver开发，对SAP的各类平台也积累了若干经验。这里就把我对J2EE和SAP ABAP Basis两类中间件的理解做一梳理和比较，权作抛砖引玉。

正文之前，需要说明一点，以下技术不在讨论之列

1）作为NetWeaver的一部分，SAP也有自主开发的J2EE Engine，提供符合J2EE规范的服务。只要理解了J2EE服务，不难理解SAP J2EE Engine。

2）SAP部分产品建立在.NET平台上，如BPC。

3）类似TRex、MDM等产品，本身自带独特的平台。

本文讨论的重点是SAP的ABAP Basis系统和比较有代表性的J2EE Engine（如JBoss、WebLogic、Websphere等）

既然中文Wiki列出了“过程调用、分布式组件、消息队列、事务、安全、连结器、商业流程、网络并发、HTTP服务器、Web Service”等服务类别，我们不妨就按照这个次序，一一比较。此外，我还会加上以下几点：O-R Mapping，进程/线程管理，内存管理。它们可能乍看起来有的属于上层工具库，有的属于下层操作系统的范畴，但和中间件的服务关系都很密切。

1. 过程调用

J2EE的过程调用主要是通过Application Client来实现的。例如，为了在远程客户端调用一个Session Bean的方法，可以在客户端编写调用程序，客户端程序在运行时，实际上调用部署在客户端本地的Session Bean的一个本地代理（Proxy）。这个Proxy使用了Java语言的Proxy技术，它的Sevice Interface看起来和服务器端的Remote接口是一样的，只是它本身并没有业务逻辑的实现，而只负责客户端和服务器端的通信，实际业务逻辑由Session Bean来完成

SAP的过程调用通过RFC（Remote Function Call）来完成。一个RFC就是一个单独的方法，不同的ABAP服务器之间通过CPI-C协议调用RFC，执行远程服务过程。SAP BAPI也是基于RFC来实现的。RFC不止可以被ABAP平台调用，也可以通过JCo等组件被Java、C++等程序调用。RFC有多种类型，可以同步执行（sRFC），也可以异步执行（aRFC），此外还有提供事务服务的tRFC和保证执行次序的qRFC等。总体上来看，SAP的RFC功能更加繁多，为上层实现提供的很多有用的feature。

2. 分布式组件

中间件为了保证服务的高可靠性和高性能，往往使用硬件集群的方式，组织多个服务器实例并行提供服务。J2EE规范对集群并没有明确的规定，各厂家都有自己的实现。基本上提供的服务包括负载均衡（把客户端请求dispatch到不同服务器上，避免单个服务器负担过重）、状态迁移（把运行中的Session Context复制到备份服务器上）、失效恢复（一旦主服务器死掉，备份服务器立即接替）。

SAP也采用了集群技术，一个应用服务器集群可能包含多台应用服务器。通过T-Code SM51可以查看存在哪些Instances，它们可能处于不同的硬件服务器上。另外，ABAP Server的登录用户被组织成不同的Logon Group，每个Logon Group可以选择不同的Instance处理服务请求，通过客户分组，保证了单个服务器实例不至于过载。

3. 消息队列

JMS（Java Message Service）标准为J2EE的消息队列处理提供了基础，它支持2类消息处理方式：点对点方式和发布/订阅方式。前者维持一个消息队列，消息发送者向队列填充消息，消息接收者则从队列摘取消息，是一个典型的生产者/消费者模式；后者则类似于新闻组的订阅，消息发布到特定的Topic上后，每个Topic的订阅者都会接收到。基于JMS，用户可以进一步定义MDB（Message Driven Bean）来处理消息。

ABAP系统使用Event的概念来处理消息队列。用户需要将应用程序的服务与Event相关联，相当于订阅了特定的Event。当某件事发生后（如某个文档被创建），一个Event便被触发，所有订阅这个Event的Service都会收到此Event，进行特定处理。ABAP系统中Event的关联，可以使用T-Code SWETYPV来查看，在这个工具里，我们可以看到这种Event订阅的方式最常见的Use Case是进行Workflow的触发。

需要说明的是，相当多的J2EE厂商，单独提供了消息处理的产品，如IBM的MQ，BEA的Tuxedo（我对Oracle收购BEA之后的产品策略不甚了解，请高手指点）等。而SAP的XI，作为单独的消息交换Hub，也是NetWeaver平台的独立组成部分。由此可见，消息队列服务在企业级应用中所起的作用之重要。原因就在于企业对消息交换的服务质量，在可靠性、事务性、顺序性等方面有种种特殊要求；而且消息交换服务器对于连结异构系统起着至关重要的核心作用，对于在长期业务实践中积累下来大量异构遗留系统的企业来说，MQ、XI之类的消息交换服务器相当于信息孤岛之间的桥梁。

4. 事务

即使没有J2EE平台，Java Developer也可以通过JDBC来访问数据库，而事务就体现在JDBC的commit或rollback方法中。在J2EE平台上，无论是Entity Bean还是Java Persistence API，都提供了基于配置的事务管理机制。J2EE的JTS（Java Transaction Service）规范定义了对事务管理器框架的实现要求，而JTA（Java Transaction API）规范定义了应用程序，事务管理器和资源管理器之间的接口。

ABAP的事务机制，是通过COMMIT WORK语句和ROLL BACK语句控制的，直接嵌入到ABAP Open SQL语言之中，非常易用。为了提高性能，避免单个LUW过长地锁定Object，ABAP平台允许同步更新和异步更新，提供了V1，V2和V3的更新机制。这样，数据的更新可以集中来做，提高了系统的效率。不过这种多进程异步更新的机制，有时也给二次开发带来一定的困惑。有一次，我的同事调试一段程序，在Debug状态下工作正常，而直接运行就读不出刚刚写入的数据，问题就处在多进程协作不同步上面。我给她的COMMIT WORK语句加上“AND WAIT”后缀，让主进程等待Update进程工作结束再读取数据，就解决了这个问题。详细的技术文档见这里。

有趣的是，我对JTA和JTS的深入了解还是在进入SAP之后。为了使用XI同某种异构系统通信，必须在NetWeaver J2EE平台上的XI Adapter Framework下开发一个新的Adapter，那真是很有意思的一段经历。对XI Adapter有兴趣的朋友可以看看这里，开发的核心当然是JCA，但事务的分量也还是蛮重的。

5. 安全

安全是Java语言成功的最关键因素之一，其核心是系统授予不同来源的代码以不同的权限。不过J2EE并不强调对恶意代码的控制，毕竟日常运行的EJB和Servlet都是雇IT民工写的，不至于来源不明，呵呵。J2EE的关键是通信安全和对不同身份用户的权限控制，各厂家都有自己的实现方式，比如SAP的J2EE Engine Security，可以在SDN上找到相关文档。

强烈推荐宫力博士的《Java安全》一书，深入浅出，非常全面，就是有些地方罗列的API有点太多了，需要精简一下篇幅，呵呵。

SAP基于ABAP的产品具有极为完善和细粒度的安全审查机制，是基于最基本的AUTHORITY-CHECK语句来执行的。AUTHORITY-CHECK语句的本质很简单，就是检查当前用户是否被某个特定的字符串附了身，这个字符串往往是通过T-Code PFCG赋予某个角色，而再用SU01把这个角色授予特定用户。在这个基础上，各个应用程序开发了形形色色的检查机制，比如BW的安全机制，干脆就是PA的一门课程。

当然SAP应用程序还有更复杂的检查机制，比如基于组织结构的路径、基于业务流程的步骤等等的安全检查，分门别类，异常复杂。

6. 连接器

刚才提到的JCA（J2EE Connector Architecture），为用户开发Adapter提供了框架。开发人员一方面需要遵守J2EE的Interface规范，另一方面需要熟悉异构系统的通信协议，开发出的Adapter打包成RAR文件，部署到J2EE服务器上，就成了一个Proxy。J2EE服务器可以通过调用这个Adapter，来同远程异构系统通信。

SAP的ABAP平台本身具有一定的同异构系统通信的能力，例如和Java通过JCo通信、和R2系统通信、和注册到Gateway上的远程应用程序等等的通信。但这些不是重点，重点在于XI。XI作为SAP系统的Message Broker，可以充当ABAP平台与各类外部系统的翻译。

话虽如此，一旦有新的通信协议，没有现成的XI Adapter怎么办？那就开发一个Adapter呗，而且这个Adapter还是基于J2EE的JCA，只是在SAP自己的J2EE Engine上做。上面说过，我对JCA的深入了解，还要感谢SAP给了我开发XI Adapter的机会呢。

7. 商业流程

商业流程的核心是BPM（Business Process Managment），很多J2EE Server或装有独立的产品，或配有组件，支持BPEL（Business Process Execution Language）。市场上各类基于J2EE的Workflow Engine的种类繁多，IBM、Oracle等都有自己的BPM实现。和上一篇提到的消息队列一样，Workflow也成了一类独立的细分市场。

SAP的ABAP平台提供了强大的Business Workflow，负责任务的分发，调配，权限控制等，这里的“强大”确实不是夸大其辞，基本上无论同步、异步，无论权限控制有多么细，无论后端Service多么古怪，ABAP Workflow都可以胜任。唯一美中不足的是真正了解它的人实在太少了，SAP之外的专家寥寥无几，更不用说懂得Workflow和Applicaiton的整合了。

基于Workfow，XI的组件ccBPM提供了更高层次的商业流程控制：跨平台流程控制。ccBPM不但负责控制工作流，而且和XI无缝集成，直接同外部系统交换数据。ccBPM的底层实现还是ABAP Workfow，调试性能等工作还是通过Workflow Monitor来做的。

8. HTTP服务器

J2EE Engine的HTTP服务，是通过Web Container组件来完成的。例如JBoss，就集成了Tomcat，作为自身的Web Container，给Servlet、JSP等Web应用程序提供各类服务。Web Container作为框架，在接到HTTP请求后，调用已部署的Web应用程序的特定方法，完成请求的处理。各种基于HTTP协议的服务，如Axis组件提供的Web Service框架，都是基于Web Container提供的框架实现的。

ABAP服务器使用ICF(Internet Connection Framework)提供HTTP服务，用户使用ABAP编写程序，作为Handler注册到ICF上，在收到对特定URL的请求后，ICF调用这些应用程序的特定方法进行处理。当然ICF只是一个大的框架，在它上面还有各类具体的框架，提供了不同的HTTP处理机制，包括BSP（Business Server Pages），WebDynpro等工具。这些服务可以通过T-Code SICF来查看。

在通信安全方面，SAP的ABAP Engine和J2EE Engine都支持HTTPS服务。ABAP Engine使用T-Code STRUST可以管理ABAP系统的证书，基于SSL协议提供Web服务。J2EE Engine则使用Key Store等Service作为PKI的的基础。

9. Web Service

前面提到过，Web Service基础设施在J2EE Engine中是基于提供HTTP服务的Web Container来实现的，包括SOAP协议解析，服务描述生成，服务注册等功能。在各类框架中，Apache Axis是应用比较广泛的一种。除了提供服务器端的功能之外，Web Service功能模块还具有解析WSDL，自动生成Client Proxy的能力，使得各类异构客户端能够顺利调用远程服务。

ABAP服务器提供了基础设施，可以把RFC包装成Web Service，只需要在Workbench里面按照Wizard的提示，一步步走下来，一个Web Service就自动生成了。除了这些开发工作外，用户还可以使用T-Code SOAMANAGER来调用Web Service的管理和日志功能。如果需要调用远程的Web Serivce，也只需要在Workbench里面通过导入WSDL创建一个ABAP Proxy，相关的proxy类和DDIC objects就被自动生成了。此外，用户需要使用T-Code LPCONFIG来管理具体的服务调用参数。

10. O-R Mapping

Java Persistence API作为EJB 3.0的基础，博彩众家之长，从Hibernate等框架汲取了丰富的营养，允许多种多样的O-R Mapping方式。把后端数据库和前端Java对象无缝连接起来。

SAP ABAP环境也提供了O-R Mapping的工具Persistence Service，实现了ABAP Object和数据库表的自动转换。

不过，O-R Mapping真的对企业级应用至关重要吗？SAP ERP在没有广泛使用O-R Mapping的情况下也取得了巨大的成功。而且无论是Hibernate、Java Persistence API还是ABAP Persistence Service，都需要一定的开发和配置技巧，有时不免因辞害意，使得程序开发人员难以集中精力于应用逻辑的开发，总是被技术细节所困扰。而SAP传统的OPEN SQL，非常简单易用，只要再掌握了DB Update方面的一些技巧，就可以快速上手。一个鲜明的例证就是，SAP的各类服务接口如BAPI等，往往是使用的是结构化参数，而不是对象参数。

帕特里克·亨利曾说过，“难道生命就这么可贵，和平就这么甜蜜，竟值得以镣铐和奴役作为代价？”。我要说，“难道对象的概念就这么甜蜜，竟值得用大量精力，将完全没有对象概念的DB关系表和Object做相互转换？”在应用程序中使用结构化数据，已被R3证明是站得住脚的。强行在体系结构里面加上一层O-R Mapping，祸兮福兮，未可轻定。

11. 进程/线程管理

Java平台具有线程（Thread）的概念，与进程不同，各线程之间共享数据，通过wait、notify等方法协同运作，使用synchronous关键字进行并发控制。Java除了基础的synchronous机制外，提供了Collections.synchronizedMap 等机制来保证并发安全性。详细的描述，可以参考O’Reilly出版社的《Java Threads》一书。

ABAP平台则采用了传统的进程（Process）机制，各进程之间一般不共享数据。当然作为例外，可以使用SPA/GPA参数在各Session之间交换数据，来简化用户的数据输入。例如，在一个Session运行MM02，输入Material Number，完成处理后，在另一个Session运行MM03，刚才输入的Material Number就自动出现在输入框中了。如果要看具体的代码，可以到Function Module EINSTIEGS_DATEN_VORSCHLAGEN中，找到代码“GET PARAMETER ID ‘MAT’ FIELD MATERIAL.”，就能看到后台是怎么做的了。

ABAP使用Lock机制来控制并发进程对共享资源的访问，一个专门的Enqueue Server负责管理和监视加锁队列，保证不至于发生读写冲突。这是因为ABAP的进程一般不共享数据，因此它没有类似syncrhous的关键字或者API。几乎所有的共享资源都在程序内存之外，所以需要用Enque和Deque的方法来访问数据库表、条目、甚至外部文件和Service等共享资源。

各J2EE Server都通过线程池来避免临时生成线程带来的系统负荷，而ABAP系统中也随时准备着若干进程以备处理请求，通过SM50可以监视这些进程。

12. 内存管理

Java和ABAP都不需要应用程序主动释放内存，而是使用特定的垃圾收集器自动检测Object是否已不再被引用，它们也都能检测所谓循环引用，保证内存的及时释放。

ABAP内存管理的一个特点是所谓的延迟复制机制，即：为提高效率，在Internal Table之间赋值时并不复制内存数组，直到其中一个Internal Table的内容被更改，才真正复制数组内容，避免了不必要的仅为满足“读”的需要而进行数组复制。

在会话信息保存方面，J2EE和ABAP都有Session Context的概念，其中ABAP的Roll Buffer将某个Session的Context临时保存下来，释放该Session的资源，以便Process接收下一个用户请求。呵呵，典型的拆东墙补西墙，凭着几个有限的进程/线程并行处理远大于这个数量的并发客户。

————————————————————————————-

总结一下：无论是J2EE还是ABAP，各种服务基本都具备，从技术的角度来说，很有异曲同工之妙。从时间上来看，ABAP早在20世纪80年代就已出现，各种Service得到逐渐的丰富。J2EE则可以看作是20世纪末开放式平台对这些Service的又一次实现，降低了企业级应用开发的门槛。究竟孰优孰劣，还是让时间来检验吧。