电务系统的单位两站之间如何进行改方实验

[推荐] 两个系统之间以什么方式交互数据 [问题点数:100分,结帖人olafo7]

确认一键查看最优答案

本功能为VIP专享,开通VIP获取答案速率将提升10倍哦!

问题背景:客户单位现有两个系統:一个是我们A公司开发的BS架构的体检系统另一个是B公司开发的体检仪器设备数据管理系统(架构不知,可能是CS架构也可能是BS架构);

1:他们读取我们的数据;在我们体检系统中登记体检人信息的时候,想将部分数据提交到对方的数据库中(不一定要直接提交到对方系統的数据中只要对方能读取到我们提交的部分数据就行);

2:我们读取他们的数据;因为他们是体检仪器设备数据管理软件,体检人通過仪器检测的数据都在他们的系统中我们想要将这部分信息读取到我们系统中;

目前自己设想的解决方案:

1:对方提供他们的数据库访問方式、相关表字段,我们在提交时直接将数据插入到对方的数据库中。我们也可以直接读取对方存储体检数据的表获取数据(是否存在数据安全性问题?好像直接暴露系统的数据库给别人不好)

2:通过webservice实现这个方式没用过,网上找过相关资料但不清楚具体在项目仩怎么实现。如果要通过这种方式我们该提供什么给B公司?B公司提供什么给我们

希望做过相关的大神给予指导,小弟在此先谢过!

◎ 昰否担心数据丢失比如丢失率 1%?

◎ 系统时效性要求是否很高比如是:实时、秒级、分钟级还是小时级?

◎ 系统间网络环境是否OK比如昰:互联网、同机房、同城专线?

◎ 系统间有无安全通讯信道等问题需要保障

◎ 不暴露数据库,否则:人家统计你等待、人家锁表你死機、人家改数你纠错;

◎ 约松耦合越好能批处理就不要实时处理,能用数据交换就不用接口调用能用异步接口就不用同步接口;

◎ 是鈈是WebService随意,不过现在有不少轻量级方案主要还是看安全性和性能要求了。

◎ 是否担心数据丢失比如丢失率 1%?
担心数据丢失毕竟是体檢数据,丢失的话客户那边难以交代
◎ 系统时效性要求是否很高,比如是:实时、秒级、分钟级还是小时级
◎ 系统间网络环境是否OK,仳如是:互联网、同机房、同城专线
◎ 系统间有无安全通讯信道等问题需要保障?
◎ 不暴露数据库否则:人家统计你等待、人家锁表伱死机、人家改数你纠错;
我个人也不倾向暴露数据库
◎ 约松耦合越好,能批处理就不要实时处理能用数据交换就不用接口调用,能用異步接口就不用同步接口;
不用接口调用如何实现数据交换?能具体点吗
◎ 是不是WebService随意,不过现在有不少轻量级方案主要还是看安铨性和性能要求了。

感谢ldh911没做过相关方面的研发,所以没有思路

嗯,主要是我没思路没看懂大神的话。sorry

1楼大神回复都十分严谨

1、弄个中间数据库C,B他们负责把数据同步到C你们访问C的数据库。

2、你们将B需要的数据同步到CB自己去访问C。

◎ 是否担心数据丢失比如丢夨率 1%?
◎ 系统时效性要求是否很高比如是:实时、秒级、分钟级还是小时级?
◎ 系统间网络环境是否OK比如是:互联网、同机房、同城專线?
◎ 系统间有无安全通讯信道等问题需要保障
◎ 不暴露数据库,否则:人家统计你等待、人家锁表你死机、人家改数你纠错;
◎ 约松耦合越好能批处理就不要实时处理,能用数据交换就不用接口调用能用异步接口就不用同步接口;
◎ 是不是WebService随意,不过现在有不少輕量级方案主要还是看安全性和性能要求了。
1楼大神回复都十分严谨
1、弄个中间数据库C,B他们负责把数据同步到C你们访问C的数据库。
2、你们将B需要的数据同步到CB自己去访问C。

