用友U9产品SOA设计架构遭技术质疑

近日，ITPUB社区ERP板块，一位使用ERP多年的网友李新(化名)在学习使用U9的过程中，发帖抱怨U9中使用了大量的存储过程，并质疑号称全球第一款基于SOA架构的ERP系统U9，其SOA设计架构理念到底体现在哪些地方?
　　该社区的信息化相关板块，聚集了国内大部分ERP实施顾问，讨论产品线涵盖国内外主流的ERP产品和技术。李新的帖子发布后，立刻在ITPUB社区引发了轩然大波，多达上百位从事ERP顾问和选型，及实施的技术网友参加了讨论，发表自己的见解。
用友ERP 存储过程滥用?
　　记者调查了解到，整个U9产品的核心计算的确几乎全部通过存储过程实现，包括MRP计算、ATP计算、成本计算甚至密码的加密算法也在存储过程实现。整个系统用了7百多个存储过程，1百多个类似于存储过程的标量函数。
　　网友alone1998认为，“纯粹的SOA不提倡用存储过程/函数,把数据库只视为一个存储数据的地点。所有的业务逻辑都不在数据库中实现,在应用服务器中实现业务逻辑。从这个角度讲
U9肯定不是严格的SOA构架。但是,实际使用中,纯粹的SOA构架效率存在问题,需要频繁的读写数据,对硬件要求也高(我们的一个ERP,采用类似构
架,用了4台小型机做应用服务器,oracle数据库unix操作系统).要解决这个问题,需要打破这个模式,折中的办法是限制存储过程的使用,别烂用。这又需要仔细的系统设计,用友是否这样做的了不得而知。”
　　记者就此采访其它技术人员时，但他们表达了相反的观点，认为SOA的设计理念和是否大量使用存储过程没有直接关系。
　　“其它的ERP产品如Oracle
EBS同样大量使用了存储过程。用这一点来指责和质疑SOA的设计理念和研发的技术实力，立足点完全错误!至于说，有些业务逻辑计算是否一定要放在后台，通过存储过程来实现，这一点是可以讨论的。”一位从事多年ERP实施的技术顾问接受采访时表示。
　　ERP系统涉及大量的业务逻辑处理和计算，将这些业务逻辑处理计算动作全部放在后台数据库实现，的确看上去有悖分层设计架构的思想。分层开发设计的思想是，业务逻辑计算尽量封装在业务逻辑层，而不是将其全部下压到数据库层面来实现。
　　“业务逻辑处理和计算，如果直接用存储过程实现，不利于复用，也不利于数据库的跨平台移植(因为大部分数据库系统的SQL标准实现是有差别的，在一个DBMS中能够正常运行的存储过程，放到另一个平台几乎全部要重写);我们在做项目时，如果有开发人员这么做，被视为是偷懒的表现。”一个从事CRM系统开发的项目主管小李认为。
　　据记者了解，还有批评者认为，现在U9把中间层要做的事情都让数据库服务器代劳，显然对数据库服务器带来成本的压力。另外，安全性也是一个问题，因为系统存储过程一般都是开放的，任何人都可以随意修改，对系统的稳定性和安全性带来隐患。
　　“如果通过存储过程来实现如MRP计算，如果计算量很大的情况下势必会造成服务器的资源耗尽，一旦进行MRP计算，所有人都无法工作了。并且，这种计算资源消耗在前端是无法知道进度的，象死机一样，当然也无法知道什么时候能够结束。大量的计算也回带来死锁，乃至瘫痪。根据我以往的经验，并发数超过100就很困难了，不可靠了(丢数据、死机等)。要达到200，购买最好的服务器恐怕也困难。”一位有着数据库管理经验的ERP技术实施顾问这样认为。
　　对此，EBU平台开发部经理张劲涛的解释认为，ERP软件需要处理大量业务数据，核心计算通过数据库存储过程来实现，一方面是为了减少网络数据流量，提高数据处理效率;另一方面在数据库层面进行事务处理和控制比在应用程序中使用分布式事务更高效、占用的资源更少;还有一个就是灵活性问题，设计良好的存储过程，当业务逻辑或规则发生变化时，可以不用修改软件代码，只需修改存储过程即可，这对于用户和软件开发商来讲，可以降低维护成本和升级花费;另外，扩展开来还有一个系统健壮性和安全性问题，在非电信级商业网络环境中(比如：大多数企业局域网)，尽量减少设备节点和层次意味着更高的可靠性，尽量减少数据在网络上暴露和传输的机会意味着更高的安全性。
　　另外，他也承认使用存储过程有可能使得系统存在缺陷。“存储过程的一个缺陷是对于非数据密集型运算其实是很低效的，可能会过多的占用DB
Server的CPU资源，而使得性能强大的Application
Server的计算能力被闲置;另外，对于强调协作的分布式应用来，计算能力的过于集中在一定程度上降低了灵活性，毕竟现在早已不是大型主机的时代。”
　　最后他认为U9产品中大量使用存储过程是一个比较合适的做法，并无不对。“对于商业软件来讲，核心计算是否选择存储过程实现不能一概而论，要根据具体应用的特点和性能要求综合考虑，在此过程中可靠性和有效性往往会起很大的作用。”
SOA的设计理念到底体现在哪些地方?
　　ERP产品的设计架构理念引入SOA的思想值得提倡。从技术的角度来看，SOA对软件开发的影响是深远的，一方面SOA在继承传统的面向对象和组件化(构件化)编程思想的同时，更加强调了软件作为商业资产的可复用、可集成能力，其中软件(组件)的开放性和标准化是SOA的基石，它消除了软件(组件)之间交流和衔接的障碍，是软件实现“积木式”灵活装配的基础，同时，SOA强调了服务的治理，其实是为软件(组件)制定了一个价值衡量标准(或服务分割标准)，用以界定软件(组件)的服务价值，这是软件(组件)可复用、按需组装的价值基础;
　　另一方面，SOA强调了支撑“积木式”编程的统一基础设施环境，包括设计时的服务组装、运行时的服务调度(比如：工作流引擎)、统一的服务通信总线(ESB)，这些基础设施提供了随需应变的服务组装能力和可伸缩、低耦合、可靠高效、分布式的服务运行环境，这是对组件化(构件化)编程模式的最新发展和完善。SOA是第一个真正完整、系统的阐述和实现组件化(构件化)编程思想的软件架构，是当前软件系统架构的集大成者。
　　对用友U9产品SOA设计理念在技术上的具体体现问题，用友软件股份有限公司EBU平台开发部经理张劲涛接受记者邮件采访时谈到，“U9的SOA是将企业的核心业务构造为一系列可复用的标准服务，这些服务具有良好的接口定义和松耦合特性。U9的SOA解决方案就是将这些服务按企业的不同需求和业务规则进行组装，组装过程是可变化可调整的，这样软件可以随企业的发展变化而任意组合和扩展，跟企业一起成长和进化，使得企业的IT资产得以“动态”保值增值。”
　　“从技术角度来看，这个解答相对说得比较含混，这更像一个商业性的媒体回答。” ITPUB社区一位资深技术主管在接受记者采访时对此回答表示不满。
　　“从技术编码实现上讲，用友U9产品内部可能改变了过去定义dll接口的紧耦合或集成调用方式，不同模块之间全部采用Webservice调用，并定义了良好的服务边界。如果内部实现具备这些特征，那证明该产品设计的确实现了SOA的理念。”
　　“如果你宣称你的产品是符合SOA架构设计，你无需去解释SOA架构的好处，业界解释这么多年了，好处大家都知道，你只要告诉我们，U9的研发过程经历的SOA架构的服务定义、软件设计、流程(应用)实施这三个过程中，我们的技术和架构团队是如何做的?我们的开发队伍是如何实现的。比如，服务的定义，我们如何确定服务的粒度，不同行业的服务定义有何差别等等?再比如，用友的UAP支持SOA架构，是如何实现ESB支持BPM的?;坦率说，目前完全基于SOA架构实现的大型软件产品并不多，如果将这些软件架构及设计经验公布出來，我个人是非常愿意学习和研究的。用友如果这样做，也能给对手造成技术壁垒。”
　　据记者调查了解，大部分ERP技术实施顾问及一些开发者，对用友U9这样利用SOA来做产品宣传并不满意。另外，用友ERP产品从U8到U9这种颠覆性的设计演进产品的方式也是用户不能接受的，这2个产品从技术兼容性和升级上讲，几乎没有任何关系，因为从U8到U9完全可以看成是2个不同的产品，整个设计和架构全变了。
　　“如果一个企业的重要ERP系统，每5-6年就要推倒重来一次，不管是对用户还是对软件提供商而言，都是无法承受之重!”
　　中国企业信息化20年的历程也是中国本土软件企业成长的历程，我们看到国产的ERP软件厂商今天已经逐步具备了和世界级的软件厂商竞争的实力和机会。理论上讲，不存在完美或没有BUG的软件，因此我们没理由来苛求任何一款软件产品。但是，如果像用友这样的代表性厂商，今天如果能在自己前进的路上考虑得更深远一些，步伐放缓使得每一步迈得更坚实一些，那么明天它一定会走得更好更远!