由于这些web服务暴露于网络并且分布于不同的网络，所以它们很容易受到风险和安全威胁，从而影响基于它们的进程。因此，web服务或API测试非常有必要，可以确保它们执行正确并正确地响应查询。

市场上有不少商业和开源的测试工具可用于测试它们的连通性，响应性和性能。这些测试工具自动地为特定场景如功能测试，负荷测试，性能测试等执行测试。以下工具不按任何特定顺序排列。

以下就是你必须为你的API或Web服务测试需求考虑的12个伟大的web服务测试工具：

1.SoapUI

SoapUI是一个开源的，跨平台的测试工具。它可以自动操作功能、回归、合规以及SOAP和REST web服务的负载测试。它配备了一个易于使用的图形界面，并支持行业领先的技术和标准，以模拟和鼓励web服务的行为。

主要特征

• 以一种Project、TestSuite、TestCase或LoadTest水平提供可打印，可导出，和基于HTML的报告。
• 自带集成Hudson、Bamboo、Maven、ANT和JUnit。
• 允许开发自己的一套功能作为SoapUI插件。
• 记录、监视和显示所有数据。
• 支持WS-Security和SSL解密。

官方网站：https://www.soapui.org/

2.TestingWhiz

TestingWhiz是一种无编码测试自动化工具，自带API / web服务测试能力。它可以让你执行功能、回归、合规，以及基于HTTP和FTP通过WSDL接口的REST和SOAP web服务的负载测试和模拟。它也允许我们进行拒绝服务和渗透检查，以确保web服务的整体健康。此外，它还可以让你执行从端到端的测试，从Web UI，业务逻辑，到数据库和ETL，而无需编码。

• 支持字符串比较来验证API响应。
• 通过集成的bug跟踪工具，如JIRA，Mantis和FogBugz来帮助记录API缺陷。
• 用一个收发邮件设施生成可视化的日志和测试执行报告。
• 允许跨越多台机器和节点的分布式并行执行。
• 用Jenkins、Bamboo & Hudson提供持续集成。
• 支持数据驱动和关键字驱动测试。

官方网站：http://www.testing-whiz.com/

3.SOAPSonar

SOAPSonar为HTML、XML、SOAP、REST和JSON提供了全面的web服务测试。它通过对OASIS和W3C标准的开箱即用提供了功能、性能、合规性、互操作性和安全测试。

• 用XSD-mutation支持漏洞测试。
• 提供全面的WSDL和Schema解析。
• 用行为建模和多路同时负载事务来执行负载测试。
• 提供XML，DOC，XLS，PDF，RTF和RPT格式的报告。
• 与HP质量中心集成。

官方网站：http://www.crosschecknet.com/products/soapsonar.php

4.SOAtest

SOAtest是利用Parasoft测试验证API和API驱动应用程序的一个企业级工具。它对功能单元，集成，安全性，仿真，模拟，合规以及技术，如REST、JSON、MQ、JMS、TIBCO、HTTP和XML的负载测试提供了强健的支持。

• 提供端到端的测试。
• 支持120+协议/消息类型。
• 自带一个易于使用的界面。
• 帮助创建复杂，可扩展和可重用的测试，而无需编码。
• 支持连续集成测试。

官方网站：https://www.parasoft.com/product/soatest/

5.TestMaker

TestMaker是一个开源工具，通过PushToTest来测试和监测web，web服务和SOA应用程序的性能。它运行在Jython（用Java编写的Python）上。TestMaker可以重用Selenium测试，SoapUI测试，Sahi公司测试或任何用Groovy，Java，Python，PHP，Ruby和Perl写的测试到功能，负载和性能测试中。

• 对于功能、负载和性能测试使用命令行提示。
• 用标准的多窗口IDE提供一种直观的外观和感受。
• 提供一个监测仪表板来运行测试，并显示实时结果。
• 归功于Jython语言，因此允许访问所有的Java库和类。

官方网站：http://www.pushtotest.com/testmaker-open-source-testing

6.Postman

Postman是另一个API / web服务测试工具，它自带功能强大的HTTP客户端支持。它有一个易于使用的请求构建器，允许你编写测试用例和管理响应数据和响应时间，以便于API测试用例的高效测试和管理。

• 允许在一个叫Postman Collections的功能中收集和组织API。
• 促进协作和API数据以及团队控制的共享。
• 自带粘贴文本的功能，用于在命令行窗口创建无障碍测试。
• 允许在Postman界面内编写Boolean测试。

