媒介
时期变了。
以往数据更多的经由历程人工录入，从专用收集协定的终端转移到“玻璃屋子”里的大铁盒子，如今信息无所不在、无时不在，不过不一定都邑汇总到您公司里，许多时刻人人是在一个“平”的天下里分享数据，信息泉源的渠道多了、信息本身的变化也更加频仍。不仅如此跟着Web 2.0、Enterprise 2.0和Internet Service Bus等一系列观点的涌现，您发明单单从本身的“玻璃屋子”里找供货商供应的堆栈地点远不如Google Map轻易。
彷佛以往镣铐数据的种种枷锁在互联网下被逐一突破，但作为IT从业者，我们的事情是为用户供应它们所需的数据和他们愿望猎取信息的手腕，因而运用必需能够经得起种种变化，包含以往我们体贴的用户界面的变化、运用间挪用的变化、运用内部逻辑的变化，另有步调愈来愈快但又是最根本变化——数据本身的变化。
关联模子通知我们要用二维表格形貌信息天下，但这是太“不”天然不过了，看看手边的一本书或是家里的装修设想、立时要完工项目的使命剖析，彷佛套到一个二维表格里总不合适，而且即使经由历程“实体——关联”僵硬的削足适履后，在疾速变化的环境下又老是要牵涉到“数据——运用——前端交互”一系列更改，而且经常是牵一发起满身。
彷佛许多新一代运用已找到了更适合新趋向的计划——XML，用一种更切近我们本身头脑的体式格局构造运用、构造用户体验。那末关于企业而言，构造数据这类相对基础性的事情是不是也能够用XML的头脑举行呢？应当能够。
应对数据实体本身的变化
数据实体以往老是被假设为运用中最为稳固的部份，不管我们用设想情势照样采纳种种开源的开辟框架（包含这些框架本身）都是只管在顺应运用本身变化的题目，那末现实的状况怎样呢？
l 我们须要交换的数据实体经常要依据本身、合作方的须要变化；
l 合作方给我们的数据实体也经常变化；
l 跟着SOA和Enterprise 2.0观点的推出，数据实体本身从多个源mash up出来，同时数据实体本身也被重复的拼装和组合；
l 跟着营业的细化，我们本身的员工老是愿望猎取愈来愈雄厚，同时也愈来愈详实的信息；
因而，以往视需求也好、设想也好以为能够最早牢固下来的数据实体在愈发迅速的手艺和营业近况前须要不停调解。为了顺应这个请求我们能够自顶向下入手，不停调解运用本身的柔性；另一个体式格局是从“根”上处置惩罚这个题目，采纳本身就能够不停顺应这些变化的新数据模子，比方：XML数据模子和XML相干手艺家属。
比方，定义用户实体的时刻，最初下面的信息就够了，个中ICustomer是运用会运用的用户接口，而CUSTOMER为关联数据库体式格局下的示意，<Customer>为XML体式格局：
不过紧接着我们就发明这个实体设想有些题目，因为还要增添用户的办公室电话、室庐电话，另有能够1、2个电子邮件，他的MSN或Skype号码等。不斟酌其他题目，仅仅从关联模子范1的请求，那末RDBMS和XML两个模子生长的效果就成了：
不难看出，虽然仅仅只是“客户”数据实体小节“联络信息”的一个变化，关联模子和XML模子在顺应性方面就有异常大的区分，关联模子须要不停扩大出新的关联用来形貌不停细化的数据实体，而XML模子本身的条理性能够供应变化条件下，本身的不停延长和扩大。现实项目中，“学历状况”、“事情经验状况”等信息也存在相似的题目，关联模子下即使某位客户愿望把某阶段事情状况的“借调”体式格局补充进去，也会发明因为设想上没有预留相应的字段，因而只好把它作为字符串“揉”在“事情单位”字段里，背面补充个“（借调）”，这即是僵化的数据模子本身抹杀了数据的营业语义中包含的信息；而条理模子能够把它作为一个子节点或属性来形貌，如许不仅能够把关联模子下须要多个关联（客户、学历状况、事情经验、联络信息）集合在一个数据实体内部，而且能够把每一个实体本身的扩大信息（比方“事情况式”：借调、交换、短时间集合）等也形貌在数据实体内部，同时从外部运用看“客户”实体本身依旧是一个实体，如许用更切近现实营业情况的数据实体才更有用的顺应外部变化。
上面我们议论的仅仅是一个数据实体，进一步生长到细致营业范畴模子模子的时刻，每每须要同时综合多个数据实体合作完成营业功用，这时刻情况又怎样呢？比方：保单须要客户供应除了上述信息外的个人康健信息，后代、父母、伴侣家庭重要成员信息，同时会从其他从业机构猎取用户的信用信息等，而且差别的数据实体组合重要用于企业内部的各别的运用范畴，因而从数据运用角度看为了只管让运用部份稳固，最好是数据实体稳固，但仅仅用户信息的联络体式格局部份就能够会重复的变化，假如让运用完整依靠这些变化要素组合后的效果，那末运用的稳固性确切难以保证，那末从泉源上第一步先只管保证差别运用只管仅依靠于细致一个实体或许是有用革新的第一步，这时刻XML的条理特性上风又显示出来了，比方我们能够依据差别的运用主题，自由组合这些信息：
如许运用面临的就是一个一致的<info>实体，相应的采纳专用的XML手艺能够保证运用框架稳定的状况下，新的营业能够动态相应变化的数据实体。
应对数据和内容的集成
上面提的数据实体更多是在一个已集合后的语境下议论的，但除了观点上的设想外，运用中另有一个细致的题目就是怎样怎样把他们“群集”到一同，这个平常经由历程数据集成完成。
（不过就像“架构”一词被过分滥用一样，“数据集成”一样被各个厂家依据本身的产物特性被定义成差别观点的组合，比方BI厂商力争把它描绘成ETL的代名词、供应数据交换平台的厂商形貌为完成BizTalk Framework的产物、关于SOA产物公司而言，数据集成则更多在于怎样保证在有用治理的条件下供应数据效劳，别的关于一些厂商罢了，数据集成还包含营业语义组合等。）
但作为用户，数据集成我们要偏重体贴什么题目呢？
l 数据实体的映照关联；
l 数据源的在种种交换协定、行业数据规范、平安掌握束缚下的互联；
l 数据交换历程的编排；
l 数据实体的考证和重构；
l 数据介质、数据载体的转换；
虽然理论上这些事情用编码完成不成题目，但跟着企业集成逻辑愈来愈庞杂且变化愈来愈快，修正代码即使能够敷衍一下1：N的集成，但假如经常是M：N的状况，那末就显得力不从心了。是不是能够有更简化的方法呢？仅从“映照”的逻辑条理说：
l 面向对象头脑通知我们依靠颠倒，要只管依靠于笼统而不是细致，比方依靠于接口而非实体范例；
l 设想情势通知我们，不兼容接口间适配器（Adapter）是个不错的门路；
那末数据范畴是不是也有相似的手艺呢？XML Schema + XSLT或许就是个挑选。
上面是为了兼容新、老用户实体做的转换，一样的假如须要举行上部份针对差别主体的数据实体聚合操纵也完整能够借助在笼统数据定义（Schema）条理经由历程XSLT（Schema间的适配关联）完成。
如许，我们能够在数据实体条理看到数据是怎样聚合在一同的，但之前还须要处理一个题目：车辆信息、信用信息另有遗留系统的客户信息都是离别保存在关联数据库和合作方的Web Service中，怎样连接起这个数据渠道呢？从如今看XML照样不错的挑选。
差别数据介质上的数据能够以他们根源的情势提取，比方平文本、关联数据库、EDI报文或者是SOAP音讯，经由历程差别的信息渠道通报到数据集成的会聚点，然后依据目的数据源的须要，经由历程一个适配器转换异构的数据源。
这时刻假如为每两种范例都设想一个点对点的适配器，团体范围将沿着N^2级的趋向生长，为此无妨先把他们一致为兼容这些信息的XML，然后用上面引见的XSLT手艺举行数据实体间的映照后，接着把XML再转换成目的数据源所需的情势，如许悉数适配系统庞杂度降为N级。
接着，我们看看XML手艺怎样满足只条件的那些数据集成请求：
l 数据实体的映照、数据介质、数据载体的转换、数据实体的考证和重构：
如上，先把数据一致转换为XML，然后经由历程XML条理型上风，连系XML专用手艺举行处置惩罚。
l 数据源的在种种交换协定、行业数据规范、平安掌握束缚下的互联；
XML数据不仅能够逾越收集、防火墙，而且能够很轻易的用于互联网环境（，不过您依旧能够用音讯行列体式格局把他们定义为报文），数据本身不会因为特别的二进制操纵须要遭到交换协定的限定。当前，各个行业规范基本上都在运用XML形貌本身的行业DM（Data Modal），即使您企业内部的系统本身数据实体因为数据库设想、汗青遗留等题目，本身不是相符这些DM的数据，但种种XML数据一致治理的协定和规范能够比较轻易的完成转换。关于平安性，彷佛另有没比基于WS-*相干协定更适合于互联网环境下的平安规范家属，个中一切的规范无一例外都能够用XML实体定义数据和分外平安机制间的组合关联。
l 数据交换历程的编排；
关于同构系统环境，或者是仅仅基于兼容中间件系统的平台，能够采纳遗留的事情流机制完成数据交换历程的编排，但为了顺应效劳化的时期，能够采纳更通用的BPEL规范，此时XML不仅仅是数据，同时他也作为实行指令的形状涌现，相比较一向标榜跨平台的Java手艺而言，采纳XML定义的交换历程更是跨言语的。
彷佛集成已处理了很大的题目，但一个不言而喻的题目是一切的事情我们能够都要本身做一些完成，一步步通知运用怎么做，那末当我们不再把Web仅仅当做“新颖事物”，而把它斟酌成一个效劳于我们信息内容，而且能够交互的系统时，怎样把这些散落的效劳才能呈递给我们本身呢？这时刻或许XML开放的元数据定义的上风才真正表现出来。
应对语义收集的庞杂性
撤除种种语义算法之外，怎样让疏散的种种繁多的效劳聚合在一同为我们供应效劳，个中XML一个异常症结的要素就是找到数据线索的骨干，而且明白这条骨干上实体间的关联关联及其逐渐剖析细化的历程。这个条理的数据不仅是被动由运用挪用的对象，他们本身为运用共了进一步揣摸的支撑。比方：
这里起首运用相识到当前处置惩罚的这个对象是鹅肉，因为鹅肉是一种黑肉，而黑肉是某种禽肉（fowl），禽肉能够食用，因而运用能够逐渐揣摸鹅肉能够食用。上面的揣摸历程并不庞杂，但假如用关联数据库完成却相对比较庞杂，用平文本誊写那就更难于完成了，试想一下假如同时把禽肉与蔬菜、甜点、海产物间的关联悉数用关联数据库或文本誊写，那实在太“难为”运用了。而XML差别，它能够很天然的切近我们头脑的习气，以一种开放但又交错的方法形貌我们熟习的语义，不管是企业ERP环境的生产材料预备历程，照样为了一次生日Party预备本身下厨的采购设想，亦然。
小结
或许受限于二维格子的束缚太久，我们关于运用的设想和主意愈来愈镣铐于计算机的处置惩罚本身，但跟着营业环境的变化，从营业需求发作到运用完成并上线的距离更加急促，我们要更多把本身的头脑从新从计算机中抽返来，这时刻采纳一种更开放并切近我们发散型头脑的数据手艺彷佛更可取。关于数据落地后的构造，我们能够继承采纳种种成熟的手艺完成，但在更切近营业的层面、切近这类更易变的环境下，彷佛XML柔性和力道都不错。
以上就是细致引见运用XML化的头脑构造数据（图）的细致内容，更多请关注ki4网别的相干文章！
