馒头小金鱼航海日志

在企业上网如火如荼地普及开后，下一波企业网络建设的投资热潮将是企业总分部之间的跨INTERNET联网。现在的企业家已经认识到网络给企业生产力提高带来的巨大收益，纷纷要上OA、ERP、CRM等应用系统，甚至跨互联网部署。企业联网方案由于VPN技术的成熟和几乎“无处不在”的已经部署好的广域网——INTERNET，让这个目标的实现变的非常容易。投资的设备和通信费用更是比传统的帧中继、DDN等联网方案低很多。甚至在DDNS、目录服务等技术支持下，联网的双方都可以使用动态公网IP进行VPN部署，而不必申请奇缺昂贵的静态公网IP。
现在实现VPN联网方案的主要技术是IPSEC VPN与SSL VPN，IPSEC VPN出现得较早，商用化程度较高，技术较成熟，安全性较优越。但缺憾是设备成本支出较多，分部和移动人员需要硬件IPSec VPN客户端设备和软件IPSec VPN客户端，设置工作较复杂，维护工作较多，需要专业网管支持。SSL VPN是一项近两年才发展起来新的虚拟专网技术，由于无须安装VPN客户端（不管是硬件客户端还是软件客户端）的便捷性和因此大幅降低的实施管理成本，在国内外得到了迅速的应用和发展。
同样是VPN远程联网，SSL VPN适合于在客户、合作伙伴用户、远程用户、供应商、本单位总分机构及移动员工之间建立VPN，而IPSec VPN更适用于网段间的链接。
随时随地接入
与IPSEC VPN相比，SSL VPN更加适用于单机接入总部网络的应用需求，如移动办公，而IPSEC VPN则适用于两个固定的局域网之间构建安全通道。SSL VPN使用标准的浏览器，无需安装客户端程序，即可通过SSL VPN隧道接入总部网络访问应用。SSL VPN打破了构建VPN通道要安装专用客户端的传统，倡导的是不需客户端的“随时随地移动接入”的新概念，甚至在公共上网场合（如网吧）都能够利用SSL VPN访问内网的应用资源这点是SSL VPN最具价值的特性。但是，SSL VPN并不局限于单机移动用户，也可用于分支单位的固定用户，之所以有上述叙述，是因为与IPSec VPN作比较，其实只要能上互联网，任何被授权用户都可以访问SSL VPN。现在的总分部VPN方案也越来越多采用SSL VPN实现，原因在于它对用户的应用支持范围越来越广，功能越来越接近于传统的IPSec VPN，而且SSL VPN不受上网方式限制，SSL VPN隧道可以穿透防火墙。
安全有保障
SSL VPN容易提供更细的访问控制，可以对用户、用户组的权限、资源、服务、文件进行更加细致的控制，并可以与第三方认证系统、认证中心（CA）结合。SSL VPN安全主要包括：数据通信安全、身份认证安全两个大层次。
在数据通信安全方面，SSL VPN采用标准的安全套接层（SSL）协议对传输中的数据包进行加密。SSL协议则是浏览器自带的，加密强度为128位，对一般商用来说、完全能够满足数据传输层的安全需求。
在身份认证安全方面，SSL VPN也已经走向完善。SSL VPN可以做到基于用户个体的精细控制，基于用户和组授予不同的应用访问权限，并对相关访问操作进行审计，保证只有“正确”的用户才能访问总部发布的“正确”的应用。现在大部分的SSL VPN产品一般会采用了多重身份认证手段来实现接入者的身份认证，设备的本身内置有认证服务器，而且还可与第三方的认证系统或认证中心集成。多重认证包括：用户名及密码校验；数字证书；第三方的PKI体系；CA中心；USB KEY的认证；动态密钥等等。这些认证方式可以有效的保障接入用户身份认证的安全。对于普通企业的VPN应用可以直接采用设备本身的认证，对于要求较高的企业用户可以加入企业内部的认证系统或第三方CA认证。
另外，对于内网安全， SSL VPN更优于IPSec VPN，因为IPSec VPN打开了从分支局域网到总部局域网之间的虚拟通路，它只认证两端设备的身份，不是认证每一个访问的人而对于里面传什么数据是没有有效保障的，因此有可能造成了病毒跨网传播，而一旦可上VPN的电脑被未授权的人控制，总部网络就会存在危险。SSL VPN保障到具体的应用，只有开放了具体应用，并且只有权限的用户才允许访问、并没有给接入的用户不受限地访问内网其它资源的权限，并且没有开放到局域网，因此对总部内网更安全。
因此，基于以上分析，SSL VPN完全能够满足远程用户的接入安全需求。
应用支持多
新的SSL VPN能够实现各种基于B/S，C/S结构设计的应用程序，能够实现所有IPSec VPN所支持的所有应用，因此对于用户各种网络应用的支持越来越好、越来越多，可以说已经今非昔比。
在以前，SSL VPN只支持WEB方式的应用，为用户开发的应用必须围绕着WEB来展开，但现在已经不仅局限于WEB方式。在这一点上，现在可能仍有网友认为“SSL VPN只支持WEB应用”，这是错误的。SSL VPN之所以不需要安装任何VPN客户端，就是因为用户端的电脑中只要有浏览器、就一定会有SSL协议。SSL VPN就是用到了系统已有的SSL协议来构建安全的通道，但并不等于SSL VPN只支持WEB应用。
SSL VPN除了支持WEB应用之外，还能支持基于TCP/UDP传输协议的应用（如C/S应用软件）、支持Windows网上邻居、FTP等。SSL VPN支持C/S结构的应用程序的原理是将非WEB的应用进行重定向、在用户端将所有数据转入SSL协议通道传输，在中心端进行恢复和还原。目前各路厂家们正在不断努力研发，以使自家SSL VPN产品对用户各类特殊应用的支持越来越透明。
成本维护低
SSL VPN只需维护中心节点的SSL VPN设备，客户端免维护，降低了部署和支持费用，相比较IPSec VPN，SSL VPN的设备和维护成本是最低的。对于IPSec VPN布网来说，它是局域网与局域网之间通过互联网构建虚拟连接，需要在总部、分部分别部署一台IPSEC VPN设备，而对单个移动用户需要安装专门的客户端，因此它的设备支出多出了分部的设备部分。而SSL VPN只需在单位总部部署一台SSL VPN设备就可以，其它远程用户不管它是移动在外的员工，还是分部的员工、合作伙伴用户要做访问总部，只需打开浏览器就可以了。