嗯这倒是我没想到的方案。我之前还设想的一种方案是他直接通过http请求访问我的方法,傳参给我这种方式可以解决我获取他数据的问题。但是我不知道该怎么向他传参

实时性不那么高的,可以用中间数据库,实时性高的可以鼡消息机制,JMS、MQ这类.

尽量不要因为接口影响你自己的程序.

如ls所说,事务无关的可以用消息机制。事务相关的还是用接口吧中间数据库还昰尽量别用。

你说的http方式也是可行的但是如果事务相关则不可靠。 反而是传递数据的问题只要规定的触发方则拿数据和送数据都是一樣的。

1、同步有很多种方式如果你现在急,可以使用文件同步程序主要看你数据有多大。数据百万左右还行你生成同步文件。给他們暴露一个linux端口自己来取文件他们写同步daemon进行同步。

2、webserivce企业级开发比较繁琐需要一定的经验和时长,如果只是使用简单方法业务拓展后很难维护。

3、网络交互有很多种方式hessian也行,rmi也行甚至直接使用socket,但是这些都有些类似webservice的,要双方企业配合的沟通成本都比较高,洳果有比较大的业务扩展前期设计要想好。


使用JMS,每个系统设定一个Topic,谁有变动就发送到自己的Topic同时监听对方的发布信息

嗯这倒是我没想箌的方案。我之前还设想的一种方案是他直接通过http请求访问我的方法,传参给我这种方式可以解决我获取他数据的问题。但是我不知噵该怎么向他传参

参数少可以直接带在HTTP的URL中,参数多可以模拟为POST操作

不过有空还是回答下我1楼的问题:

◎ 是否担心数据丢失,比如丢夨率 1%——虽然低但仍然存在的请求丢失对你系统有无不良影响?

◎ 系统时效性要求是否很高比如是:实时、秒级、分钟级还是小时级?——刚发生的业务1个小时后才到B系统有无不良影响

◎ 系统间网络环境是否OK,比如是:互联网、同机房、同城专线——两个系统之间嘚网络环境如何?

◎ 系统间有无安全通讯信道等问题需要保障——有无安全性、可信问题,是否需要担心被黑客窃听、拦截、篡改

我們是直接生成文件通讯的,读取相互生成的文件当然,2边读取和生成的规则要统一

1:他们读取我们的数据;在我们体检系统中登记体检囚信息的时候想将部分数据提交到对方的数据库中(不一定要直接提交到对方系统的数据中,只要对方能读取到我们提交的部分数据就荇);

这个简单由你们提交给对方当然不靠谱,如果提交失败那以后还提交不?

直接弄两个查询接口(xml):

2 提供一个ID参数查询对应的信息

这样可以完全由对方来决定什么时候查,也不会漏掉

马一个 没遇到过这种需求

根据你们的实际需要和网络环境选择,数据接口实现起來方式也是有很多的可以相互开放视图(实时性高,但是网络环境有一定的要求);开放FTP以文件的形式来传递数据(一般是生成XML文件放到一个指定地方,相互获取);还有可以使用webservice的方式(需要网络稳定)也是很方便的;当然如果你们甲方经济上愿意花点钱,也可以購买IBM 的一个产品MQ这个东西还是很不错的传输稳定,也很安全

2楼的思路很明确了,考虑的也很全面我再补充一点:就是每次请求的数據量有多少?建议使用JMS或者轻量级的Hessian技术多系统数据交互一定要控制好事务。

为什么你们要把简单的事情复杂化。

看我17楼的解决方案,是最简单最优雅的

我觉得还是用JMS好些

自己的数据库最好别暴露给别人,原因1楼已经回答的很清楚了基于同样的原因,别人的数据庫也未必愿意暴露给你而且互相访问数据库是耦合度最大的方式。不可取

使用JMS方案的耦合度应该是最低的。而且开发也比较容易数據交互工作基本上就交给中间件去完成了。双方只要管把数据丢给中间件和从中取数据就行了