官方网站：https://www.getpostman.com/

7.vRest

vRest是一个专门用于测试，模拟，以及REST API和Web服务验证的工具。它还支持与第三方API或HTTP服务交互的web，移动和桌面应用程序的测试。

• 自带一个模拟服务器功能，可用于在几分钟内创建API模拟。
• 提供了一个Chrome扩展来录制和播放测试案例。
• 支持与用于服务器整合的Jenkins整合，以及与用于bug跟踪的Jira整合。
• 有利于角色和权限管理。
• 允许导出和引入测试用例和来自于外部工具，如Postman Collections、Swagger 2等的报告。

官方网站：https://vrest.io/

8.HttpMaster

HttpMaster是另一个用于REST web服务测试的专用工具。它可以帮助测试人员测试REST API的行为，并验证以如XML、JSON和HTML格式输出的数据。凭借其通用的HTTP工具，HttpMaster也可以帮助开发人员模拟客户活动和API应用程序的响应行为。

• 自带一个易于使用和优雅的用户界面，不需要高级技术技能。
• 使用如GET，POST，DELETE等的HTTP方法。
• 提供不同的验证类型和表达式来缓解测试。
• 对测试创建和执行使用命令行界面。
• 允许存储所有信息——API调用和项目数据到一个独立的空间。

官方网站：http://www.httpmaster.net/

9.Runscope

Runscope是一个简单的工具，用来测试和监控API的性能。它可以帮助你验证是web服务还是API返回了正确的数据，同时当API出问题时给出提示。Runscope还支持API和移动app的后端服务测试。

• 允许用动态数据为甚至更复杂的情况创建测试。
• 显示视觉效果丰富的指标和分析来发现问题。
• 集成如HipChat，Webhooks，Slack和PagerDuty的工具，以便于当API坏掉时发出通知。
• 允许重用和执行跨多个地点的测试。
• 方便在中心管理测试促进更好的团队协作。

官方网站：https://www.runscope.com/

10.Rapise

Rapise是一个健壮的自动化工具，有着强大和可扩展的功能。它基于一个开放和灵活的用于REST / SOAP网络服务的快速功能测试的体系结构。 Rapise还提供对web应用程序的支持，web应用程序用用Java，.NET，AJAX，Silverlight和Flash内置。

• 使用HTTP标准方法，如POST，GET，PUT和DELETE。
• 允许存储针对特定网络服务的原型请求。
• 包含内置REST定义的生成器和对象库。
• 自带强大的集成报告功能。
• 支持跨浏览器测试和并行执行。

官方网站：https://www.inflectra.com/Rapise/

11.WebInject

WebInject是一款用于自动化功能，验收和回归web和web服务测试的免费工具。它是一个命令行工具，基于Perl，简化了测试的执行，因为它不需要在命令提示符上花时间。此外，它没有类似用户接口的IDE，这意味着，测试是在WebInject UI之外写入的。它可以在有Perl解释器的平台上运行。

• 提供实时结果显示。
• 监视系统响应时间。
• 支持不同的用处——作为一个完整的测试框架，或作为一个独立的测试运行器。
• 生成HTML和XML格式的报告。
• 允许与其他系统集成，作为外部监督的插件。

官方网站：http://www.webinject.org/

12.Storm

最后，Storm是另一个CodePlex的开源工具，用来测试用Java或.NET编写的web服务。目前，它仅支持SOAP web服务。

• 允许测试来自于独立UI的多个web服务。
• 帮助编辑原始的SOAP请求。
• 允许调用包含复杂数据类型的web服务方法。
• 支持WCF app的测试。

官方网站：http://storm.codeplex.com/

当然，可用来测试web服务的工具还有很多。欢迎分享你认为好的web服务测试工具。

来自：码农网

语言

前端和终端作为面向用户端的程序，有个共同特点：需要依赖用户机器的运行环境，所以开发语言基本上是没有选择的，不像后台想用什么就用什么，iOS只能用Objective-C，前端只能javascript，当然iOS还可以用RubyMotion，前端还能用GWT/CoffieScript，但不是主流，用的人很少，真正用了也会多出很多麻烦。

这两者有个有意思的对比：变量/方法命名的风格正好相反。苹果一直鼓吹用户体验，写代码也不例外，程序命名都是用英文全称并且要多详细有多详细，力求看变量和方法名就能知道是干嘛的，例如application:didFinishLaunchingWithOptions:。而js因为每次都要从网络下载，要力求减少代码体积，所以变量方法名是尽量用缩写，实际上有代码压缩工具，无论变量名写多长最终上线的效果是一样的，但大家也都习惯了用短的命名，例如上述objc的application:didFinishLaunchingWithOptions:方法在js里习惯的命名是:$()。

