大家好,又见面了,我是你们的朋友全栈君。
<1>什么是web服务器
“网络服务”(Web Service)的本质,就是通过网络调用其他网站的资源。
Web Service架构和云
如果一个软件的主要部分采用了”网络服务”,即它把存储或计算环节”外包”给其他网站了,那么我们就说这个软件属于Web Service架构。
Web Service架构的基本思想,就是尽量把非核心功能交给其他人去做,自己全力开发核心功能。比如,如果你要开发一个相册软件,完全可以使用Flickr的网络服务,把相片都储存到它上面,你只要全力做好相册本身就可以了。总体上看,凡是不属于你核心竞争力的功能,都应该把它”外包”出去。
最近很红的”云计算”(cloud computing)或者”云服务”(cloud services),实际上就是Web Service的同义词,不过更形象一些罢了。它们不说你把事情交给其他计算机去做,而说你把事情交给”云”去做。
Web Service的优势
除了本地服务的缺点以外,Web Service还有以下的优越性:
* 平台无关。不管你使用什么平台,都可以使用Web service。 * 编程语言无关。只要遵守相关协议,就可以使用任意编程语言,向其他网站要求Web service。这大大增加了web service的适用性,降低了对程序员的要求。 * 对于Web service提供者来说,部署、升级和维护Web service都非常单纯,不需要考虑客户端兼容问题,而且一次性就能完成。 * 对于Web service使用者来说,可以轻易实现多种数据、多种服务的聚合(mashup),因此能够做出一些以前根本无法想像的事情。
Web service的发展趋势
根据我的观察,目前Web service有这样几种发展趋势。
* 在使用方式上,RPC和soap的使用在减少,Restful架构占到了主导地位。 * 在数据格式上,XML格式的使用在减少,json等轻量级格式的使用在增多。 * 在设计架构上,越来越多的第三方软件让用户在客户端(即浏览器),直接与云端对话,不再使用第三方的服务器进行中转或处理数据。
本地服务的缺陷
“网络服务”是未来软件开发和使用的趋势,本地服务将用得越来越少,主要因为以下三个原因:
* 本地资源不足。很多数据和资料,本地得不到,只有向其他网站要。 * 成本因素。本地提供服务,往往是不经济的,使用专业网站的服务更便宜。这里面涉及硬件和人员两部分,即使你买得起硬件,专门找一个人管理系统,也是很麻烦的事。 * 可移植性差。如果你想把本机的服务,移植到其他机器上,往往很困难,尤其是在跨平台的情况下。
对本地服务,除非是大型局域网或者说ejb这类局域网协议访问,不然的话没啥意义
现在市面上有面向过程、方面、模块化编程,当然最多的是应该是面向对象,
与其说对象编程,不如说是类编程,软件即服务,若软件不能提供功能(接口方法),
也就失去原本意义,它的灵活性,独立,跨平台、跨语言
<2>web服务器有哪些
WEB服务器也可以称为网站服务器,可以用来放置网站文件,供用户浏览。那么常见的WEB服务器有哪些呢?
web服务器有哪些
①Apache
Apache是世界使用排名的Web服务器软件。它几乎可以运行在所有的计算机平台上。由于Apache是开源免费的,因此有很多人参与到新功能的开发设计,不断对其进行完善。 Apache的特点是简单、速度快、性能稳定,并可做代理服务器来使用。
②IIS
IIS(Internet信息服务)英文Internet Information Server的缩写。它是微软公司主推的服务器。IIS的特点具有:安全性,强大,灵活。
③Nginx
Nginx不仅是一个小巧且高效的HTTP服务器,也可以做一个高效的负载均衡反向代理,通过它接受用户的请求并分发到多个Mongrel进程可以极大提高Rails应用的并发能力。
④Tomcat
Tomcat是Apache 软件基金会(Apache Software Foundation)的Jakarta 项目中的一个核心项目,由Apache、Sun 和其他一些公司及个人共同开发而成。Tomcat 技术先进、性能稳定,而且免费,因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可,成为目前比较流行的Web 应用服务器。
⑤Lighttpd
Lighttpd是由德国人 Jan Kneschke 领导开发的,基于BSD许可的开源WEB服务器软件,其根本的目的是提供一个专门针对高性能网站,安全、快速、兼容性好并且灵活的web server环境。具有非常低的内存开销,CPU占用率低,效能好,以及丰富的模块等特点。支持FastCGI, CGI, Auth, 输出压缩(output compress), URL重写, Alias等重要功能。
⑥Zeus
Zeus是一个运行于Unix下的非常的Web 服务器,据说性能超过Apache,是效率的Web 服务器之一。
<3>概念
webserver 基本由这些组成
Web服务器只负责处理HTTP协议,只能发送静态页面的内容。而JSP,ASP,PHP等动态内容需要通过CGI、FastCGI、ISAPI等接口交给其他程序去处理。这个其他程序就是应用服务器。 比如Web服务器包括Nginx,Apache,IIS等。而应用服务器包括WebLogic,JBoss等。应用服务器一般也支持HTTP协议,因此界限没这么清晰。但是应用服务器的HTTP协议部分仅仅是支持,一般不会做特别优化,所以很少有见Tomcat直接暴露给外面,而是和Nginx、Apache等配合,只让Tomcat处理JSP和Servlet部分
<4>web框架和web服务的区别
web服务器(web server)的主要作用是,接收客户端请求,而web框架(web framework)则是处理web服务器收到的请求,并生成HTML内容,将生成的内容传递给web服务器,再由web服务器返回给客户端。
服务器和客户端之间的连接靠web服务器来维持,web服务器接收到请求后,将请求以及相关的参数传递给web框架,由框架负责生成内容,并将生成的内容传递给web服务器。所以web服务器的职责是接受并返回请求,web服务器的职责是内容生成。
对于Django这类的MVC 框架来说,面临的主要挑战是:易开发;对请求对象的完全访问;保持某种状态的能力;最重要的是能有写出业务级逻辑的方式。
而对于 apache, tomcat, nginx这类web 服务器来说,面临的主要挑战是并行;和数以千计的用户同时保持连接(高并发);能够在一定时间内传送大量数据(吞吐量)。
虽然Django这类的框架自带有web服务器,但是在面对以上挑战(高并发,吞吐量)时,性能太鸡肋,所以需要专门的web服务器。
<5>原理
web程序都运行在 TCP/IP 协议上,程序之间使用 socket(套接字) 进行通信,它能够让计算机之间的通信就像写文件和读文件一样简单。 一个 tcp socket 由一个IP地址和端口号组成。
IP地址是一个32位的二进制数,通常被分割为4个“8位二进制数”,写成10进制的形式就是我们常见的 174.136.14.108。我们通过IP地址来标识所连接的主机。
端口号是一个范围在0-65535之间的数字,一台主机上可能同时有多个sockets,因此需要端口号进行标识。端口号0-1023 是保留给操作系统使用的,我们可以使用剩下的端口号。
超文本传输协议(HTTP)描述了一种程序之间交换数据的方法,它非常简单易用,在一个socket连接上,客户端首先发送请求说明它需要什么,然后服务器发送响应,并在响应中包含客户端的数据。响应数据也许是从本地磁盘上复制来的,也许是程序动态生成的。传输过程如图:
HTTP请求就是一段文本,任何程序都能生成一个http请求,就像生成文本一样简单。这段文本需要包含以下这些部分:
#客户端接受的数据类型
Accept: text/html
#客户端接受的语言
Accept-Language: en, fr
If-Modified-Since: 16-May-2005
HTTP响应的结构类似于请求:
WEB服务器、应用程序服务器、HTTP服务器有何区别?IIS、Apache、Tomcat、Weblogic、WebSphere都各属于哪种服务器,这些问题困惑了很久,今天终于梳理清楚了:
Web服务器的基本功能就是提供Web信息浏览服务。它只需支持HTTP协议、HTML文档格式及URL。与客户端的网络浏览器配合。因为Web服务器主要支持的协议就是HTTP,所以通常情况下HTTP服务器和WEB服务器是相等的(有没有支持除HTTP之外的协议的web服务器,作者没有考证过),说的是一回事。
应用程序服务器(简称应用服务器),我们先看一下微软对它的定义:”我们把应用程序服务器定义为“作为服务器执行共享业务应用程序的底层的系统软件”。 就像文件服务器为很多用户提供文件一样,应用程序服务器让多个用户可以同时使用应用程序(通常是客户创建的应用程序)”
通俗的讲,Web服务器传送(serves)页面使浏览器可以浏览,然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切一点,你可以说:Web服务器专门处理HTTP请求(request),但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑 (business logic)。
以Java EE为例,Web服务器主要是处理静态页面处理和作为 Servlet容器,解释和执行servlet/JSP,而应用服务器是运行业务逻辑的,主要是EJB、 JNDI和JMX API等J2EE API方面的,还包含事务处理、数据库连接等功能,所以在企业级应用中,应用服务器提供的功能比WEB服务器强大的多。
以这样的定义,IIS、Apache、Tomcat都可以属于Web服务器,Weblogic、WebSphere都属于应用服务器。
Apache:在Web服务器中,Apache是纯粹的Web服务器,经常与Tomcat配对使用。它对HTML页面具有强大的解释能力,但是不能解释嵌入页面内的服务器端脚本代码(JSP/Servlet)。
Tomcat:早期的Tomcat是一个嵌入Apache内的JSP/Servlet解释引擎Apache+Tomcat就相当于IIS+ASP。后来的Tomcat已不再嵌入Apache内,Tomcat进程独立于Apache进程运行。 而且,Tomcat已经是一个独立的Servlet和JSP容器,业务逻辑层代码和界面交互层代码可以分离了。因此,有人把Tomcat叫做轻量级应用服务器。
IIS:微软早期的IIS,就是一个纯粹的Web服务器。后来,它嵌入了ASP引擎,可以解释VBScript和JScript服务器端代码了,这时,它就可以兼作应用服务器。当然,它与J2EE应用服务器根本无法相比,但是,从功能上说,从原理上说,它勉强可以称之为应用服务器。确切地说,它是兼有一点应用服务器功能的Web服务器。
综上:Apache是纯粹的web服务器,而Tomcat和IIS因为具有了解释执行服务器端代码的能力,可以称作为轻量级应用服务器或带有服务器功能的Web服务器。Weblogic、WebSphere因为能提供强大的J2EE功能,毫无疑问是绝对的应用服务器。对于处于中间位置的Tomcat,它可以配合纯Web服务器Apache一起使用,也可以作为应用服务器的辅助与应用服务器一起部署:
一、Tomcat与应用服务器
到目前为止,Tomcat一直被认为是Servlet/JSP API的执行器,也就所谓的Servlet容器。然而,Tomcat并不仅仅如此,它还提供了JNDI和JMX API的实现机制。尽管如此,Tomcat仍然还不能算是应用服务器,因为它不提供大多数J2EE API的支持。
很有意思的是,目前许多的应用服务器通常把Tomcat作为它们Servlet和JSP API的容器。由于Tomcat允许开发者只需通过加入一行致谢,就可以把Tomcat嵌入到它们的应用中。遗憾的是,许多商业应用服务器并没有遵守此规则。
对于开发者来说,如果是为了寻找利用Servlet、JSP、JNDI和JMX技术来生成Java Web应用的话,选择Tomcat是一个优秀的解决方案;但是为了寻找支持其他的J2EE API,那么寻找一个应用服务器或者把Tomcat作为应用服务器的辅助,将是一个不错的解决方案;第三种方式是找到独立的J2EE API实现,然后把它们跟Tomcat结合起来使用。虽然整合会带来相关的问题,但是这种方式是最为有效的。。
二、Tomcat与Web服务器
Tomcat是提供一个支持Servlet和JSP运行的容器。Servlet和JSP能根据实时需要,产生动态网页内容。而对于Web服务器来说, Apache仅仅支持静态网页,对于支持动态网页就会显得无能为力;Tomcat则既能为动态网页服务,同时也能为静态网页提供支持。尽管它没有通常的Web服务器快、功能也不如Web服务器丰富,但是Tomcat逐渐为支持静态内容不断扩充。大多数的Web服务器都是用底层语言编写如C,利用了相应平台的特征,因此用纯Java编写的Tomcat执行速度不可能与它们相提并论。
一般来说,大的站点都是将Tomcat与Apache的结合,Apache负责接受所有来自客户端的HTTP请求,然后将Servlets和JSP的请求转发给Tomcat来处理。Tomcat完成处理后,将响应传回给Apache,最后Apache将响应返回给客户端。
而且为了提高性能,可以一台apache连接多台tomcat实现负载平衡。
关于WEB服务器、应用程序服务器的更详细区别可以参考下面这篇文章:
通俗的讲,Web服务器传送(serves)页面使浏览器可以浏览,然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切一点,你可以说:Web服务器专门处理HTTP请求(request),但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑 (business logic)。
下面让我们来细细道来:
Web服务器(Web Server)
Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request),会返回一个HTTP响应 (response),例如送回一个HTML页面。为了处理一个请求(request),Web服务器可以响应(response)一个静态页面或图片,进行页面跳转(redirect),或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本,JSP(JavaServer Pages)脚本,servlets,ASP(Active Server Pages)脚本,服务器端(server-side)JavaScript,或者一些其它的服务器端(server-side)技术。无论它们(译者注:脚本)的目的如何,这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。
要知道,Web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到Web服务器里来时,它只单纯的把请求(request)传递给可以很好的处理请求 (request)的程序(译者注:服务器端脚本)。Web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响应(response)的环境,而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing),数据库连接(database connectivity)和消息(messaging)等功能。
虽然Web服务器不支持事务处理或数据库连接池,但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability),例如负载平衡(load balancing),缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。
应用程序服务器(The Application Server)
根据我们的定义,作为应用程序服务器,它通过各种协议,可以包括HTTP,把商业逻辑暴露给(expose)客户端应用程序。Web服务器主要是处理向浏览器发送HTML以供浏览,而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法 (或过程语言中的一个函数)一样。
应用程序服务器的客户端(包含有图形用户界面(GUI)的)可能会运行在一台PC、一个Web服务器或者甚至是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反,这种信息就是程序逻辑(program logic)。正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态HTML,所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。
在大多数情形下,应用程序服务器是通过组件 (component) 的应用程序接口(API)把商业逻辑暴露(expose)(给客户端应用程序)的,例如基于J2EE(Java 2 Platform, Enterprise Edition)应用程序服务器的EJB(Enterprise JavaBean)组件模型。此外,应用程序服务器可以管理自己的资源,例如看大门的工作(gate-keeping duties)包括安全(security),事务处理(transaction processing),资源池(resource pooling),和消息(messaging)。就象Web服务器一样,应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。
一个例子
例如,设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询 (query)后,网站会进行查找(lookup)并把结果内嵌在HTML页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序服务器 的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。
情景1:不带应用程序服务器的Web服务器
在此种情景下,一个Web服务器独立提供在线商店的功能。Web服务器获得你的请求(request),然后发送给服务器端(server- side)可以处理请求(request)的程序。此程序从数据库或文本文件(flat file,译者注:flat file是指没有特殊格式的非二进制的文件,如properties和XML文件等)中查找定价信息。一旦找到,服务器端(server-side)程序把结果信息表示成(formulate)HTML形式,最后Web服务器把会它发送到你的Web浏览器。
简而言之,Web服务器只是简单的通过响应(response)HTML页面来处理HTTP请求(request)。
情景2:带应用程序服务器的Web服务器
情景2和情景1相同的是Web服务器还是把响应(response)的产生委托(delegates)给脚本(译者注:服务器端 (server-side)程序)。然而,你可以把查找定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化,此脚本只是简单的调用应用程序服务器的查找服务(lookup service),而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。这时当该脚本程序产生HTML响应(response)时就可以使用该服务的返回结果了。
在此情景中,应用程序服务器提供(serves)了用于查询产品的定价信息的商业逻辑。(服务器的)这种功能(functionality)没有指出有关显示和客户端如何使用此信息的细节,相反客户端和应用程序服务器只是来回传送数据。当有客户端调用应用程序服务器的查找服务(lookup service)时,此服务只是简单的查找并返回结果给客户端。
通过从响应产生(response-generating)HTML的代码中分离出来,在应用程序之中该定价(查找)逻辑的可重用性更强了。其他的客户端,例如收款机,也可以调用同样的服务(service)来作为一个店员给客户结帐。相反,在情景1中的定价查找服务是不可重用的因为信息内嵌在 HTML页中了。
总而言之,在情景2的模型中,在Web服务器通过回应HTML页面来处理HTTP请求(request),而应用程序服务器则是通过处理定价和有效性(availability)请求(request)来提供应用程序逻辑的。
警告(Caveats)
现在,XML Web Services已经使应用程序服务器和Web服务器的界线混淆了。通过传送一个XML有效载荷(payload)给服务器,Web服务器现在可以处理数据和响应(response)的能力与以前的应用程序服务器同样多了。
另外,现在大多数应用程序服务器也包含了Web服务器,这就意味着可以把Web服务器当作是应用程序服务器的一个子集(subset)。虽然应用程序服务器包含了Web服务器的功能,但是开发者很少把应用程序服务器部署(deploy)成这种功能(capacity)(译者注:这种功能是指既有应用程序服务器的功能又有Web服务器的功能)。相反,如果需要,他们通常会把Web服务器独立配置,和应用程序服务器一前一后。这种功能的分离有助于提高性能(简单的Web请求(request)就不会影响应用程序服务器了),分开配置(专门的Web服务器,集群(clustering)等等),而且给最佳产品的选取留有余地。
<7>了解和简单的服务
server 有两重意思
作为开发者,我们说 server 的时候,一般指的后者,也就是一个 24 小时运行的软件程序。
一台主机上面可以运行多个这样的程序。
顾名思义,Web Server 就是提供 Web 服务的 Server。
比如我们访问 http:// http://baidu.com,其实就是在使用百度的 Server 提供的服务。
一般来说, Web Server 对外提供的是 HTTP 服务(也可以是其他服务),这就是为什么我们的网址都以「http://」开头。
下面是有 Node.js 写的一个最简单的 HTTP server
// 文件名 index.js
// 使用 node index.js 可运行本程序
var http = require('http')
var server = http.createServer( function (request, response){
response.end('这是页面内容,你请求的路径是:' + request.url)
})
server.listen(8080, function(){
console.log("正在监听 %s 端口", 8080);
});
你不用看懂这段程序,你只需要知道两件事情:
这就是一个最简单的 HTTP server。
提供 HTTP 服务的 server 分为两类。
1. 静态文件服务器
这种服务器简单地根据访问路径,返回对应的文件。
比如用户访问 http:// 123.123.123.123:8080/a/b/c/d.html,那么这种服务器就会在网站根目录找到 a/b/c/d.html 文件,原样返回给用户。
2. 动态内容服务器
这种服务器返回的内容一般不是文件,而是动态生成的字符串(比如从数据库中获取的字符串)。
比如用户访问 http:// http://weibo.com/home,那么这种 http://weibo.com 的服务器则会返回当前用户最新的微博消息。显然每个用户得到的内容是不一样的
<8>app server和web server的区别
app服务器和web服务器的区别是什么呢?
简单来说,web服务器提供页面给浏览器,而app服务器提供客户端可以调用的接口。具体而言,我们可以说:
Web服务器处理HTTP请求,而app服务器基于多种不同的协议,处理应用程序的逻辑问题。
以下将详细介绍它们之间的区别。
Web服务器
web服务器处理HTTP协议。当收到一个HTTP请求之后,web服务器会返回一个HTTP响应,比如一个HTML页面。为了处理请求,它可能响应一个静态的HTML页面、图片、重定向,或者代理(delegate)其他动态响应。这些动态响应可以由其他程序生成,包括CGI脚本,JSPs,servlets,ASPs,服务器端的Javascript,或者其他服务器端技术。而这些服务器端程序响应,大多数时候都表现为HTML页面,供浏览器访问。
理解一个web服务器的代理模型(delegate model)相对比较简单。当web服务器接收到一个请求,它只是简单的将请求交给处理该请求的最优程序。除了为服务器程序简单的提供一个运行环境(服务器程序可以在其中运行,并且返回生成的响应)之外,web服务器不提供任何功能。服务器程序一般自己处理交换(transaction)、数据库连接、消息分发等。
虽然web服务器不提供以上的服务,但是它一般会提供诸如容错机制,负载均衡、缓存、集群等的可扩展性。而后者,一般来说不应该部署在web服务器上,而应该在app服务器上!
App服务器
根据我们的定义,app服务器可以基于各种不同的协议(可能包含HTTP协议),为客户端程序提供应用逻辑的处理。不同于web服务器主要发送用来展示在浏览器上的HTML页面,app服务器为客户端程序处理应用逻辑方面问题。应用程序使用这些逻辑,就如同调用一个对象的方法(或者面向过程编程中的函数)一样简单。
这些应用程序可能包含PC机上运行的GUI进程,web服务器,甚至其他的app服务器。app服务器和客户端之间的通信并不局限于简单的显示标记,而是可以由程序逻辑,比如数据表单、方法调用,而非静态的HTML,这样,客户端程序就可以按需去用了!
在大多数情况下,app服务器通过元件API,比如基于j2ee app服务器的EJB,来提供应用逻辑。而更多的情况下,app服务器自己管理自己的资源。这些责任(gate-keeping)包括安全、进程交互、资源池、消息分发等。同web服务器一样,app服务器也可能需要各种可扩展性和容错机制。
一个例子
以一个提供实时价格和相关信息的在线商店为例,它极有可能提供了一个表单,用户可以选择不同的产品并查询。它会查找,并通过HTML网页展示结果。这个网站可能有多种方式来实现这个功能,下面我们将举两个相反的例子,一个不使用app服务器,而另一个使用。通过这两个例子,可以帮助你理解app服务器的功能。
场景1:web服务器,而非app服务器
在这个场景里,web服务器独自提供在线商店的功能。它接受用户的请求,交给服务器端程序处理。该服务器端程序通过数据库,或者纯文本,查找到价格信息,然后生成HTML响应,通过web服务器返回给用户的浏览器。
总结来说,web服务器仅需要接受HTTP请求,并响应HTML网页。
场景2: web服务器 + app服务器
同场景1一样,web服务器仍然代理脚本生成的响应。但是你可以把业务逻辑部署在app服务器上。这样,脚本就不需要去关注怎样查询和生成响应,而仅需要调用app服务器提供查询服务,从而利用其生成它的HTML响应。
在这个例子中,app服务器提供了价格查询的业务逻辑。这个逻辑不应该包含怎样去展示,或者强迫客户端使用这些数据。相反的是,客户端和app服务器进行交互,只有当客户端调用了app服务器的价格查询服务的时候,该服务才查找到信息并返回。
同HTML代码生成分离开后,价格查询逻辑的复用性提高了。另外一个客户端,比如收银机,同样可以调用这个接口。而场景1里,价格查询服务就很难被重用,因为它和HTML页面紧密联系。
总结来说,第二个场景中,web服务器处理HTTP请求,并返回HTML页面,而app服务器处理业务逻辑。
注意事项
近来,XML web服务器模糊了app服务器和web服务器的界限。发送一个XML请求给web服务器,web服务器可以像过去的app服务器一样,处理数据并返回响应。
另外,很多app服务器包含web服务器,这就意味着你可以把web服务器看做app服务器的一个子集。虽然app服务器包含web服务器的功能,但是开发者还是很少以此身份发布app服务器。如果需要的话,他们通常将web服务器和app服务器分离开。这样的目的是,性能(简单的web请求不会影响到app服务器的性能)、发布配置(专用的web服务器,集群等)、更好的厂商选择。
<9>应用服务器和web服务器
Web服务器的基本功能就是提供Web信息浏览服务。它只需支持HTTP协议、HTML文档格式及URL。与客户端的网络浏览器配合。因为Web服务器主 要支持的协议就是HTTP,所以通常情况下HTTP服务器和WEB服务器是相等的。
以这样的定义,IIS、Apache、Tomcat都可以属于Web服务器
Web服务器(Web Server)可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request),会返回一个HTTP响应 (response),例如送回一个HTML页面。为了处理一个请求(request),Web服务器可以响应(response)一个静态页面或图片, 进行页面跳转(redirect),或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本,JSP(JavaServer Pages)脚本,servlets,ASP(Active Server Pages)脚本,服务器端(server-side)JavaScript,或者一些其它的服务器端(server-side)技术。无论它们(译者 注:脚本)的目的如何,这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。
要知道,Web服务器的代理模型(delegationmodel)非常简单。当一个请求(request)被送到Web服务器里来时,它只单纯的把请求(request)传递给可以很好的处理请求 (request)的程序(译者注:服务器端脚本)。Web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响 应(response)的环境,而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing),数据库连接(database connectivity)和消息(messaging)等功能。
虽然Web 服务器不支持事务处理或数据库连接池,但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability),例如负载平衡(load balancing),缓冲(caching)。集群特征(clustering-features)经常被误认为仅仅是应用程序服务器专有的特征。
应用服务器(The Application Server)
微软给定义为:我们把应用程序服务器定义为“作为服务器执行共享业务应用程序的底层的系统软件。
根据定义,作为应用程序服务器,它通过各种协议,可以包括HTTP,把商业逻辑暴露给(expose)客户端应用程序。Web服务器主要是处理向 浏览器发送HTML以供浏览,而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就像你调用对象的一个方法(或过程 语言中的一个函数)一样。
应用程序服务器的客户端(包含有图形用户界面(GUI)的)可能会运行在一台PC、一个Web服务器或者甚至 是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反,这种信息就是程序逻辑(program logic)。 正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态HTML,所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。
在大多数情形下,应用程序服务器是通过组件(component)的应用程序接口(API)把商业逻辑暴露(expose)(给客户端应用程序)的,例 如基于J2EE(Java 2 Platform, Enterprise Edition)应用程序服务器的EJB(Enterprise JavaBean)组件模型。此外,应用程序服务器可以管理自己的资源,例如看大门的工作(gate-keepingduties)包括安全(security),事务处理(transaction processing),资源池(resource pooling), 和消息(messaging)。就象Web服务器一样,应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。
以这样的定义,Weblogic、WebSphere都属于应用服务器。
Apache:在Web服务器中,Apache是纯粹的Web服务器,经常与Tomcat配对使用。它对HTML页面具有强大的解释能力,但是不能解释嵌入页面内的服务器端脚本代码(JSP/Servlet)。
Tomcat:早期的Tomcat是一个嵌入Apache内的JSP/Servlet解释引擎Apache+Tomcat就相当于IIS+ASP。后来的 Tomcat已不再嵌入Apache内,Tomcat进程独立于Apache进程运行。 而且,Tomcat已经是一个独立的Servlet和JSP容器,业务逻辑层代码和界面交互层代码可以分离了。因此,有人把Tomcat叫做轻量级应用服务器。
IIS:微软早期的IIS,就是一个纯粹的Web服务器。后来,它嵌入了ASP引擎,可以解释VBScript和JScript服务器端代码了,这时,它 就可以兼作应用服务器。当然,它与J2EE应用服务器根本无法相比,但是,从功能上说,从原理上说,它勉强可以称之为应用服务器。确切地说,它是兼有一点应用服务器功能的Web服务器。
综上:Apache是纯粹的web服务器,而Tomcat和IIS因为具有了解释执行服务器端代码的能力,可以称作为轻量级应用服务器或带有服务器功能的Web服务器。 Weblogic、WebSphere因为能提供强大的J2EE功能,毫无疑问是绝对的应用服务器。对于处于中间位置的Tomcat,它可以配合纯Web服务器Apache一起使用,也可以作为应用服务器的辅助与应用服务器一起部署。
常见的web服务器: (其实IIS和Apache同时也支持基础的应用服务器的功能)
Microsoft IIS
Microsoft的Web服务器产品为Internet Information Server (IIS), IIS 是允许在公共Intranet或Internet上发布信息的Web服务器。IIS是目前最流行的Web服务器产品之一,很多著名的网站都是建立在IIS 的平台上。IIS提供了一个图形界面的管理工具,称为 Internet服务管理器,可用于监视配置和控制Internet服务。
IIS是一种Web服务组件,其中包括Web服务器、FTP服务器、NNTP服务器和SMTP服务器, 分别用于网页浏览、文件传输、新闻服务和邮件发送等方面,它使得在网络(包括互联网和局域网)上发布信息成了一件很容易的事。它提供 ISAPI(Intranet Server API)作为扩展Web服务器功能的编程接口;同时,它还提供一个Internet数据库连接器,可以实现对数据库的查询和更新。
Apache
Apache 源于NCSAhttpd服务器,经过多次修改,成为世界上最流行的Web服务器软件之一。 Apache是自由软件,所以不断有人来为它开发新的功能、新的特性、修改原来的缺陷。Apache的特点是简单、速度快、性能稳定,并可做代理服务器来 使用。本来它只用于小型或试验Internet网络,后来逐步扩充到各种Unix系统中,尤其对Linux的支持相当完美。
Apache是以进程为基础的结构,进程要比线程消耗更多的系统开支,不太适合于多处理器环境,因此, 在一个Apache Web站点扩容时,通常是增加服务器或扩充群集节点而不是增加处理器。到目前为止Apache仍然是世界上用的最多的Web服务器,世界上很多著名的网站 都是Apache的产物,它的成功之处主要在于它的源代码开放、有一支开放的开发队伍、支持跨平台的应用(可以运行在几乎所有的Unix、 Windows、Linux系统平台上)以及它的可移植性等方面。
常见的应用服务器:
IBM WebSphere
WebSphere Application Server 是一 种功能完善、开放的Web应用程序服务器,是IBM电子商务计划的核心部分,它是基于 Java 的应用环境,用于建立、部署和管理 Internet 和 Intranet Web 应用程序。 这一整套产品进行了扩展,以适应 Web 应用程序服务器的需要,范围从简单到高级直到企业级。
WebSphere 针对以 Web 为中心的开发人员,他们都是在基本 HTTP服务器和 CGI 编程技术上成长起来的。IBM 将提供 WebSphere 产品系列,通过提供综合资源、可重复使用的组件、功能强大并易于使用的工具、以及支持 HTTP 和 IIOP 通信的可伸缩运行时环境,来帮助这些用户从简单的 Web 应用程序转移到电子商务世界。
BEA WebLogic
BEA WebLogic Server 是一种多功能、基于标准的web应用服务器,为企业构建自己的应用提供了坚实的基础。各种应用开发、部署所有关键性的任务,无论是集成各种系统和数据库,还是提交服务、跨 Internet 协作,起始点都是 BEA WebLogic Server。由于 它具有全面的功能、对开放标准的遵从性、多层架构、支持基于组件的开发,基于 Internet 的企业都选择它来开发、部署最佳的应用。
BEA WebLogic Server 在使应用服务器成为企业应用架构的基础方面继续处于领先地位。BEA WebLogic Server 为构建集成化的企业级应用提供了稳固的基础,它们以 Internet 的容量和速度,在连网的企业之间共享信息、提交服务,实现协作自动化。BEA WebLogic Server 的遵从 J2EE 、面向服务的架构,以及丰富的工具集支持,便于实现业务逻辑、数据和表达的分离,提供开发和部署各种业务驱动应用所必需的底层核心功能。现在已经归于Oracle所有。
IPlanet Application
IPlanet Application Server作为Sun与Netscape联盟产物的iPlanet公司生产的iPlanet Application Server 满足最新J2EE规范的要求。它是一种完整的WEB服务器应用解决方案,它允许企业以便捷的方式,开发、部署和管理关键任务Internet 应用。该解决方案集高性能、高度可伸缩和高度可用性于一体,可以支持大量的具有多种客户机类型与数据源的事务。
iPlanet Application Server的基本核心服务包括事务监控器、多负载平衡选项、对集群和故障转移全面的支持、集成的XML 解析器和可扩展格式语言转换(XLST)引擎以及对国际化的全面支持。iPlanet ApplicationServer 企业版所提供的全部特性和功能,并得益于J2EE系统构架,拥有更好的商业工作流程管理工具和应用集成功能。
Oracle IAS
Oracle iAS的英文全称是Oracle Internet Application Server,即Internet应用服务器,Oracle iAS是基于Java的应用服务器,通过与Oracle数据库等产品的结合,OracleiAS能够满足Internet应用对可靠性、可用性和可伸缩性的要求。
Oracle iAS最大的优势是其集成性和通用性,它是一个集成的、通用的中间件产品。在集成性方面,Oracle iAS将业界最流行的HTTP服务器Apache集成到系统中,集成了Apache的Oracle iAS通信服务层可以处理多种客户请求,包括来自Web浏览器、胖客户端和手持设备的请求,并且根据请求的具体内容,将它们分发给不同的应用服务进行处 理。在通用性方面,Oracle iAS支持各种业界标准,包括 JavaBeans、CORBA、Servlets以及XML标准等,这种对标准的全面支持使得用户很容易将在其他系统平台上开发的应用移植到 Oracle平台上。
Tomcat
Tomcat是一个开放源代码、运行servlet和JSP Web应用软件的基于Java的Web应用软件容器。Tomcat Server是根据servlet和JSP规范进行执行的,因此我们就可以说Tomcat Server也实行了Apache-Jakarta规范且比绝大多数商业应用软件服务器要好。
Tomcat是Java Servlet2.2和JavaServerPages 1.1技术的标准实现,是基于Apache许可证下开发的自由软件。Tomcat是完全重写的Servlet API 2.2和JSP 1.1兼容的Servlet/JSP容器。Tomcat使用了JServ的一些代码,特别是Apache服务适配器。随着Catalina Servlet引擎的出现,Tomcat第四版号的性能得到提升,使得它成为一个值得考虑的Servlet/JSP容器,因此目前许多WEB服务器都是采用Tomcat。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/191792.html原文链接:https://javaforall.cn