什么样的客户端服务器跨平台

⑴ 客户端是什么意思

客户端”是和“服务器端”相对的毕掘一种说法，客户端也称为用户端，是指与服务器相对应，为客户提供本地服务的程序。

除了一些只在本地运行的应用程序之外，一般安装在普通的客户机上，需要与服务端互相配合运行，客户端是不占用内存程序的。

(1)什么样的客户端服务器跨平台扩展阅读：

客户端和服务器端的区别

1、脚本语言的不同：

客户端脚本语言中，有些是作为客户端脚本语言来运行的，它们由客户端的解释器来解释，如VBScript、javascrip、JScript等都可以作为客户谈乎端脚本语言，当它们嵌入到HTML文件中时，即可以按照顺序被执行或者响应某个事件而对事件做出应答。

而另外一些作为服务端脚本语言来运行的，如php、CGI、JSP等，它们由服务端的解释器来解释，当作为服务端脚本语言来运行时，它们主要生成HTML内容，也可以生成客户端脚本，当被传到客户端的浏览器时，这些客户端脚本代码也可以被解释实现特定的功能。

2、执行的功能不同：

客户端应该理解为C/S，即通过向客户机上写一些程序，保证即使服务器端出现故障或者维护时候，客户端依然可以在保证工作的前提下、实现脱机工作。

服务器主手侍核要应用于数据库和Web服务，而PC主要应用于桌面计算和网络终端，设计根本出发点的差异决定了服务器应该具备比PC更可靠的持续运行能力、更强大的存储能力和网络通信能力，同时，对数据相当敏感的应用还要求服务器提供数据备份功能。

⑵ web server与app server有什么不同

1、处理问题不同
Web服务器处理HTTP请求，而app服务器基于多种不同的协议，处理应用程序的逻辑问题

2、功能不同
当web服务器接收到一个请求，它只是简单的将请求交给处理该请求的最优程序。除了为服务器程序简单的提供一个运行环境之外，web服务器不提供任何功能。不同于web服务器主要发送用来展示在浏览器上的HTML页面，app服务器为客户端程序处理应用逻辑方面问题。

3、提供的服务不同

web服务器一般会提供诸如容错机制，负载均衡、缓存、集群等。app服务器通过元件API，比如基于j2ee app服务器的EJB，来提供应用逻辑。而更多的情况下，app服务器自己管理自己的资源。这些责任（gate-keeping）包括安全、进程交互、资源池、消息分发等。

(2)什么样的客户端服务器跨平台扩展阅读

主要web server产品

1、kangle

kangleweb服务器（简称：kangle）是一款跨平台、功能强大、安全稳定、易操作的高性能web服务器和反向代理服务器软件。除此：kangle也是一款专为做虚拟主机研发的web服务器。实现虚拟主机独立进程、独立身份运行。

用户之间安全隔离，一个用户出问题不影响其他用户。安全支持php、asp、net、java、ruby等多种动态开发语言。

2、nginx

Nginx（发音同 engine x）是一款轻量级的Web服务器/反向代理服务器及电子邮（IMAP/POP3）代理服务器，并在一个BSD-like 协议下发行。由俄罗斯的程序设计师Igor Sysoev所开发，供俄国大型的入口网站及搜索引擎Rambler（俄文：Рамблер）使用。

其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：新浪、网易、腾讯等。

3、apache

Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上，由于其跨平台和安全性被广泛使用，是最流行的Web服务器端软件之一。

同时Apache音译为阿帕奇，是北美印第安人的一个部落，叫阿帕奇族，在美国的西南部。也是一个基金会的名称、一种武装直升机等等。

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服务器处理业务逻辑。

⑶ 什么是跨平台