objc与js都是动态语言，使用起来还蛮像，但objc是编译型，速度快，很多错误也能在编译过程中被发现，js是解释型，性能依赖于解释引擎，即使在强劲的v8引擎下性能也赶不上编译型语言，语言太动态，变量完全没有类型，写起来爽，debug起来稍微费点劲。一直感觉js轻巧灵活放荡不羁充满各种奇技淫巧，objc中规中矩没c++ java那么严肃也没有js那么灵活。

线程

前端开发几乎不需要线程这个概念，浏览器实现上页面HTML和CSS解析渲染可能与js不在同一个线程，但所有js代码只执行在一条线程上，不会并发执行，也就不需要考虑各种并发编程的问题。在新的JS特性中可以创建worker任务，这样的任务是可以另起一条线程并行执行的，但由于并不是所有浏览器都支持，不同线程传递数据各个标准定的还不一样，使用场景也少，似乎没有大规模用起来。对于数据库操作/发送网络请求这样的任务是在不同于js代码执行线程的，不过这些都由浏览器管理，前端无需关心也无法影响这些线程，只需接收事件回调，不需要处理任何并发问题。

终端开发需要大量使用多线程，iOS有一条主线程，UI渲染都在这个线程，其他耗时长的逻辑或者数据库IO/网络请求都需要自己另开线程执行，否则会占用主线程的时间，导致界面无法响应用户交互事件，或者渲染慢导致滚动卡顿。程序逻辑分布在多个线程里跑，需要处理好各种代码并发执行可能带来的数据不一致/时序错乱之类的问题，并发也导致有些bug难以排查，一不留神就掉坑，需要适当用一些队列/锁保证程序的执行顺序。iOS提供了一套多线程管理的方法GCD，已经把线程和队列封装得非常简单易用功能强大，比其他端或后台是好很多了，但还是会花大量功夫在处理多线程问题上。

存储

终端开发需要大量的数据存储逻辑，手机APP不像浏览器，用户打开浏览器必定是连着网，但打开一个APP时很可能是离线，也很可能处于网络状况极差的移动GPRS，所以必须把之前请求回来的数据保存好。保存数据后又需要与服务端最新的数据同步，如果全量同步数据量太大，耗流量速度也慢，于是需要增量同步，需要与服务端一起制定实现增量数据返回的方案，需要处理好客户端与服务端数据一致性的问题。当数据存储量大结构复杂时，还需要利用好有限的内存做cache，优化各类存储查询性能。

前端在桌面端很少需要存储，除非是Single Page App，不存储自然就不需要数据更新的一系列工作，数据都是从后台取出拼接后直接显示到页面上，即使像微博有可以在页面内不断加载更多数据，数据也只存在于内存，不会持久化存储，因为桌面端网速稳定，不计流量，所有数据可以直接从后端拿取，客户端没必要再做一套存储。移动端那些做得很像原生APP的Web应用就跟终端开发一样了，数据同样保存到SQLite，存储逻辑以及要处理的问题都差不多。

框架

在第三方框架上Web前端和iOS开发完全相反，Web原生弱小又十分开放，让大量第三方框架和类库可以施展拳脚，而iOS原生强大又十分封闭，导致第三方框架没有多少生存空间。

浏览器一开始只为内容型的网页而设计，js也只是这个网页上能加点小特效的脚本语言，在Web应用时代跟不上发展，需要很多第三方库和框架辅助，再加上前端开发是完全开放的领域，导致库和框架百花齐放多如牛毛，在初期多数库的作用集中在封装dom操作，大家不断重复造dom操作基础库的轮子，在一段时间百家争鸣后独尊jQuery，在有使用库的网站中90%以上使用jq，几乎成了个标准基础库。后期大家已经不再重复造这个基础库的轮子了，多了一些代码组织和前端架构的框架，例如一些帮助项目模块化的框架require.js，MVC框架backbone/angular.js等。

iOS开发苹果已提供了完整的开发框架cocoa，而这框架在每一代系统中都在升级优化和添砖加瓦，开发模式也已经定型，第三方框架没有多少生存空间，大量流行的开源项目是一些通用组件和库，像网络请求库AFNetworking，数据库操作库FMDB。而一些大的框架像beeFramework/ReactiveCocoa较难流行起来。