由于最近经济形势的变化，很多开发人员只关注他们短期的工作前景。与此同时，把时间和精力花在学习最能带来回报的新技术上是件非常重要的事情。这里是我们列举的10种你需要马上开始学习的技术，让你的简历在未来5年不会落伍。这个列表并不完全，有很多业界的领域（比如大型机开发人员）没有涉及。尽管如此，对通常的主流开发来说，学习其中至少7项技能肯定不会错 ——不但要达到能在面试时侃侃而谈的程度，还得能在工作中运用自如。
1) 编程语言三选一 (.NET, Java, PHP)
除非开发世界有根本的改变（类似小行星击中雷德蒙），在不远的将来，大部分开发人员将需要了解三大开发平台——.NET (VB.NET或者C#), Java, 或者PHP——中的至少一个。并且只了解核心语言也是不够的。因为项目会包含越来越多不同的功能，你需要对相关框架和库有深入的了解。（本人以为C/C++可能比这三个语言更有竞争力）
2) 互联网Rich Application (RIAs)
不管爱她还是恨她，最近几年，Flash的用途突然间不仅仅是制作政治人物弱智歌曲演唱动画而已了。Flash也萌生出了以Flex和AIR为形式的附加功能。Flash的竞争对手，比如JavaFx和Silverlight，也在不停的在特性和性能上加筹码。HTML5集成了所有RIA的功能，包括数据库连接，而W3C正式地贴上了AJAX的标签。在不久的将来，RIA专家将会是简历的一个重要筛选条件。
3) Web开发
Web开发在近期内不会消失。很多开发人员满足于忽略Web或者只是使用他们的框架给他们提供的”基本元素”。但是公司需要越来越多的真正知道怎样使用底层技术进行“手工编码”的人。所以要获得成功请在未来5年里努力钻研JavaScript，CSS和HTML。
4) Web服务
REST或者SOAP？JSON或者XML？ 尽管选项和答案取决于项目本身，不使用或者创建Web服务对一个开发人员（甚至是那些不做Web应用程序的）来说越来越困难。那些原来采用ODBC，COM或者RPC domains的领域，现在也在某种程度上过渡到了Web服务。不会用Web服务的开发人员将会发现他们被排挤或者沦为维护人员。
5) 其它软实力
有一种已经开始了很久的趋势，IT在企业内部或者外部变得越来越透明。开发人员被卷入越来越多的非开发性会议和过程以给与反馈。举个例子，CFO要改变会计规则不能不依靠IT去更新系统。如果没有IT去升级CRM的工作流，运营经理就不能更改呼叫中心的流程。同样的，客户常常需要和开发小组一起工作来保证他们的需求被满足。每一个开发人员都需要找主持人帮助或者去学习《怎样结交朋友并影响别人》么？不是。但是拥有这种能力的开发人员对他们的雇主来说更有价值——并且更抢手。
6) 掌握一门动态的和/或一门函数编程语言
像Ruby，Python, F#, 和Groovy这样的语言并不很主流——但是他们包含的想法却是。比如说，微软的.NET中的LINO系统是函数编程技术的直接产物。Ruby和Python在某些部门很热门，分别感谢Rails框架和Silverlight。学习其中的一门语言不只会提升你的简历；它能开阔你的视野。我见过的每一个顶级开发人员都推荐学习至少一种动态或者函数编程语言，用来理解新的思考方式，个人经验来讲，我可以告诉你确实有用。
7）敏捷开发方法
在敏捷开发方法刚开始进入主流视线的时候，我持怀疑态度，和其他我认识的很多家伙一样。它看起来就像某种对传统的下意识反应，丢掉控制和标准而偏爱混乱。但是随着时间的推移，敏捷开发背后的智慧被更好的定义和表达出来。很多团队不是应用了敏捷开发就是在进行敏捷开发的概念证明实验。尽管敏捷开发不是治愈项目失败的终极灵药，它的确在很多项目上有一席之地。在未来几年里，对有着敏捷开发环境的理解和成功经验的开发人员的需求将会高速增涨。
相关领域知识
和敏捷开发密切关联，开发小组在项目定义中被越来越多的看做是同伴。这意味着了解问题领域的开发人员能够用更可见的，高价值的方式给项目作出贡献。敏捷开发中，一个能够说，“从这里，我们也可以很简单的添加这项功能，而且这能给我们带来很多回报，” 或者 “噢，这个要求和我们的日志中显示的使用模式并不相符” 的人将是优胜者。正如许多开发人员有抵制了解问题领域的想法，不可否认的是越来越多的组织希望（如果不是要求）开发人员至少能理解基本的内容。
9) 开发修养
几年之前，很多（如果不是大部分）团队都没有使用bug跟踪系统，版本控制，和其他类似工具；只有开发人员和他们选择的IDE。但是，感谢新的整合套件的开发，比如Microsoft Visual Studio Team System以及高质量开源环境的爆炸性发展，没用到这些工具的组织变得更不常见。开发人员必须比知道怎么在代码控制中提交和获得代码或者怎样用VM系统配置测试环境了解更多的东西。他们需要在适当的地方养成严格的卫生习惯以保证他们和其他的小组恰当的合作。“代码牛仔”，把所有的东西存放在私人USB盘上，不把对任务对象的相应改变记录成文档，等等的人，在传统的团队里不受欢迎，在需要团队成员之间紧密合作的敏捷开发环境中更是如此。
10) 移动无线开发
上世纪90年末代web开发被主流接受开始在很多领域将传统的桌面程序边缘化，在2008年，移动无线开发开始兴起，在未来5年里，它将会变得越来越重要。当然，移动开发有很多不同的方法：针对移动设备的web应用程序开发，针对市场的RIAs，和直接在设备上运行的应用程序。不管你选择了哪个方向，把移动开发加入你的技能集会保证你满足未来的需求。

