如何使用XML技术进行异构数据源的数据集成

[myelan]

对于结构化数据（关系数据，面向对象数据……）异构平台的
进行数据集成
是不是可以使用XML技术

对应的要了解哪些技术
如何能很快掌握

在sourceforge上有没有相应的软件

对于做这样的工作，有什么好的建议

[scalene]

问题一：你设想你的框架应用在什么领域？
问题二：你的XML中间件采用什么技术？对于客户端来说，作用是什么？

[congling]

有必要吗？我觉得不要因为XML而什么都使用Xml,这样做只会降低效率，如果你使用.NET，还不如直接写ADO.NET的Provider，如果使用Java也可以写JDBC的Provider, 我觉得更有意义。

[leimin]

to: congling(congling)
我觉得不要因为XML而什么都使用Xml,这样做只会降低效率???????
我觉得XML会提高效率，后台只要生成XML文档和商业逻辑，前台进行XML解析和显示。在网络传输中的包也比较小和安全，最后还可以实现跨平台的异构数据库的数据交换.....
优势太多了！
你说的MS .NET也是基于XML的数据交换的.

[K1933]

其实很多时候我觉得应该经JDBC之类的接口，因为XML无法完全实现如银行/制造企业等大型系统，因为XML的后台计算方式确实比关系型数据库较差点。
特别是一些大型的ERP系统中，很多处理方式你不能不用C/S架构，因为B/S方式相对来说会更慢。而C/S模块中对XML来说是比较困难的。

[congling]

to leimin(黄山光明顶):
我不认为Xml会提高效率，ADO.NET的SqlServer Provider以及ADSI的Provider 100%不是Xml去做的，我不明白你是说什么Provider是用XML进行数据交换的。

Xml多了编码和解码的工作，而二进制流相对而言简便多了，SQL Server2000支持（通过IIS发布）XQuery，你用它去测试一下，看看直接写SQL快还是所谓的XQuery快。
XML仅仅是做数据统一，效率绝对不高！
我觉得他的这种结构改成ADO.NET作为中间层，然后只要做一个HTML的Provider就可以了，而且效率远远比XML要高得多。

[congling]

XML传输数据数据量绝对不小，这是一个作为XML的缺点，搞不清楚为什么你会说XML传输数据量小，你相对什么而言啊？MSDN上有一片文章，讲Web Service和Remote接口的，他认为在局域网内部最好使用Remote接口，为的就是减少传输量

[zarz]

关注

[leimin]

TO：congling(congling)
Q1.
XML传输数据数据量绝对不小，这是一个作为XML的缺点，????
我有一个EXAMPLE:比如你作WEB开发，用户请求一个PAGE,如果是一般的方式，SERVER返回HEML,SCRIP,data scream,....,都要通过NETWOEK返回，而XML只是返回XML流，XML-->HTML的解析可以放到CLIENT。
如果你在本地一个人的TEST，可能发现XML还要慢，但如果USER一多就可以体现XML的优势了！。

[JollyFred]

xml还在不断的发展中，相信它会越来越完善。当然不能因为它的hot，而盲目去应用它，也不能因为它的一些弊端，去全盘否决它。每项技术都有它的长处和适用场所。
我觉得xml的最大好处，在于它定义了一种数据交互的标准，便于实现跨平台的应用系统，在同构的环境下的确它的效率不是特别高，但它数据自描述性的优势是二进制文件无法比拟的。

[leimin]

Q2.Xml多了编码和解码的工作，而二进制流相对而言简便多了，???
XML是电子商务，或一些商业数据交换的工具，并不是COMPUTER底层开发的平台，如果你开发一个适时监控软件当然是而二进制流相对而言简便多了，
请你不要偏离主题！！！

[gameboy999]

想做XQuery,去参考一下Ipedo数据库的实现吧

[jhliu500]

我覺得xml要用在需要的地方,如果純粹為了用它而用就沒有必要了

[myelan]

谢谢 gameboy999(C2Java) 、leimin(黄山光明顶) 、 congling(congling) 、 K1933(K1933) 、JollyFred(蝈蝈)
我重新考虑一下
以后再做讨论

给分了

[myelan]

请大家继续讨论
分不够，加

[careless]

xml是最理想的，这一点是肯定的。
但传递方式是个问题，如果我们的两个异构系统在远程，我们该如何选择消息传递系统来传递xml数据呢？用JMS吗？还是SOAP什么的？

