| 作者 |
内容 |
| liubing76 |
一个系统体系的问题？？？
一个系统体系的问题？？？
我们的系统，采用DB(oracle)+Ejb(weblogic 6.1)+Jsp
的三层结构，业务逻辑主要在Ejb中实现，现在系统要
与别的厂家的系统提供接口，要求
1：透过防火墙
2：支持事务的概念（commit,rollback)
3：客户端的开发平台与语言（无限制win,unix,linux,c++,vb,pb等）
4：不想改变我们已经开发的结构，同时不增加成本
如（不使用Tuxedo,Corba)
我们想
方案1：我的接口生成XML文件，但是他不支持事务
方案2：使用corba,他(corba)的服务器端作为Ejb的客户端
其他系统，作为corba的客户端调用。但是增加成本
需要corba服务器如(visibroker等）
方案3：使用使用消息中间件Tuxedo或MQseries,他(Tuxedo)的
服务器端作为Ejb的客户端, 其他系统，作为Tuxedo的客户端调用。
但是增加成本需要消息服务器如(Tuxedo等）
方案4：使用Weblogic的JMS服务或Web Services等，但是BEA技术支持
说Weblogic的JMS服务或Web Services的功能比较弱。
方案5：使用RMI-IIOP协议，好象可以.技术不太熟（不能确定可不可以）
方案6：使用最古老的Socket通信，好象不能通过防火墙,并且事务要自己开发
方案7：使用HTTP隧道技术，客户端模拟Http协议，与Servlet或JSP
通信，在Servlet端调用ejb.在vb和vc与java swing中我使用过
在其他语言没用过，感觉想原始的Web Services.他们的内容使用
XMl.但是事务的感念也没有
|
| 02/02/04 19:31 |
酷帖！ 臭帖！ 回复 |
酷帖评价： 臭帖评价： |
| 返回页首 |
|
| 清风淡月 |
 回复:
一个系统体系的问题？？？
有点高深，不懂，希望多向你学习！
你一下子提了那么多的名字啊 |
| 02/02/04 21:01 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| lczzhang |
 回复:
是C/S还是B/S?
|
| 02/02/04 21:23 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| zzgod@263.net |
 回复:
一个系统体系的问题？？？
不清楚你的系统，于其他系统的关系，建议不一定准确。
1方案：好办法，事务方面是否可直接在数据库上作文章
2、3方案：最省力的办法，boss一定会骂你
4、5：没听说谁这么玩过。（惭愧！！考虑一下可实现性）
6：绝对可行，人工成本巨大（老板不在乎）
7：方案1的变种，何必绕那么大的圈子。 |
| 02/02/05 08:48 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| qingrun |
回复:
一个系统体系的问题？？？
下面，我说一下我的个人看法，不一定正确，仅供参考：
方案1：我的接口生成XML文件，但是他不支持事务——事务处理好象不应该是在这里做的吧？
方案2：使用corba,他(corba)的服务器端作为Ejb的客户端其他系统，作为corba的客户端调用。但是增加成本需要corba服务器如(visibroker等）——如果这个方案只是因为成本的话，我可以给你推荐一个相当稳定的，不需要花钱的broker，是一所大学的研究所做出来的，我们已经使用过，名字是：minibroker，具体的学院名称我记不大清楚了，你可以查找一下。
方案3：使用使用消息中间件Tuxedo或MQseries,他(Tuxedo)的服务器端作为Ejb的客户端,
其他系统，作为Tuxedo的客户端调用。但是增加成本需要消息服务器如(Tuxedo等）——我对Tuxedo不熟悉。不过，如果你打算用MQseries的话，我建议你们的应用服务器改用WebSphere。
方案4：使用Weblogic的JMS服务或Web Services等，但是BEA技术支持说Weblogic的JMS服务或Web
Services的功能比较弱。——WebLogic有没有支持EJB2.0的规范？如果支持了的话，还没有支持MDB么？如果支持了MDB的话，那就没有问题了，你可以放心的使用！
方案5：使用RMI-IIOP协议，好象可以.技术不太熟（不能确定可不可以）——应该可以，不过，这好像只是网络传输部分的解决，并不是整体体系框架的内容，这在WebLogic和WebSphere中都实现了。不能算是一个独立的方案。
方案6：使用最古老的Socket通信，好象不能通过防火墙,并且事务要自己开发——呵呵，这个我就不能赞成了。
方案7：使用HTTP隧道技术，客户端模拟Http协议，与Servlet或JSP通信，在Servlet端调用ejb.在vb和vc与java
swing中我使用过在其他语言没用过，感觉想原始的Web
Services.他们的内容使用XMl.但是事务的感念也没有——事务的处理部分也应该是在ejb中做的，而不是这个部分应该处理的，HTTP技术在WebServer中都做了很好的支持，这个好像也不属于体系方面的问题。也不能算是一个独立的方案，如果你真的是打算使用vb、vc来和java组件通信的话，我建议还是使用rmi-iiop！ |
| 02/02/05 09:02 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| liubing76 |
 回复:
一个系统体系的问题？？？
我的事务的概念是指：
我们的系统提供的接口A,另一家系统的接口B,在被别的的系统调用
算做一个事务，那么他应该支持commit.rollback等基本的事物概念。
项目背景：一著名电信运营商的系统被分为4个子
系统，分别被不同的公司中标，他要求每家要对外提供接口
满足以上的要求。我们的系统已经开发完成。 |
| 02/02/05 09:59 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| jdev |
回复:
一个系统体系的问题？？？
问题似乎可以简化为两个核心：事物和通讯。
事物按照进一步阐述可以理解为嵌套式事务，即一个整体形事物分成几个相关的子事物来处理，解决的办法可以采用两阶段提交的方式来实施，J2EE中应该实现了相应的功能。
通讯的方式，如果客户端是由Java编制，RMI将是最好的方案，因为RMI提供了基于Servlet进行中转的联结方式；如果采用其它客户端，可能采用Socket通讯更直接、有效。
基于WEB的应用程序的通讯方式绝大多数是基于TCP/IP的，如果不采用HTTP
Tunneling,
就必定要在防火墙中打开某固定的断口（即使CORBA也不例外）。采用XML或WEB
Services等的方式也只是定义了系统间数据交换的格式，通讯方式也不会超出以上的范畴。
国外电信行业应用系统实现方式基本上是采用比较成熟的技术，如CORBA等，定义系统间的接口是系统间应用的接口，常常通过定义IDL来实现，如由Lucent、Nortel等世界电信7大巨头定义的G7体系已经被逐渐使用。
一些个人经验，希望会有所帮助。
// jdev
|
| 02/02/05 10:59 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| liubing76 |
回复:
是C/S还是B/S?
客户端无要求，平台，语言，C/s或B/S |
| 02/02/05 11:50 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| liubing76 |
 回复:
一个系统体系的问题？？？
to jdev:
讲的很好，谢谢各位！！！ |
| 02/02/05 12:34 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
| w_rose |
 对“事务”的理解不能太技术化！
“事务”应当严格应用在数据库操纵技术中，并且应当保证“事务”的开始到结束几乎在瞬间就能完成，否则就不许拆开成几个不同的“事务”，并且通过修改业务流程来使用。
比如：售票员要先锁定一张机票，然后输入客户资料，最后输入付款资料确认机票已经售出，以后系统就不会再将此张机票卖给其它人。
也许，你选择在锁定机票前开始一个数据库事务——错！如果终端操作员在应该输入客户资料的时候上厕所去了，那么此事务开始后自动加锁的资料如何解锁，其它终端很可能被你锁住。
正确运用的“锁”只是一个业务概念上的锁，而不是数据库意义上的锁。当操作员“锁定”一张票时，只是将票的一个标志改变了，其它人要“锁定”此票时程序会检查此标志，从而禁止再次重复“锁定”。并且，如果后台发现有一张票得锁定时间超过20分钟，也可以强行删除锁定，则原来锁定票的终端会在确认票时进入一个错误处理。此过程中，数据库的“事务锁定”都是瞬间完成的，要使得整个业务数据准确，就需要改变部分业务流程，并且将如何应付意外的业务流程教给操作员。
总之，业务意义的“锁”其实是一种业务上处理各种意外情况的规则，千万不要技术化地用数据库的“事务”概念简单处理。那样，可能你写出的程序在单机上测试时很好，但无法在商业环境中实用。
使用XML目的是为了方便定义应用对象，因此应当用业务的语言来设计XML的内容，不要在XML传递时传递什么SQL之类的东西。 |
| 02/02/06 23:47 |
酷帖！ 臭帖！ 回复 |
| 酷帖评价： 臭帖评价： |
| 返回页首 |
|