兼容

前端开发需要兼容大——量的浏览器，桌面的chrome，safari，ie6-ie10，firefox，以及各种套壳猎豹360等浏览器，移动端iOS/Android各自的浏览器，以及无限的不同的屏幕尺寸。看起来挺可怕，实际上也没那么难搞，只是拿出来吓唬下人。桌面端chrome/safari以及各种套壳的极速模式用的都是Webkit，差异很小，firefox也大体遵从标准实现，与Webkit差别不大，旧的ie6/7就需要特别照顾，不过很多网站都不支持ie6了，移动端更是一家亲，全是Webkit，除了新特性上的支持程度不一，其他差异不大。对于不同的屏幕尺寸，高端点的会用响应式布局，针对不同屏幕尺寸自适应到不同布局，一般点的桌面端定死宽度，移动端拉伸自适应宽度就搞定。

终端开发也需要兼容各种不同的系统版本和手机尺寸，Android不用说，iOS也有3.5/4/4.7/5.5/9.7英寸这些尺寸，不过兼容起来跟Web一样挺容易，就是自适应宽度，iOS的UIKit把这些都处理好了，还有autolayout，sizeClass等高级特性可用，在尺寸上并不用花太多功夫。系统版本上iOS7为分水岭，iOS7前后版本UI上差异比较大，需要做一些功夫兼容，不过iOS用户更新换代很快，预计再过一两年iOS7以下用户就可以忽略了。

性能

终端和前端都是面向用户的，性能优化目的都是尽快呈现内容，以及让程序在用户操作下流畅运行。终端主要关注的是存储/渲染性能。当一个APP存储数据量大，数据关系复杂时，数据查询很容易成为性能瓶颈，需要不断优化数据存取的效率，规划数据IO线程，设计内存cache，利用好终端设备有限的内存，渲染上避免重复渲染，尽可能复用视图，寻找最高效的渲染方案。

前端关注页面加载速度，由于Web页面的结构/样式/程序/资源图片都是实时请求的，要让页面更快呈现内容，就要优化这些请求，让这些资源以最快速度加载下来，包括合并图片/合并代码减少请求数，压缩代码，并行请求，根据版本号缓存代码请求，gzip压缩，模块/图片懒加载等。此外跟终端一样也关注渲染性能，遵从一些规则避免页面reflow，避免使用CSS阴影这样耗性能的特效，用CSS3动画代替js等。

编译

终端开发需要编译的过程，把程序编译成机器语言，再与各种库链接后生成平台对应的可执行文件，最后由操作系统调度执行。在iOS终端开发中编译和链接的规则苹果已经在xcode这个开发工具上封装好，一般开发可以不用关心，但有深层需求时还是需要跟编译打很多交道，例如用编译前端Clang自定义静态代码检测规则，写编译脚本做自动化编译和持续集成，打包生成静态库，根据链接后的可执行文件的组成优化APP体积等。

前端开发的程序则不需要编译过程，只需要把代码扔给浏览器，浏览器边解析代码边执行。虽然js/css代码写完无需做任何事情浏览器就可以解析执行，但为了上面说的性能优化，前端代码上线前会对所有代码和资源文件进行处理，这些处理包括：压缩合并js/css，合并css sprite图，处理模块依赖，处理代码资源版本号，处理资源定位等。这个过程很像传统程序的编译，把给人看的代码优化处理成给机器看的，并解决一些依赖关系，可以算是前端的编译过程。像grunt.js/fis这些工具可以帮助完成这个编译过程，通常前端编译跟上线部署结合在一起，作为上线系统的一部分。

安全

前端和终端的安全性问题上虽然不需要像后端考虑得那么多，但还是有些需要注意。在请求的安全上，终端和前端都一样，用户向后端发送的请求都需要经过层层路由，不知道在哪里就被截获篡改或回放了，于是需要做一些措施防御这些情况，最常见的就是身份验证，多是采用会过期的token形式代替用户名密码，防止被抓包后黑客可以永远登陆这个账号。数据安全要求高的会用加密传输，或者使用https，另外还需要看情况处理一些DNS劫持，运营商广告植入等问题。

