项目中ejb接口设计的问题?

banq:
你好,我们公司现在正在用java做一套OA.涉及到了ejb和工作流,之所以费这么大力气是考虑到要和甲方的mis/ERP集成一套信息化系统,并且甲方的业务非常的分散,许多需求还没有真正开发出来,随时可能有新的需求加进来,所以现在很是头痛:(有几个问题想请教一下!
1)因为是团队作业,所以需要ejb和表示逻辑分头开发,这时ejb的接口如何封装处理呢?(servlet/javabean?如何性能达到最优呢?)
2)怎么样才能作到一个良好的设计架构,能够轻松加入新的需求,而使整体布局不受影响?
3)最后一个问题,现在这个架构该如何设计呢?
说了这么多,希望banq能够以自己的丰富经验给指出一个方向,从banq的论坛上获得了不少的帮助再次表示感谢!
yesky12

你这个案例其实是个很常见。

建议使用web services和原来系统连接,这样,现有OA系统要有XML文件的规划,以便将来能连接。

具体如何有一个良好的架构,取决与你们对原来系统和现有系统的掌握程度。

划分系统边界,做好接口

banq:
现在的情况是企业信息化水平为零,我们希望做一个良好的架构,现在是准备用ejb来封装业务逻辑,使ejb和前端的jsp开发人员的关联降到最低,分成业务逻辑和表示逻辑两个编程块分别由jsp程序员和ejb程序员开发。
存在的问题就是接口该怎么封呢?

EJB封装业务逻辑,jsp作表示层,和用户交互。
在ejb外面可以做一层service,降低耦合以及使它具有良好的扩展。就像板桥说的,方便和其他的系统集成。

用 Session Bean 做 Facade 或 Proxy 封装业务逻辑
JSP/Servlet 做显示逻辑

JSP -| |---------------------- |-EJB1
|--| Session Bean Facade | --|
JSP2 -| |---------------------- |-EJB2

把ejb的接口封在servlet或javabean中怎么样呢?哪一种能够更好的实现业务逻辑和表示逻辑的分离。

需求的变更管理和软件的版本控制也很重要,过多的考虑设计未必是好事
尤其对于这种需求变动频繁的项目做好refactoring的准备,可以参考xp的
一些原则性做法.