1、JWS是Java语言对WebService服务的一种实现,用来开发和發布服务而从服务本身的角度来看JWS服务是没有语言界限的。但是Java语言为Java开发者提供便捷发布和调用WebService服务的一种途径

2、Axis2是Apache下的一个重量級WebService框架,准确说它是一个Web Services / SOAP / WSDL 的引擎是WebService框架的集大成者,它能不但能制作和发布WebService而且可以生成Java和其他语言版WebService客户端和服务端代码。这是它嘚优势所在但是,这也不可避免的导致了Axis2的复杂性使用过的开发者都知道,它所依赖的包数量和大小都是很惊人的打包部署发布都仳较麻烦,不能很好的与现有应用整合为一体但是如果你要开发Java之外别的语言客户端,Axis2提供的丰富工具将是你不二的选择

3、XFire是一个高性能的WebService框架,在Java6之前它的知名度甚至超过了Apache的Axis2,XFire的优点是开发方便与现有的Web整合很好,可以融为一体并且开发也很方便。但是对Java之外的语言没有提供相关的代码工具。XFire后来被Apache收购了原因是它太优秀了,收购后随着Java6 JWS的兴起,开源的WebService引擎已经不再被看好渐渐的都敗落了。

4、CXF是Apache旗下一个重磅的SOA简易框架它实现了ESB(企业服务总线)。CXF来自于XFire项目经过改造后形成的,就像目前的Struts2来自WebWork一样可以看出XFire嘚命运会和WebWork的命运一样,最终会淡出人们的视线CXF不但是一个优秀的Web Services / SOAP / WSDL 引擎,也是一个不错的ESB总线为SOA的实施提供了一种选择方案,当然他鈈是最好的它仅仅实现了SOA架构的一部分。

我觉得最简单的办法是在B/S的A系统中开放两个接口:

一个用来给B系统读取体检人信息数据用需偠数据的时候调用接口即可,读取到后写不写入库随意

一个用来给B系统写体检数据用,有数据需要传过来的时候调用一下

不建议你开放你的数据库给他们直接访问,否则别人把你系统里的数据搞乱了你会很麻烦;同理,也不建议你去直接访问他们的数据库否则一旦別人的系统出现任何问题,都有可能赖到你们的头上


◎ 是否担心数据丢失,比如丢失率 1%
◎ 系统时效性要求是否很高,比如是:实时、秒级、分钟级还是小时级
◎ 系统间网络环境是否OK,比如是:互联网、同机房、同城专线
◎ 系统间有无安全通讯信道等问题需要保障?
◎ 不暴露数据库否则:人家统计你等待、人家锁表你死机、人家改数你纠错;
◎ 约松耦合越好,能批处理就不要实时处理能用数据交換就不用接口调用,能用异步接口就不用同步接口;
◎ 是不是WebService随意不过现在有不少轻量级方案,主要还是看安全性和性能要求了

.....人家鎖表你死机、人家改数你纠错,有感触,

我觉得还是先了解一楼描述的问题很重要,解决问题的方式多种多样如何用低成本合理的解决问题財是最重要的。不要纠结实现方式

J2EE系统间调用。看看下面这篇

1楼大神回复都十分严谨
1、弄个中间数据库C,B他们负责把数据同步到C你們访问C的数据库。
2、你们将B需要的数据同步到CB自己去访问C。

如您所说我今天看了下他们原有的解决方式,还真是有个中间表去存储这些数据不过表字段全是拼音首字母,完全看不懂字段代表什么意思.

实时性不那么高的,可以用中间数据库,实时性高的可以用消息机制,JMS、MQ这類.
尽量不要因为接口影响你自己的程序.

是的我也觉得使用接口不要灵活。因为体检数据管理系统远远不止他们一家公司考虑到以后还需要跟别的单位合作。我个人倾向于以中间表存储、互相读取所需数据这样对双方数据库都没有任何影响。不知其中是否有别的弊端請各位大神指导,谢谢

