本文将全面介绍 ebXML,包括规范集主要目标的概述以及 ebXML 之所以存在的总体原因。除了总体概述之外,还将介绍有关消息传递层、注册、业务策略及 ebXML与XML Web services之间关系的一些细节。
ebXML 简介
为什么我们需要另一种 XML 语言呢?似乎每天都会开发出或批准新的 XML 标准。同时,又好像有一台巨型 XML机器在模仿业界或公共语言而创造着新语言。这种严酷的条件可能会引起某种不规则性,技术专家必须设法确定从过去所使用的遗留格式转移到新XML版本所产生的价值。当然,在维护健全性(sanity)和安全性时,必须已全部完成所有这些工作。
XML 语言这种不确定性部分是由于XML自身的简单性。XML无法独自实现多少功能,而且在某些方面还过于简单。必须在现有规范的基础上继续开发规范,将XML打造成为有用的东西。不少情况下,开发新 XML 语言仅因娱乐,似乎始终需要“XML化”每一种可能的计算格式或交互。
本简介的主要目标是使读者确信,ebXML并不只是对基于非XML EDI (Electronic Data Interchange) 的业务交互的格式的盲目更改。虽然ebXML早已被冠以“不过是另一种XML语言”的头衔,但事实上它对于业务而言有着重要的总体益处,这主要是由于其特殊的视角。
特殊业务的视角
ebXML锋芒最劲的功能之一是其实现特殊业务交互的能力。乍一看,特殊(ad hoc)这个术语会使人联想起自然灾害和意外事件等负面景象,但正是ebXML的该功能特性才使之对于经营电子商务而言功能尤为强大。
为了做一简单类比,设想在当地超市购买食品。假定您一直常从超市 A 购买食品。随着时间的推移,您基于其提供的商品和同意购买物品的流程(比如,与超市职员交互及使用ATM卡来进行购买)与该超市发展业务关系。虽然您与超市A有长久的关系,但您与超市的关系是临时的、是权宜之计。
设想现在新开一家商店,超市B,对于同一种商品它以更低的价格对外出售。当然,您最好与超市B开始发展新的业务关系,而且您可能会这样做,因为可以预计其业务流程和交互与超市A的没什么两样,也就是说您将用英语讲话以及可能使用ATM卡来进行交易。此处,这种业务关系的特殊本质是使自由市场经济运作起来;您可以轻松地放弃先前与超市A的关系并迅速与超市B建立新关系。
然而,通过 Internet 的电子商务另有基础设施的成本,该成本包括在经营业务的总价格之内。例如,如果安排两个业务进行电子交易,则必须付出筹备基础设施和软件的代价,而且还要使业务交互和策略规范化,包括充分的安全策略。
随着时间的推移,如果出现提供更低的商品和服务价格的新业务,则该交互模式和所需的技术将成为经济障碍。换言之,如果经营业务的成本包括沉重的基础设施和流程修改成本,则没有理由降低商品价格(如果最终不会遇到麻烦的话)。
例如,假定超市B只是稍稍压低价格,而超市的所有职员都讲不同的语言并只收两美元面值的现钞。在这种情况下,您经营业务所需的额外成本(例如,您学习语言以及手头上有合适的货币)可能会超过该价差。
ebXML的核心价值之一是其技术角度的宽广视野。它构建于XML、SOAP、HTTP及SMTP(所有这些都是比较容易进入的开放标准)之上。从理论上讲,关注技术广度会使电子商务接近于特殊自由市场的概念(我们在超市购物时都曾亲身体验过)。
XML Web 服务如何?
好像我已犯下了一个分类错误,在未提及XML Web服务或面向服务的架构的情况下而对SOAP和XML高谈阔论。然而,原来ebXML架构先于许多普通的XML Web服务标准,而不遵从大多数概念。了解XML Web服务和ebXML架构概念广度的一种简单方法是对以下三个术语进行重新整理:线、描述和发现。
第一个术语表示消息传输技术。对于XML Web服务和ebXML而言,都是SOAP,但相似之处仅此而已。XML Web服务有一个松散耦合的线堆栈,该堆栈由可靠传输 (WS-Reliability) 和 安全 (WS-Security) 的各个规范组成,而ebXML将所有这些功能都融入到自己的消息传递标准和ebMS中,从而使用混合技术。
对于描述和发现堆栈,XML Web服务分别使用Web Services Description Language (WSDL) 和UDDI。对于ebXML,这些描述和发现机制是ebXML注册的一部分;此外,ebXML还包含针对业务流程和协作的附加规范。
简而言之,ebXML是一个独立的规范集,具有内部一致性,而且不依赖于新兴标准和规范。
ebXML 概述
为了实现刚才所讨论的特殊视野,ebXML为业务交互提供一个完整的框架,全部是作为供应商中立规范集而交付的。该完整的框架设计用于答复大量的全盘业务问题。这些问题的观点针对指定的贸易合作伙伴来进行表述:
我如何描述自己的业务流程和特定接口呢?
我如何与其他合作伙伴共享自己的业务流程呢?
我如何得知自己的合作伙伴支持哪些业务流程呢?
我如何描述特殊交易的业务消息呢?
我如何描述要使用的安全策略和技术配置呢?
从理论上讲,如果贸易合作伙伴可以用这些术语描述其自身,则便可以进一步融入于临时的、电子的自由市场之中。这些问题中的许多可以通过实现共享的信息注册来解决,其中业务协议和流程可以集中。该中心点存储库称为ebXML注册。同时,还有实际线级消息传递层及业务流程规范和协作信息的规范。具体的ebXML规范集反映为如下概念:
集中的共享注册:Registry Information Model、Registry Services Specification (ebRIM、ebRS)
业务流程和协作:Business Process Specification Schema、Collaboration-Protocol Profile 和 Agreement Specification (ebBPSS、ebCPPA)
消息传递:Message Services Specification (ebMS)
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
松散耦合的七个级别
当ZapThink考虑做面向服务架构(SOA)的时候,我们通常要避免关于“什么是或者不是SOA” 语义的争论,但是侧重于确定面向服务系统的特性和提供机构采用的架构方法的益处。
-
SOA治理并非始于技术
在SOA的世界中,SOA治理的概念越来越得到注意。然而,SOA治理如何定义和执行实际上取决于SOA治理厂商。实际上,在考虑SOA治理的时候,混乱是个巨大的问题……
-
松散耦合的七个级别:服务策略和流程
发挥服务契约的作用,要抽象实施、后期绑定、使用媒介、基于注册的系统要在没有断裂的情况下,允许无破损服务契约的改变,使系统更大程度上变化……
-
利用原子性获取SOA颗粒度
那些无法被分解的流程便用来创建带有一定颗粒度的组合服务。对于和设计面向服务架构有关的语句,你读过几回呢?对于严格的原子性定义你又了解多少呢……