跨平台泛指程序语言、软件或硬件设备可以在多种作业系统或不同硬件架构的电脑上运作。
广义面言，一般的计算语言都可做到跨平台，开发商只需要提供各种平台下的Runtime/中间件环境即可。严格而言是指用某种计算机语言编制的程序只需要做小量的修改，编译之后即可在另外一种平台下运行，此时并不提供Runtime/中间件环境。例如Java是一种提供Runtime环境的跨平台解决方案，而C而是一种标准且严格的跨平台语言。
跨平台概念是软件开发中一个重要的概念，即不依赖于操作系统，也不信赖硬件环境。一个操作系统下开发的应用，放到另一个操作系统下依然可以运行。相对而言如果某种计算机语言不用修改代码即可做到高度跨平台，那么此语言就越抽象，硬件控制力就越低，只适合开发高度抽象的模型系统。诸如java,delphi和易语言，都已做到了跨平台。它们将可以在多种系统下开发，运行和维护。
大部分电脑语言从绝对意义而言，都是跨平台的：因为都是以高级的、人类可读的方式来对CPU发号指令，这样也就没必要依赖于任何作业系统。但如果要用系统的部件工具箱，来新建用户图形界面（GUI），就可能会用到开发员特定系统中的API函数或库类。虽然C++是跨平台的，但Windows下用到Win32 API的C++程式，一般就不能在Unix机器上编译。不同编译器对语言规范的解释也有所差异。这样的话，在针对不同系统进行构建之前，程式就得加以考虑。
一些如Java这样的语言，从一开始就意识到要在各个平台下运行，所以跨平台在其平台的本地语言环境中已经实现。例如，Java可以跨平台使用，正是由于Swing库在许多平台下的实现。类似的，能进行跨平台的文件存取，是因为有各自平台下文件存取的库。以此类推，各种跨平台问题，都需要各自的本地库来解决。wxWidgets框架就是这样的一个跨平台库，根据不同的跨平台问题，提供了许多不同的解决方案；类似的库有许多，可以根据不同语言的跨平台开发，而采用相应的库。
针对每种作业系统、CPU，而提供并测试各自的编译版本，这种做法的可行性很小；开源软体则允许用户自己来编译目的码（object code），这样在跨平台方面更好一些。类似的，那些解释型语言，或者需要虚拟机的语言，也更加符合跨平台的要求，因为用户也要自己进行编译。Sun公司的Java虚拟机Hotspot，只针对几种而不是全部平台，提供编译好的二进位文件。例如，Sun对于GNU/linux，只支持i386平台，但如果谁在PowerPC或者SPARC电脑上运行Linux，就只好自己编译本地的机器码（machinecode），或者使用第三方软体，才能运行Java程式。
许多API（应用程式接口）依赖于平台。OpenGL可以看作是跨平台的，因为其不依赖于任何特定的作业系统、CPU构架或者某个牌子的图形设备。特定平台的API可以在其他系统上作为兼容层而新建，例如WINE的库，Windows程式就可以在UNIX系统上运行。
另外许多程式语言还有跨平台的扩展以及中间件，这样程式设计师对于同样的原始码，只要进行一点小修改，就可以在不同平台下编译/运行，例如Qt和wxWidgets。
支持多种作业系统的软体
1. 资料库管理系统(DBMS)：
MySQL：Solaris、Linux、Windows、FreeBSD
Oracle：Solaris、Linux、Windows
2. 网站服务器、应用程式服务器：
Apache：Solaris、Linux、Windows、FreeBSD
Tomcat：Linux、Windows、FreeBSD
3. 网际网路浏览器：
Mozilla Firefox：Linux、FreeBSD、Solaris、AIX、Windows、
可在不同作业系统上进行软体开发的程式语言
C语言、C++、Java
Perl、Tcl、Erlang
Python、Delphi+Kylix、REALbasic
开发java应用的跨平台，包含五方面的内容：
一、跨应用服务器
二、跨数据库
三、跨操作系统
四、跨浏览器
五、多语言支持
下面分别来说一下。
■跨应用服务器
这一点，看起来好像有些多余，java的口号之一不就是“一次编译，到外运行”嘛，可实际经验告诉我们，这仅仅是一个口号而已。实际中是“一次编译，到处调试”。为什么会这样？从应用服务器来说，各个产品或多或少都在标准的java规范之上进行了一些拓展，小规模的应用开发，多以tomcat为基准；大规模的应用，多以weblogic/websphere为基准。
那么开发完成的应用，可否在所有的应用服务器上正常部署呢？答案是否定的。在tomcat5上部署没问题，在tomcat4上却可能有问题；在tomcat5/4上没问题，却可能在resin/jetty/weblogic/websphere上有问题。在我的经历中，在resin/jetty/weblogic为基准进行开发的应用，部署到tomcat上基本上没什么问题。但是以tomcat为基准的应用，部署到其他应用服务器中，却可能出现各种各样的问题。这与tomcat本身的定位和开发方式有关，它更像是一个学术产品，而不是一个商业产品。
小型的应用，我偏好resin，它的速度、稳定性、兼容性、中文处理，都是非常不错的。相比而言，以“纯java、快速”着称的jetty，就不太令人满意。jetty的4/5/6各个版本中，对session的存放位置、web.xml的标准、struts的plugin的支持、log4j的处理，都各不相同。在最新的jetty6中，竟然会要命地“不能使用session.validate()”方法，一使用此方法之后，就无法再使用set/getAttribute了。
也曾经在将一个应用转移到websphere5上时，费劲周折。这个应用跑在其他应用服务器上都没问题，但是一部署到ws5上，就无法正常加载struts的配置文件。本以为是struts配置文件写得有问题，但即便把所有的action/form配置均去掉，只保留一个空的配置文件，也无法正常启动。最后实在无法，只能乱碰运气，考虑是否是struts的几个jar包版本有问题，经检查，发现应用中使用的是struts1.2的jar包，换成struts1.1的jar包，再启动后就一切正常。这样的问题，可真的是折磨人呢。
所以，我认为跨应用服务器是很重要的。你不能告诉客户，俺们的系统只能跑在tomcat下面，至于您花重金购买的weblogic/websphere，对不起，我们暂时还不支持。客户会吐血的。
■跨数据库
经常看到某大公司产品，要求必须使用oracle或者sqlserver数据库，你想换个数据库来部署？没门，人家说了，我们的产品只支持这一种数据库，你就老实的用吧。但对于客户方来说，为了减少投资，并且保证内部系统尽可能使用同一种数据库以减少维护成本（总不能请一个oracle DBA，再请一个sqlserver DBA吧？），总会希望新系统使用的数据库是以前用过的吧。
现在有了hibernate，在此基础上开发的应用，基本上是能满足跨数据库要求的，个人认为这是hibernate最大的亮点。但也要注意，在开发中尽可能考虑到不同数据库的特性。诸如sqlserver的text/image字段上不能查distinct，oracle内的各种对象名称长度不得超过30等，尽量不要调用数据库的内部特性（如存储过程、视图等）
■跨操作系统
这一点，貌似没有什么可说的，很少有开发出的系统只能部署在一种操作系统上的。不过有一点也要注意，如果系统中某些功能依赖于通过JNI来调用windows本地组件的话，比如打印、word/excel操作，或与只能运行在windows下的报表组件(如国内的数巨报表、如意报表)集成的话。
■跨浏览器
窃以为，如果只是做国内的应用，这一点倒不重要，就以IE为标准来开发也未尝不可。
PS：完全支持IE也不是一件容易的事情，IE5/6本身就有不少的差异。
但如果产品本身想立足于世界，想与国外产品竞争，对浏览器的全面支持也必不可少。至少应该同时支持ie和firefox吧，如果对自身严格要求的话，我认为应以opera为标准，opera对html/css/javascript的标准是实现和支持得最好的浏览器。
■多语言支持
如果您的产品只想在中国卖，根本就不考虑世界市场，那这一条就pass好了。
Java程序跨平台需要注意什么
使用Java语言编写应用程序最大的优点在于“一次编译，处处运行”，然而这并不是说所有的Java程序都具有跨平台的特性，事实上，相当一部分的Java程序是不能在别的操作系统上正确运行的，那么如何才能编写一个真正的跨平台的Java程序呢?下面是在编写跨平台的Java程序是需要注意的一些事情：
1.编写Java跨平台应用程序时，你可以选择JDK1.0，1.1，1.2或支持它们的GUI开发工具如：Jbuilder,VisualAgeforJava等等，但是必须注意你的Java程序只能使用Java核心API包，如果要使用第三方的类库包，则该类库包也要由Java核心包开发完成，否则在发布你的程序的时候还得将支持该Java类库包的JVM发布出去。也就是说，你的程序需要是100%纯Java的。举一个例子，VisualJ++就不是纯Java的，由VisualJ++编写的程序也就不具有平台无关性。
2.无论你使用的是JDK或其他开发工具，在编译时都要打开所有的警告选项，这样编译器可以尽可能多的发现平台相关的语句，并给出警告。虽然不能保证没有编译时警告错误的程序一定是跨平台的，但含有警告错误的程序却很有可能是非平台无关的。
3.在程序中使用任何一个方法的时候，要详细察看文档，确保你使用的方法不是在文档中已经申明为过时的方法(Deprecatedmethod),也不是文档中未标明的隐含方法(Undocumentedmethod)。
4.退出Java程序时尽量不要使用java.lang.System的exit方法。Exit方法可以终止JVM，从而终止程序，但如果同时运行了另一个Java程序，使用exit方法就会让该程序也关闭，这显然不是我们希望看到的情况。事实上要退出Java程序，可以使用destory()退出一个独立运行的过程。对于多线程程序，必须要关闭各个非守护线程。只有在程序非正常退出时，才使用exit方法退出程序。
5.避免使用本地方法和本地代码，尽可能自己编写具有相应功能的Java类，改写该方法。如果一定要使用该本地方法，可以编写一个服务器程序调用该方法，然后将现在要编写的程序作为该服务器程序的客户程序，或者考虑CORBA(公共对象请求代理)程序结构。
6.Java中有一个类似于Delphi中的winexec的方法，java.lang.runtime类的exec方法，作为该方法本身是具有平台无关性的，但是给方法所调用的命令及命令参数却是与平台相关的，因此，在编写程序时要避免使用，如果一定要调用其他的程序的话，必须要让用户自己来设置该命令及其参数。比如说，在windows中可以调用notepad.exe程序，在linux中就要调用vi程序了。
7.程序设计中的所有的信息都要使用ASCII码字符集，因为并不是所有的操作系统都支持Unicode字符集，这对于跨平台的Java中文软件程序不能不说是一大噩耗。
8.在程序中不要硬性编码与平台相关的任何常量，比如行分隔符，文件分隔符，路径分隔符等等，这些常量在不同的平台上是不同的，比如文件分隔符，在UNIX和MAC中是“/”，在windows中是“\”，如果要使用这些常量，需要使用jdava.util.Properties类的getProperty方法，如java.util.Properties.getProperty(“file.separator”)可以获得文件分隔符，getProperty(“line.separator”)返回行分隔符，getProperty(“path.separator”)返回路径分隔符。
9.在编写跨平台的网络程序时，不要使用java.net.InetAddress类的getHostName方法得到主机名，因为不同的平台的主机名格式是不同的，最好使用getAddress得到格式相同的IP地址，另外，程序中所有的主机名都要换成IP地址，比如www.263.net就要换成相应的IP地址。
10.涉及文件操作的程序需要注意：不要在程序中硬性编码文件路径，理由和8中一样，只是这一点特别重要，因此单独提出。而且，不同平台对于文件名使用的字符及最大文件名长度的要求不同，编写你的程序的时候要使用一般的ASCII码字符作为文件的名字，而且不能与平台中已存在的程序同名，否则会造成冲突。
11.如果您写的程序是GUI程序，在使用AWT组件时不能硬性设置组件的大小和位置而应该使用Java的布局管理器(layoutmanager)来设置和管理可视组件的大小和位置，否则有可能造成布局混乱。
12.由于不同的操作系统，不同的机器，系统支持的颜色和屏幕的大小和分辨率都不同，如何获得这些属性呢?使用java.awt.Systemcolor类可以获得需要的颜色，如该类的inactiveCaption就是窗口边框中活动标题的背景颜色，menu则是菜单的背景颜色。使用java.awt.Toolkit的getScreenResolution可以以“象素每英寸”为单位显示屏幕的分辨率。该类的getScreenSize可以得到屏幕大小(英寸)，loadSystemColors可以列出所有的系统颜色。