求指点~刚刚进入保险行业搞技术觉得好彷徨啊~! - 第3页 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

大部分时间我都在根据业务流程反推IT流程。总公司IT真好，知道正向流程，不用像我一样反推。等使用了oracle10g object后估计得有一大批反推高手下岗。
银保通我不熟悉。有没有高手可以介绍一下。但我估计，银保通应该是在银行或者保险公司设立一个前置机，然后让银行端用户使用。而且应该是保险公司与银行间的对帐，不应该是保险公司与银行操作员间的对帐
大部分时间我都在根据业务流程反推IT流程。总公司IT真好，知道正向流程，不用像我一样反推。等使用了oracle10g object后估计得有一大批反推高手下岗。
银保通我不熟悉。有没有高手可以介绍一下。但我估计，银保通应该是在银行或者保险公司设立一个前置机，然后让银行端用户使用。而且应该是保险公司与银行间的对帐，不应该是保险公司与银行操作员间的对帐 [/B]
银行柜面人员之揭录单，然后通过专线接到保险公司的前置机
直接进入保险公司的核心系统承保，然后承保或者拒保信息返回
银行柜台操作人员，在银行直接打印保单。
银行每天象保险公司传输收费信息。
银行柜面人员之揭录单，然后通过专线接到保险公司的前置机
直接进入保险公司的核心系统承保，然后承保或者拒保信息返回
银行柜台操作人员，在银行直接打印保单。
银行每天象保险公司传输收费信息。 [/B]
这个流程有几个需要解决的：
1、如果银行人员，录入出现错误，如何处理。给保险公司的维护人员打电话？如果可以打电话，那么又怎么确定这个修改的申请，是正确的人，提出的正确要求，即如何确定要求的正确性和不可抵赖性。
2、投保人在投保后又期内退保，资金如何处理。按收支两条线要求，如何处理。谁能相信客户带现金今天投保，明天来退保，却不能马上得到现金的情况会让客户满意。
3、对帐，这是个老问题。按财务流程应该逐级对帐，但银行的各个营业网点，会替保险公司对帐吗。尤其是银行操作者操作的不是本银行的系统，而是另一个公司的系统时。
4、这个流程会导致保险公司基层网点和银行基层网点相互竞争。
5、在这个流程中J2EE位置在那呢。
大多公司核心系统都已成熟，争取全程参加个外围系统设计开发，在此阶段进一步了解核心系统及其业务逻辑。
[B]两个方向（我的观点，欢迎大家拍砖）；
1、实时交易系统，如录单，保单生效。从目前看J2EE在这个领域应用还是有困难的。原因
a、技术力量的薄弱。很多搞J2EE架构的搞到最后变成了，JSP+Servlet+javabean+EJB的混合体
b、硬件价格。保险公司再有钱，搞AIX集群的恐怕也没几家受的了。所以才有linux上的oracle RAC出现。但国内普遍对LINUX核心应用不放心。
c、既有系统的移植。从现在既有系统向JAVA平台移植，难度极大，和重做差不多。
d、中间件竞争。java中间件与TUXEDO，MQ竞争还处于劣势。java速度与C/C++还有较大差别。
2、非实时系统。如业绩查询，数据仓库。J2EE是最好的选择。而且我估计这部分应用将会成为保险公司真正的核心。实时应用这部分不应该是保险公司的核心应用，但现在各家基本都把它当作核心，这本身就是一个怪胎。使用J2EE原因：
a、可以让管钱的，有权的，非常有成就感。轻轻一点鼠标就看见想看的东西，恩，这钱没白花有效果。
b、便于移植，至少是理论上的。有钱了，买两台RS9000玩，要求一天之内把系统移植RS9000上，至少理论上可行，不信，移个C/C++应用试试。
c、使用了新技术，上市的时候，过发审委这关比较容易。
备注：
事实上从2001年的SUNONE到2005年的J2EE并没有本质上的进步，到是开源社区搞出一些新东西。号称世界上最快的AS jboss就是这时出现的，一开始SUN还说JBOSS不符合J2EE标准，现在也符合了 [/B]
就这个，我提点不同意见
1、实时交易系统，如录单，保单生效。从目前看J2EE在这个领域应用还是有困难的。原因
a、技术力量的薄弱。很多搞J2EE架构的搞到最后变成了，JSP+Servlet+javabean+EJB的混合体
JSP+Servlet+javabean+EJB难道不是j2ee架构吗？
b、硬件价格。保险公司再有钱，搞AIX集群的恐怕也没几家受的了。所以才有linux上的oracle RAC出现。但国内普遍对LINUX核心应用不放心。
j2ee是跨平台的，不是要跑在aix上的。
至于你说的linux上的oracle RAC那和j2ee没有关系
c、既有系统的移植。从现在既有系统向JAVA平台移植，难度极大，和重做差不多。
这个确实是这样的
d、中间件竞争。java中间件与TUXEDO，MQ竞争还处于劣势。java速度与C/C++还有较大差别。
速度从jdk1.4出来后，就差别没有那么明显了，更多的时候，不是对速度的要求，是对系统扩展性和二次开发的要求。
2、非实时系统。如业绩查询，数据仓库。J2EE是最好的选择。而且我估计这部分应用将会成为保险公司真正的核心。实时应用这部分不应该是保险公司的核心应用，但现在各家基本都把它当作核心，这本身就是一个怪胎。使用J2EE原因：
保险公司的核心系统就是承保系统
a、可以让管钱的，有权的，非常有成就感。轻轻一点鼠标就看见想看的东西，恩，这钱没白花有效果。
这个，什么样的web-based的系统都可以实现的，不一定要j2ee的。比如oracle的erp。
b、便于移植，至少是理论上的。有钱了，买两台RS9000玩，要求一天之内把系统移植RS9000上，至少理论上可行，不信，移个C/C++应用试试。
这个，至少我从aix往linux移植，或者从windows到linux，没啥问题。
c、使用了新技术，上市的时候，过发审委这关比较容易。
这个我就不懂了.....
备注：
事实上从2001年的SUNONE到2005年的J2EE并没有本质上的进步，到是开源社区搞出一些新东西。号称世界上最快的AS jboss就是这时出现的，一开始SUN还说JBOSS不符合J2EE标准，现在也符合了
我不太清楚对本质性的进步定义是啥，
说穿了，都是it而已，那岂不是啥进步都没有了。
就我知道的几个案例说明一下吧
网站用j2ee得就太多了，不举例了
保险公司，目前用的规模比较大的一家
，能够支撑80多家分支机构的作业，
每天承保单数在3000单以上，访问次数
100万以上。