搞ORACLE ERP 的一点感慨

05-11-10 鲁中正气
去年,有辛接触了oracle ERP,在这之前,对板桥研究着的这些东西,也是非常感兴趣,陶醉其中,简直有些走火入魔,不过也真有所成,搞了个和板桥这个框架有点类似的东西。然后,带着好奇的心情,虔诚的学习态度,认真学习了ORACLE ERP的技术架构体系,工具,和方法,在几个印度高人的带领下,技术上算是有些门目了,已经进入了比较自在的境界。国庆节,又专门去学了学oracle 的财务模块 实施顾问的课程。

至此,感觉,搞这ERP,什么00,AOP,IOC,乱七八遭的东西都不难,难得的是积累。我看过ORACLE erp 产品的一部分JAVA源代码,感觉其思想古老的很,在代码一级,和BANQ相比,比banq差远了,但是在构件一级,我门就很难超过它。

最大的感慨是如果国家能拿出飞船升天的精力,组织一帮象Banq这样人的来搞个china erp,估计什么SAP,oracle erp,统统很快就会被干掉。

1
Kyle_Yin
2005-11-11 01:12
思想如此古老,比BANQ都差远了的 ORACLE, 银行户头居然攥着上百亿美金先进,BANQ都说了,它的时代已经结束了。

这世界,岂不是没天理了?^_^

可见那个先进模式,框架了啥的好像没那么值钱呦~~

》我看过ORACLE erp 产品的一部分JAVA源代码,感觉其思想古老的很,在代码一级,和BANQ相比,比banq差远了

鲁中正气
2005-11-11 09:21
应用范围不一样吧。

鲁中正气
2005-11-11 09:23
光靠banq自己的力量恐怕难以成行。

element
2005-11-16 00:28
ERP架构设计始于业务架构设计,而不是编程框架设计,业务架构设计的好坏是系统设计是否成功的主要因素;因为只有业务架构稳定了,才可能使系统架构获得稳定的基础,即使用再烂的编程架构,也顶多是编程环节多了一部份工作量,也大部分仅限于第一次编程。从长期来看业务架构稳定性的对系统的稳定性贡献是最大的;否则你就是有再好的编程架构,也会疲于应付业务架构的不稳定性――业务对象的不断变化。

编程技术仅仅是整体系统涉及技术的一部分,而且处于下游,各种编程框架、设计模式都有其问题域,但我感觉似乎太小、太细,不能抓住编程框架的元目标――作为共享、抵抗变化等降低成本与提高可靠性的利器。如果脱离应用范围讨论编程框架,我觉得有点无的放矢,毕竟每一类应用的特点不尽相同。oracle erp用的主要技术是主机/终端年代就有的技术(RAD 工具,经过多年的积累,业务层次的稳定性已经很强了),只不过是拿java applet重新作了一个解释器与做了一些java技术包装而已,其核心的业务架构一直是比较稳定的。

建议能把框架讨论与模式讨论能与解决的问题与关联起来,多拿出一些篇幅讨论一下框架与模式对终极目标(给开发商、用户带来的价值)的贡献。

初来乍到,如有冒犯,请多包涵。

鲁中正气
2005-11-16 09:35
欢迎,欢迎!

element 也在搞ORACLE ERP?有空多来灌灌水。

我前一阵刚参加了个培训,学学了oracle的功能架构,目前正在思考阶段,由于它涉及的各行业知识太多,现在感觉要学的东西还很多。

blueoxygen
2005-11-16 09:58
> 去年,有辛接触了oracle

> ERP,在这之前,对板桥研究着的这些东西,也是非常感兴趣?> 陶醉其中,简直有些走火入魔,不过也真有所成,搞了个和板

> 耪飧隹蚣苡械憷嗨频亩鳌H缓螅藕闷娴男那椋系难

> 习态度,认真学习了ORACLE

> ERP的技术架构体系,工具,和方法,在几个印度高人的带领?> ,技术上算是有些门目了,已经进入了比较自在的境界。国庆

> 冢肿湃パЯ搜oracle 的财务模块 实施顾问的课程。

> 至此,感觉,搞这ERP,什么00,AOP,IOC,乱七八遭的东西都

