实战Web服务

  框架结构web service: 实战Web服务 实质： 案例需要刻画 运用的体例框架结构 catalog service order service feedback service 交互，交互些什么? 干什么采用鉴于web效劳的处置计划? 什么是须要公然的? 参考材料 作家简介 关系实质： 鉴于web效劳的运用、处置计划和开拓平台 什么是web效劳? 干什么须要web效劳? 动静电子商务形式 柴晓路 (fennivel@uddi-china.org)chief system architect2001年8月14阿曼文是框架结构web效劳的系列作品的第四篇，继商量了web效劳的贸易需要，本领设置和本领典型以及现有现有的web效劳试验之后，经过运用一个简直的案例发端对web服求实战的篇章。在正文中给出了一个本质的具备适用性而且不妨蔓延出去的计划机产物买卖商场的案例，经过扼要的体例领会、模块分别，对涣散体例间待调换的数据举行了界分，同声为设置鉴于web效劳的api的数据构造奠定了体例和领会的普通。在先前的作品系列内里，我仍旧对web效劳的贸易需要、web效劳的本领实行以及web效劳暂时的运用以及开拓东西做了所有的引见，那么在接下来的作品中，我将贯串一个范例来精细地刻画怎样真实地筹备、安排和创造一个web效劳的简直运用。正文所援用的资源重要囊括两类，一类是web效劳的本领资源网站，包括了洪量web效劳的本领消息，另一类是web效劳“stack"系列本领典型，她们是一个完全的本领体制，囊括uddi、soap、wsdl、xml等。正文的结果给出了那些资源的链接，有爱好的读者群不妨经过那些资源链接找到所需的实质。案例需要刻画在这边咱们假如运用后台是一个计划机产物出卖商场，个中的脚色及其对应的动作刻画如次：计划机产物买卖商场，该商场是接洽计划机产物消费商/零卖商与耗费者之间的经营销售平台。其工作和功效囊括：搜集并颁布来自各个计划机产物消费商/零卖商的产物目次；接收耗费者的购置乞求并真实地寄递给消费商/零卖商体例实行购置工作；搜集来自耗费者的耗费反应，给出商品购置的扶引倡导，并传递给消费商/零卖商。 消费商/零卖商，这是径直出卖计划机产物的商家，他不妨经过本人的web颁布产物目次，同声也能将目次传递给计划机产物买卖商场。他不妨接收订单(来自本人的web网站大概来自计划机产物买卖商场)并转入里面处置体例，至于资本流和物流则由离线体例实行。 耗费者，计划机产物的购置者(大概是部分，也大概是企业)，他不妨考察计划机产物目次，不妨运用在线的定购效劳举行购置。 经过对之上脚色及其动作的领会，咱们觉得在最后的实行体例中该当有如许几种大纲档次上的东西：产物目次，产物目次由消费商/零卖商爆发，由计划机产物买卖商场汇总归类，由耗费者欣赏运用。 订单，订单由耗费者天生，由计划机产物买卖商场传播，由消费商/零卖商接收。 反应消息，由耗费者爆发，由计划机产物买卖商场汇总归类，由耗费者和消费商/零卖商运用。 用户，用户分两类，一类是耗费者用户，一类是消费商/零卖商用户，辨别用来处置两类工作。 运用的体例框架结构归纳上头的领会，咱们不妨将所有体例按如次框架结构分别：figure 1. 体例分别大纲 大师大概会创造，marketplace system和retailer system这两个体例没什么大辨别嘛? 简直是如许，咱们在安排的功夫该当无时无刻不许忘怀"重用"这个观念，重用的组件越多，开拓的价格就越少，保护的价格也越低，可扩充性也就越好，固然重用不许引导功效的变化，这也是咱们须要提防的。底下我花一点篇幅略微领会一下框架中的三个重要效劳：catalog service、order service和feedback service。catalog service对于这个效劳而言，retailer system中的catalog service该当是marketplace system功效的子集。retailer system中，catalog service该当完备如次功效：类型(category)处置，囊括减少一个category、简略一个category、窜改一个category等；产物(product)处置，囊括减少一个product、简略一个product、窜改一个product、挪动一个product(从一个category下挪动到另一个category下)等；数据调换，囊括单个类型下一切产物的导出导出(import/export)，单个产物数据的导出导出，所有类型树的导出导出等；数据备份，所有目次下一切产物数据的备份/回复等。而marketplace system中，须要减少一个功效：在数据调换和数据备份模块该当供给对指定命据具有者的关系数据的操纵，比方导出某个类型下ibm的一切产物之类。order service对于这个效劳而言，retailer system中的order service和marketplace system中的order service不妨说基础没有什么实质上的分辨。她们都将完备如次功效：接收订单 向其余接收订单的效劳发送订单 两者的辨别，只是在乎retailer system中的order service接收的订单来私用户界面，而须要向marketplace system中的order service传递。marketplace system中的order service接收的订单来自retailer system中的order service，而须要向本人里面的企业运用传递订单。feedback service对于feedback service而言，在两个体例中的位置与catalog service是一致的。反应消息(feedback)处置，囊括减少一条反应消息、简略一条反应消息、窜改一条反应消息等，反应消息不妨挂在category下，也不妨挂在product下(有对准一类产物的评测汇报，也有对准一个产物的运用评介等)； 数据调换，囊括与单个类型关系或与单个产物关系的反应消息的导出导出(import/export)，以及与单个用户(retailer用户，数据具有者)关系的一切反应消息的导出导出等； feedback不妨看作是与所有产物目次树的各个结点关系联的指摘作品。不只在marketplace体例中由耗费者颁布并归耗费者查问，同声也将在关系的retailer体例生存并可供retailer运用。交互，交互些什么?咱们将之上功效刻画加以归纳，去除里面实行的局部，咱们不妨发此刻internet上须要传输的数据的论理视图如次：figure 1. 数据实业联系图 个中黄色的三个实业实足不妨看成是一个树状的消息目次，个中有三个档次的结点：category，product和feedback，category的子结点不妨是category、product和feedback，而product的子节点只能是feedback，所有目次树的根结点是category。而对于每个product而言，都有一个数据具有者，这个数据具有者该当是marketplace中的一个retailer帐号。另一类实业是订单，对于一张订单而言，将不妨包括多个product的定购记载，以及定购东西：某个retailer。在体例之间交互数据是交互的第一档次：数据调换，但是对于web效劳而言，光光罕见据调换是不够的，该当供给更高档次：效劳集成的扶助。所以，交互的实质不只囊括互订交互的数据，同声该当包括对数据的操纵(比方数据乞求，数据增添，数据革新之类)。那些常常会对应与效劳端的一个处置模块。不管是对数据的操纵，仍旧数据自己，为了在体例与体例之间举行交互，更加是异构平台之间，咱们须要将一切的操纵(效劳挪用)和操纵的数据(效劳挪用的参数和归来值)举行典型化的刻画，产生典型文书档案后颁布以供一切须要介入互操纵的系全部同按照。干什么采用鉴于web效劳的处置计划?我在前方仍旧就干什么电子商务须要web效劳作了发端的阐明。电子商务须要解脱独力处置计划的实行形式，须要唾弃搀杂体例贯穿的实行本领。一个灵验的电子商务运用一致不该当是只是鉴于步调员以及那些搀杂的代码的。对于电子商务而言，保守的由步调员主宰的由里向外的开拓形式该当被由用户主宰的由外向里的开拓形式代替。繁杂的串行的开拓轮回该当被立即的，赶快的运用安装所代替。同声如许的运用该当天才就完备高可定制性。即使商量其贸易实质，这是来自过程功夫检验的贸易本领观念："立即创造"以及"范围可舒卷"等观念，咱们须要做的即是将保守的贸易观念蔓延到电子商务中去。经过运用web效劳，企业不妨往日所不大概的办法经过笼统和搀和将自己的电子商务组件化。当一个企业的中心比赛力被组件化之后，那么那些中心比赛力就不妨很简单地在各别的企业之间共享，同声框架结构跨企业的电子商务运用，产生商务web。在咱们的这个计划机产物出卖搜集运用中，咱们不妨预示到各别的出卖商沿用的体例很大概是五花八门的，有鉴于windows/iis的web运用，有鉴于java platform的web运用，也有鉴于windows平台的桌面运用，也有大概是鉴于unix的erp运用局部，要兼容那么多品种的运用，用普遍的集成本领很难满意一切场所的须要。纵然满意了，当有其余想介入这个体制的新的retailer展示的功夫，相互的集成价格也是没辙先见的。而经过颁布预先设置好的可扩充的效劳考察典型，使得那些须要集成入体制的retailer体例都不妨以一种简单地规范的办法加入。大师大概会说retailer体例不也是咱们来开拓的么？是的，一局部，以至大概是很大学一年级局部retailer体例大概用的都是与marketplace体例同构的平台，并且只然而是效劳模块少了几块罢了。但是，咱们是处在internet的盛开互联的期间，对于marketplace来说，越多的retailer的加入就代办着更多的商业机械，marketplace的经营者确定会想尽方法罗致，集成更多的retailer体例，那么与其每展示一个异构的retailer体例就要应用人工物力与其举行单点集成的名目开拓，不如拟订一种典型，使得那些新介入的retailer不妨按照那些典型自决地介入体例。marketplace同样完备海纳百川的本领，同声又不必指数倍地加入开拓价格。同声即使该典型变成一种大众接收的典型的话，其余的兼容该规范的marketplace同样也不妨展示，而按照该典型的retailer体例则不妨普遍地以极低的价格接入到一切兼容该典型的marketplace中去，赢得更多的出卖时机和渠道。以至依照典型来实行，retailer体例之间还能实行低价格的平等互联。不妨说，按照典型的鉴于web效劳的效劳集成是真实的依照internet的盛开互联观念的internet期间的效劳集成的办法。什么是须要公然的?咱们仍旧提出咱们须要公然的是挪用典型，那么挪用典型该怎样设置呢，即使大师在本专栏先前的对于uddi的作品中伴随我略微接洽了一下uddi典型的话，那么基础不妨领会对于web效劳而言(uddi registry即是一种规范的web效劳)，典型设置不妨分为两局部:programmer's api：这是一致保守含意的api设置，然而装载的介质是soap message，也即是说programmer's api是一组soap api，各别的api用来实行各别的效劳挪用，在这局部中须要设置各别的soap api的动作和实行的挪用/相应的功效刻画； data structure：这局部设置了在soap动静中传输的参数/数据和相应数据的xml形式，这局部为每个api弥补的动静方法，同声为最后的api处置供给了数据层领会/包装的典型。 在反面的作品中，我草率正文关心的这个demo case，一步一步地报告怎样设置programmer's api和data structure。参考材料web service 本领/指摘网站 uddi-china.org, 以uddi为主的web效劳本领网站。 webservices.org, web效劳的归纳类本领网站。 ibm developerworks/web service zone, ibm的web效劳本领资源重心 msdn online web services developer resources, microsoft的web效劳的开拓者资源网站 itpapers/web service, itpapers的web效劳指摘作品 处置b2b电子商务运用交互和集成的interop stack系列本领规范典型 uddi实行白皮书, uddi-china.org, uddi.org uddi本领白皮书, uddi-china.org, uddi.org uddi步调员api典型, uddi-china.org, uddi.org uddi数据构造参考, uddi-china.org, uddi.org web service description language (wsdl) 1.0, ibm, 25 sep 2000 soap: simple object access protocol specification 1.1, ibm, microsoft, developmentor, 2000 extensible markup language (xml) 1.0 (second edition), w3c, 6 oct 2000 作家简介 柴晓路: 上海得易电子商务本领有限公司(dealeasy)首席体例框架结构师、xml本领参谋。uddi-china.org蓝色火苗处事室(blue blaze studio)分子。uddi advisor group分子，wsui working group分子。2000年获复旦大学大学计划机科学硕士学位，曾在国际计划机科学学术聚会(icsc)、亚太地区区xml本领商量会(xml asia/pacific'99)、华夏xml本领商量会(北京)、计划机科假期刊等各类国际、海内要害聚会与期刊上公布舆论多篇。擅长于鉴于xml的体例集成和数据调换的本领接洽，同声对数据库、面向东西本领及cscw等本领比拟长于。