Google 的使命是 Web，在 Google 眼中，未来的一切应用都将 Web 化，一直以来，Google 为 Web 开发与设计者推出了大量免费工具，让他们更好地创建，维护，改善他们的 Web 站点，这些工具包含了开发，分析，维护，修补等等用途，本文将介绍15款这样的工具。
1. Google Chrome Developer Tools

这是 Google Chrome 中类似 Firefox Firebug 以及 Web Developer Toolbar 的一个扩展，用于调试你的网页，包含一个 DOM 探测器，一个 JavaScript 调试台，可以设置执行断点和跟踪，一个类似 YSlow 的执行分析器。
2. Webmaster Tools

一个对网站拥有者来说非常有用的程序，可以帮助你从各个角度改善自己的站点。可以发现站点中的恶意程序，发现搜索引擎爬虫遇到的错误，可以发现你的 HTML 代码中需要改进的部分。还可以帮你发现你的站点中最热门的网页，并发现你站点中的错误链接。
3. Google Web Toolkit

Google Web Tootlkit （GWT）是一个 Web 开发基础框架，为开发者提供了一些基础类库，GWT 同 Google 的其它产品，如 AdWords，FeedBurner，Google Ajax 类库等紧密集成，这里有一个 Google Docs 教程。
4. Google Code [...]