其他安全问题终端很少考虑，在未越狱的iOS机器上系统已经帮忙保证了整个APP运行环境的安全，而在越狱的机器下恶意程序拥有root权限可以做任何事情，APP也难以防范。前端方面浏览器的特性使前端开发有几个安全隐患，一是Web页面上任意位置都可以动态插入js代码，浏览器会无区别地执行这些代码，二是身份验证信息都统一保存在cookie里，三是页面上可以随意通过iframe嵌入其他网站的页面。造成XSS、CSRF、cookie劫持这些攻击手段，所以前端写代码时都需要考虑还这些安全问题，做好相应的防范，最简单和重要的防范就是对所有用户输入输出的内容做完整的过滤，避免页面内被嵌入恶意代码。

交互/开发

最后说下对这两个领域在交互和开发上的个人感触。以前在做Web前端时，感觉Web让人机交互倒退了十年，交互都是硬邦邦的点击—啪一下出来结果，滚动是一格格地刷新，很多人当时在鼓吹html5可以做出多么炫的效果时，实际上FLASH在十年前就可以做出来了，还比最现代的浏览器更流畅。iPhone流行后，人机交互终于恢复了应有的水平，体验上比Web流畅太多，指尖交互/流畅的动画/便捷的滑动手势/无限制的实现，主流终于恢复或超越了十年前Flash的水平。

但人机交互提升了，开发方式却大倒退，Web的开发方式非常先进，用户用到的都是最新版本，发现bug可以马上上线秒修复，特别适用于互联网环境下的快速迭代，而终端APP不行，撇开iPhone的审核不说，Android也无法做到保证用户用的是最新的程序，用的都是传统的客户端更新的方式，bug的修复版无法及时给到用户，无法一天上线几十次，需要维护很多旧版本，开发方式倒退回Web时代以前。这都是因为移动网络不稳定以及流量有限造成的，移动端无法像桌面端浏览器那样完全依赖网络，所以在移动网络稳定流量免费之前，开发方式都不会有多大变化。

另外并不看好HTML5，网络上说它可以取代APP说了三四年，到现在也没什么战绩，我看不到它的优势，原生APP可以获得更多的系统资源，更流畅的人机交互体验，HTML5在这方面永远比不上，而它在移动端网络和流量的限制下也无法发挥Web的开发优势，所以它不会成为主流，只适合做一些轻量的小东西。

随着智能手机的不断普及，无线音乐行业成就了一些大头手机音乐客户端公司，这些公司拥有着上百万甚至千万级别规模的用户群体。

手机客户端音乐的不断发展及用户群体的不断壮大，随之也带来了大量无线音乐数据的产生。这些数据看似杂乱无章、繁多冗余，但却隐藏着很多的秘密。如果能有效地对这些数据进行组织管理，并且利用相关技术进行挖掘、分析，少则可以揭示一个公司一次决策实施后的效果，发现公司现有存在的重大问题，多则发现潜在的高价值业务或需求，这些业务或需求很有可能为公司的发展提供战略性指导意见。

下面以国内某著名手机客户端音乐公司的无线音乐数据为例，我们还是按照发现问题、解决问题、结果验证这三个方面来说明无线音乐数据的组织与应用。

发现问题

通过对该数据进行分析挖掘，我们发现如下几个问题。

（1） 用户、歌曲均存在长尾效应

从数据中我们发现用户有两种行为，一种是下载、一种是试听，

每种行为中，我们发现用户和歌曲均存在“长尾现象”，绝大部分用户只试听或下载系统中的少部分歌曲，而大部分歌曲出于闲置状态。具体信息如下图

音乐的长尾问题

说明：图中左子图横坐标表示用户的听歌，纵坐标表示对应用户所占比例。右子图横坐标表示歌曲的被多少人听过，纵坐标表示对应度歌曲所占比例。造成这方面的原因可能是：数据量大，信息过载严重用户找不到自己喜欢的歌曲。

此时大多数用户直接转向流行榜或热歌榜歌曲，就会造成系统中热门歌曲越热门，冷门歌曲越冷门的现象。

（2） 歌曲覆盖率低

从数据中我们还发现歌曲的覆盖率很低，在整个抽样数据中歌曲

覆盖率只有2.01%。绝大部门歌曲根本没有被用户听过或者下载过，这不仅造成系统资源的大量浪费，而且造成公司资金的无辜流失（因为每首歌曲都要付版权费，而系统中98%的歌曲处于浪费状态）。歌曲的覆盖率累计分布如下如图。

歌曲覆盖率图

说明：图中横坐标表示歌曲的被听歌人数（去重），纵坐标是不小于这个数目的歌曲所占的比例。