> 荒眩训玫氖腔邸N铱垂ORACLE erp

> 产品的一部分JAVA源代码,感觉其思想古老的很,在代码一级

> BANQ相比,比banq差远了,但是在构件一级,我门就很难?> 过它。

> 最大的感慨是如果国家能拿出飞船升天的精力,组织一帮象B

> nq这样人的来搞个china erp,估计什么SAP,oracle

> erp,统统很快就会被干掉

人家积累那么多年的代码了,能不古老么。等我们带人搞出来了,再有人看我么的代码一样古老。

ERP这种东西不能看代码有多么优美吧……

Kyle_Yin
2005-11-16 12:14
这个问题的答案很简单:就是因为 ORACLE ERP 的框架严重恶心,导致用户怨声载道,所以 ORACLE 最终不得不靠收购来实现在应用领域的扩张。

呵呵。

>

> 建议能把框架讨论与模式讨论能与解决的问题与关联起来,?

> 拿出一些篇幅讨论一下框架与模式对终极目标(给开发商、用

> Т吹募壑担┑墓毕住?

> 初来乍到,如有冒犯,请多包涵。

banq
2005-11-16 16:28
>ORACLE ERP 的框架严重恶心,导致用户怨声载道

这个我赞同,Oracle是靠数据库出其不意暴发,它有数据库包袱,又没有深厚的软件设计功底,所以他的中间件产品都是变相将用户向数据库诱导,典型的打着红旗反红旗。

Kyle_Yin
2005-11-16 17:02
呵呵,终于找到共同语言了。

ORACLE 新的应用框架,所谓 FUSION ADT,感觉还是恶心。压根就是原来那些东西,拼凑到一起起个新名字就充数。这么复杂的东西,实在看不出比J2EE规范方便到哪里去,当作内部工具也就罢了,外部客户要是拿来写应用那根本是给自己找堵。既然要用那么复杂的框架,我干吗不用标准J2EE API?至少还能保持平台兼容。用了ADT既不减少工作量,又绑定在ORACLE身上。傻啊?

ORACLE 在应用框架方面的根本方向仍然是错误的。

banq
2005-11-16 17:18
以前有个客户找我培训J2EE,说是最热门的技术,然后那个传话的人还没说清楚,说成JDT,说是搞Java的人听到这个名词就知道,我就没想到ADT,以为是JSF呢,结果,我知道那个客户给Oracle误导到没治的地步了,我跟他们说:你们要好好从J2EE开始培训,结果他们可能认为我水平不行,ADT都不知道,我这个堵啊!

我不是想诽谤oracle等公司,但是我做一做“Java技术大侠”还是可以,不从经济利益为谁讲话,只从客观 至少我认为客观角度谈论。

鲁中正气
2005-11-17 09:16
不过,听说下一个版本的oracle erp 将安全采用j2ee架构,具体什么样,不知道。即便是推出了,估计用户也很少用吧,毕竟用户以前投入了这么多了。据我所知,原来搞ORACLE 二次开发的人对J2EE精通的也很少。

鲁中正气
2005-11-17 09:20
现在大家都正在学J2EE的各种技术,以配合ORACLE的转型,有个印度的,年龄挺大了,吓得去做EBS DBA了,呵呵,其实还是做EBS DBA好。

cats_tiger
2005-11-17 09:42
〉ERP架构设计始于业务架构设计,而不是编程框架设计

业务框架是否稳定不取决于我们搞编程的吧。即使业务建模工作再到位,也架不住“某部委的一纸文件”。河北省搞了一个信息交换平台,其实就是把数据挖掘和数据仓库技术改头换面,目的就是为了“一个稳定的业务框架”,因为这种另类的数据库结构(表被旋转),“添加一个字段”这样的工作就变成“添加一条记录”了。本来数据仓库是用来做统计分析和决策支持(OLAP)的,结果被几个人搞成作业务系统(OLTP)的,KAO,真是天才呀!

blueoxygen
2005-11-18 10:47
为啥搞oracle ERP的要精通j2ee?

作SAP顾问连 java都不会也很正常。

猜你喜欢
2Go 1 2 下一页