J2EE平台架构上开发CRM的技术过程控制标签以及熟悉一般的java语言就可以进行开发了。
EJB
EJB假如除往它的语言特点外,我想对于大多数有比较丰富编程经验的开发职员来说应当可以轻松懂得,他非常类似于微软的DCOM。他有一个自己要存活要运动的一个容器,为了可以让客户进行透明调用,而不必关心肠位,他还必须有一个本地和远程接口,同时还应当有一个相干的配置文件,以便告诉容器她要怎样的活法。对于开发职员来说,假如采用一种集成化的开发工具,如JBuilder,就可以大大减少工作量。在JBuilder中通过配置相干的服务器路径、容器信息,我们可以通过它的模板来完成一个EJB组件的开发以及分发,非常方便也非常简略。
在开发过程中,建议的开发方法是在会话bean内部调用实体bean,由于实体bean没有状态但是对数据库的亲和,而会话bean中有我们为了把持程序而需要的高低文信息,因此,我们可以联合这两种bean的所有优点,来比较轻松的进行开发。比如在会话bean中用实体bean进行数据库的访问同时会话bean用来保存客户的高低文信息。
3.3 J2EE各组成部分在开发CRM利用系统中的脚色
我们已经提到过,开发一个硬朗的、可拓展的CRM利用系统中的各个模块,除了召唤中心外我们都将采用浏览器/服务器模式。因此,下面的模式是除了召唤中心模块之外的方法:
浏览器--------〉Jsp脚本文件--------调用---------〉Servlet------调用--------〉EJB------访问数据库---------〉处理返回。
其中Jsp属于前台开发职员进行的开发内容,也就是供给给客户的用户界面,请求是雅观,应用性强,便于把持;
Servlet、EJB为后台开发职员开发的具有可以重用性的包含商务逻辑的组件,也就是说,他们重要是进行企业的商务逻辑的处理。请求是开发的程序必定要硬朗,充分留心到业务逻辑的独立性与组合性。
在开发CRM系统时,前面已经说过,系统分析员自身对于J2EE技巧的把握深度,对于CRM系统业务的懂得程度将极大的决定了系统的成功与否。就是在做系统分析时必定要做到将功效完整细化到Servlet、EJB组件所封装的商务逻辑中往,并且要重复论证其公平性与独立性。
3.4 J2EE各技巧实现CRM利用系统的特点
Jsp相对来说比较简略,但是在开发过程中系统分析员必定要留心尽可能少地将商务逻辑放到Jsp文件中,有几个原因,一是Jsp文件本身的可掩护性比较差,尤其是假如不采用
1、划分版面的界面逻辑,用包含文件的方法给程序员断定开发代码;
2、尽量不将商务逻辑放在Jsp文件中,所有的业务处理都要调用后台的组件;
3、当涉及到的界面逻辑较多的时候,要给程序员设计JavaBean来进行处理,而不是在Jsp文件中直接嵌进java代码,否则会造成Jsp文件的可读性非常差,掩护与调试异常艰苦。
Servlet作为在服务器后台进行处理的组件,除了业务上商务逻辑要独立、完整、可组合的、正确等的请求外,还有一个很重要的请求:就是线程安全性。显然,我们都知道Servlet相比通用网关接口CGI有着明显的优点就是可以掩护一个线程池,不用每一次都要创立一个新的线程,但是可能很多程序员都会心识不到一个经常会碰到的标题:实例变量在所有的线程之间是共享的,并且假如存在着Servlet链互调时,就会产生数据毛病。因此系统分析员必定要勉励程序员多留心利用Java供给的方法(如声明自己的类实现了Runnable接口或者采用同步synchronized技巧等)解决线程的标题,另外还要留心的是数据库的连接标题,由于假如频繁的访问数据库会造成数据库服务器的累赘同时使客户真个回馈速度变慢,因此要留心利用预先分配连接并在开释以后能够回收的连接池。所以,在开发Servlet也要留心下面的3个标题:
1、勉励程序员关注线程安全标题(如采用声明自己的类实现了Runnable接口或者采用同步synchronized技巧等解决线程的标题);
2、数据库的访问要充分利用JDBC技巧的预先分配连接并在开释以后能够回收的连接池;
3、勉励系统分析员将商务逻辑划分成单个的独立的可通用的可重用的商务逻辑组件,在实际的程序中通过Servlet链来完成某项商务逻辑。
EJB实际上单就程序的写作方面要比Servlet简略的多,它使程序员只需要关心要实现的是甚麽就可以了,而不必关心事务的处理,底层的把持等等标题。但是也还是有一些编程方面的请求:
1、最好能够在程序中将所有的static字段都声明为final型的,这样可以保证多个实例涌现时语义的不一致标题;
2、留心线程标题,同Servlet;
3、不应用文件系统。EJB组件可以通过环境命名高低文用一种标准的方法进行环境实体查询,基础上是不用文件系统。
4、禁用socket来进行监听和吸收连接,或者用其进行多路发送。
5、不可能用awt函数来完成键盘的输进和输出,假如有的话,应当是向把持台输出把持信息,由于组件是用来在服务器端完成某一项商务逻辑的。
第四章:J2EE平台架构开发CRM的内容
本章的内容是一个非常大的部分,他所涵盖的就是具体的开发方案,其中包含应用案例图,运行图等等。由于某种原因,这儿就不写了,请体谅。
第五章:技巧层面把持J2EE平台架构开发CRM的过程
在J2EE平台上开发CRM利用系统,是一个非常优良的方案,一方面J2EE是一项比较成熟的技巧规范,各大IT服务器、中间件厂商也都大力推重并支撑,尽管微软大力推出.NET,但是毕竟.NET是一项新的技巧规范,假如在其上进行开发的话,风险显然要大得多,而J2EE目前却正是在走向成熟。
正像任何事情一样,在先进的J2EE平台上开发CRM利用系统必需要有一个良好的实行过程,在这个过程当中,有一个非常重要的脚色:系统分析员。系统分析员自身对于J2EE技巧的把握深度、对CRM利用系统的业务懂得程度很大得影APP软件响了开发的过程,甚至可以尽不夸张的说,系统分析员自身的素质决定了开发的成功与否,这是一个非常要害的因素。 首先是系统分析员对于客户的需求的懂得程度,只有深进的懂得了客户的需求,才干够将商务逻辑很好的划分;其次是系统分析员的思维是否周密,是否严谨,是否具有很强的逻辑思维能力,由于这涉及到将商务逻辑进一步细化成独立的可重用的业务逻辑与应用逻辑。第三是其是否对于J2EE技巧有着非常深的把握,这是实行CRM的另外一个重要之处,由于在全部的开发过程中,实在重心就在服务器端组件的开发上,一个系统能否稳固,高效的运行,很大程度上取决于开发技巧上是否规范与公平,而系统分析员在实行编码阶段的重要职责就是负责检查程序员的程序代码
在开发过程中另外一个留心的是开发职员的分工。在J2EE平台上的开发与一般的软件开发概念不同,它有着严格的分工:
1、系统分析员;
2、后台组件开发程序员(重要是Servlet与EJB);
3、后台服务器实行技巧职员(重要负责组件的治理);
4、后台组件测试职员;
5、前台用户界面程序员(重要是jsp程序员+美工);
6、前台测试技巧职员;
在实际的实行过程中,后台服务器实行技巧职员可以充当后台组件测试职员的脚色,同样,前台用户界面程序员可以充当前台测试技巧职员,由于他的页面中所包含的逻辑比较少。
总结一下,要害的几点: 1、商务逻辑必定要划分的非常公平,原则是一个组件中应当只含有一种商务逻辑,一般的商务逻辑应当是通过几个组件的协同合作来实现的(如何划分,如何组合就是看系统分析员的功底了!) 2、分工必定要明确,除了上面所列出的脚色充当之外,尽量避免前台程序员与后台程序员的脚色互换,否则很可能造成商务逻辑组件之间的耦合,而这是尽对不答应的,否则随着开发过程的进行,就会创造越来越难以把持利用的开发。所以在开发过程中必定要留心组件的商务逻辑的独立性与唯一性,系统分析员和项目负责人必定要严格把关,这一点非常非常重要。
第六章:CRM利用系统各个模块的具体技巧实现
利用系统都是开发商基于对某项业务的深入懂得而产生的,不同的行业有不同的商务逻辑,即便是同一行业也有不同,因此,要根据客户的实际需求来做。但是,作为一个CRM系统她都有一个共同的框架,就是上面所提到的,由于,一套完整和实用的CRM系统可以看作是: 框架+具体商务逻辑。而框架部分则就是上面请求系统分析员所做的工作:将通用的商务逻辑抽象出来做成组件,以备复用。
本章应当是一个具体的模块设计,其中包含组件组合应用图,流程图以及其他的文档等等。出于和第四章同样的原因,请体谅。
第七章:国内CRM系统目前存在的标题以及采用J2EE技巧进行的解决方案
我们研究过国内几家CRM系统,学习到很多的东西,但同时也创造一些标题,现在举几个例子:
1、 大而全,但是各个功效做的太过于简略,无法实用。
2、 缺乏集成能力,无法将网页、电邮、电话、传真等集成。
3、 没有与客户的互动渠道。
就这三个原因,是由于在全部的设计上偏离了以客户为中心的原则,没有将客户的需求具体、完整的划分成个体的、独立的功效组件,没有将各个功效做成是以客户为核心的插件,再加上如开发本钱的压力等。而假如是采用J2EE,并且严格的按照公平划分的组件的方法来进行开发,就会解决或者避免或者减轻这些标题。比如,在开发完销售模块与服务模块的组件之后,电子商务模块基础上也就完成,只需要少许的其它组件就可以完成一个电子商务模块。