造成这方面的原因可能是：大量歌曲处于冷启动状态，数据稀疏。作为冷启动作曲，系统不知道如何把他推送到适当的用户手里，而用户也不能通过有效方式找到他，就使得这类歌曲处理系统的暗处，不容易被发现。

（3） 用户每天听歌时间呈间断性分布

在给定的样本数据中，我们发现用户听歌行为并不是均匀分布，而是间断性分布，即在不同的时间用户听歌集中度不同。为了更好的看出效果，我们将一天分为8个时间段，每个时间段包括3个小时，在每个时间段内用户听歌活跃性如下图。

用户活跃时间图

说明：图中横坐标表示时间段，纵坐标是该时间段内用户的活跃性比。

造成这方面的原因可能是： 下班、休息、乏困疲惫时间

用户在无限端听歌的模式还是倾向于休闲与娱乐，主要是以休息碎片时间为主。

（4） 不同用户对歌曲的属性依赖性不同

在样本数据中，歌曲有专辑与歌手两种属性。我们从用户的长程关联显著性、短程关联显著性等方面对用户的听歌行为进行分析，分析具体结果如下表：

说明：图中Strong null model、Weak null mode、Temporal null model分别表示系统中所有播放之间相似度值，所有歌曲之间的相似性值，相邻播放之间相似性值。Album表示专辑，Artist表示歌手。造成这方面的原因可能是： 与专辑相比用户倾向于听同一个歌手的歌曲

（5） 不同用户听歌行为不同

从数据中我们分析还得出，不同活跃性的用户所听歌曲也不同。分析中我们从歌曲新颖性、歌曲在专辑上的相似性、歌曲在歌手上的相似性三个指标上对不同活跃性的用户所听歌曲进行分析。

具体信息如下图

歌曲的三个维度分析

说明：图中横坐标表示用户的活跃性值，纵坐标表示对应活跃性用户所听歌曲的新颖性值、歌曲在专辑上的相似性值、歌曲在歌手上的相似性值

造成这方面的原因可能是： 用户可能呈分群现象

活跃性较低的用户可能是普通用户，这类用户根据自己的爱好来选择自己想听的歌曲。活跃性较高的用户可能是专业用户，这类用户根据自己的专业需要来选择自己想听的歌曲。

解决方案

从上面一小节的讨论中，我们已经知道无线音乐端大数据中可能隐藏的几个问题如下：

①用户、歌曲均存在长尾效应

②歌曲覆盖率低

③用户每天听歌时间呈间断性分布

④不同用户对歌曲的属性依赖性不同

⑤不同用户听歌行为不同

当一个公司面对以上问题时应该采用怎样的解决方案来解决或者

改善当前情况是另一个重要的问题。尤其是上述问题①、②，如果处理不恰当，可能会影响整个公司是否能正常运行,甚至影响公司的发展。

因此，本部分从无线音乐数据出发，提出几种适合的解决方案。

（1）用户、歌曲均存在长尾效应，我们可以采用以下技术

采用信息过滤技术，一种方法可以对歌曲进行分类，将不同的用户映射到不同的歌曲类别中。另一种方法就是个性化推荐技术，系统自动的分析用户的偏好为不同用户过滤相应的歌曲。

（2）歌曲覆盖率低，我们可以采用如下技术

歌曲覆盖率低主要是因为用户找到不到音乐，造成这个问题的原因主要有两种：①音乐本身的信息不充足，②音乐有信息，但是用户找不到这些音乐。

所以一方面我们可以给音乐打标签，使用标签信息来表示歌曲的具体属性；另一方面，我们可以采用推荐技术对歌曲进行个性化推荐。

（3）用户每天听歌时间呈间断性分布，我们可以采用如下技术

在不同的时间，我们设置不同的主题歌曲以适应不同的听歌场景，比如夜晚放舒缓、平滑的歌曲，上午上摇滚、重金属之类的歌曲。

当然具体的场景还需要通过进一步的数据挖掘来获得，本文只是提出一种方法，对具体技术不做过多阐述。

（4）不同用户对歌曲的属性依赖性不同，我们采用如下技术

通过历史数据分析获取用户对歌曲属性的依赖性，从中我们能得知用户对哪种属性更加依赖。当发现用户对流派更依赖，则我们可以根据流派为其播放歌曲，当发现用户对歌手感兴趣，则我可以根据歌手为其播放歌曲。

（5）不同用户听歌行为不同，我们可以采用如下技术