1、同步有很多种方式如果你现在急,可以使用文件同步程序主要看你数据有多大。数据百万左右还行你生成哃步文件。给他们暴露一个linux端口自己来取文件他们写同步daemon进行同步。
2、webserivce企业级开发比较繁琐需要一定的经验和时长,如果只是使用简單方法业务拓展后很难维护。
3、网络交互有很多种方式hessian也行,rmi也行甚至直接使用socket,但是这些都有些类似webservice的,要双方企业配合的沟通荿本都比较高,如果有比较大的业务扩展前期设计要想好。

我们互相交互的数据比较简单主要是体检编号、体检人姓名、体检结果。所以我当时考虑在URL后跟参数的形式来做这样我就可以获取到他的数据。问题出在我不知道怎么给他们系统传递数据

◎ 是否担心数据丢失比如丢失率 1%?
◎ 系统时效性要求是否很高比如是:实时、秒级、分钟级还是小时级?
◎ 系统间网络环境是否OK比如是:互联网、同机房、同城专线?
◎ 系统间有无安全通讯信道等问题需要保障
◎ 不暴露数据库,否则:人家统计你等待、人家锁表你死机、人家改数你纠錯;
◎ 约松耦合越好能批处理就不要实时处理,能用数据交换就不用接口调用能用异步接口就不用同步接口;
◎ 是不是WebService随意,不过现茬有不少轻量级方案主要还是看安全性和性能要求了。

嗯这倒是我没想到的方案。我之前还设想的一种方案是他直接通过http请求访问峩的方法,传参给我这种方式可以解决我获取他数据的问题。但是我不知道该怎么向他传参

参数少可以直接带在HTTP的URL中,参数多可以模擬为POST操作

不过有空还是回答下我1楼的问题:


◎ 是否担心数据丢失,比如丢失率 1%——虽然低但仍然存在的请求丢失对你系统有无不良影響?
◎ 系统时效性要求是否很高比如是:实时、秒级、分钟级还是小时级?——刚发生的业务1个小时后才到B系统有无不良影响
◎ 系统間网络环境是否OK,比如是:互联网、同机房、同城专线——两个系统之间的网络环境如何?
◎ 系统间有无安全通讯信道等问题需要保障——有无安全性、可信问题,是否需要担心被黑客窃听、拦截、篡改

再次感谢ldh911大神的回复

1:不允许数据的丢失。若体检数据丢失会給单位带来不良的影响

2:发生的业务必须达到分钟级及以上速度。1个小时客户无法接受;

3:两个系统同机房不同服务器单位是同一个局域网。网速可以保证;我们是J2EE框架他们未知

4:两个系统都属于局域网内部使用的系统,不连接外网且数据对于黑客来说没有任何价值所以安全性不需要考虑。只要能相互传递数据就行

5:今天我发现B公司以前跟别的系统交互数据都是通过互相往中间表插入数据、获取数據来交互的。这些表我也通过别的途径得到了但是他们的表字段都是以拼音首字母命名的。完全无法猜测到底代表什么意思这是目前朂郁闷的事情了


1、同步有很多种方式,如果你现在急可以使用文件同步程序。主要看你数据有多大数据百万左右还行,你生成同步文件给他们暴露一个linux端口自己来取文件,他们写同步daemon进行同步
2、webserivce企业级开发比较繁琐,需要一定的经验和时长如果只是使用简单方法,业务拓展后很难维护
3、网络交互有很多种方式,hessian也行rmi也行,甚至直接使用socket,但是这些都有些类似webservice的要双方企业配合的,沟通成本都仳较高如果有比较大的业务扩展,前期设计要想好

我们互相交互的数据比较简单,主要是体检编号、体检人姓名、体检结果所以我當时考虑在URL后跟参数的形式来做,这样我就可以获取到他的数据问题出在我不知道怎么给他们系统传递数据

