webservice工作过程.doc

我们从一个应用看看Web Services是怎么运作的: 有一个咖啡连锁店的老板叫Coffee Break,要拓展自己销售的咖啡品种,他指示他的采购经理去寻找一些新的咖啡提供商,得到他们的咖啡全部价格,并且在需要时能够立即下订单,Coffee Break能够分析他们的价格,并决定选用哪一种咖啡,从哪个公司进货.询价采购经理就将具体任务分配给软件工程师,软件工程师认为寻找新的咖啡提供商的最好办法是搜索UDDI注册中心. ,Coffee Break在UDDI注册中心注册了自己. 软件工程师发出了一个查询所有咖啡提供商的指令也就是基于SOAP发送XML文本. UDDI注册中心接受了这个XML文本,并开始精确的搜索,但搜索完成后,注册中心将发回那些有关怎样联系那些符合条件的咖啡经销商的信息.也是基于SOAP发回XML文本. 工程师的下一步工作就是从这些分销商名单中列出他们的咖啡销售价格,这个工作分两步: 1.获取和分析WSDL文本(Services Description Language (WSDL) document).这也是一个XML文本,它给出了所有关于Web service的信息:告诉访问者自己提供哪些服务,服务内容是什么,怎样获取这些服务内容等. 2.工程师分析了WSDL文本后,得到了获取咖啡销售价格的方法和相应的网址.他就向那些具体的咖啡经销商网址发出请求,以获得其销售的咖啡价格. 每个咖啡分销商都会接受到这样的请求,在他发出销售价格之前,他也会先去查询一下产品的当前期货价格,这样Coffee Break就得到了最新的XML文本格式的咖啡价格.如下面: coffee 单价哥仑比亚咖啡19.20/哥仑比亚咖啡/单价 /coffee 分析价格并订购读取XML文本有两种方式:SAX和DOM,对于简单比价,使用SAX比DOM更有效率,但是如果要修改价格表,就要使用DOM,Coffee Break的工程师使用SAX比较了这些分销商发来的价格表,并得出了一张结果表,报送到采购经理或老板Coffee Break.一旦决定订购咖啡,也是通过发送XML文本和经销商联系. 通过Internet销售Coffee Break 已经准备好了新的咖啡品种,需要在他的网站上发布这个咖啡品种新的价格.Coffee Break当然不能以自己进货的价格销售咖啡,工程师就使用DOM修改了一下上面的XML文档,将每个价格乘125%,这就是Coffee Break的咖啡销售价格. 工程师使用JSP做了一个订单表单.在这个JSP程序里,他可以从上面修改后的XML文档中读取每个咖啡的名称和价格.顾客只要选择购买数量,然后按Submit就当前咖啡放入自己的购物车,开始了网上购物.Web Service是将XML文本在各个网站之间传送和接受,以达到信息交换的目的.在接受和传送时有一个协议,就是SOAP(Simple Object Access Protocol),这是个XML+http的协议.当前我们网站公布信息,都是通过http协议发送到用户的浏览器上,因此SOAP有广泛的应用基础,现在就差XML的普及. 不过,因为XML是纯粹的数据结构,但只有数据的互联网将倒退到学术科研时代,因此,类似Frontpage Dreamweaver基于XML的强大的页面设计工具是重要的,但是这样的可视化工具很难设计. 所以XML的普及有时间问题,那么Web Services提供的上述美好前景的真正实现,恐怕不是一两年内会达到的. 但是Web Services为专门从事互联网服务的公司带来的机会,因为他们的客户是一个个商业网站,因此,他们可以开发一个个商业应用,而不必将这些应用象普通软件一样安装在他们客户的服务器上,而是让他们的客户网站通过SOAP来调用这些软件功能,并支取一定的使用费. 对于作为客户的网站来说,购买了某个互联网服务,不必专门设立服务器,购买大量软件,还要维护他们,只要通过直接调用提供该功能的Web Services就可以，比如购物车功能，这是每个网上商店都必须的，但每个商家不一定去购买这个软件，只要在自己网页中直接调用网上商店的Web Services就可以。 但现在最致命的是Web Services的安全性。 Sun的Web Service:/webservices/docs/ea2/tutorial/index.html Open source的Web Service服务器,需Tomcat同时运行:/axis ―――――――――――――――――――――――――――――――――――― 我们从一个应用看看Web Services是怎么运作的: 有一个咖啡连锁店的老板叫Coffee Break,要拓展自己销售的咖啡品种,他指示他的采购经理去寻找一些新的咖