Web service到底是什么；在什么情况下你应该使用Web service。
　　分布式应用程序和浏览器
　　研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。
　　传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。在我看来，结果就是一个发布容易，但开发难度大而且用户界面极其受限的应用程序。极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。不信？问问你的会计师对新的基于浏览器的会计软件有什么想法：绝大多数商用程序用户希望使用更加友好的Windows用户界面。
　　关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时，当前许多防火墙也配置为只允许HTTP连接。
　　许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上，那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。而且，目前还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的”高级程序到程序交流(APPC)”等来完成的。在以前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。只有通过Web Service，客户端和服务器才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。
　　什么是Web Service
　　对这个问题，我们至少有两种答案。从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Web service 的应用程序叫做客户。例如，你想创建一个Web service ，它的作用是返回当前的天气情况。那么你可以建立一个ASP页面，它接受邮政编码作为查询字符串，然后返回一个由逗号隔开的字符串，包含了当前的气温和天气。要调用这个ASP页面，客户端需要发送下面的这个HTTP GET请求：
　　http://host.company.com/weather.asp?zipcode=20171
　　返回的数据就应该是这样：
　　21,晴
　　这个ASP页面就应该可以算作是Web service 了。因为它基于HTTP GET请求，暴露出了一个可以通过Web调用的API。当然，Web service 还有更多的东西。
　　下面是对Web service 更精确的解释： Web services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。
　　Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。
　　新平台
　　Web service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面(interface)的平台提供了一些方法来描述界面、方法和参数（译注：如COM和COBAR中的IDL语言）。同样的，Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。最后，我们还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。下面几个小节就简要介绍了组成Web service平台的这三个技术。
　　XML和XSD
　　可扩展的标记语言(XML)是Web service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。
　　XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是64位？这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个Web service时，为了符合Web service标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。在第二章中，我们将深入XSD，学习怎样转换自定义的数据类型(例如类)到XSD的类型。
　　SOAP
　　Web service建好以后，你或者其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。实际上，SOAP在这里有点用词不当：它意味着下面的Web service是以对象的方式表示的，但事实并不一定如此：你完全可以把你的Web service写成一系列的C函数，并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。
　　WSDL
　　你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web service。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。
　　UDDI
　　Universal Description, Discovery and Integration
　　为加速Web [...]

SPSS是软件英文名称的首字母缩写，原意为Statistical Package for the Social Sciences，即“社会科学统计软件包”。但是随着SPSS产品服务领域的扩大和服务深度的增加，SPSS公司已于2000年正式将英文全称更改为Statistical Product and Service Solutions，意为“统计产品与服务解决方案”，标志着SPSS的战略方向正在做出重大调整