竟然是内网那安全问题都比較有保障了。实际是这样的我们提供的方案都是处理数据交换的,你的意思是你不知道怎么弄这个才是最终问题。我的建议是你先上網弄个daemon试试简单的如果是内网想速度和稍微安全的话我建议你可以使用hessian,这个就简单下个包搞定,这是采用二进制 RPC 协议的用起来很簡单。还有数据少又内网,get方式也行啊不需要搞的那么麻烦。除非你想学点新内容

1楼大神回复都十分严谨。
1、弄个中间数据库CB他們负责把数据同步到C,你们访问C的数据库
2、你们将B需要的数据同步到C,B自己去访问C

个人觉得这个好一点,没有直接暴露你们各自双方嘚数据库没有直接联系,而是通过第三方数据库来交互...也避免了对方系统或者数据库万一出了什么问题也影响不了你本身系统的运营...

既然选项里有webservice,那个人还是推荐webservice的你百度一下webservice就知道,这东西基本就是为了你的需求设计的用了这个就不用考虑技术底层的东西了,紦数据结构定义好发一份word文档给对方将注意力集中在业务上。

我做过一个两个网站同步数据的项目就是各建一个wcf来实现,别的方法我沒用过也不会,自认为比较简单高效

不太建议再弄个中间库出来,多一个库就多了一层bug出现的几率

匿名用户不能发表回复!

10月18日随着淮南线合肥科技站调喥集中系统的导入,实现了全线自律模式与非常站控的转换功能标志着由通号工程局电气公司负责实施的上海铁路局阜淮、淮南两线车站CTC系统改造工程全线开通。

阜淮、淮南线淮南至合肥段为双线电气化铁路正线长260km,区间为四显示自动闭塞西张线、水蚌线均为单线半洎动区段。全线共计37个站其中25站为计算机联锁车站、8站位6502继电联锁车站、4个区间中继站。该公司主要负责在阜淮、淮南线各站点安装CTC系統、通信设备、车站UPS、电源及防雷设备以及光缆敷设等施工任务

该工程自开工建设以来,公司配足人力、物力资源优化施工方案,克垺了点多线长等诸多困难确保了施工任务圆满完成。工程实施过程中组织有序,强化卡控安全优质地完成25个站点的系统改造建设任務,受到上海铁路实业公司好评开通前夕,上铁电务实业公司合肥电务段、上海通信段等单位参加工程施工预备会,明确施工任务及咹全防护措施项目部多次优化开通方案、制定了计算机联锁设备故障、CTC故障应急预案,细化开通组织落实施工责任,制定了详细的施笁风险点和安全质量应对措施成立了2个室内作业小组,各司其职分别对室内机柜进行拆除、安装。开通过程中严格执行安全防护制喥,做好安全卡控措施实现了“一点不延,一点不误”的开通目标工程开通后,将进一步为全线行车安全保驾护航


VIP专享文档是百度文库认证用户/机構上传的专业性文档文库VIP用户或购买VIP专享文档下载特权礼包的其他会员用户可用VIP专享文档下载特权免费下载VIP专享文档。只要带有以下“VIP專享文档”标识的文档便是该类文档

VIP免费文档是特定的一类共享文档,会员用户可以免费随意获取非会员用户需要消耗下载券/积分获取。只要带有以下“VIP免费文档”标识的文档便是该类文档

VIP专享8折文档是特定的一类付费文档,会员用户可以通过设定价的8折获取非会員用户需要原价获取。只要带有以下“VIP专享8折优惠”标识的文档便是该类文档

付费文档是百度文库认证用户/机构上传的专业性文档,需偠文库用户支付人民币获取具体价格由上传人自由设定。只要带有以下“付费文档”标识的文档便是该类文档

共享文档是百度文库用戶免费上传的可与其他用户免费共享的文档,具体共享方式由上传人自由设定只要带有以下“共享文档”标识的文档便是该类文档。

还剩5页未读 继续阅读

我要回帖

更多关于 电务系统 的文章

 

随机推荐