根据用户特征将用户分群，这样可以将用户分为多个不同的群体。针对不同的群体我们给其播放的歌曲不同，比如普通用户可以热歌为主进行播放，而对于专业歌手，我们则以高多样的歌曲来为其播放。

结果验证

为了进一步说明上述解决方案的有效性，此处我们仅采用推荐算法来进行说明当系统采用该解决方案后，系统中出现的一些显著变化，具体的变化如下：

l 用户更容易找到自己喜欢的歌曲

用户找更容易找到歌曲

该音乐网站目前采用热歌榜（GRM）来组织歌曲，通过此种方式用户找到其喜欢歌曲的概率是千分之一左右，当我们采用了3种推荐方法（分别是OCF、HC、MD）后，发现用户找到自己喜欢歌曲的概率明显增加，而且对于MD算法，其准确度提升了10倍之多。

系统长尾的变化

使用推荐算法前

使用推荐算法后

长尾效应的改善

从上图明显的可以看出，系统的长尾效应有显著的变化。这样的结果应该是公司最想看的结果，不仅大大缩减了公司不必要的浪费，也为用户提供更好的用户体验。

via：leiphone

随着B2B电子商务系统越来越广泛的融入商务贸易,越来越多的企业开始使用B2B电子商务系统进行商务活动。而许多中小企业受不具备自主研发以及配备专业系统等诸多条件的限制,使得第三方电子商务系统应运而生,为买卖双方企业建立了稳定、安全、便捷的桥梁,确保了信息流、资金流和物流能够高效运转。而Web服务以其良好的互操作性和跨平台、跨语言的能力,为建立不同通信机制和实现标准下的软件集成和交互提供了有效的支持。这两者的结合大大降低了企业的交易成本,扩大了企业的贸易经营活动范围。

一、Web服务体系及运行机制

Web服务是指由企业发布的完成其特别商务需求的在线应用服务,其它公司或应用软件能通过Internet来描述、发布、定位以及调用这项在线服务。Web服务可看作是一种部署在Web上的对象/组件,它提供了基于XML和SOAP协议的、可跨越Internet进行远程调用的服务机制。一个典型的Web服务体系结构包含三个实体:服务提供者创建Web服务并通过服务代理注册该项服务,从而把Web服务发布到Internet上去;服务代理者维护己发布服务的注册信息,以供服务请求者查询;服务请求者通过搜索服务代理所维护的注册表以找到所需的Web服务,然后连接并使用该服务。在开发Web服务时,既可以构建全新的Web服务应用系统,也可以把原有的系统以Web服务的形式对外发布。Web服务层的运行可以通过4个基本步骤实现:

(1)服务提供者开发服务的核心功能,并对其进行Web服务包装。接着创建一个WSDL文档,对公共功能的信息、所有XML消息的数据类型信息、所用特定传输协议的绑定信息和定位特定服务的地址信息进行描述,再通过UDDI对巴新服务及其规范发布到服务注册中心。

(2)服务请求者根据应用程序的需要,通过UDDI到服务注册中心查找相关的服务。查询到满足所需要的服务后,从服务提供者那里取得该服务的WSDL文档,了解该服务的功能与使用方式。

(3)服务请求者根据WSDL文档创建SOAP客户端程序,按照定位特定服务的地址发起连接,通过SOAP和服务提供者绑定,从而实现请求的发送和应答的接受。

(4)服务提供者处理请求者的服务请求信息,然后生成一个SOAP响应。服务请求者对SOAP消息进行解析,并将处理结果返回给应用程序。

二、第三方B2B电子商务的商务模型

通常的B2B电子商务系统应是基于一个分布式的环境,应用B/S模式的3层体系结构,由客户层、业务层和数据层组成。客户层通过用户界面和客户进行交互。业务层由电子商务系统业务的处理,实现完整的业务逻辑。数据层对数据存储与维护以及各项数据库操作,实现事务逻辑和数据逻辑。

传统的B2B电子商务系统虽然也具有快速、高效、低成本、高收益率等特点,但在实际运作过程中,电子商务的基本结构、交互接口等均没有统一的标准和解决方案,因此便造成了软件的可移植性性差并且不具备良好集成能力,使得维护、升级及更新难度加大。但这种由第三方电子商务系统为买卖双方企业所架构的平台解决了上述问题。它积极极整合第三方资源,为交易双方提供的包括认证、交易、支付、物流、信息增值业务等业务过程服务,是一种安全、诚信、高效、便捷的商务模式。它不仅为双方企业提供了稳定、安全、便捷平台还确保了信息流、资金流和物流在有限的条件下能够高效运转。

