Q. 应用集成方式有哪些?web
A. 应用能够采用如下方式集成:算法
1. 共享数据库数据库
2. 批量文件传输设计模式
3. 远程过程调用(RPC)浏览器
4. 经过消息中间件来交换异步信息(MOM)缓存
Q. 应用集成能够采用的Web服务方式有什么?安全
A. SOAP WS(Simple Object Access Protocal) 和RESTful Web Service(REpresentational State Transfer)服务器
Q. SOAP WS 和RESTful Web Service之间有什么不一样呢?app
A. 框架
SOAP WS支持既远程过程调用(例如,RPC)又支持消息中间件(MOM)方式进行应用集成。而Restful Web Service仅支持RPC集成方式。
SOAP WS是传输协议无关的。它支持多种协议,好比,HTTP(S)、 Messaging、TCP、UDP SMTP等等。而REST是协议相关的,只支持HTTP或者HTTPS协议。
SOAP WS仅容许使用XML数据格式。定义的操做经过POST请求发送。其重点是经过操做名来获取服务,并将应用逻辑封装为服务。而REST方式则容许多种数据格式,例如,XML、JSON、文本、HTML等等。并且因为REST方式采用标准GET、PUT、PSOT和DELETE 方法,所以全部的浏览器均可以支持。其重点是经过资源名来获取服务,并将数据封装为服务。AJAX支持REST方式,它可使用XMLHttpRequest对象。无状态CRUD操做(建立、读、更新和删除)更加适合这种方式。
GET – represent()
POST – acceptRepresention()
PUT – storeRepresention()
DELETE – removeRepresention()
没法缓存SOAP方式读取的内容。而REST方式的则能够,并且性能和可扩展性都更好一些。
SOAP WS支持SSL和WS-security,针对企业级应用能够有更多的安全保障,例如按需提高安全指数、经过第三方来保证身份认证信息的安全性、除了点到点SSL(point to point SSL)以外,更针对消息的不一样部分来提供不一样的保密算法等等。而REST只支持点到点SSL。并且不管是否是敏感消息,SSL都会加密整条消息。
SOAP对于基于ACID的短寿命事务管理以及基于补偿事务管理的长寿命事务有深刻的支持。同时,SOAP也支持分布式事务(译者:在一个分布式环境中涉及到多个资源管理器的事务)的两阶段提交(two-phase commit)方式。而REST因为基于HTTP协议,所以对于事务处理既不兼容ACID方式也不提供分布式事务的两阶段提交方式。
即使是要经过SOAP的第三方程序,SOAP经过内置的重试逻辑也能够提供端到端可靠性。REST没有一个标准的消息系统,于是寄但愿于客户经过重连去解决通讯失败问题。
Q.如何选择采用哪一种Web service?SOAP WS仍是REST?
A.通常而言,基于REST的Web service的优点在于其简单、性能不错、可扩展性好,而且也支持多种数据格式。而SOAP则适用于安全性和事务处理可靠性方面要求比较高的服务中。
对于这个问题的答案,更多的考虑依据是设计者对功能性和非功能性需求的要求。经过回答下列问题能够帮助你作出选择:
所提供的服务会暴露数据或者业务逻辑吗?(若是会暴露数据的话能够选择REST方式,若是会暴露业务逻辑的话能够选择SOAP WS)。客户或者服务提供商须要一个正式的契约(contract)吗?(SOAP能够经过WSDL(Web Service Description Language)提供一个正式契约)
须要支持多种数据格式吗?
须要进行AJAX调用吗?(REST能够采用XMLHttpRequest来发送AJAX调用)
同步调用仍是异步调用?
有状态调用仍是无状态调用?(REST适合无状态CRUD操做)
对于安全性的要求?(SOAP WS对于安全性的支持更好些)
对于事务处理的要求?(SOAP WS这方面更有优点)
有带宽限制吗?(SOAP消息比较冗长)
哪一种方式更适合开发者呢呢?(REST更好实现,也更好测试和维护)
Q.有什么能够用来测试Web Service的工具吗?
A.测试SOAP WS可使用SoapUI,测试RESTFul service能够采用Firefox的“poster”插件。
Q. SOA和Web service的区别是什么?
A. SOA是一种软件设计准则,一种实现松耦合,高可复用性和粗粒度的web服务的设计模式。开发者能够选择任意协议实现SOA,例如,HTTP、HTTPS、JMS、SMTP、RMI、IIOP(例如,采用IIOP的EJB)、RPC等。消息能够采用XML或者数据传输对象(Data Transfer Objects,DTOs)。
Web Service是实现SOA的技术之一。也能够不用Web service来实现SOA应用:例如,用一些传统的技术,像Java RMI,EJB,JMS消息等。可是Web service提供的是标准的平台无关的服务,这些服务采用HTTP、XML、SOAP、WSDL和UDDI技术,所以能够带来J2EE和.NET这些异构技术(heterogeneous technologies)之间的互操做性。
Q.若是可使用传统的中间件方式,例如,RPC、CORBA、RMI和DCOM,为何还要选择Web service?
A. 传统的中间件跟应用关系紧密,对应用的任何修改均可能会引发对应中间件的修改。所以这种方式下应用很差维护,复用性也比较差。通常状况下也没法支持异质系统(heterogeneity)。另外,采用这种方式应尽可能避免互联网访问应用。还有,这种方式代价更高而且可用性差。
Web service采用松耦合链接,即在客户端和服务器端之间提供了一个抽象层。这种松耦合应用能够减小维护成本并增长可复用性。Web service提供了一种基于XML和Web的新的中间件形式。Web service是语言和平台无关的,任何语言均可以用来开发一个Web service,而且部署到任何平台上,包括小型设备到大型超级计算机。Web service采用语言无关协议,例如HTTP,而且经过Web API来在不一样的应用程序之间传输XML消息。Web service能够经过互联网访问,开销少而且可用性好。
Q.开发基于SOAP的Web service有哪些方式呢?
A.有两种方式;
契约先行(也称为自顶向下,contract-first)方式:经过XSD和WSDL来定义contract,而后根据contract生成Java类;
契约后行(也称为自底向上,contract-last)方式:先定义Java类,而后生成约定,也就是从Java类获得WSDL文件。
注意:WSDL描述这样一些信息:服务所提供的全部用户操做、终端位置信息(例如,调用服务的URL),请求和响应中的简单或者复杂元素等。
Q. 上面两种方式各有什么优缺点吗?你更推荐哪一种?
A.
契约先行方式的Web service
优势:
客户端程序和服务器端程序分离,所以重构服务器端代码不会影响到客户端。
因为遵照相同的规范,所以客户端和服务器端的开发能够并行进行。
开发者能够控制请求\响应消息的结构:例如,“status”应该是做为消息的一个元素仍是一个属性?契约规定的很是明确。所以开发者能够大胆的去修改OXM(Object to XML Mapping)库,而不用担忧是否会致使“status”从元素变成“属性”。不只如此,甚至Web service框架和工具箱均可以更换,好比从Apache Axis变成Apache CXF等等。
缺点:
开发前期须要额外的一些搭建XSD和WSDL的工做。使用XML Spy、OxygenXM等工具能够简化这些工做。另外,还须要开发对象模型。
开发者须要除了Java以外,还须要去学习XSD和WSDL。
契约后行方式的Web service
优势:
开发者不用去学习XSD、WSDL和SOAP相关知识。能够经过框架或者工具集利用已有服务来快速构建新的服务。例如,经过基于IDE向导快速构建应用。
学习曲线和开发时间会比契约先行方式小。
缺点:
项目初始的开发时间会缩短,可是一旦contract发生变化或者须要加入新的元素,那么随之而来的维护和扩展应用所带来的开发时间会是怎样呢?采用这种方式,因为客户端和服务器端之间紧密耦合,所以将来潜在的变化可能破坏客户端的contract,致使全部的客户都会受到影响,为了不这中状况的发生,项目开发时须要很当心的开发和管理将来要发布的服务。
XML的有效负载(payload)没法控制。这也就是说修改应用的OXM库会致使某个元素错误的变成了属性。