Kirstan Vandersluis是Xaware公司的创建者和首席科学家，是开放源数据集成供应商，他为建立数据服务层提供工具，其工作主要是关于为面向服务架构(SOA)应用，创建数据服务混合，本月在JavaOne会议上，在同SearchSOA.com网站的访谈中，他解释到，数据服务mashups和XML一样也是一种标准。

　　你能解释一下什么是数据服务mashups吗？

把许多资源中的数据放到一个逻辑单位中，就是一个数据服务mashups。所以数据的方式同样也是一种mashups。这是完全不同的球类游戏，我们将虚拟世界的任何地方的数据放入逻辑单位。并且正试图获取一束末端数据系统，这些系统非常复杂，按照XML模式，该系统更加合理化，有些人将一些理念注入到设计中。

当你获得了所有的数据资源，你最终会将这些数据放入何种业务功能中呢？

　　最后，你将拥有一个和模式相匹配的XML数据集，你可以调用服务从根本上取回数据。

　　你能举一个类似旅游公司的例子么?

　　对于一个旅游公司来说，你可能对客户针对旅游史提出的不同观点很感兴趣。所以，网站需要信息。这就是我们没有涉及的GUI块。前端应用会提出要求：“获取用户意图。这里有用户ID”于是数据mashups就成了来自许多资源的数据组合。在这里有一个CRM系统，因此我们要在CRM系统中查看基本的客户文件。我们要进入旅游管理系统获取旅游历史。如果数据返回，可能会有一些粗格式，这也许是来自CRM或者API的直接文件，旅游管理系统可能是一个主框架，这些数据会依次返回。然后这些粗数据被自动的转化为XML数据集。这些数据集被连到了更大的用户意图结构上。并将其返回应用程序。

　　在数据服务mashups有那些比较么，我们可以对这些数据库和数据市场做些什么？

　　这是我们做事的另一种方式，一种物物交换。我们肯定不是在说我们正在取代数据库。你可以在一个小的应用中使用它。这个方法带来的一个好处就是所有一切都是实时的。实时的将一个子要求传递到任意一个系统。可以一定程度上将数据库技术融入到你的数据服务mashups中。你可以直接查询操作系统。这在一定程度上是由应用程序的要求所驱使的。如果你需要实时数据，我们就有。成为一个抽取层也很好，因为你可以依照模式建立自己的应用。这样你就可以随着时间的推移做出变化，而不会影响到程序。应用程序依赖XML模式规定的合同。所以如果你一开始你将所有的数据服务都指向你的数据库，过后你就会发现那并不是实时的，你可以改变正在混合起来的数据集，因此其中的一个可能干扰了一个操作数据源。

　　你会如何描述那些使用工具的人的工作？它是一个数据架构么？谁真正在做这项工作？

　　通常，它要么是一个数据设计师，要么是一个Java开发商，或者是一个熟悉数据的人。当然数据源是有比例关系的，任何数据设计师或者数据库管理员在这种情况下都是很舒服的，，也许那是一个Java开发商，一个数据设计师经常是典型的情况。

　　你是在典型的数据设计师的工具箱中找到这些技能组的么?

　　是的，我在那里找到了。一般来说，我在人们那里得到了良好的反馈。我们从数据设计师那里得到很好的反馈，因为它是视觉化的。当我们可以使用元数据时， 我们就将其曝光。这只不过是个拉住鼠标的拖放问题。所以我认为，这完全在他们的技能可以解决的范围内，这比我们以前做的要好的多。

　　你认为业务方的人们理解数据服务么？当你和他们交谈时，他们意识到数据服务的价值了么？

　　我认为二者是不可调和的。有些人做到了，有些人做不到，我必须要说大多数人没做到，我认为这更主要的是他们理解面向服务架构的问题，这是他们使用数据服务层的典型例子。在一定程度上，他们引进了面向服务架构，他们就理解了数据服务层。我要说他们大多数并不理解。有些经常和商务人士打交道的客户把大量的精力投入到将业务方参与到SOA战略中，但是他们的速度太慢，以致成果并不明显。

　　我们在SOA中的数据服务的采用程度如何？你有没有从中获利或者发现一些真实的应用程序？

　　数据服务的采用肯定在增长，我们已经有了50,000下载量。这仅仅是在我们有了GA产品之后过去两个月的下载量。当然人们不会在在两个月的时间里将理论付诸实践。从某种程度来说一切还为时太早，但是我相信数据设计师和开发商在SOA方面是理解的。数据服务层应用的另一更为广阔的领域就是丰富的网络应用方面。在这个领域，使用Ajax的屏蔽部分被服务所迁移。从数据的颗粒性角度来说，这确实是一个不同的领域。在该领域中你需要高度的粒状数据和许多服务，而不是最终会被业务和服务所驱动并且被业务所规定的SOA方面。这就导致你只有一些粗研磨的服务，但是我看到它在两个领域都有增长。

　　这就是我们要令其更加成熟的数据服务标准，有你需要的标准么？

　　我们的世界主要是以XML模式为中心。这是关键的标准，建立和XML模式相适应的数据类型。这还有一些关于服务调用的标准：WSDL和SOAP标准以及REST。

　　那些类似保险业ACORD为特定行业量身订做的标准如何，这些标准足够成熟么？

　　我认为ACORD发展状况良好。保险业比其它行业采用XML 和XML 模式都要多并且时间更长。在XML公布之后不久他们就开始研究ACORD，由于行业的不同，成熟的程度也不相同，但是保险业发展尤为成熟。

　　考虑到你对XML的关注，XML的数据十分整齐，在你做数据服务时会因为机构没有一直遵循标准而碰到问题么？

　　从标准的角度来说，它是十分整齐的。你会在用户想要应用标准的用户化过程中遇到问题。ACORD是我们尤其需要考虑的一个标准。每一个主要信息组都有一个为用户设计的扩展区域。当然，你越将其用户化，你就增加了无法和其它公司配合操作的风险。从标准的角度来说，XML非常整齐，但是在有配合操作性的地方肯定有用户化。这些都是人们在设计应用时需要考虑的因素。

　　当我们跨行业使用这些程序时，例如我们需要从保险业、金融业和医疗行业获取数据时，会遇到问题吗？

　　不会。你可以创建和任何模式相匹配的服务。该服务可以是翻译成数据服务模式中任何一个一个模式。

　　在数据服务开发中能够产生问题的最坏的实践是？

　　不合适的XML设计就是个问题。有时人们甚至没有设计出一个模式。当他们开始设计XML实例时，并没有将其按照逻辑组织。这就使得他们不得不在整个设计周期不断的做出改变。如果你的机构设计不是很合理，就会遇到再处理后端系统的麻烦。在你的逻辑视图和真正的物理结构之间，总会有阻抗失配。所以，你可以在保证自己的逻辑结构是合理的，你就能够避免这些麻烦。