三、基于Web服务的第三方B2B电子商务

由于Web服务的消息传递通过SOAP实现,而SOAP能够穿越企业的防火墙进行通信,完全屏蔽不同软件平台的差异,因此Web服务有能力为这些分布式的企业应用建立松散耦合的B2B集成。在第三方B2B电子商务系统中,保持中立的电子交易市场集成买方企业和卖方企业的电子商务系统,协助买卖双方达成交易是整个交易系统的核心。利用Web服务技术可以将现有的企业业务逻辑进行封装,实现与第三方电子商务系统的完美集成。作为成长中的中小型企业,没有完善的电子商务解决方案,可以利用第三方电子商务系统提供的服务,使用Web服务客户端应用程序开展电子商务。

以阿里巴巴B2B电子商务网上贸易平台为例,说明一下连接买卖双方的电子商务系统完成整个电子交易的过程。首先卖方企业通过注册加盟为阿里巴巴网上贸易平台会员等形式获得企业商品的发布权,发布包括商品名称、种类、数量、规格等描述信息。然后买方企业将所需要商品的信息,比如功能、特点等要求在阿里巴巴网上贸易平台上检索。网上贸易后台根据买方企业的要求做语义匹配,提供经过筛选的满足要求的企业与产品信息。最终卖方企业和买方企业在交易语义上达成一致,网上贸易平台按照预先设定的交易规则为交易双方签订交易合同直至完成交易。

四、基于Web服务的第三方B2B电子商务的安全策略

基于Web服务的第三方B2B电子商务交易平台的前提是安全性,确保买卖双方交易的合法、安全、数据完整是该平台必须解决的问题。基于Web服务的数字证书、数字签名、数据加密技术都是可以直接利用在B2B电子商务中。

1.数字证书是由CA(Certificate Authority)发放并利用电子手段来证实一个用户的身份及用户对网络资源的访问权限。包括用户的姓名、公共密钥、公共密钥的有限期、颁发发数字证书的CA、数字证书的序列号以及用户本人的数字签名。它是电子商务交易双方身份确定的唯一安全工具。数字证书的内容格式是CCTTTX.509国际标准规定的,电子商务交易需要电子商务证书,而电子商务认证中心(CA)就承担着网上安全电子交易认证服务、签发数字证书并确认用户身份的功能,数字签名是实现认证的重要工具。

2.所谓数字签名就是附加在信息单元上的一些数据,或是对信息单元所做的密码变换,这种数据或密码变换允许信息接收者确认消息的来源和信息单元的完整性并保护数据防止被人伪造。通过数字签名能实现对原始报文的鉴别与验证,保证报文的完整性、权威性和发送者对所发报文的不可抵赖性。

3.数据加密技术就是按照确定的密码算法将敏感的明文数据变换成难以识别的密文数据。通过使用不同的密钥,可用同一加密算法,将同一明文加密成不同的密文。当需要时可使用密钥将密文数据还原成明文数据,称为解密。密钥加密技术分为对称密钥加密和非对称密钥加密两类。对称加密技术是在加密与解密过程中使用相同的密钥加以控制,它的保密度主要取决于对密钥的保密;非对称密钥加密法是在加密和解密过程中使用不同的密钥加以控制,加密密钥是公开的,解密密钥是保密的。

随着电子商务普及程度越来越高,中国电子商务交易额也逐年上升,中小企业B2B交易规模几乎占到B2B总体交易额的一半,而以阿里巴巴、慧聪网、环球资源为代表的基于Web服务的第三方B2B电子商务平台占据着B2B电子商务市场的绝大部分份额,中小企业将更多地选择第三方B2B电子商务平台。随着Web服务技术的不断发展,第三方B2B电子商务也将更加辉煌。（来源：《企业导报》编选：中国电子商务研究中心）

参考文献

[1]李政伟,夏士雄,聂茹.基于Web服务的动态电子商务应用架构[J].计算机工程与设计.2005(4)

[2]丁学君.电子商务中的信息安全问题及其对策[J].计算机安全.2009(2)

[3]杨艳,唐胜群,张文涛.XML Web服务技术探讨[J].计算机应用研究.2005(4)

[4]谢怀,傅宏,唐晓寒.基于Web服务的第三方B2B电子商务研究[J].软件导刊.2008(11)

本文转载自中国电子商务研究中心:http://b2b.toocle.com/detail–5775238.html