[congling]

to leimin(黄山光明顶)：
你的第一个关点仅仅是比较了HTML，而实际和我说的根本不是同一个问题，而且有一个明显的漏洞--XML是不能代替Script的，很多东西需要客户端的支持，而XML特点是做数据的转化，但是目前的趋势Web部分更多人会将他做成是类App-Script类型，没有Script引擎是很难做的(要判断几个复杂耦合条件以及完成一些自动填充性质的工作，使用XSL语法不仅仅难看，而且很多逻辑是无法表示的），即使Microsoft没有弱化Script Engine的开发。

第二个关点你说对了，XML就应该用于商务应用上，最主要是B2B以及对不同系统的耦合。不过象他这样的系统是比较特殊的，XML中间件并非要耦合其他系统。
对于这个系统，中间件与客户端接口如果是分离的（非同机），应该使用XML，而后台接口我觉得使用ADO.NET或者JDBC比较适合。

毫无疑问前台必须建立一套XML的规范(Schema DTD)，包括输入输出。
如果按照我的想法： Wrapper SQL以及XML DBMS都可以使用ADO.NET去开发，根本不用写中间件，而唯一要写Provider的只有website wrappper,写这个Provider也有相应的规范（要知道定义一套完整的规范是不容易的），但是对于SQL的语法以及语义解释，网上还是比较多源码可以查考的(可以参照MySQL的实现）。

而如果后台使用XML，
1）你需要定义后台XML的规范，其中包括输入查询语句输出的结果的编码规范，使他能够容易作为插件插入你的系统
2) 你必须使用写对应的Provider，如果你统一使用XQuery，而后台数据库指定是SQLServer2000，那SQL Provider可以和IIS一起完成此项工作，不过效率甚低以至你可能要做优化；如果你使用Oracle也可以（不过接口兼容性是一个测试目标）。 我暂时不知道.NET是否支持XQuery的XML DBMS的查询，如果不支持，你要重写这一个Provider.至于WebSite，你一样要解释XQuery语法，因此XQuery的语法语义词法解释器是不可或缺的，但是这部分资料不多，而且不成熟。毕竟只有1-2年。


总上所诉，我认为还是写ADO.NET/JDBC的Provider比较适合

[congling]

还漏了一点，如果你使用XML作为后台，还需要写一个中间平台，来Dispatch/解释前台的语法以及后台的响应，如果你完全使用一种XML技术（例如XQuery），可能中间件工作会比较轻松

[congling]

to careless(深潭静水)：
如果使用XML，那么可以同一使用HTTP/XML的解决方案，毕竟这种解决方案外部耦合度较小（SOAP是其中一种解决方案）。因为这仅仅是使用POLL技术，没有必要使用JMS等消息系统。

[mem_fox]

我觉得设计上没有什么错误，我也是先把和核心数据从数库中直接转换成
DOM对象，然后用XPath操作，感觉还不错，不过Dom对象要是很多，再启动的时候就比较慢了，而且不停的做和数据库的同步也是满累的事情

[waveqi2002]

其实XML主要是一种标准，而非具体的某一具体的产品或者中间件产品

它的最大作用是提供一个面向应用的标准的数据定义，比如是各种电子商务系统、各种领域的综合查询系统，它最大的工作量是数据抽象和规范的定义，目前国际上这方面的探讨研究很多，成果也很多，比如是电力系统的各种资源描述等。

当然，XML本身的灵活性也支持用户自行定义数据格式，其实这样并非XML最适当的用法。

将来真正XML的应用产品，应该更好的研究国际标准，或者参与各种国际标准的定义当中，而非对同一个对象，今天你抽象一个数据模型，明天他抽象一个数据模型。这样其实和大家目前利用TCP/IP通讯一样，报文格式不一样，又有什么生命力呢？

我的意思是，大家少搞一些形式上的东西，研究的深一些，而非今天追这个潮流明天追那个潮流，这样中国软件肯定是永远在大家不停的追求一些表面上的东西，而慢慢失去自己真正的目标。

所以，即使是有些不清楚但赶时髦的用户提出一些华而不实的东西，我们供应商也要学会说不，更不能给用户加强渲染这样类似的“高新技术",实际上正是这种现象才导致中国软件一直是"虚"而"弱"的根本原因。要研究新技术，但更要以我为主。