这段时间做项目，美工设计的界面输入框都是圆角的，确实很好看，研究了一下，实现起来真还有些麻烦

firefox，safri，chrome这些浏览器基本都一定程度支持新的CSS3标准，可以用CSS来搞定圆角：

  1: border-radius: 5px; /* css 3标准 */
  2: -moz-border-radius: 5px; /* mozilla */
  3: -webkit-border-radius: 5px; /* webkit */

可是M$的IE就麻烦了， 直道IE9 还没完整支持CSS3，就只能用背景图片法，前后补图法等等，来模拟圆角效果了

上网查了一些资料，摸索着用Flex写了一个 文件上传的工具。没做太多修饰，主要代码贴出来，免得以后忘了

   1:  <!-- filename :flashuploader.mxml -->

   2:  <?xml version="1.0" encoding="utf-8"?>

   3:  <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"

   4:                  xmlns:c="component.*"

   5:                  width="450" height="450" minWidth="460" minHeight="400" initialize="application1_initializeHandler(event)" layout="absolute">

   6:      <mx:Style source="css/main.css"/>

   7:      <mx:states>

   8:          <mx:State name="TEST">

   9:              <mx:AddChild position="lastChild" relativeTo="{filelist}">

  10:                  <c:uploadFile currentState="UploadError">

  11:                  </c:uploadFile>

  12:              </mx:AddChild>

  13:          </mx:State>

  14:      </mx:states>

  15:      <mx:LinkButton id="selectbutton" x="5" y="5" label="{selectlabel}" click="button1_clickHandler(event)"/>

  16:      <c:CountingVBox id="filelist" x="5" y="36" height="100%" maxCount="{max}"/>

  17:      <mx:Script>

  18:          <![CDATA[

  19:              import component.uploadFile;

  20:              import mx.events.FlexEvent;

  21:              private var filter:Array;

  22:              private var single:Boolean;

  23:              

  24:              private var fileRefs:FileReferenceList;

  25:              

  26:              private var fileRef:FileReference;

  27:              [Bindable]

  28:              private var max:int=10;

  29:              [Bindable]

  30:              private var selectlabel:String="文件上传";

  31:              

  32:              

  33:              

  34:              private function button1_clickHandler(event:MouseEvent):void

  35:              {

  36:                  if (single){

  37:                      fileRef = new FileReference();

  38:                      fileRef.addEventListener(Event.SELECT,singleSelectHandle);

  39:                      fileRef.browse(filter);

  40:                  }else{

  41:                      fileRefs = new FileReferenceList();

  42:                      fileRefs.addEventListener(Event.SELECT,multiSelectHandle);

  43:                      fileRefs.browse(filter);

  44:                  }

  45:              }

  46:              

  47:              private function singleSelectHandle(event:Event):void

  48:              {

  49:                  var file:uploadFile = new uploadFile();

  50:                  file.parentContainer=filelist;

  51:                  //                file.fileRef = FileReference(event.currentTarget);

  52:                  file.fileRef = fileRef;

  53:                  filelist.addChild(file);

  54:                  

  55:              }

  56:              

  57:              private function application1_initializeHandler(event:FlexEvent):void

  58:              {

  59:                  if( parameters.labelselect !=null) selectlabel = parameters.labelselect;

  60:                  if( parameters.ext != null)

  61:                      if ( parameters.type!=null)

  62:                          filter=[new FileFilter(parameters.type,parameters.ext)];

  63:                      else

  64:                          filter = [new FileFilter("Select Files"+parameters.ext, parameters.ext)];

  65:                  

  66:                  

  67:                  if (parameters.single!=null && "true" == parameters.single.toLowerCase()){

  68:                      single = true;

  69:                      max = 1;

  70:                  }else{

  71:                      if (parameters.max !=null )

  72:                          max = parameters.max ;

  73:                      if (isNaN(max)||max<=0 ) max=int.MAX_VALUE;

  74:                  }

  75:                  filelist.addEventListener("EMPTY",restoreSelectButton);

  76:                  filelist.addEventListener("FULL",disableSelectButton); 

  77:                  var prefix:String="http://localhost/fileupload";

  78:                  filelist.urlRequest = new URLRequest(prefix+"/upload.php");

  79:              }

  80:              

  81:              private function multiSelectHandle(event:Event):void

  82:              {    

  83:                  var fileList:Array=fileRefs.fileList;

  84:                  for(var i:int =0;i<fileList.length;i++){

  85:                      

  86:                      var file:uploadFile = new uploadFile();

  87:                      file.parentContainer=filelist;

  88:                      file.fileRef = fileList[i];

  89:                      filelist.addChild(file);

  90:                  }

  91:              }

  92:              

  93:              private function restoreSelectButton(event:Event):void

  94:              {

  95:                  selectbutton.visible=true;                

  96:              }

  97:              

  98:              private function disableSelectButton(event:Event):void

  99:              {

 100:                  selectbutton.visible=false;                

 101:                  

 102:              }

 103:              

 104:          ]]>

 105:      </mx:Script>    

 106:  </mx:Application>

   1:  <!-- filename: component/uploadFile.mxml -->

   2:  <?xml version="1.0" encoding="utf-8"?>

   3:  <mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml"

   4:             xmlns:c="component.*"

   5:             height="20" width="440" initialize="canvas1_initializeHandler(event)" >

   6:      <mx:states>

   7:          <mx:State name="UploadError" >

   8:              <mx:SetProperty name="label" target="{progressbar1}" value="{errorInfo}"/>

   9:              <mx:SetProperty name="styleName" value="error"/>

  10:          </mx:State>

  11:          <mx:State basedOn="UploadError" name="FileError">

  12:              <mx:SetProperty name="x" target="{image1}" value="317"/>

  13:              <mx:RemoveChild target="{progressbar1}"/>

  14:              <mx:SetStyle name="styleName" target="{label1}" value="error1"/>

  15:              <mx:SetProperty name="toolTip" target="{label1}" value="{errorInfo}"/>

  16:          </mx:State>

  17:      </mx:states>

  18:      <mx:Image x="5" width="16" height="16" source="{fileicon}" verticalCenter="-1" />

  19:      <c:FilenameLabel x="23"  width="160" text="{filename}" truncSize="10" verticalCenter="-1"/>

  20:      <mx:Label x="185" width="64" text="{extname}" verticalCenter="-1"/>

  21:      <mx:Label id="label1" x="251" width="64" text="{filesize}" textAlign="right" verticalCenter="-1"/>

  22:      <mx:ProgressBar id="progressbar1" x="317" width="100" height="16" label="%3%%" labelPlacement="center" maximum="100" source="{_fileRef}"

  23:                      verticalCenter="-1"/>

  24:      <mx:Image id="image1" x="419" width="16" height="16" click="cancle_clickHandler(event)" source="@Embed('icons/cancel.png')" verticalCenter="-1"/>

  25:      <mx:Script>

  26:          <![CDATA[

  27:              import flash.events.MouseEvent;

  28:              import flash.events.ProgressEvent;

  29:              

  30:              import mx.controls.Alert;

  31:              import mx.events.FlexEvent;

  32:              import mx.states.Transition;

  33:              

  34:              private static var MAX_FILE_SIZE:uint =int.MAX_VALUE;

  35:              

  36:              private var _parent:CountingVBox;

  37:              [Bindable]

  38:              private var _fileRef:FileReference ;

  39:              [Bindable]

  40:              private var errorInfo:String="";

  41:              [Bindable]

  42:              private var fileicon:Class;

  43:              [Bindable]

  44:              private var extname:String;

  45:              [Bindable]

  46:              private var filesize:String;

  47:              [Bindable]

  48:              private var filename:String;

  49:              

  50:              

  51:              

  52:              

  53:              public function set fileRef(value:FileReference):void

  54:              {

  55:                  _fileRef = value;

  56:                  filename=_fileRef.name.substring(0,_fileRef.name.indexOf(_fileRef.type));

  57:                  extname=_fileRef.type;

  58:                  var size:uint=_fileRef.size;

  59:                  var unit:String="B";

  60:                  if(size>10240){

  61:                      size/=1024;

  62:                      unit="KB";

  63:                  }

  64:                  if(size>10240){

  65:                      size/=1024;

  66:                      unit="MB";

  67:                  }

  68:                  if(size>10240){

  69:                      size/=1024;

  70:                      unit="GB";

  71:                  }

  72:                  

  73:                  filesize=size.toFixed(0)+unit;

  74:                  fileicon=getFileIconClass();

  75:                  if (checkFilesize()){

  76:                      _fileRef.upload(_parent.urlRequest);

  77:                      _fileRef.addEventListener(DataEvent.UPLOAD_COMPLETE_DATA,upload_complete); 

  78:                }

  79:              }

  80:              

  81:              public function set parentContainer(p:CountingVBox):void

  82:              {

  83:                  _parent = p;

  84:              }

  85:              

  86:              

  87:              private function getFileIconClass():Class

  88:              {

  89:                  [Embed("icons/Unknown.png")] 

  90:                  var unknown:Class;

  91:                  

  92:                  [Embed("icons/doc.png")]

  93:                  var doc:Class;

  94:                                  

  95:                 //其他文件类型

  96:                  

  97:                  if (_fileRef.type == null){

  98:                      return unknown;

  99:                  }

 100:                  

 101:                  var type:String=_fileRef.type.toLowerCase();

 102:                  if (type == ".doc") return doc;

 103:                  if (type == ".docx") return doc;

 104:                  //其他文件类型

 105:                  

 106:                  return unknown;                

 107:              }

 108:              

 109:              private function cancle_clickHandler(event:MouseEvent):void

 110:              {

 111:                  _fileRef.cancel();

 112:                  _parent.removeUploadedFile(_fileRef);

 113:                  _parent.removeChild(this);

 114:                  if (_parent.count<1){

 115:                      _parent.dispatchEvent(new Event("EMPTY"));

 116:                  }

 117:              }  

 118:              

 119:              protected function upload_complete(event:DataEvent):void

 120:              {

 121:                  _parent.addUploadedFile(_fileRef); 

 122:              }

 123:              

 124:              protected function upload_IO_error(event:IOErrorEvent):void

 125:              {

 126:                  errorInfo="UploadError";

 127:                currentState = "UploadError";

 128:                   

 129:              }

 130:              

 131:              private function checkFilesize():Boolean

 132:              {

 133:                  if (_fileRef.size>MAX_FILE_SIZE){

 134:                      errorInfo = "File too Big";

 135:                      currentState = "FileError";

 136:                      return false;

 137:                  }

 138:                  return true;

 139:              }

 140:              

 141:          ]]>

 142:      </mx:Script>

 143:  </mx:Canvas>

 144:   

你是否有过复查程序时发现有些注释毫无用处？程序注释是为了提高代码的可读性，为了让原作者以外的其他开发人员更容易理解这段程序。

我把这些让人郁闷的注释方式归为了五类，同时把写出这些注释的程序员也归为了五类。我希望读了这篇文章后你感觉自己不属于其中的任何一种类型。如果你有兴趣的话可以读一下另外一篇文章 五种程序员(英文)，和这篇讲到的五种程序员对比一下。

1. 高傲的程序员

public class Program

{

static void Main(string[] args)

{

string message = “Hello World!”; // 07/24/2010 Bob

 Console.WriteLine(message); // 07/24/2010 Bob

 message = “I am so proud of this code!”; // 07/24/2010 Bob

 Console.WriteLine(message); // 07/24/2010 Bob

 }

}

这种程序员是如此的欣赏自己的程序，以至于不得不在每行代码上都署上自己的大名。应该让版本控制系统来提供程序变更的信息，他这样做一眼看去并不能说明谁对这行代码负责。

2. 过时的程序员

public class Program

{

static void Main(string[] args)

{

/* 这段程序已经不再有用

* 因为我们发现千年虫问题只是一场虚惊

* 我们的系统不会恢复到1/1/1900 */

//DateTime today = DateTime.Today;

//if (today == new DateTime(1900, 1, 1))

//{

// today = today.AddYears(100);

// string message = “The date has been fixed for Y2K.”;

// Console.WriteLine(message);

//}

 }

}

如果一段程序不再有用（比如废弃了），那就删了它吧——不要被几行没用的注释搞的程序混乱不堪。即使你可能以后重用这段代码，你也可以使用版本控制系统，用它把你的程序恢复到以前的样子。

3. 天真的程序员

public class Program

{

static void Main(string[] args)

{

/* 这个程序是用来在屏幕上

* 循环打印1百万次”I Rule!”

* 每次输出一行。循环计数

* 从0开始，每次加1。

* 当计数器等于1百万时，

* 循环就会停止运行*/

for (int i = 0; i < 1000000; i++)

{

Console.WriteLine(“I Rule!”);

}

}

}

基本的编程语法规则我们大家都知道——我们不需要“编程入门”。你不需要浪费时间来解释一个显而易见的东西，我们更希望知道的是你的程序功能——那是浪费空间了。

4. 传奇的程序员

public class Program

{

static void Main(string[] args)

{

/* 有一天我在大街上的一家星巴克里

* 和销售部的Jim讨论问题，他告诉我

* 销售代表是依据以下的比例提取佣金的。

* 周五: 25%

* 周三: 15%

* 其它日期: 5%

* 我是否告诉你过我点了一个卡拉梅

* 铁咖啡和两份的Espresso?

*/

double price = 5.00;

double commissionRate;

double commission;

if (DateTime.Today.DayOfWeek == DayOfWeek.Friday)

{

commissionRate = .25;

}

else if (DateTime.Today.DayOfWeek == DayOfWeek.Wednesday)

{

commissionRate = .15;

}

else

{

commissionRate = .05;

}

commission = price * commissionRate;

}

}

如果你不得不在注释里写明需求，那也不要提到人名。销售员Jim很可能在公司里不再是销售。而且大多数读到这段注释的程序员未必都知道Jim是谁。你描述的是实际情况但跟我们的内容不相干，所以就省掉吧。

5. 未来程序员

public class Program

{

static void Main(string[] args)

{

//TODO: 将来我会修复这个问题 – 07/24/1995 Bob

 /* 我知道这个问题很难解决而且

* 我现在依赖于这个Contains函数，但

* 我以后会用一种更有意义，更

* 优雅的方式打印这段代码。

* 我只是现在没时间。

*/

string message = “An error has occurred”;

if(message.Contains(“error”))

{

throw new Exception(message);

}

}

}

这种注释是一种集大成者，它包含了上面所说的注释的所有问题。TODO注释在一个项目最初的开发阶段是非常有用的，但这个注释看起来是在好几年前的产品程序里的——它证明了程序有问题。如果程序有问题需要解决，马上解决，不要拖到日后再解决。

如果你写过这样的注释，或者是你正在寻找一种最好的注释方案，我推荐你读一读Steve McConnell写的《Code Complete》这本书。这是我推荐给所有程序员必读的六本书中的一种。或者你可以学学如何停止注释你的程序(英文)。

你是否在你的程序里还见到过其它种没有意义的或讨厌的注释？欢迎共享。

英文原文：5 Types of Comments to Avoid Making in Your Code

　　开发框架的选择，始终是个仁者见仁、智者见智的事情。尤其是Web层的开发框架，数量非常多，而且各有特色，如：Struts、WebWork、Spring MVC、Tapestry、JSF、WebPage3.0……等等。

　　下面先来看看为什么要使用Web开发框架

　　一：使用框架的必然性

　　框架，即framework。其实就是某种应用的半成品，把不同应用程序中有共性的一些东西抽取出来，做成一个半成品程序，这样的半成品就是所谓的程序框架。

　　软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。这样每次开发就不用白手起家，而是可以在这个基础上开始搭建。

　　使用框架的最大好处：减少重复开发工作量、缩短开发时间、降低开发成本。同时还有其它的好处，如：使程序设计更合理、程序运行更稳定等。基于这些原因，基本上现在在开发中，都会选用某些合适的开发框架，来帮助快速高效的开发应用系统。

　　了解了使用框架的必然性，下面来看看如何选择，当然我们的话题集中在Web层的开发框架。在谈这个问题之前，先来看看我们在Web开发中究竟需要做些什么工作：

　　二：Web层开发的工作

　　在J2EE开发中，分层是基本的思想，3层架构或者多层架构早已深入人心，在这里我们就把目光集中到Web层，看看到底Web层开发做了那些工作：

　　1：数据展示

　　Web层需要从逻辑层获取需要展示的数据，然后以合理的方式在页面进行展示

　　2：人机交互

　　用户需要从界面上输入数据，在界面上进行按钮点击，进而触发事件，标准的事件驱动模型，然后跟后台进行数据交换，出现新的界面。

　　3：收集数据，调用逻辑层接口

　　Web层收到用户的事件请求，需要调用相应的逻辑层接口来进行处理，Web层是不会有任何逻辑处理的。调用逻辑层接口，需要传递参数，这时需要收集用户在界面上输入的数据，然后进行组织，组织成为逻辑层接口需要的数据封装形式(通常都是ValueObject)。

　　4：根据逻辑层的数据来重新展示页面

　　逻辑层处理完了，需要返回数据或信息到界面上。这个时候Web层需要根据返回的值选择合适的页面，然后展示这些数据或者信息。

　　从上面可以看出，Web层开发的主要工作集中在展示上，也就是图形用户界面。这一部分是用户直观感受应用程序的窗口，也是用户要求最多的地方，其表现形式也是最丰富的。

　　三：Web层开发的步骤

　　下面再来总结一下Web层开发的大致步骤(也就是需要开发人员做的工作)：

　　注意：这里讨论的Web层开发，是不使用任何开发框架时候的开发。

　　1：写页面Html，到底有哪些数据需要在界面上表现

　　2：每个数据的具体表现形式，如：有的需要表现成为下拉列表，有的需要表现成为单选按钮等。

　　3：界面表现形式的逻辑布局，所谓逻辑布局是指某些数据的表现形式应该放在前面，某些应该放在后面;某些放在上面，某些放在下面。如：某个请假
申请的业务，有请假开始时间和结束时间，很明显开始时间的表现就应该排在结束时间的前面。而美工是负责最后页面的美观，一般美工不能动界面的逻辑布局。

　　好了，确定了值的来源，开发人员就要写代码来获取这些值，然后把这些值赋值到对应的表现形式里面。

　　5：还有一些比较特殊，也就是真实操作的是一类值，但是在界面上显示的是另一类值，比如：数据库中有用户编号，到了界面上就得显示用户姓名，但
是所有的操作都是要操作用户编号的。我们把这种情况分做：真实值和表现值，他们有一定的内在联系。这些都是要开发人员去转化和维护的。

　　6：接下来就应该开发功能性的事件响应了。用户点击了某个按钮或者触发了某个事件，首先是客户端：数据检测、客户端事件处理;然后提交到服务端，服务端要获取到客户端提交的数据，然后调用相应的逻辑层接口来响应。当然如何写逻辑层的实现这里就不去谈论了。

　　7：逻辑层执行完过后，返回数据和信息到Web层，开发人员还需要写代码去处理，选择哪个页面来显示，如何显示这些数据和信息等。

　　8：在整个交互的过程中，还必须考虑到如何控制权限，如：某些数据不能显示，某些数据不能编辑等等;同样还需要考虑到消息的配置和国际化等等。这些功能起源于逻辑层，但是实际的控制要到Web层，这些都需要开发人员来控制。

　　9：完成了上面的开发步骤，页面基本的功能开发就告一段落，接下来开发人员需要考虑页面美观的问题了。大家可能会说：“不是有美工吗，还需要开
发人员干什么?”。事实上美工多半只能出一个静态页面的美化模版，美工对于一推Java代码和Html的混杂物，多半是没有办法的，更不要说还有一些内容
是动态生成的，美工就更不可能搞定了。还是得开发人员上阵，按照美工给的模版，开始添加Css：class、id、style……

　　10：完成上面的开发，基本页面的开发工作就完成了，最后的一个步骤就是把各个页面有机的组织起来，开发应用程序的整体应用导航框架，通常就是菜单，然后把各个功能页面跟菜单结合起来，形成一个完整的应用。

　　在这里我们省略了开发期反复的调试过程，仅总结开发的步骤。

　　四：选择Web开发框架的目的

　　了解了如果没有框架，我们需要做的工作，这对选择框架有非常大的帮助。

　　框架，直白点说，就是一个半成品，能够帮我们做一些事情的半成品。

　　框架的选择，就是看哪个框架最合适，从而减少开发的工作量，提高开发的效率和质量，并有效减少维护的工作量，最终达到节约综合开发成本，获取更多的收益。

　　五：选择Web开发框架的标准

　　声明：这里所谈的选择Web开发框架的标准，只是我们的总结和一家之言，并不是放之四海而皆准的真理，请根据您的体会客观的看待我们的总结。

　　另外：我们这里更多的讨论业务功能性应用程序的Web开发框架。

　　1：选择能够对我们的开发过程提供更多、更好帮助的Web开发框架

　　2：Web开发框架的学习一定要简单，上手一定要快，没有什么比使用能得到更深的体会。那些动不动就需要半个月或者一个月学习周期的框架，实在是有些恐怖。

　　3：一定要能得到很好的技术支持，在应用的过程中，或多或少都会出现这样或者那样的问题，如果不能很快很好的解决，会对整个项目开发带来影响。一定要考虑综合成本，其实这是目前应用开源软件最大的问题，碰到问题除了死肯文档就是查阅源代码，或者是网上搜寻解决的办法，通常一个问题就会导致1-2天的开发停顿，严重的甚至需要一个星期或者更长，一个项目有上这么几次，项目整体的开发成本嗖嗖的就上去了。

　　4：Web开发框架结合其他技术的能力一定要强，比如：在逻辑层要使用Spring或者Ejb3，那么Web开发框架一定要能很容易，很方便的与它们进行结合。

　　5：Web开发框架的扩展能力一定要强。在好的框架都有力所不及的地方，这就要求能很容易的扩展Web开发框架的功能，以满足新的业务需要。同时要注意扩展的简单性，如果扩展框架的功能代价非常大，还不如不用呢。

　　6：Web开发框架最好能提供可视化的开发和配置，可视化开发对开发效率的提高，已经得到业界公认。

　　7：Web开发框架的设计结构一定要合理，应用程序会基于这个框架，框架设计的不合理会大大影响到整个应用的可扩展性。

　　8：Web开发框架一定要是运行稳定的，运行效率高的。框架的稳定性和运行效率直接影响到整个系统的稳定性和效率。

　　9：Web开发框架一定要能很好的结合目前公司的积累。在多年的开发中已有了很多积累，不能因为使用Web开发框架就不能再使用了，那未免有些得不偿失。

　　10：选择开发框架另外要注意的一点就是：任何开发框架都不可能是十全十美的，也不可能是适应所有的应用场景的，也就是说任何开发框架都有它适用的范围。所以选择的时候要注意判断应用的场景和开发框架的适用性。

　　XSS攻击，跨站脚本攻击是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。XSS攻击将对用户的web安全构成巨大的威胁。

　　XSS攻击：跨站脚本攻击(Cross Site Scripting)，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆。故将跨站脚本攻击缩写为XSS。XSS是一种经常出现在web应用中的计算机安全漏洞，它允许恶意web用户将代码植入到提供给其它用户使用的页面中。比如这些代码包括HTML代码和客户端脚本。攻击者利用XSS漏洞旁路掉访问控制——例如同源策略(same origin policy)。这种类型的漏洞由于被骇客用来编写危害性更大的phishing攻击而变得广为人知。对于跨站脚本攻击，黑客界共识是：跨站脚本攻击是新型的“缓冲区溢出攻击“，而JavaScript是新型的“ShellCode”。

　　数据来源：2007 OWASP Top 10的MITRE数据

　　注：OWASP是世界上最知名的Web安全与数据库安全研究组织

　　从这张图中我们看到，在2007年OWASP所统计的所有安全威胁中，跨站脚本攻击占到了22%，高居所有Web威胁之首。

　　XSS攻击的危害包括

　　1、盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号

　　2、控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力

　　3、盗窃企业重要的具有商业价值的资料

　　4、非法转账

　　5、强制发送电子邮件

　　6、网站挂马

　　7、控制受害者机器向其它网站发起攻击

　　XSS漏洞的分类

　　XSS漏洞按照攻击利用手法的不同，有以下三种类型：

　　类型A，本地利用漏洞，这种漏洞存在于页面中客户端脚本自身。其攻击过程如下所示：

　　Alice给Bob发送一个恶意构造了Web的URL。

　　Bob点击并查看了这个URL。

　　恶意页面中的JavaScript打开一个具有漏洞的HTML页面并将其安装在Bob电脑上。

　　具有漏洞的HTML页面包含了在Bob电脑本地域执行的JavaScript。

　　Alice的恶意脚本可以在Bob的电脑上执行Bob所持有的权限下的命令。

　　类型B，反射式漏洞，这种漏洞和类型A有些类似，不同的是Web客户端使用Server端脚本生成页面为用户提供数据时，如果未经验证的用户数据被包含在页面中而未经HTML实体编码，客户端代码便能够注入到动态页面中。其攻击过程如下：

　　Alice经常浏览某个网站，此网站为Bob所拥有。Bob的站点运行Alice使用用户名/密码进行登录，并存储敏感信息(比如银行帐户信息)。

　　Charly发现Bob的站点包含反射性的XSS漏洞。

　　Charly编写一个利用漏洞的URL，并将其冒充为来自Bob的邮件发送给Alice。

　　Alice在登录到Bob的站点后，浏览Charly提供的URL。

　　嵌入到URL中的恶意脚本在Alice的浏览器中执行，就像它直接来自Bob的服务器一样。此脚本盗窃敏感信息(授权、信用卡、帐号信息等)然后在Alice完全不知情的情况下将这些信息发送到Charly的Web站点。

　　类型C，存储式漏洞，该类型是应用最为广泛而且有可能影响到Web服务器自身安全的漏洞，骇客将攻击脚本上传到Web服务器上，使得所有访问该页面的用户都面临信息泄漏的可能，其中也包括了Web服务器的管理员。其攻击过程如下：

　　Bob拥有一个Web站点，该站点允许用户发布信息/浏览已发布的信息。

　　Charly注意到Bob的站点具有类型C的XXS漏洞。

　　Charly发布一个热点信息，吸引其它用户纷纷阅读。

　　Bob或者是任何的其他人如Alice浏览该信息，其会话cookies或者其它信息将被Charly盗走。

　　类型A直接威胁用户个体，而类型B和类型C所威胁的对象都是企业级Web应用，目前天清入侵防御产品所能防范的XSS攻击包括类型B和类型C。

　2、XSS攻击防御

　　基于特征的防御

　　XSS漏洞和著名的SQL注入漏洞一样，都是利用了Web页面的编写不完善，所以每一个漏洞所利用和针对的弱点都不尽相同。这就给XSS漏洞防御带来了困难：不可能以单一特征来概括所有XSS攻击。

　　传统XSS防御多采用特征匹配方式，在所有提交的信息中都进行匹配检查。如， 对于这种类型的XSS攻击，采用的模式匹配方法一般会需要对“javascript”这个关键字进行检索，一旦发现提交信息中包含 “javascript”，就认定为XSS攻击。这种检测方法的缺陷显而易见：骇客可以通过插入字符或完全编码的方式躲避检测：

　　躲避方法1)在javascript中加入多个tab键，得到    

　　躲避方法2) 在javascript中加入&#x09编码字符，得到 

　　躲避方法3) 在javascript中加入字符，得到    

　　躲避方法4)在javascript中的每个字符间加入回车换行符，得到

   躲避方法5)对"javascript:alert('XSS')"采用完全编码，得到

<IMGSRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29>

　　上述方法都可以很容易的躲避基于特征的检测。而除了会有大量的漏报外，基于特征的还存在大量的误报可能：在上面的例子中，对"http://www.xxx.com/javascript/kkk.asp?id=2345"这样一个URL，由于包含了关键字“javascript”，也将会触发报警。

　　基于代码修改的防御

　　和SQL注入防御一样，XSS攻击也是利用了Web页面的编写疏忽，所以还有一种方法就是从Web应用开发的角度来避免：

　　步骤1、对所有用户提交内容进行可靠的输入验证，包括对URL、查询关键字、HTTP头、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。

　　步骤2、实现Session标记(session tokens)、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。

　　步骤3、确认接收的的内容被妥善的规范化，仅包含最小的、安全的Tag(没有javascript)，去掉任何对远程内容的引用(尤其是样式表和javascript)，使用HTTP only的cookie。

　　当然，如上操作将会降低Web业务系统的可用性，用户仅能输入少量的制定字符，人与系统间的交互被降到极致，仅适用于信息发布型站点。并且考虑到很少有Web编码人员受过正规的安全培训，很难做到完全避免页面中的XSS漏洞。

　　正是由于传统检测方法存在诸多缺陷，国内厂商(如启明星辰天清入侵防御系统)并未采用这一方法，而是采用了基于攻击手法的行为检测方法。　　

　　首先对各种场景下的XSS攻击样本库进行整理和分类，并建立起XSS攻击行为特征库，在实时攻击检测阶段，对所有可能实现XSS攻击的数据来 源，如HTTP-Refere、URL、COOKIE、表单数据等，进行数据收集和初步分析，存在注入脚本的用户提交信息才进入下一步的XSS攻击判断。

　　这种分析方法有以下几点优势：

　　A：采用行为特征库而非数据特征库方式，可以避免由于检测固定特征导致的误报可能。

　　B：内置数据预处理过程，可以对所有可能包含XSS攻击的数据进行预处理，放行大部分正常HTTP请求，仅对少量疑似事件进行深入分析，提升分析速度，降低资源开销。

　　C：XSS攻击行为特征库维护由启明星辰公司AD-LAB(积极防御实验室)和博士后工作站负责，AD-LAB拥有大批漏洞发掘和分析人 员，2007年发现并获得CVE编号的漏洞数量多达26个，是国内独立发掘CVE漏洞数量最多的团队。启明星辰博士后工作站是业内第一家驻企业的信息安全 博士后工作站，为产品算法实现、研究技术转化提供有力保障。

　　3、综论

　　XSS攻击作为Web业务的最大威胁之一，不仅危害Web业务本身，对访问Web业务的用户也会带来直接的影响，如何防范和阻止XSS攻击，保障Web站点的业务安全，是定位于业务威胁防御的入侵防御产品的本职工作。只有结合对XSS攻击的分析，才能能准确的发现和防御各类XSS攻击行为，保障Web业务的正常运营。

Tags: XSS, Web, Web安全, 攻击, 网页挂马, 防御

Tags: 产品经理, 项目经理, BUG, 需求

　　ERP实施顾问在推进项目的过程中，应该注意项目团队中各成员之间的相互激励。如果激励制度设置的不当，可能项目小组成员不仅不会创造贡献，还很有可能发生内部战争，产生一些比必要的内耗。

　　ERP实施顾问在推进项目的过程中，应该注意项目团队中各成员之间的相互激励。如果激励制度设置的不当，可能项目小组成员不仅不会创造贡献，还很有可能发生内部战争，产生一些比必要的内耗。为此，实施顾问必须建立有效的只针对个人而不是成员之间的激励制度。换句话说，即将现有的个体之间的竞争，人与人之间的比较，转化为自己和自己的竞争。如果错误的将所有的项目小组成员都赶到一条独木桥上，让他们去夺取隔岸的那一颗唯一的胜利果实，那么合作将不可能形成，相互激烈就会被相互泄气所代替。

　　原则一：不要在团队内部缔造英雄。

　　在国际上，有一个著名的足球教练，他说过一句非常有哲理的话，我是记忆犹深。他说，我们足球队没有英雄，个个都是英雄。确实，在足球场上赢得胜利，不是前锋一个人的功劳，而是后卫、中锋、门卫一起的功劳。若在足球场上过度的强调进球人的贡献的话，则难免会在团队中形成隔阂。所有的光环都在射球人身上的话，那谁以后还去当这幕后的英雄呢?

　　所以，笔者认为，在ERP项目的团队中，不要塑造个人英雄。ERP项目实施小组中，没有英雄。只要项目取得成功，那么个个都是英雄，每个人都应该得到嘉奖。

　　若我们在激励员工的时候，以个人为单位进行嘉奖，会产生什么情况呢?则难免就会形成员工个人与个人之间的竞争。俗话说，人比人，气死人。这真是团队管理的禁忌。笔者认为，ERP项目要取得成功，不是靠个人之力，而是团队相互协作的结果。所以，不要在团队内部之间形成相互赛跑的局面，而应该努力培养一个自我提升的氛围。

　　2、要设置尽量多的胜利帽子，而不要造成众人抢过独木桥的现象。在足球赛场上，会按不同的位置设置不同的奖项。如最佳守门员、最佳前锋、最佳后卫等等。如此的话，每个位置的人就会坚守自己的岗位，努力做的更好。他们就不会三心二意，觉得自己所负责的位置没有出风头的机会，一心就想着去射门、去做前锋等等。如此的团队，其协作型又怎么会好呢?其实，在ERP项目中也有类似的问题。若我们在设置项目激励制度的时候，只设置了一个奖项，如把项目奖金的80%奖励给项目实施过程中有杰出贡献之人，而这人也就只有一个。那会产生什么样的情况呢?项目小组成员个个都是企业的皇子，他们就会为了争夺这个太子的位置，相互扯后腿，相互攻击。企业这是人为的造了一条独木桥。如此的话，ERP项目小组的各个成员之间，就会拉小帮派，就不会有劲往一处使了。笔者是非常反对这种做法的。笔者现在的处理方式是，以部门为单位，进行选拔。也就是说，我们ERP项目有五个部门参与的话，则把80%的奖金分为5份，每个部门一份。让每个部门自己选择一个杰出贡献人员。如此的话，就可以有效的避免部门之间的竞争，同时，又能够起到激励的作用。

Tags: 项目管理, ERP, 软件工程

　　Sun的官员日前表示MySQL 5.1开源数据库的正式版将在未来的几周内公开发布（generally available）。Sun原定于2008年更早的时候公开发布该版数据库，但为了让开发人员修复软件漏洞而不得不推迟发布时间。

　　Sun日前已经确认最新版的MySQL 5.1的所有重大漏洞已经被修复，一切都准备就绪，翘首以盼的开源用户可以期待它能够在未来的几周之内公开发布。Sun公司的数据库产品部门副主席Zack Urlocker表示，Sun的开发人员已经在很多方面对MySQL 5.1进行了反复检查和测试，确保公开发行的正式版毫无问题。

　　Sun的官员早在四月份的MySQL大会上就曾经放出消息说，这个新版的MySQL数据库会在会议结束的几周之内与大家见面。不过，为了找出 MySQL 5.1的重大漏洞并将其修复所花费的时间远远超出了Sun的预算，所以MySQL 5.1正式版的公开发布时间不得不一拖再拖。

　　市场调查机构451集团的分析师Matt Aslett表示，数周前MySQL的创始人Monty Widenius邀请MySQL的开发人员帮助公司决定是否该公开发布MySQL 5.1。很显然，该公司对之前5.0的公开发布以及5.1候选版发布时因为不够审慎所犯下的错误仍然心有余悸，以至于现在很担心会不会第三次犯错。 MySQL认为有必要公开咨询发布事宜的事实表明，公司对于漏洞报告过程信心不足，不然就是过于谨慎了。

　　Urlocker称，Sun承诺，在给该产品贴上公开发行的标签并正式推荐客户将其用在生产环境前，必须确保产品是真的没有问题可以投放市场才 行。这也是Sun为什么在产品发布候选版(RC)阶段找人来帮忙的原因。同时，Urlocker也表示，在开发人员的努力下，目前已经把客户曾经上报没有 修复的优先级为一和二的已知漏洞都修复了。

　　Forrester市场调查机构的分析师Noel Yuhanna则认为，如果MySQL要扩展其现有功能，以便为高性能的企业级环境提供支持，那么在这条提升的道路上必定会遇到困难，而Sun的延迟发布 就是最有力的证明。MySQL 5.1的研发大概耗时了三年时间，Sun对MySQL的项目一直都雄心勃勃，为此增加了大量企业级功能，以改善性能，例如基于行的复制等特性。这个功能可 以在主服务器和从服务器之间复制数据的变化，而不是实际的SQL语句。为了提高灵活性，MySQL团队还添加了混合复制功能，可以根据单个的SQL操作来 选择使用语句复制或行复制。其他的增强功能还包括支持五种不同的数据分区形式——hash分区、list分区、key分区、range分区和sub-partitioning分区，据称这项功能可以帮助客户处理超大型的数据集。考虑到这些功能都非常复杂，确实需要在研发和测试过程中投入相当大的力度，特别是如果想让这款软件能够支持大型复杂的生产环境的话。

Tags: Mysql, 产品发布, Sun

在电子信息时代，是否充分利用电子商务成为中小企业成败的关键。但在中小企业运用电子商务的过程中，会遇到一些问题，影响到中小企业的电子商务的实施。

在电子信息时代，是否充分利用电子商务成为中小企业成败的关键。“没有电子商务，企业就只能等待死亡!”或许有些偏激，但确实是企业发展壮大的基本。但在中小企业运用电子商务的过程中，会遇到一些问题，影响到中小企业的电子商务的实施。

首先，对电子商务认识不足的问题

许多中小企业管理基础落后，领导信息化意识不强，也没有充分认识到知识经济时代抢占信息市场的重要性。或者对如何开展电子商务理解比较片面，如 认为电子商务就是上网，或简单地建一个网站，而相关的管理基础却没有跟上，企业的电子商务仅停留在表面的网站建设上。因此中小企业不但在观念上要重视电子 商务，而且要了解电子商务的实质，不宜盲目跟风。

此外，电子商务不单是一个企业的事情。中小企业供应链的管理能力欠缺，如何和供应链的核心企业合作，借助其平台或第三方共享交易平台开展业务也是中小企业开展电子商务的重要话题。

其次，设施落后的问题

中小企业使用互联网和参与电子商务的程度参差不齐。据统计，目前参与电子商务的企业仅为22.3%，在众多的行业用户中，汽车行业、电子行业和 贸易行业等信息化建设水平较高。但在这些领先的行业，电子商务的应用也极不平衡，很多网站都不成熟，如网站建设目的不明确，不知道目标用户是谁，不能反映 出企业的形象，网站功能简陋，用户找不到自己需要的信息，用户的咨询也常常得不到回复等。有些企业虽然建立了网站，但过于关注于传统业务，网站利用率极 低，甚至成为一个空壳。

由于资源有限，许多中小企业需要把主要精力集中放在业务上，难以投入足够的资源进行信息化建设。但中小企业普遍对采购、生产、库存、销售、财务 和人事等方面的应用有一定需求，应用服务提供商模式ASP就成为中小型企业开展电子商务的选择。就目前ASP的发展情况而言，由于观念、安全等方面的因素 影响，ASP在国内的发展并不让人满意。

再次，执行不力的问题

由于中小型企业管理者还未充分认识到电子商务给企业发展，营销手段带来的革命性变化，因此对人才的培养没有足够的重视，导致电子商务人才的匮 乏。中小型企业开展电子商务既要技术又要人才，但这方面的人才在大企业也不是很充裕。专业人员的不足，电子商务模式缺乏创新，导致中小型企业缺乏网络经营 的经验，电子商务的优越性表现不出来，许多中小型企业涉足电子商务心有余力不足。

资金短缺是中小企业的普遍困难。在有限资金的合理使用方面，许多中小企业尚处于摸索阶段。很多中小企业对硬件的投资占到整个信息化投资80%以上，而配套软件和IT服务等方面投入相对滞后，对软件的选型不恰当，咨询合作伙伴协调不力，最终会使企业的投资回报率低，难以获得持久的发展动力。

第四、缺乏规划的问题

中小型企业开展电子商务往往缺乏长远规划，比较注意短期效益。电子商务涉及业务转型，不同企业发展电子商务的方式也是不同的。从利用互联网浏 览、收集、发布信息，到建立企业网站，建立信息平台，实施网上采购，再到建立行业联合采购平台，完善自己的供应链管理系统等，中小型企业电子商务的实施要 逐步到位，长远规划，分步实施。

电子商务在我国的发展时间不长短，中小企业对实施电子商务发展战略方面还缺乏深刻的认识，但是，“机不可失，时不我待”，在不以我们的意志为转移的、势不可挡的电子商务发展大潮面前，中小企业除了尽早实施电子商务以外，别无选择。否则，迟早要被电子商务潮流所淘汰。

最后，全球化不足的问题

当今，全球电子商务的发展是不可逆转的态势。电子商务是世界经济全球化和科技发展的必然产物，其发展势头不可阻挡，目前电子商务在技术上已初步 具备实施条件，在美国的推动下，国际组织和发达国家政府相继发表电子商务文件，而且从多边贸易自由化发展的趋势来看，不久将会有这方面的国际协议和规则出 台。而目前的电子商务国际谈判主要集中在少数发达国家之间，发展中国家若不及时参与到对话中来，不利于形成电子商务的国际框架。

对于中小企业来说，要致力于产品技术含量的提高、附加值的增加，最重要的是要增强企业的全球意识。全球电子商务专家中国诺网认为，企业要真正地 实施全球化战略，最紧迫的是提高企业的信息化程度。在融入国际市场后，已经有相当多的中小企业认识到，网站的建设尤其是直接针对客户的英文网站的建设，将 成为企业业务增长的一个关键因素;同时也是企业区别于其他同行，建立自身品牌的重要平台。而中小企业从网站的建立到托管再到维护这之间花费的金钱，与在信息化程度提高、客户来源更广、品牌价值提升后获得的利润相比，根本不值一提。正是意识到了网络的重要性，中小企业的英文网站纷纷地建了起来。

品牌化、信息化、全球化，中小为外贸企业重新迎接更大商机的必经之路。全球电子商务专家中国诺网作为国内首家成熟的全球电子商务平台，为国内中 小企业精心准备了高质量的海外空间，让国内外贸企业的网站在海外高速、稳定的运行。让全世界都能快速访问你的网站，让你的网站为你带来更多的定单!使中国 企业的全球互联梦想不再遥远。

Tags: 中小企业, SMB, 电子商务

　　从根本上说，这一现象的真正原因是出自组织体系。如果公司具备一套明确的体系，并得到管理高层的高度支持，那就可以借助相应的软件来顺利展开工作。如果本末倒置，舍体系而求软件，那恐怕世上任何一款软件都难以从本质上解决问题。

　　从管理角度来看，人们通常将问题划分为三大类：即技术与技能、价值与行为，还有组织体系。

　　一套成熟的体系并不一定要基于软件(尽管软件能起到很大的作用)。它如同一本员工手册，明确指导每位员工该做什么，何时做，以及如何去做，同时提供绩效测量和责任分配的方式。

　　体系是公司的缩影

　　从本质上说，公司就是一种体系。不同的体系造就了不同的公司特色。一套精良的体系是往往都会受到公司管理层的大力支持。公司中每个人都应参与、了解，并从中得到帮助。体系是一种收集智能、获取反馈的形式。

　　比如在CRM方面，我们就曾发现许多软件实施其实都踏入了误区。主要表现为：首先，几乎没有人去真正使用这一系统；其次，公司管理人员也忽略了这一现象。

　　从根本上说，这一现象的真正原因是出自组织体系。如果公司具备一套明确的体系，并得到管理高层的高度支持，那就可以借助相应的软件来顺利展开工 作。如果本末倒置，舍体系而求软件，那恐怕世上任何一款软件都难以从本质上解决问题。有不少公司一套接一套地实施各种软件，斥资数百万，但却忽略了体系的 重要意义。

　　大道至简

　　每一家成功的企业都有成熟完善的员工手册。这种手册是一种活文件，它会定期更新，并用来培训指导新晋员工。

　　制定公司体系不是研究航天科学，所以越简单越好。然而，有不少企业往往匮乏这一体系来与员工进行双向沟通，并测量他们的绩效。我们认为，体系是提高效率最简单的方式。

　　比如有一家专业服务公司就部署了CRM软件，并将它集成到销售与市场体系中，从而为该公司带来了显著的投资回报。这家公司所谓的“秘诀”就是设 计一套体系来达成既定目标，明确与每个责任人沟通，然后测量工作绩效。CRM软件中所获取的数据会在董事会中进行回顾检验，从中查看该公司创建了多少潜在 客户，制定了哪些流程。在这家公司中，从来没有人讨论“我们该如何让员工使用CRM”之类的问题，因为使用CRM早已被定义成工作的一部分。

　　善于借鉴

　　借鉴优秀公司在这方面的经验能帮助中小企业做的更好。很多公司都十分勤快地向CRM中录入各种联系人资料，但CRM却没有带给他们什么成长。而 一旦你制定了一套明确的体系，你的员工就知道何时该跟进案例，如何根据服务等级协议(SLA)测量绩效。CRM还是原来的CRM，但员工却有了更为明确的 工作目标与方向。

　　有些公司或许喜欢聘请外部顾问来分析自己的商业流程，但归根到底，只有你自己才最了解你的企业，也只有你自己才能量体而裁，设计出合适的体系。

　　在一个体系里，软件只是一种颇具价值的催化剂，而不是替代品。

Tags: SMB, 中小企业信息化, SaaS

　　厂商们或许总是在考虑用户需要什么产品功能或什么解决方案，那么，现在，是否可以换个角度想一下用户不需要哪些产品功能或者哪些解决方案?

　　“相比我们总在关心用户需要什么而言，或许我们很少去关注用户不需要什么，而这一点却同样值得我们去关注与重视。”酷爱绘画艺术的Trend Micro(趋势科技)全球CEO近日指出。

　　的确，对于熟悉了企业商业运作流程的IT供货商来说，满足用户需求一直被解读为对用户需要什么的回答，然而从数学的角度看，这显然不是一个充分 且必要的等式。相应地，需要在回答用户需要什么的基础上追加用户不需要什么。当然，这样的追加并非只适用于Trend Micro这一家或者这一类安全类的供应商，诸如软件及其升级功能、硬件设备、系统解决方案中各子模块功能等统统都应在追加之列。

　　随便环顾一下我们身处的网络环境，或者再稍试遥想一下网络建设之初的当年，不算完善的网络环境发展至今虽然明显有七拼八凑的嫌疑，但至少在上线 的当时，各个零散的软件或者硬件都的的确确曾经发挥过各自独有的功效。大概分析一下也不难理解，网络环境从不成形到成熟显然会经历需求在前、供应在后的阶 段，相应的产品也自然都是跟着需求一步一步建设起来的。但是到今天，相信70%以上的企业用户都深切感受到网络环境错综复杂的痛楚。这就说明人们不再一味 地需要“叠加式”的供应模式了，用户需求也已经进入需求与供应的磨合期。

　　对此，或许厂商们依然会辩驳“我们一直在挖掘和满足用户的需求，用户希望磨合的话那就磨合好了”，或者对于一些大型供应商还会拿出很多整合型的 系统解决方案……凡此种种，其实我们不难发现很多时候或很多情况下，用户的声音都被淹没了，供应商总会用方案或者产品引导用户，使得原本用户比较清晰的需 求意向演变为最终上线后的落差，久而久之，错综复杂的痛楚也将继续上演……

　　面对相似功能的产品如何选择，甚至面对不同叫法却相似功能的产品又该如何选择，对于既要满足当前网络承载的需求又须考虑未来可扩展的用户们，这些都正在成为他们所头疼的问题。

　　那么，用户到底希望怎么做呢?

　　从需求来看的话很简单，无非是“做减法”——简捷而奏效，在现有的IT资源上用最有性价比的投入同时获得原有资产的充分利用和IT设施的可持续 发展。或许从实现的角度，供应商甚至会恐惧这样的需求，但无论如何，现在用户市场出现的产品功能重叠、难以协同、采购量与功效比严重脱节等现象实在不容忽 视。

Tags: 企业信息化, 需求,

　　在未来的三至五年里，随着五个主要的消费者和商业趋势的加速发展，云计算将不断发展并且获得更广泛的应用。

　　云计算基本上是用于一个由大量的连接在一起的计算机系统组成的共享的IT基础设施的一种方法。由于它访问“虚拟”资源，云计算不受本地和远程计 算机的功率和能力的限制。云计算是下一代企业数据中心，能够像互联网一样操作，向连接到网络的用户提供极大的规模和快速的访问能力。

　　云计算为需要时的使用、降低成本和能源的使用提供一种简化的、集中的平台。与网格计算不同，网格计算是为一项具体的任务分布IT资源，云计算是在整个活动范围内使用的。受到媒体最多关注的这种平台是外部托管的服务，但是，有些是在企业内部使用的，特别是在全球运营的企业中使用。

　　在未来的三至五年里，随着五个主要的消费者和商业趋势的加速发展，云计算将不断发展并且获得更广泛的应用。

　　1.网络成为一种全球共享的通信媒介

　　目前，网络用于交换、发布和操作信息。网络内容不再像早些年那样是静态的，全球用户每一天都在改变网络内容。维基百科、Facebook和 YouTube等网站就是突出的例子。不过，这些网站只是冰山的一角。社交网络、流音频和视频和其它协作工具正在企业内部网的防火墙后面快速发展。知识工 人，特别是那些搞研发的知识工人，使用网络应用程序在全球范围内协作研究项目。

　　中国电信和欧洲专业服务公司Sogeti使用内部云计算平台在员工之间进行在线的、实时的集思广益的讨论。这个高性能的平台能够搜集Sogeti公司1.8万员工的意见并且对这些意见进行分类和分析以便应用到业务中。

　　互动、实时的通讯也称作Web 2.0，是云计算的主要推动因素。云计算能够使用现有的基础设施在极短的时间内处理大量的信息以满足动态网络的高性能的需求。

　　2.使用较少的能源的需求

　　由于担心成本问题和增加碳排放量，减少IT部门使用能源的目标正在日益受到关注。云计算更有效地使用能源，减少了运行数据中心所需要的耗电量。 过剩的计算能力会得到利用，不是打开电源，使用能源，而是保持待机状态。据研究机构Info-Tech Research Group称，大多数计算机服务器都是一直在运行的，但是，仅有10%至20%的工作负荷得到了利用。通过整合资源，云计算平台能够升级或者降级，节省能 源和运行成本。

　　3.急切需要的技术创新

　　在全球经济中，寻求更多的技术创新、把新思想更快地应用到市场和实用技术加快实现结果是推动云计算的主要动力。云计算能够随时随地在需要时以较低的成本提供强大的计算能力。

　　在中国无锡的一个工业园区，大多数新兴的软件企业都能够让员工把计算机插入网络接口访问整个公司的IT基础设施。这个工业园区与IBM合 作创建了一个云计算中心为园区内的租户提供托管的服务。IT是这个工业园区的基础设施的一部分，同取暖、照明和水一样。对于软件新型企业来说，这就意味着 降低了开发产品的成本。他们不用购买和操作自己的服务器、应用程序和工具，只需要为自己实际使用的IT服务付费。越南国家大学最新建立了一个云计算平台以 便更快地培养员工队伍的IT技能。

　4.寻求简单化

　　虽然技术的发展越来越高级，但是，用户希望技术仍然像以前一样容易使用。以服务的方式在互联网上提供软件取得的市场成功就是向简单化发展的一个 例子。软件服务也是云计算的一个先驱。通过购买一项服务，而不是直接购买软件产品，企业能够直接使用最新的软件，没有复杂性和管理成本，也不需要进行升 级。

　　云计算能够给整个IT范围带来同样的简单性。有些云计算平台是由外部托管的并且是作为一项服务购买的。这对于那些缺乏技术人员的小企业是有吸引力的。然而，许多企业，特别是大企业，可能会选择内部的平台，特别是在存在安全和隐私问题的金融等行业。

　　5.消除混乱建立结构

　　网络实现了快速访问大量的信息。但是，分类这些信息是一个挑战。谷歌等搜索技术的成功就在于满足了次序和分类的需求，因为信息的快速扩张超出了人类大脑能够处理的速度。谷歌在美国的搜索网站每个月的访问人次达到1.41亿。

　　每一天大量的互联网用户都要向全球的网站贡献数据、照片、音频和博客。没有快速和准确地找到用户需要的信息的能力，网络作为一种生产率工具的价值就会开始消失。

　　云计算是专门为消除混乱建立次序量身定做的技术。云计算提供了把各种不同种类的信息集成在一起的能力。为处理大量的数据提供了更多的计算能力，提供更简单的基础设施管理复杂性。

　　作为一种新兴的技术，云计算将随着时间的发展而变化。云计算的真正价值是能够对主要的商业和市场趋势做出反应。这些趋势未来几年将仍然存在于我们的技术环境中。

Tags: 云计算, 技术趋势, web2.0

　　此外，方便地设置和配置的虚拟机能够让数据中心更灵活和更动态化，对变化的应用程序工作量迅速做出反应。一个增加的优势是虚拟机管理程序提供的操作系统分区非常适合当前的N层的、以Web为中心的应用程序架构。

　　尽管有这些大量的好处，虚拟化对于数据中心管理员并不是一个真正的祝福。虚拟化的薄弱方面(也称作虚拟蔓延)能够很快侵蚀掉从物理向虚拟化过渡 节省的硬件和人员开支。蔓延还是一个粘糊糊的词汇。一个人的蔓延也许是另一个的适应性。但是，Embotics公司产品营销经理Anthony Mar对于这个词汇提出了这样的定义：虚拟蔓延可以定义为虚拟机没有适当的IT控制的扩散。他补充说，这不是关于虚拟机的实际数量的问题。这主要是关于虚 拟环境如何构造和控制的问题。

　　FastScale公司负责工程的副总裁Richard Offer说，鼓励这种行为被认为是零成本创建虚拟机。他指出，虚拟机是很容易创建和存储的，特别是与物理服务器相比更是如此。用户没有认识到存在着极度浪费的累积成本。

　　创建虚拟机的容易和方便性是造成蔓延的主要因素。但是，根本的原因是围绕虚拟机管理缺少管理控制和流程。Info-Tech分析师John Sloan指出，即使一家公司拥有一个除非例外全部采用虚拟化的政策，这家公司仍然需要正式的部署流程，甚至要像对待物理服务器那样对待虚拟服务器。

　　独立质询顾问Anil Desai在Embotics公司赞助的白皮书中称，虚拟机蔓延最常见的根源是没有计划和没有协调的部署、非生产的虚拟机和虚拟设备。

　　虚拟机蔓延成本增加

　　虚拟蔓延不仅是管理方面令人讨厌的问题，它还是有昂贵代价的。Mar指出，虚拟机的四类成本包括基础设施、管理系统、服务器软件和管理。在虚拟机基础设施中，虽然机器也许是虚拟的，但是，它们消费的资源是真实的。

　　Mar指出，应用程序需要处理、内存、存储和网络，无论它是否包含在虚拟机中。你拥有的虚拟机数量越多，你需要的资源就越多，它的成本就越多。

　　CiRBA公司共同创始人和首席技术官Andrew Hillier指出，他称作“朽木”的利用率不足的虚拟机或者孤儿式的虚拟机的成本会非常高，因为一个真运行而不做任何有用的工作的镜像仍然在消耗系统的内存。所有的虚拟机都要占用有价值的硬盘空间，每个ISO镜像通常占用几GB空间。

　　Mar指出，蔓延还会增加数据中心管理系统的成本，因为许多管理系统的许可证都是根据管理的节点或者客户端代理收费的。这意味着你拥有的每一台 虚拟机都有累计的许可证费用。Mar还谨慎地指出，虽然虚拟机很容易创建和部署，但是，配置、监视、升级和使用补丁等标准的系统管理活动是有管理成本的。

　　Info-Tech公司的Sloan赞成这个观点。他指出，许多服务器管理任务，如升级补丁、都把服务器当作运行的操作系统和应用程序实例处理。在这方面，100个虚拟服务器仍是100个管理实例，而不管下面的物理服务器的数量是多少。

　　由于包含各种变量，预测蔓延的财务成本是有问题的。这些变量包括没有使用的多余的机器、IT管理员逐步增加的开销、需要的新的软件许可证的数量、硬盘空间的成本和存储管理等。

　　据Embotics公司进行的调查，大多数客户认为他们公司的大约30%的虚拟机很可能是冗余的。实际的物理服务器审计证实了这个数字。这个审计指出，有些客户把冗余量定在50%以上。Embotics的客户预计他们运行一台普通服务器的成本大约是1000至3000美元。这些成本包括操作系统、应用程序、工具和相关的管理系统代理程序等软件许可证。Mar称，一个150个虚拟机的环境平均有5万至15万美元的费用与冗余的虚拟机有关。

　　由于虚拟机的设置不当，蔓延还增加了软成本，如增加的安全风险或者遵守法规的问题。

　　如何减小或者防止蔓延

　　减小蔓延的两个主要方法是恢复对虚拟机的生命周期管理控制和根据可用的物理资源优化虚拟机和相关应用程序的使用。Sloan说，改善虚拟机管理对于虚拟机厂商来说是一个积极开发和差异化的领域，因为虚拟机管理程序将很快被修改。第三方软件开发商也进入了这个领域，推出一些新的基于政策的虚拟化管理产品，特别是针对管理虚拟化环境独特难题的产品。

　　优化软件旨在通过描绘虚拟化应用程序工作量的特点并且把它们映射到数据中心的服务器池和存储中来改善可用资源的利用。比较新的方法许诺通过创建 FastScale公司所说的“动态应用程序捆绑”来显著减少虚拟机占用的资源。“动态应用程序捆绑”是一个小的、功能齐全的软件环境(一个虚拟机镜像使 用大约1%的内存)，仅需要一个应用程序需要的准备的软件组件。

　　虚拟化是一个强大的工具，允许IT部 门快速建立和部署新的系统环境，同时增加使用不足的硬件的利用率。遗憾的是虚拟机创建的简单性和方便性能够导致不太好的事情，如大量冗余的、很少使用的或 者孤儿式的虚拟镜像。如果部发现这个问题，这种虚拟蔓延将迫使企业付出巨大的成本。不过，新的管理工具和优化软件现在能够让数据中心管理员控制虚拟机环 境，更有效地把虚拟的应用程序映射到他们的物理服务器。

Tags: 虚拟化, 虚拟机, 成本.IT, 架构

　　对于小型 项目，首先，必须有文档要求，否则后期的修改、维护、升级都会变得异常困难;其次，对文档的要求应该“适度”，即够用即可。一切以便于后续工作为目标，不 做过于繁琐的要求，不应把大量精力投入进过于繁琐的文档编写。此外，还应注意文档的版本控制，保证文档和代码的一致性。

　　小型软件项目，通常是指工作量在3-12人月之间的项目，在小型软件开发企业中，这类项目一般是放任自流，少有管理。在这类项目中，项目经理的 角色常常由公司老总或部门老总亲自充当， 项目往往具有投资少、人员少、时间紧、需求不明确等特点。由于针对小型项目，缺乏科学有效的管理方式，或企业难以负担类似于大型软件开发的管理成本，这类 项目的开发过程往往会产生诸如项目进度难以控制、产品缺陷多、后期维护工作量大、客户满意度低、文档缺乏等诸多问题。一项调查表明，大约有70%的小型软 件开发项目超出了预期时间，90%以上的项目费用超出预算。因此，小型项目迫切需要引入适度的开发管理。本文将针对小型软件项目开发过程中的核心管理问题 给出一些行之有效的解决方案。

　　一、需求管理

　　对于任何类型的软件项目，需求阶段都是最重要的阶段，需求管理是整个软件项目管理的重中之重。需求管理通常包括两个大方面的问题：需求收集分析与需求变更管理。

　　首先，对于需求收集与分析，核心风险来自于需求不明确。由于客户和软件开发团队的背景不同，对同一问题的理解自然存在差异。这些差异如果不能在 需求的最初阶段尽量弥合，那么必然导致需求增加与需求更改。因此，在需求分析阶段，要求需求分析人员具有丰富的客户沟通经验，必须多花一些时间，充分了解 用户的目标与工作过程，站在客户立场上，设身处地考虑问题，帮助用户将模糊的需求清晰化，将简略的需求明细化、完善化，将混乱的需求逻辑化、条理化。

　　其次，任何项目都无法承受频繁的需求变更与需求增加。因此，除了在需求收集阶段需要尽可能将需求细化外，还需要在适当阶段尽量冻结需求。公司的 销售人员往往倾向于接受用户模糊的要求，并暗示用户“什么都好商量”。这往往给项目后期甚至项目完成后又频繁更改需求，甚至导致项目严重拖延、开支严重超 出预算埋下祸根。因此，在需求细化的后期阶段，必须“拉下脸来”，就需求冻结和后期需求增加的费用支付方式和客户达成共识。

　　二、关注项目设计的灵活性

　　对于中小型项目，在设计过程中，必须关注设计的灵活性。在实际的项目中，即使在需求阶段花再多的经历，也没法完全避免开发阶段的需求变更。因此，在架构设计中，尽可能采用灵活的设计就至关重要。对于项目设计人员，可以借鉴RUP(Rational Unified Process)中基于组建的体系结构思想，利用基于独立的、可替换的、模块化组件的体系结构管理复杂性，提高重用率，构建有弹性的、能适应变化的、易于理解的、有助于重用的体系结构。

　　三、开发进度管理

　　开发进度管理，主要需要关注如下几个方面：

　　1. 任务分配、人力资源分配、时间分配要和工程进度协调;

　　2. 任务分解要合理，并且尽量并行化;

　　3. 对项目进度控制要尽量细致，并且在实际执行过程中审查要严格;

　　4. 针对项目中不容易控制的部分，譬如技术难点、来自于客户的时间拖延要做好充分的准备;

　　5. 要为测试、缺陷修正和预期的需求变更预留足够的时间;

　　如有必要，还应采用适当的协同进度管理工具。

　　四、开发团队管理

　　对于开发团队管理，要做到分工明确、因人施用。根据水平的高低，合理分配工作量。并且关注团队内部的交流沟通结构，避免“互相等”和“误解”。尽量让每个人的工作量饱和化。在项目开始以后，要尽可能保持团队稳定，避免人员变更给团队带来的协作混乱。

　　五、配置管理和SQA

　　软件配置管理(SCM)的主要作用是标识、控制、和状态统计。

　　这些功能的意图是维护和跟踪功能、配置、产品、产品基线、需求规约和其他文档的变更，软件版本的描述;跟踪变更申请，问题报告和解决记录，提供配置控件委员会(CCB)会议纪要等。

　　软件开发之后的变更需要从多个侧面加以注意:

　　1. 任何返工都是有代价的

　　2. 将资源用于返工则无法开展新项目

　　3. 如果变更不能精确的标识和控制，那么软件的版本就会因为未知和没有记录的修改而无法跟踪

　　4. 如果变更没有考虑到所有的副作用，那么对于一个变更所引起的连锁反应的跟踪是非常费时间的

　　5. 变更次数的增加会使系统面目全非

　　当项目经常变更时候，SQA是非常重要的。SQA应该进行Pareto分析和趋势分析以确定引起变更的根本原因。SQA同时要保证系统的影响是可跟踪、可测试和可验证的。SQA的一个主要目标是在开发的早期发现问题，避免其进入下游开发中。

　　六、文档管理

　　对于小型项目，首先，必须有文档要求，否则后期的修改、维护、升级都会变得异常困难;其次，对文档的要求应该“适度”，即够用即可。一切以便于 后续工作为目标，不做过于繁琐的要求，不应把大量精力投入进过于繁琐的文档编写。此外，还应注意文档的版本控制，保证文档和代码的一致性。

Tags: SQA, 项目管理, 软件工程

Tags: QQ, Linux,

     MySQL Server将永远保留完整的功能和开放源代码，MySQL数据库驱动和新的存储引擎都将如此。此外MySQL 6.0即将加入的备份功能，MyISAM driver，加密和压缩备份功能都会继续开源。

    此举显示Sun仍然遵守开源的承诺。

Tags: Mysql, 开源, 数据库, 博客

　　在国内，作为“甲方”的电信和一些大型国企已经开始探索在IT外包应用中引入ITIL，规范管理IT外包商;作为“乙方”的IT服务商也开始探索建立符合ITIL的服务管理体系，提升服务水平。

　　从企业内部来说，国内有一个很庞大的外包群体，尤其是国资企业，他们一般采取谁开发、谁运维的外包模式，把相当一部 分维护工作外包给应用开发商，这是国内最普遍的外包形态。但是，他们在外包方面存在诸多困惑，主要困惑是不知道怎么去管理这些外包服务商，也不知道怎么去 量化这些服务，到底什么是好的服务，什么是不好的服务，服务要做到什么程度才算好的等。

　　从企业外部环境来看，目前市场上的IT外包服务商的服务水平还有待进一步提高。大多数外包商只是针对他自己开发的软硬件来提供外包服务，缺乏全 面服务能力，无法支持企业的整体IT外包需求。大多数外包商还缺乏可量化、规范的IT外包服务管理体系，这种不明朗的服务状态，让服务商和用户单位都面临 着很大的挑战：用户单位对服务质量感到不满意，而服务单位不一定能得到合理服务费用，往往只能通过持续不断的项目形式来得到回报。总之，以上两个方面的问 题都不同程度制约着IT外包应用的进一步发展。

　　从IT外包发展趋势来看，企业越来越重视IT外包服务品质，希望IT外包服务商具备规范的服务体系、较高的服务水平，哪怕价格相对高一点。

　　面临这样的挑战，IT外包双方都不得不突破原有管理模式，寻找新的发展方向。在国外，ITIL是指导企业IT外包应用的最佳实践方法，尤其在 ITILv3.0版本中增加了对外包服务管理的内容。在国内，作为“甲方”的电信和一些大型国企已经开始探索在IT外包应用中引入ITIL，规范管理IT 外包商;作为“乙方”的IT服务商也开始探索建立符合ITIL的服务管理体系，提升服务水平。

　　“甲方”关注质量监控和考核

　　对于IT外包双方来说，ITIL的价值各有不同。通过实施ITIL，作为“甲方”的用户可以更加明确IT外包双方的职责、日常要做的工作内容等，从而创建一个如何规范外包商的服务管理体系。

　　目前，大多数企业的IT外包合同内容非常简单，只简单说明一下针对哪些系统提供维护服务，全年花多少钱，派多少人常驻等。很多企业IT外包方面 的负责人所面临的挑战是：需要IT外包商提供什么样的服务水平，才能让企业业务部门满意?如果业务部门不满意，该怎么驱动IT外包商改善服务?到目前为 止，大多数IT外包合同对以上内容没有非常明确的定义。

　　另外，外包的IT设施会有一些增减变化，服务的用户数量也可能发生变化，如果在原来合同里没有明确说明改怎么办?由于缺乏一种相应的管理机制， 比如针对这些变化该如何进行协调等,那么最终就是客户吃亏或者IT外包商吃亏。通过部署ITIL的服务目录和服务水平协议，用户可以把整个外包内容细致 化、量化，明确提出IT外包商该做些什么，并把这些服务项目放进服务合同中，改变以往粗放式的合同。

　　举例来说，原来没有明确说明外包商该怎么做后台的维护工作，详细化之后，用户可以明确要求IT外包商把日常巡查管理做起来，代理厂商、代理服务 商每天要巡检几次、要巡检哪些内容;而且系统会自动检查是否做过巡检，如果两小时内没有巡检，系统就会向用户主管人员发一个短信，通知他们外包商没有做巡 检。对用户来说，这确确实实提供了一种非常便利的管理手段;对于外包商来说，通过这种规范性管理，从而帮助他们提升外包服务的管理水平。

　　通过实施ITIL，用户还可以对外包商进行量化考核。以前很多IT外包合同没有明确的考核指标，不管是对外包商还是用户，都是不公平的。举例来 说，现在用户可以对服务满意度进行量化，分为满意、不满意、比较满意等几个等级。如果70%客户满意那么就是比较满意;低于50%的客户满意，就是不满意 等。随后把这些量化的满意度指标放进合同中，明确提出今年的满意度是多少，明年要提升多少等，如果外包商达不到，就要接收惩罚。这样，考核就比较细化了。

　　总之，用户可以在外包过程中更有效地承担起质量监控和服务考核的角色。

　　“乙方”重点规范服务流程

　　通过实施ITIL，作为“乙方”的外包商可以搭建一个可量化、可视化、可控的服务管理体系，提升服务能力、服务水平、服务架构。目前，大多数 IT外包商的服务能力比较薄弱，通过部署以ITIL为基础的管理流程，外包商能够以更科学的方法学会怎么做服务、怎样配备人员、设置什么样的服务职能以及 制订日常服务规范等，从而提升了管理能力、服务能力，并进而跟踪服务成本的组成，帮助服务单位为优化和降低成本打下基础。

　　在组织体系设计上，ITIL打散以往按技术划分部门的组织体系，提供层级化的组织架构，把服务人员按照一线、二线、三线来划分。一线人员记录服 务的呼叫，并处理简单故障;二线人员处理一线解决不了的问题;三线人员解决难度较大的问题。另外，ITIL还针对不同流程设置相应的流程经理，去推动和优 化每个流程的实现。这种对服务资源进行重新整合的服务架构，把服务提供的日常职能和岗位划分清晰，不仅可以提高处理故障的效率，还使相同数量人员的服务能 力极大提高。

　　ITIL的核心是流程管理，包括故障处理流程、变更流程等十大流程。通过实施ITIL，外包商能够把日常操作全部流程化，并通过自动化工具对流程执行情况进行及时追踪。 在这个基础上，可以对各个流程的执行效果、服务质量进行量化考核和统计分析。

　　简单来说，乙方只要按照服务水平协议，做好外包的过程控制，就可以了。

　不同的实施关键点

　　对于IT外包双方来说，由于角色不同，因此导致二者在ITIL实施方面具有明显不同的特点。

　　IT外包商的服务管理体系设计与一般数据中心的相似，不同的是在开始就要规划好服务容量。因为数据中心的服务内容变化是缓慢的、渐进的，但是 IT外包商的服务内容变化的剧烈程度远远高于数据中心，这是最大的差别。因此，IT外包商的服务管理体系需要能够适应这样一种动态变化的环境，需要具备一 定弹性。比如，IT外包商当前为两个企业提供外包服务，如果第三个企业的服务合同进来时，这种服务管理体系是否能够容纳。

　　为了保持弹性，IT外包商需要重点关注人力资源的能力规划，比如多少人接多少个呼叫是合理的，边际效应是什么样，最大承受能力应该有一个范围，也就是说，一个人接多少个呼叫是不会亏本的，而且一个人最多能够承受多少个呼叫才不会使得服务质量明显下降。

　　相比IT外包商，用户不是那么关注IT外包商提供服务的细节，通常是让他的外包商来参与这些细节。只要看到外包商是按照IT服务流程和规范在运 作，就可以了。用户比较关注的是控制点，比如服务目录、服务水平协议的内容，服务质量、量化的考核指标，对故障的定义也非常关注，要求在多长时间内必须解 决故障，什么等级的故障多长时间之内不能处理，就必须升级等，这些问题是用户必须花精力来做的事情。

　　总之，ITIL可以使IT外包双方之间的沟通更快捷、高效，提高IT外包的应用效果，为IT外包应用的进一步发展提供有力支持。

Tags: ITIL, IT外包, 信息化, SaaS

　　对于许多小型企业来说，SaaS是采用先进技术的最好途径，它消除了企业购买、构建和维护基础设施和应用程序的需要，近年来，SaaS的兴起已经给传统套装软件厂商带来真实的压力。

　　SaaS是Software-as-a-service(软件即服务)的简称，它是一种通过Internet提 供软件的模式，用户不用再购买软件，而改用向提供商租用基于Web的软件，来管理企业经营活动，且无需对软件进行维护，服务提供商会全权管理和维护软件， 对于许多小型企业来说，SaaS是采用先进技术的最好途径，它消除了企业购买、构建和维护基础设施和应用程序的需要，近年来，SaaS的兴起已经给传统套 装软件厂商带来真实的压力。

　　SaaS服务提供模式

　　SaaS服务提供商为中小企业搭建信息化所需要的所有网络基础设施及软件、硬件运作平台，并负责所有前期的实施、后期的维护等一系列服务，企业无需购买软硬件、建设机房、招聘IT人 员，只需前期支付一次性的项目实施费和定期的软件租赁服务费，即可通过互联网享用信息系统。服务提供商通过有效的技术措施，可以保证每家企业数据的安全性 和保密性。企业采用SaaS服务模式在效果上与企业自建信息系统基本没有区别，但节省了大量用于购买IT产品、技术和维护运行的资金，且像打开自来水龙头 就能用水一样，方便地利用信息化系统，从而大幅度降低了中小企业信息化的门槛与风险。

　　SaaS服务的优势

　　对企业来说，SaaS的优点在于：

　　⒈ 从技术方面来看：企业无需再配备IT方面的专业技术人员，同时又能得到最新的技术应用，满足企业对信息管理的需求。

　　⒉ 从投资方面来看：企业只以相对低廉的“月费”方式投资，不用一次性投资到位，不占用过多的营运资金，从而缓解企业资金不足的压力;不用考虑成本折旧问题，并能及时获得最新硬件平台及最佳解决方案。

　　⒊ 从维护和管理方面来看：由于企业采取租用的方式来进行物流业务管理，不需要专门的维护和管理人员，也不需要为维护和管理人员支付额外费用。很大程度上缓解企业在人力、财力上的压力，使其能够集中资金对核心业务进行有效的运营。

Tags: SaaS, 中小企业，IT外包

标签: 中小企业, email营销, 用户体验, 设计

美国负责贸易的副国务卿Christopher Padilla近日对媒体表示，如果中国坚持建立自己的技术标准而不是遵循世界的标准，中国将有被“技术隔离”的危险。

他表示，中国建立自己的技术标准其实只是为了阻止外国公司进入这个世界上最大的市场而已。

Padilla说，中国正在面临日本80年代同样的问题：他们觉得自己已经够强大了，开始制定其标准而要求世界遵从起来。美国的公司已经发现在中国做生意越来越难，因为信息技术的安全标准大不相同，他们需要付出额外的代价。

他认为，现在看来中国的这种努力并没有取得成效，反而使得中国成为了一个“被隔绝的技术孤岛”。中国现在正在开发自家的3G标准，虽然这可能会让中国在短期内更有竞争力，但是长期以来会限制产品的研发，减少用户的选择范围，从而最终阻碍中国的增长。

标签: 技术标准, 3G

了解 Eclipse 插件如何使用 OSGi

Eclipse 和 OSGi 的关系，从 plugin.xml 到 manifest.mf

级别： 中级 原帖地址：http://www.ibm.com/developerworks/cn/opensource/os-ecl-osgi/index.html

Scott Delap (scott@clientjava.com), Desktop/Enterprise Java 顾问

Eclipse 集成开发环境（IDE）和 Eclipse Rich Client Platform（RCP）应用程序的核心由 Open Services Gateway Initiative（OSGi）规范的实现驱动。本文通过描述对 Eclipse 平台而言插件是什么，并跟踪从 Eclipse V2.1 到今天基于 OSGi 的实现中插件的发展，阐明了 Eclipse 与 OSGi 的关系。还解释了 OSGi manifest.mf 文件选项以及通过 Eclipse 提供的添加项。

大多数 Java™ 编程语言开发人员通过作为 IDE 的功能认识了 Eclipse。Eclipse IDE 实际上由叫做插件 的交互式组件的集合组成。这些插件组成了 IDE 的基础，它们还可用于创建其他桌面应用程序。创建基于 Eclipse 的应用程序所需的最小插件集称为 Eclipse Rich Client Platform（RCP）。但是，插件本身不能启动。它们需要在一个环境中启动和操作。Eclipse 使用 OSGi R4 规范的实现提供了该环境。

因为 Eclipse 在本质上是由 OSGi 驱动的，因此必须了解 Eclipse 插件的概念与 OSGi 框架有什么关系。在本文中，我将通过描述对 Eclipse 平台而言插件是什么来详细解释这种关系。然后，将描述在 Eclipse V2.1 平台到今天基于 OSGi 的实现中插件的发展。最后，将详细介绍应用于 Eclipse 插件的 OSGi 提供的 manifest.mf 选项。

插件是什么？

Eclipse 联机帮助将插件定义为：

“插件是为系统提供功能的代码和/或数据的结构化包。可以以代码库（带有公共 [应用程序接口] API 的 Java 类）、平台扩展甚至文档的形式来提供功能。插件可以定义扩展点、定义良好的位置，其他插件可以在这些位置添加功能。”

要注意的一个重点是插件以结构化方式提供功能。它们可以提供服务（比如日志）或可用于用户界面（UI）的功能，比如编辑器。不管什么功能，所有插件都以相同的结构化方式来定义。

到 OSGi 的发展

如前所述，Eclipse 使用 OSGi 作为插件系统的基础。但并非总是如此。早期版本的 Eclipse 也设计为插件集合，而且 Eclipse 包括自己专用的插件系统来管理交互。但是，随着 Eclipse IDE 要求的增长，必须需要一个更强壮的解决方案。这个新系统的基本要求包括动态添加新插件和停止现有插件的能力。经过大量研究之后，Eclipse 创建者决定通过实现 OSGi 框架规范替换专用的插件框架。

OSGi 是服务平台的规范。Eclipse 提供了该规范的许多可用实现之一，并用作最新 OSGi R4 规范的参考实现。OSGi 是基于 Java 的框架，旨在用于需要长运行时间、动态更新和对运行环境破坏最小的系统。起初，OSGi 旨在用于家庭自动化和家庭网关设备。最近，从手机到汽车都发现了它的踪迹。

在核心，OSGi 是一个组件和服务模型，如图 1 所示。OSGi 规范定义了一个叫做绑定包 的模块化单位。（在下文中，除非特别指明，Eclipse 术语插件 和 OSGi 术语绑定包 可交换使用，因为所有 Eclipse 插件现在都是 OSGi 绑定包。）OSGi 还提供了 Java Virtual Machine（JVM）级别的服务注册，该绑定包可用于发布、发现和绑定至服务。

OSGi 规范定义了绑定包生命周期的基础架构和绑定包的交互方式。这些规则通过使用特殊 Java 类加载器来强制执行。在一般 Java 应用程序中，CLASSPATH 中的所有类都对所有其他类可见。相反，OSGi 类加载器基于 OSGi 规范和每个绑定包的 manifest.mf 文件中指定的选项（稍后将详细介绍）来限制类交互。

Eclipse IDE 使用围绕模块化和绑定包生命周期的一个 OSGi 子集。但是，它最低限度地使用了 OSGi 提供的服务支持。相反，Eclipse 提供自己的扩展点系统来启用绑定包交互。绑定包将功能暴露给其他扩展。绑定包还定义自己的扩展点，允许其他绑定包向其贡献功能。使用 Eclipse 中扩展点的一个示例是 Preferences 窗口。核心 Eclipse 插件提供中央窗口，并暴露扩展点以允许其他首选项页面的贡献。当插件添加到 Eclipse 中时，它们可以贡献它们自己的页面。Eclipse 中扩展点的模型不同于基本的 OSGi 服务。绑定包扩展点由定义绑定包拥有；其他绑定包只对这些点做贡献。相反，任何绑定包可以实现和使用 OSGi 服务。

使用 OSGi 实现 Eclipse

在 3.1 之前版本的 Eclipse 中，在每个插件的 plugin.xml 文件中定义插件依赖关系以及扩展和扩展点。在使用 OSGi 的新版本 Eclipse 中，依赖关系信息被分解到 manifest.mf 文件中，而 plugin.xml 文件只包含扩展和扩展点的 XML 定义。看一个演示该发展的生动的工作示例十分有用。清单 1 展示了 Eclipse V3.0 中 org.eclipse.pde.ui 插件的代码段。

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin
   id="org.eclipse.pde.ui"
   name="%name"
   version="3.0.2"
   provider-name="%provider-name"
   class="org.eclipse.pde.internal.ui.PDEPlugin">

   <runtime>
      <library name="pdeui.jar">
         <export name="*"/>
      </library>

   </runtime>
   <requires>
      <import plugin="org.eclipse.core.runtime.compatibility"/>
      <import plugin="org.eclipse.ui.ide"/>
      <import plugin="org.eclipse.ui.views"/>
      <import plugin="org.eclipse.jface.text"/>

      <import plugin="org.eclipse.ui.workbench.texteditor"/>
      <import plugin="org.eclipse.ui.editors"/>
      <import plugin="org.eclipse.ant.core"/>
      <import plugin="org.eclipse.core.resources"/>
      <import plugin="org.eclipse.debug.core"/>
      <import plugin="org.eclipse.debug.ui"/>

      <import plugin="org.eclipse.help.base"/>
      <import plugin="org.eclipse.jdt.core"/>
      <import plugin="org.eclipse.jdt.debug.ui"/>
      <import plugin="org.eclipse.jdt.launching"/>
      <import plugin="org.eclipse.jdt.ui"/>
      <import plugin="org.eclipse.pde"/>

      <import plugin="org.eclipse.pde.build"/>
      <import plugin="org.eclipse.search"/>
      <import plugin="org.eclipse.team.core"/>
      <import plugin="org.eclipse.ui"/>
      <import plugin="org.eclipse.update.core"/>
      <import plugin="org.eclipse.ui.forms"/>

      <import plugin="org.eclipse.ant.ui"/>
      <import plugin="org.eclipse.jdt.junit"/>
      <import plugin="org.eclipse.ui.intro"/>
      <import plugin="org.eclipse.ui.cheatsheets"/>
   </requires>


<!-- Extension points -->
   <extension-point id="pluginContent" 
   name="%expoint.pluginContent.name" 
   schema="schema/pluginContent.exsd"/>
   <extension-point id="newExtension" 
   name="%expoint.newExtension.name" 
   schema="schema/newExtension.exsd"/>
<extension-point id="templates" 
name="%expoint.templates.name" 
schema="schema/templates.exsd"/>
<extension-point id="samples" 
name="%expoint.samples.name" 
schema="schema/samples.exsd"/>

<!-- Extensions -->
   <extension
         point="org.eclipse.ui.perspectives">

      <perspective
            name="%perspective.name"
            icon="icons/eview16/plugins.gif"
            class="org.eclipse.pde.internal.ui.PDEPerspective"
            id="org.eclipse.pde.ui.PDEPerspective">
      </perspective>
   </extension>

<export name="*"/> 声明暴露了插件中的所有包以供其他插件使用。插件依赖关系导入部分列出了 org.eclipse.pde.ui 插件需要的必备插件。

接下来两部分定义了 org.eclipse.pde.ui 可用于其他插件的扩展点以及它对其他插件的贡献。在本例中，可以看到自定义 Eclipse Plug-in Development Environment（PDE）视图的定义。

下面来看 Eclipse V3.1 中的同一插件定义。清单 2 展示了 plugin.xml 文件。

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>

    
<!-- Extension points -->
   <extension-point id="pluginContent" 
   name="%expoint.pluginContent.name" 
   schema="schema/pluginContent.exsd"/>

   <extension-point id="newExtension" 
   name="%expoint.newExtension.name" 
   schema="schema/newExtension.exsd"/>
   <extension-point id="templates" 
   name="%expoint.templates.name" 
   schema="schema/templates.exsd"/>
   <extension-point id="samples" 
   name="%expoint.samples.name" 
   schema="schema/samples.exsd"/>

<!-- Extensions -->
   <extension
         point="org.eclipse.ui.perspectives">
      <perspective
            name="%perspective.name"
            icon="icons/eview16/plugins.gif"
            class="org.eclipse.pde.internal.ui.PDEPerspective"
            id="org.eclipse.pde.ui.PDEPerspective">

      </perspective>

注意，导出和导入信息不见了。该信息现在位于清单 3 所示的 manifest.mf 文件中。

Manifest-Version: 1.0
Bundle-Name: %name
Bundle-SymbolicName: org.eclipse.pde.ui; singleton:=true
Bundle-Version: 3.1.0
Bundle-ClassPath: org.eclipse.pde.ui_3.1.0.jar
Bundle-Activator: org.eclipse.pde.internal.ui.PDEPlugin
Bundle-Vendor: %provider-name
Bundle-Localization: plugin
Require-Bundle: org.eclipse.core.runtime,
 org.eclipse.ui.ide,
 org.eclipse.ui.views,
 org.eclipse.jface.text,
 org.eclipse.ui.workbench.texteditor,
 org.eclipse.ui.editors,
 org.eclipse.ant.core,
 org.eclipse.core.resources,
 org.eclipse.debug.core,
 org.eclipse.debug.ui,
 org.eclipse.jdt.core,
 org.eclipse.jdt.debug.ui,
 org.eclipse.jdt.launching,
 org.eclipse.jdt.ui,
 org.eclipse.pde,
 org.eclipse.pde.build,
 org.eclipse.search,
 org.eclipse.team.core,
 org.eclipse.ui,
 org.eclipse.update.core,
 org.eclipse.ui.forms,
 org.eclipse.ant.ui,
 org.eclipse.jdt.junit,
 org.eclipse.ui.intro,
 org.eclipse.ui.cheatsheets,
 org.eclipse.update.configurator,
 org.eclipse.help.base
Bundle-ManifestVersion: 2
Eclipse-AutoStart: true
Export-Package: org.eclipse.pde.internal.ui;x-internal:=true,
 org.eclipse.pde.internal.ui.build;x-internal:=true,

 . . .

 org.eclipse.pde.ui,
 org.eclipse.pde.ui.internal.samples;x-internal:=true,
 org.eclipse.pde.ui.templates

各种插件导入现在被指定为必需的绑定包，* 包导出已经替换为显式导出的包列表。

插件级的依赖关系改为需要显式导出和导入包的依赖关系，当 Eclipse 宣布这个消息时，曾引起大量骚动。主要抱怨的是缺乏已经存在于 Eclipse 早期版本中的 <export name="*"/> 的替代物。但是，该省略有许多原因。最重要的原因是从显式导入和导出中获得的速度收益。早期版本的 Eclipse 必须打开并浏览每个插件 jar 文件以确定它包含哪些类。不包括 * 导出还提供了一级保护来避免插件暴露不必要的类。插件开发人员必须进行专门选择来使插件中的功能可供外部使用。该限制允许内部包保留在内部。

OSGi 清单选项

OSGi R4 框架核心目前的规范草案几乎有 PDF 格式的 300 页。介绍该规范的每个部分超出了本文范围，但我将讨论 Eclipse 插件开发人员特别感兴趣的 OSGi manifest.mf 选项：

Bundle-Activator

该类用于启动和停止绑定包。在上面的示例插件中，指定了 org.eclipse.pde.internal.ui.PDEPlugin 类。该类扩展 org.eclipse.core.runtime.Plugin，实现了 BundleActivator 接口。

Bundle-ClassPath

该属性指定要用于绑定包的 CLASSPATH。该属性可以包含对绑定包 jar 文件中目录或 jar 文件的引用。可以使用句点指明绑定包的根。在示例 Eclipse PDE 绑定包中，指定了绑定包 jar 文件中的 org.eclipse.pde.ui_3.1.0.jar。如果将插件的源版本导入工作区中，导入过程将更改绑定包 CLASSPATH 以显示为 Bundle-ClassPath:，这允许插件的开发版本挑选已编译的绑定包类。

Bundle-Version

该属性指定绑定包的版本号。包导入和必需的绑定包规范可以包括绑定包版本号。

Export-Package

该属性指定要公共暴露给其他插件的所有包。

Import-Package

该属性指定要从必需插件中显式导入的所有包。默认情况下，必须为要启动的绑定包解析所有包。还可以将包导入指定为可选项，以支持包不存在的情况。显式导入的类在 Require-Bundle 插件中的包之前解析。

Require-Bundle

该属性指定要在给定绑定包中导入使用的绑定包及其已导出的包。指定的绑定包在显式包导入之后解析。

Eclipse 提供的其他清单选项

伙伴类加载器选项 首先为 Hibernate 创建插件。然后创建一个插件，其中包含与 Hibernate 有依赖关系的特定于域的类。将下列行添加到 Hibernate 插件清单中：Eclipse-BuddyPolicy: registered。 将下列清单属性添加到包含特定于域的类或资源的插件清单中： Eclipse-RegisterBuddy: hibernate。 该行允许插件通过声明将自己暴露给 Hibernate 插件，而它预先并不知道这些插件。现在，Hibernate 插件可以看到需要的类，虽然它并没有专门导入它们。

OSGi 规范包括的 manifest.mf 配置选项不提供 Eclipse 平台需要的所有功能。因此，Eclipse 创建者添加了多个扩展（还建议将它们包括在未来版本的 OSGi 规范中）：

Export-Package 头扩展

Eclipse 具有两个 OSGi 解析器方法 —— default 和 strict，可以使用 osgi.resolver 属性指定它们。Eclipse 还包括对 Export-Package 属性的两个扩展 —— x-internal 和 x-friends，启用 Strict 模式时，会强制执行这两个扩展。

x-internal

该属性的默认值是 false。当使用该选项将内部包指定为 true 时，Eclipse PDE 禁止其使用。

x-friends

该选项类似于 x-internal，但允许特定绑定包使用具有该选项的已导出包。其他绑定包被禁止。x-internal 选项优先于 x-friends。

Eclipse-AutoStart

默认情况下，Eclipse 根据需要加载绑定包。因此，当导入绑定包包含的第一个类的绑定包需要这个类时，就会加载这些绑定包。将该值指定为 ?? 会导致 Eclipse 在启动时加载绑定包。还可以指定例外情况列表，它们是无需启动包含它们的绑定包就可以加载的类和资源。

Eclipse-PlatformFilter

该属性允许为要启动的绑定包指定必须等于 true 的条件。可以将下列信息包括在指定的表达式中：

• osgi.nl，表示语言
• osgi.os，表示操作系统
• osgi.arch，表示架构
• osgi.ws，表示窗口系统

展示如何使用该属性的一个示例是，在启动使用 SWT_AWT 桥的插件之前验证操作系统是否是 Mac OS X。（Standard Widget Toolkit（SWT）的 Mac OS X 实现当前不支持该功能。）

Eclipse-BuddyPolicy

该选项指定加载绑定包策略的类。通常，绑定包只在其内部类和从依赖绑定包中导入的内部类中具有可见性。在 Eclipse 新闻组中用来解释伙伴类加载的流行示例是 Hibernate。Hibernate 框架必须查看用户创建的而非 Hibernate 本身一部分的类和资源。这样的一种情况是当使用项目动态填充来自 Hibernate Query Language（HQL）查询的类时。默认情况下，Hibernate 将无法查看位于包含 Hibernate jar 文件的插件外部的类，而需要修改 Hibernate 插件以创建包含 Hibernate 地图不可接受的类的每个插件。幸运的是，伙伴类加载器选项 一节中介绍的伙伴类加载器选项解决了这个问题。

Eclipse 和 OSGi 的未来趋势

Eclipse 已经从使用 OSGi 中大大受益，获得了以动态方式管理组件生命周期的一个健壮的系统。新的使用方法每天都在被发掘，比如服务器层特征 servlet、JavaServer Pages 以及 Eclipse 样式插件中的其他 HTTP 资源。

Eclipse Foundation 已经决定在驱动 OSGi 规范向前发展的过程中扮演关键角色，以便于自己和其他人利用 OSGi。在从专用 Eclipse 插件框架转换到 OSGi 的过程中，对 OSGi 规范进行了许多添加，这些添加成了 OSGi R4 规范发行版的一部分。因此，Eclipse Equinox 项目已经成为不断发展的 OSGi 参考实现。该实现以及用于管理发展 OSGi 的 Java Specification Request（JSR） 291 的创建，保证了 Eclipse/OSGi 合作伙伴关系将在未来几年里不断取得成功。

标签: OSGI, 技术趋势, SOA, 组件化, JAVA, ECLIPSE

　 　对于中国数量众多的中小企业而言，在ERP系统应用方面需要进一步加深对信息化应用的理解，需要更多地深入应用而非停滞于徘徊中，尤其是已经进入应用阶 段的企业，更需要在长期的实际应用中去挖掘系统的价值。此外，在ERP系统的选择过程中，应该多学习国际经验，建立科学的产品选择观。

　　【IT专 家网独家】中小企业是我国国民经济中最具活力、并且是推动经济发展的重要力量。对于我国的中小企业而言，他们面临资金少、规模小、业务单一、员工素质不 高，管理体系不规范等亟待解决的问题。面对复杂多变的经营环境，越来越多的中小企业开始寻求信息化手段来帮助自己增强市场竞争力，希望借助先进的管理软件 来理顺生产资源和提高管理水平和效率。

　　中小企业进入成长期后，原有的管理模式将不再适应企业内外环境的变化，企业迫切需要借助信息化手段进行规范的管理，ERP的实施自然是其中不可缺少的一环。但是，中小企业从诞生之日起就有着自身的顽症和特点，如何针对这些顽症和特点来实施ERP，少走冤枉路，少花冤枉钱，提高成功率是每个中小企业主所关心的问题。

　　ERP应用是一项系统的综合工程，它包括前期论证、选型、系统实施、系统验收、二次开发等阶段，其中，ERP选型即是开始也是难点。选型决定了 整个ERP项目的方向，选型过程就如同远航船舶的舵手，如果舵手指错了方向，那么开足马力的行驶只能是偏离正确的方向越来越远。如何选型，成为摆在中小企 业面前的一道难题。

　　“只选对的，不选贵的”，这是中小企业选择的准则。“以信息化带动工业化，以工业化促进信息化”，国家明了走新型工业化道路的战略，中小企业信 息化得到前所未有的重视。然而，中小企业信息化的实践表明，数以亿计的信息化投资似乎并没有带来人们预期的收益。在中小企业信息化过程中还存在一些误区， “信息化黑洞”、“上信息化项目是找死，不上是等死”等问题的出现，始终困扰着中小企业信息化的成功实施。为此，笔者总结了在中小企业选择ERP的时候， 可以将以下内容作为参考依据：

　　一、中小企业选择ERP依据分析

　　依据一：ERP实施企业必须有准确定位。ERP项目本质上是一个管理项目，而不是纯粹的IT项目，它的导入 和实施会涉及到企业管理的方方面面，需要对企业现有的管理模式、业务流程、作业方式和作业习惯进行系统整合，以提高企业的管理水平和效率为不断完善的主 线。因此，在ERP项目选型之前，企业一定要对ERP项目作一个明确和准确的定位。一个正确的定位对项目选型乃至实施工作都可以起到极强的指导作用，直接 影响ERP项目的效果。

　　依据二：ERP上线时间必须明确。在选型之初，企业要对自身现状进行调查，了解企业的规模、人员素质、管理 模式、信息化基础等方面的情况，以明确信息化需求。中小企业具有一些共性，例如，管理基础薄弱，业务流程和组织结构都还需要不断完善，企业的发展策略可能 会随着市场的变化而不断地调整;资金投入有限，可融入资金的渠道相对较少;没有相对规范的业务流程;信息化基础薄弱，在信息化建设方面投入的资金较少，有 经验的信息化建设人才更少。除此之外，不同企业有着各自不同的特点，在分析现状时必须明确这些特点，挖掘自身不同于他人的需求，将这些作为确定ERP项目 是否上马和确定系统类别及使用年限的重要依据。

　　依据三：将企业自身的发展规划作为选型的依据。中小企业一般比较关注企业的当前需求，比如一些急需改善的问 题、急需提高的效率等。这本身是没有问题的，但是，相当多数的企业忽略了企业长期的需求、今后可能出现的问题等，也就是说，对自身的信息化建设没有一个通 盘的考虑，哪里有洞哪里补。这样做可能很快就见到了效益，而且只付出了比较小的成本，但是却为以后的信息化建设留下了隐患。今后随之而来的，可能是企业使 用的系统越来越多，越来越杂，造成数据无法整体共享、系统重复建设等问题。

　　依据四：服务提供商的选择。选择专注于某个行业的中小服务提供商，实际看重的是其背后的专业化服务团队，在 这个团队中，包括了行业的管理咨询专家、软硬件工程技术人员等，他们能从专业的角度帮助用户选型、分析、实施，乃至二次开发。因此，选择有行业背景的中小 服务提供商即可以满足企业的实际业务需求又可以节省ERP项目成本。

　　依据五：ERP项目实施预算是按时完成的关键。确定预算范围是决定选型广度的基础。由于中小企业可融入资金 的渠道相对较少，因此，要注意根据自身财务状况及ERP系统使用年限预期确定ERP项目预算框架，以保证项目顺利进行。ERP项目除了实际购买软件和支付 实施顾问企业的费用外，还需要考虑到很多的人力资源相关成本，如用户保证项目参与时间引起的加人情况、项目加班等一系列费用，这些都会对企业正常运营情况 下的整体预算成本造成很大的压力，因此，这些机动费用必须考虑在项目预算中。充足的预算是保证ERP项目按时完成的关键。

　　依据六：企业内部各部门的沟通必须充分。在选型前必须在企业中高层范围内进行讨论、确认。沟通是非常重要 的，对于中小企业来说，大多中高层都是一个家族的成员，对于大项投资的金额、时间、回报率都是非常关注的，没有大家的共识与参与，很容易导致选型成了单一 的选价格，那就失去了投资ERP项目的意义。选型沟通的另一个重点要选择ERP产品和企业适用性一定要有良好的对接，ERP产品要在企业中应用必须适合企 业的管理流程、管理需求，相当一部分现有的软件是不适合中小企业需求的，这就需要进行流程再造，对于哪些管理流程需要调整和再造，也需要在选型前和管理层 进行充分的沟通，取得一致意见，然后和服务提供商进行商榷，进行产品的升级或二次开发。

　　依据七：评价标准的设立是必要的。软件产品的功能，即产品是否能满足企业的实际业务的需求、满足到那种程度，对于部分特殊的需求，是否有针对性的解决方案。大体上而言针对软件产品有三个评价指标：

　　第一、软件产品的成熟度分析和了解。对于软件产品的成熟度可以从供应商的发展历史、在行业内拥有的客户数量和客户类型来考察。最好用公司的现有 业务数据对供应商提供的演示版进行数据测试，并且去供应商以前客户实地考察一下，了解其实施的背景、基础、过程、遇到的问题以及目前的运行状况、适用性及 稳定性等情况。将这些资料综合作为考察产品成熟度的标准。

　第二、软件产品的人性化程度分析和了解。软件产品的人性化程序主要指界面的友好性，可操作性。如视窗操作，图形化的功能界面(图形化的业务流程、 查询系统等)，与桌面主要应用系统的集成(如：与Office系统的集成等)，简便的界面和菜单功能设计，界面操作直观、简单，符合现有的系统操作习惯， 不需要额外增加软件学习成本。

　　第三、软件产品的扩展性分析和了解。软件产品的扩展性主要体现在两个方面：第一,与其他软件系统的集成，在采用现有解决方案的基础上，企业可很 容易的扩展到电子商务、办公自动化、客户关系管理、供应链管理等系统，并且所有这些解决方案都是无缝集成的。第二,系统的二次开发，在项目实施和运行的过 程中，可以对现有的系统进行功能完善，能否提供稳定可靠的二次开发能力是软件产品是否成熟的关键因素之一。

　　依据八：对ERP提供商技术实力和服务水平设立评价标准。服务提供商的技术实力和服务水平也会影响到ERP项目的成功与否。服务提供商能够为企业提供什么样的技术保障，是否有完善的售后服务体系等。大体上而言针对服务提供商有以下三个评价指标：

　　第一、服务提供商的行业经验。供应商目前实施的客户中与本公司生产和业务管理以及实施基础等方面是否有相似的类型，这可以为企业ERP项目导入上的成功提供强有力的支持。

　　第二、服务提供商的实施力量。作一个管理项目，实施顾问的管理背景和合理的知识结构、丰富的项目经验非常重要。企业实施顾问应具备企业一线管理 的经验，对企业的业务和管理运作非常熟悉，有过在类似公司的任职的经历以及多年的ERP项目实施经验等。而不能是以IT背景人员作为实施的主要力量。

　　第三、ERP软件系统的实施方法及文档管理规范。服务提供商是否能够提供完整的实施方法论体系，作为双方项目导入和实施工作的指导。好的系统必须要在科学的方法论体系的指导下实施才有可能取得真正的成功。

　　系统的文档建立和保存是整个项目成功的保障。通过科学严密的文档控制系统，不仅可以很好保证实施效果，而且即使公司出现人员调整，通过有关实施 文档纪录，新员工也可很快熟悉有关业务操作流程，降低人员培训成本和系统运行的风险。在项目实施的过程中，供应商是否有能力协助企业编制产品编码系统、业 务科目技术文档，以及各种严密的实施过程控制文档(如细化的项目实施计划、实施服务意见反馈调查表、阶段性的实施服务报告等)，细化的岗位业务操作流程、 业务改进报告等。

　　以下将列举一些在中小企业选型过程中普遍存在的误区，希望引起实施企业的注意：

　　首先、制定ERP项目的目标时，目标过高，ERP实施范围的范围过大，脱离企业的实际业务情况和现有资源。对企业内部的现有资源缺乏客观的评价，盲目上马。

　　其次、整个选型过程由IT技术部门负责，以计算机技术人员为主导，业务部门不参与选型。在实际环境中，各个部门的业务都很繁杂，ERP的应用本 身就是与各个部门密切相关的工作，别人不了解你的业务，也无法替你发表意见，只有亲自参加选型过程，才能充分理解所要选择的ERP系统，使本部门的业务需 求得到满足。

　　第三、迷信国外的服务提供商产品，造成产品的水土不服。不对软件产品进行功能性测试，只相信典型用户的参观效果。在一个公司成功的ERP软件，拿到另一个公司未必成功，在一个企业失败的ERP系统，换另一个企业则可能成功。

　　第四、过于相信供应商的承诺，决不能把承诺作为系统建设的一部分，也就是说不能把系统建立在任何承诺之上，谨慎的做法，就是把承诺当作不存在来进行系统的选型和实施。

　　最后、过于追求新技术，ERP是基于软件技术的商品，但它的目标是进行业务管理，不是为了实现某项技术。有的企业在选型的时候过分注重ERP软件的技术基础，要求必须采用B/S方式、必须跨平台等等，这犯了本末倒置的错误。

　　总而言之，ERP项目成功的关键在于企业要有较为明确的实施目标以及远景规划，从管理的角度来组织，而不是简单的软件采购行为。对于国内大多数 中小型民营企业来说，由于资源、经验乃至认识的不足，要做到一步到位绝非易事，因此必须从企业高层给予足够的重视与支持，这是ERP项目成功实施的关键。

　　二、中小企业选择ERP注意事项分析

　　第一、分析和规划自身企业信息化建设的需求。在选择ERP软件之前，企业必须首先明确自己的需求，也就是企业实现信息化要解决什么问题。当前， 很多企业还是处在传统的手工管理模式，还处在由计划经济向市场经济转换的过渡阶段，企业管理有很多不足和缺陷。解决这些问题，正是引进ERP系统的主要目 的。因此，企业在购买ERP软件之前，必须对自身的管理进行诊断和冷静的思考。在对现状进行认真分析的基础上，做好企业信息化建设的规划，在规划中确定管 理信息系统建设的目标，系统涉及的范围，要解决的关键问题，系统建设的阶段划分和进度要求，并对企业在现行条件下可投入的人力、物力、财力进行可行性分 析。

　在此基础上提出ERP软件选型的需`求任务书，提供给ERP服务提供商，作为软件选型的依据。这种信息化建设的前期规划是非常重要的，它将成为企 业信息化建设全过程的指导性文件，是各阶段实施工作的依据。“规划”的正确性是非常重要的。“规划”既要保持一定的先进性，又要具有实用性。因此，“规 划”的编制是一件非常重要和严肃的事。企业决策层要领导和参与此事，并抽调各部门的领导和业务骨干及信息化技术人员组成专门小组。如果企业缺乏对ERP了 解的人员，可以聘请社会上专业的IT咨询专家参与此项工作。

　　第二、功能是否满足企业自身的需求。在明确了企业的需求以后，使软件的选择有了依据。选择的ERP软件的功能与企业的需求相符合，是ERP软件 实施成功的关键因素。当前，在国内ERP软件市场上，ERP商品化软件种类繁多，令人眼花缭乱。有些大型ERP软件(特别是一些国外著明的ERP软件公 司)，具有强大的功能，能较好地适合各类企业的需求。但是由于种种原因，不是所有的企业都能购买这些大型ERP软件。

　　特别是占企业总数中绝大多数的中小企业，由于规模小、财力有限等原因，只能在国内ERP市场上选择那些中小型ERP软件。这些软件虽然都冠以 ERP的牌号，但由于软件开发商的历史、技术背景、应用的程度、投入的力度等的差别很大，软件功能和性能上的差异也很大。因此，企业在选择这些软件时，不 能仅仅停留在表面上，被口头上的宣传所迷惑，要对软件的功能结构进行认真地研究和考查。

　　例如对制造业企业来说，首先要考虑软件是否适合自己企业的生产类型。大家都知道，制造业的生产类型可分两大类：离散制造业和流程制造业。在离散 制造生产类型中，又可分为三种类型：多品种小批量生产、大批量流水生产、单件小批生产。这些不同的生产类型有着完全不同的生产模式(不同的生产流程、生产 计划方式、生产组织和控制方式等)。

　　对应不同生产类型，ERP软件将提供不同的生产管理解决方案相适应。多品种小批量生产类型适用MRPII/ERP传统的生产计划与控制功能，既 由主生产计划(MPS)—物料需求计划(MRP)—车间任务与作业管理组成的三级管理体系，生产管理系统的核心是物料需求计划模块，它将按零件提前期和相 适应的批量准则，组织零部件的生产和采购。因此，这类生产类型的企业在购买ERP软件时，要仔细考察软件是否具备以上提出的功能。特别是第三级计划—车间 生产作业(工序级)计划的功能，由于其数学模型比较复杂，实施难度比较大。

　　有些软件此模块的功能比较弱，甚至有些软件根本就没有此功能;对于大批量流水生产类型，在ERP软件系统中，最适合的生产管理解决方案是MRP/JIT混 合生产管理模式。在此方案中，零部件的生产准备计划和原材料的采购计划是由MPS—MRP系统去解决，而车间生产管理则采用按订单拉动的准时生产 (JIT)管理系统来完成。JIT准时生产管理系统遵循市场和订单拉动机制，真正做到按需生产。JIT的计划模式是按节拍生产的流水线生产计划。

　　在当前市场上的一些中小型ERP软件，JIT功能很弱，甚至缺乏此功能;对于单件和小批量生产类型的企业，一般是按客户订单来组织生产，按订单 的要求制造或装配，甚至是按客户的要求进行重新设计或改动产品。这种生产类型的关键是如何快速地按客户的个性化需求生产出客户需要的产品。为做到这一点， 要求ERP系统具有快速将客户对产品的技术要求转化为基础制造数据的功能，自动生成针对客户订单个性化要求的制造数据，如订单产品结购数据(OBOM)和 订单工艺路线数据等。在ERP商品化软件中，这些功能通常是由配置控制模块完成的。也可采用与ERP紧密集成PDM软件来完成。因此，这类企业在购买ERP软件前，要很好地研究着些瓶颈问题的解决方案，有针对性地考察ERP软件。

　　综上所述，要避免ERP软件选择方面的风险，企业必须做好需求分析，找到自己的特点和关键问题，做到心中有数。这样才能有针对性地考察软件，选准软件，减少由于软件与企业不匹配而造系统实施的失败。

　　第三、考察并评估ERP的成熟度。ERP软件包是一个大型的、复杂的软件，程序中的关联错综复杂。任何一个软件包都不可避免地存在着缺陷和错 误，只是程度的不同。企业应用ERP能否顺利地取得成功，与ERP软件的质量和软件的可靠性有很大的关系。因此，企业在选择ERP软件的时侯，要认真考虑 该软件是否成熟可靠，这是企业选择ERP软件的一个重要标准。

　　ERP是一个管理应用软件，它的成熟度自然与它在企业实际应用的程度有关。ERP软件在开发成功以后，除了要经过严格的试验室测试以外，更重要 的是要经过在企业中的反复应用的过程中进行不断的磨练，通过对错误和缺陷的不断修改和补充，使软件的可靠性和成熟度不断得到提高。试验室测试通是常通过人 为设计的程序和模拟数据进行的，具有一定的局限定性。而在企业现场中的实际应用，软件会经受到大量的实际数据和复杂的业务流程的考验，这是试验室条件不能 比拟的。所以，企业在选择ERP软件时，必需考查该软件公司的历史和经历，考查该软件包的形成和发展过程，以及应用的客户数和应用效果的评价，并且考查该 软件商软件版本维护的机制。一般来讲，通过大量客户工程化考验软件的质量和可靠性要高一些，企业要尽量避免成为不成熟产品的试验场。

　　第四、考察服务提供商的实施经验和能力。企业要想成功实施ERP系统，在选择ERP服务提供商时除了要认真考察该公司提供的ERP软件产品，还 要重视对该公司实施ERP能力和经验的考察。由于ERP系统的复杂性，在实施的过程中牵涉面大，要比其它的应用软件实施起来困难得多。

　　同时，ERP系统涉及的新知识和新技术较多，特别对我国企业来说，ERP属于新生事物，企业中缺乏ERP的专业人才。因此，在实施过程中需要 ERP提供商在技术上的大力支持，特别是对ERP项目的组织和实施技术更为重要。为做到这一点，大型的ERP供应商(特别是国外公司)，一般都有若干专业 的咨询公司为该软件做专门的咨询和实施服务，但对我国大多数的中小型ERP软件公司来说当前还做不到这一点。因此，要求这些公司不但提供ERP软件产品还 必须具有ERP咨询和实施服务的能力。企业在寻找ERP建设的合作伙伴时，不但要求其软件好，要更关注该公司是否具备较强的咨询和实施力量，还要考查该公 司咨询实施的经历和业绩。

　　ERP系统的实施也可以说是一种艺术，管理咨询和实施服务人员对ERP系统的经验和对企业现场管理的理解程度，对ERP实施有着重要的影响。 ERP是一个巨大的知识宝库，如何把这些丰富的功能，结合企业管理现场的实际充分地加以运用起来，就会取得可喜的效果。这正如医生看病一样，一个优秀的医 生如果只有医学理论知识是不够的，还要有大量的临床经验。医生的经验越多，他为病人的诊断就越准确，治疗方就案就越有针对性，治疗效果就越好。同样的道 理，在ERP系统实施的过程中，只有具有丰富咨询和实施经验的专家，才能为企业现行管理做出确切而中肯的诊断，才能提出优秀的解决方案，才能成功地进行系 统实施。

　　因此，企业在选择ERP合作伙伴时，要特别重视对实施经验和效果的考查，要走访该公司的成功和失败的客户，多听听客户的反映，吸取其成功的经验和总结失败的教训，保证ERP实施成功。

　　第五、ERP的选型就是选择其实际功能。由于我国ERP的开发与应用还在初级阶段，国内市场上销售的ERP软件产品在功能上和各功能解决问题的深度上都有很大差别。一般来看，MRPII系统的传统功能，如进销存、财务、生产等各软件都比较完整。

　　但在新发展起来的一些ERP功能，如JIT、CRM、SCM、DSS 等，或者缺乏，或者功能不完善。这可能是由于某些软件商的开发历史较短，应用的经验不足;同时，也由于ERP的这些新功能目前还缺乏通用的标准，这样必然 引起ERP软件商在定义这些新功能时的混乱。因此，为企业选择这些功能时造成很大困难。在选择这些功能时，不要只看表面，要看该模块实际上能解决什么问 题，特别是能否解决企业需要解决的问题。例如，决策支持是ERP系统“能动性”功能之一。在传统MRPII的决策是面向结构化问题的决策，它所解决问题的 决策过程的环境和原则是能用明确的语言描述的。而在ERP中决策支持功能增加了新内容，它要求对企业经营管理中大量的非结构化和半结构化的决策问题提供解 决方案。如新产品开发、投资决策、企业并购等决策。

　　为此，企业在选择和评价ERP软件的决策功能时，不能只从该功能的表面上看，而首先要确认企业所需决策问题的框架，进而检查软件提供的决策功能能否解决这些问题。其它的功能如JIT、CRM、SCM等 在各ERP软件提供的功能也存在很大差异，企业同样要给予注意。但是，更重要的一点，企业在考查这些软件功能的时侯，千万不要忽视该软件商实施这些软件的 经验和这些模块应用的效果。有些服务提供商在功能清单上虽然也列出了这些模块的介绍，但并没有在客户现场中应用，技术服务人员对这些模块的理解还局限在概 念上，对这些新兴功能在企业现场应用缺乏实践经验。这对该系统成功实施造成一定困难。

　　总结

　　因此，对于中国数量众多的中小企业而言，在ERP系统应用方面需要进一步加深对信息化应用的理解，需要更多地深入应用而非停滞于徘徊中，尤其是 已经进入应用阶段的企业，更需要在长期的实际应用中去挖掘系统的价值。此外，在ERP系统的选择过程中，应该多学习国际经验，建立科学的产品选择观。

　　在实施ERP系统的选型的阶段应该运用SWOT的分析方法进行对企业自身的优劣势、面对外界的机遇挑战进行分析，通过对自身人员、制度、技术、 资金、文化、实施前景等方面的详尽的分析，形成科学的预测分析。这样，才能够尽可能多地避免面对以后企业实施ERP的过程中出现的各种困难，保证ERP的 顺利实施。

标签: ERP, 信息化, 中小企业, 技术趋势

　　作为一种基于互联网的超级计算模式，云计算的核心理念是构建一个虚拟计算与存储资源的集合，并以此提供协同化的IT服务。随着SOA的普及和搜索、开放协作、社交网络等Web 2.0应用的高速成长，云计算提出的创新共享基础架构方法开始得到了主流软件厂商的广泛认同。

　　随着Sun在刚刚举行的2008 JavaOne开发者大会上宣布推出“Hydrazine”计划，集结在“云计算”旗帜之下的软件供应商又增加了一位重量级成员。基于“Hydrazine”计划，Sun希望利用其核心技术打造一个包含网络环境、数据中心和其他基础设施组件在内的完整解决方案，使得开发人员利用Sun平台创建托管应用与服务，并由此获取经济利益。凭借此举，Sun正式进军云计算领域，也由此展开了与IBM、微软、Google等巨头的新一轮竞技。

　　作为一种基于互联网的超级计算模式，云计算的核心理念是构建一个虚拟计算与存储资源的集合，并以此提供协同化的IT服务。随着SOA的普及和搜索、开放协作、社交网络等Web 2.0应用的高速成长，云计算提出的创新共享基础架构方法开始得到了主流软件厂商的广泛认同。但虽然相关构想不断推出，但直至2007年11月，IBM发布包含具体产品的“蓝云”计划，“云计算”的关注热情才被真正点燃。

　　4月22日，微软基于Web的Live Mesh平台的推出向业界表达了其争霸云计算江湖的雄心。微软CTO Ray Ozzie曾暗示，Live Mesh将帮助微软成就从个人运算向网络运算的战略转折。在Live Mesh框架中，数据中心被视作一个软件平台，可以提供远程控制、数据存储等多种服务，同样支持开发者在其上开发新的网络应用。

　　5月，云计算在消费和企业领域的两个实践先驱——IBM和Google宣布增强云计算合作，意图通过强势联盟确保在这一领域的领先位置。双方计划扩大自2007年10月启动的云计算联合研究计划，Google CEO施密特表示，“企业云”的价值高于“消费云”是促成双方合作的动因，两家公司将共同拓展云在商用领域的价值。

　　互联网方面，除了Google持续通过互联网向用户交付计算能力和服务外，Amazon.com在2007年向开发者开放了名为“弹性计算机云”的服务，为小型企业按需提供Amazon数据中心的处理能力。雅虎也在2007年将一个小规模“云”开放给卡内基-梅隆大学的研究人员。2008年1月，Salesforce.com推出了基于云计算架构的随需应变平台——DevForce，它可以帮助企业开发人员在虚拟环境中创建商业应用。

　　总之，2008年是众多软件厂商“云计划”频出、相关产品密集发布的一年。这也意味着在这片未来超级计算的乐土正酝酿着一场大争斗。随着各软件厂商云计算技术框架的不断完善，该领域的竞争将日趋激烈，也会有更多参与者加入战团。面对云计算引领计算模式变革的能力，以及其实现超级计算资源整合的结果，软件厂商们对这一领域的任何机会都不会轻言放弃。

标签: 技术趋势, 云计算, SOA

 今天早些时候，接到来自四川震区政府和摄制组的求助信息，由于一直下雨，绵阳北川地区的大量灾民情况非常堪忧，现在急需可以让灾民避雨的60万顶帐篷！根据下午四川政府最新发布的信息，全省急需帐篷总共260万顶！

借助网络的力量，让更多的人了解灾区的求助信息，协助灾区的同胞最大限度地得到帮助，是我们所有网友义不容辞的责任。为此，我们恳请广大网友在看到这一消息时，立即在您的网站上帮助发布这一信息，使得我们灾区同胞能够少度过一个冰冷潮湿的夜晚，多一份温暖。

一个网站的力量有限，联合起来力量无穷。您的帮助和努力对灾区人民是莫大的帮助，希望所有的发布商和我们一起，充分发挥我们手中互联网的力量，为抗震救灾出一份力！

标签: 地震, 求助, 汶川

　　【IT专家网独家】广告无处不在。根据几个来源的消息，平均每个人每天会接触到超过3000个广告信息。并且这不仅 仅是通过传统媒体，例如电视，广播和广告牌。你可以在纽约出租车的牌子上面看到，在你飞机椅子后面托盘的表面上面看到，甚至是在进行中的电视比赛上面。那 么为什么还要用电子邮件呢?

　　从历史上讲，电子邮件战略家出于以下几点原因不建议我们把广告放到电子新闻邮件中：

　　广告会扰乱重点，特别是那些接受这订约的首要相关内容。

　　商人通常对于放置在电子邮件中的广告中的图像，感觉和动画毫无控制力，这就导致了品牌的颜色和格调之间的冲突。

　　商人通常还对广告中动态展现的对象或者特定内容没有控制权。例如，Pontiac购买了所有的广告为来宣传他们最新的GTO，而在同一篇Car & Driver文章中，宣传的则是新的福特野马。

　　额外图像的展示干扰了递送能力，特别是“兜售的”动态GIFS会让你的品牌失去光彩。

　　在将广告放入你的电子新闻邮件之前，你还需要仔细考虑如下内容。但是这并不意味着你就不能做了。实际上，你会发现，许多商人都在他们的电子邮件信息中投放了特写广告。与其它任何媒体一样，在电子邮件中放置广告也有一些最佳方案。这里就是一些可以考虑的：

　　多大尺寸的位置最适合你的电子邮件模板?电子邮件中最常使用的和推荐的广告尺寸是68 x 60的头脚框，右边的120 x 600，250 x 250的方块，当然还有各种字体长度的文字广告。

　　看看对于你正在使用的模板来说哪个尺寸混合起来最自然。不一定就一个规划——创建2个或者3个版本，每个都使用不同的广告尺寸和布局。然后测试，测试，再测试。哪个规划的打开率最高?哪个具有最高的穿越率?最高的选择率?哪个广告位置得分最高?

　　考虑测试一下图像广告和文字广告。图像广告通常会带来更高的穿越率(媒体成本也较高)，但是你可以选择一个递送起来更加友好的文字，文字的好处就是无论信息怎么传达，它都可以显示。

　　要注意，是在你的电子邮件中添加广告，而不是变成广告。与其将每个广告为都卖出去，还不如把它们都卖给一个广告客户。这就确保了广告客户独家“拥有”，并且打开了广告客户创造和谐的广告位，从而避免混乱的画面，带来更高的业绩。

　　如果有可能的话，尝试控制内容。对于有些人来说，这很容易，但是对其他人来说则是不可能的。开发一个广告指导文档，限制令人不愉快的广告内容。 如果你可以鼓励相关的广告内容，那么就开始吧。例如，如果你的电子新闻邮件内容集中在保健，那么就要控制广告的内容是宣传保健产品和服务的。如果可能的 话，还要考虑在你的电子邮件中宣传哪个牌子——从你的身份出发来添加或者删剪它们?

　　关闭回路。尽管现在要追踪电子邮件业绩中的基本要素，例如点击率和打开率更加简单了，但是还是要将利润与点击挂钩。这通常要求进行整合，不论是 手工的还是自动的，广告客户的数据和发送电子邮件的商人的数据。了解你的电子邮件中的广告的ROI，是一个很强大的卖点，它可以让你要求更高的媒体费用。

　　说了这么多，一些电子新闻邮件就是为了展示广告而存在的。对于很多出版商来说都是这样。上面的许多围绕着测试和内容的建议仍然有用。尽管广告是发送新闻信件的第一原因，你的布局会反映出这一点。

　　当电子邮件存在的目的就是为了广告的时候，内容就是退居二线了。在这些情况中，广告应该吸引人的视线。它应该被放在“最上面”，而不是和背景混 合在一起。它应该在栏目之上，而不是埋藏在你的电子邮件中用户需要滚动才能看到它。这会确保你的广告可以抓住眼球，带来更多的点击，从而带来更多的广告利 润。

　　电子新闻邮件中的广告可以做，但是必须根据情况而定。遵循最佳方案，你可以确保广告帮助你完成目标，而不是帮倒忙。

标签: 企业信息化, 邮件推广, 广告

　 　如果代码开发人员一直以来都不能为代码使用者提供真正需要的代码开发，那所谓的最佳“企业级架构”将永远无法实现。然而，在现实中，大部分从事代码开发 的人并不会把另外一些可能需要到这些代码开发的人当作使用者去对待。这也是面向服务架构(SOA)未能获得成功的原因所在。

　　【IT专家网独家】SOA绝对不是一个单纯的IT问题，企业必须从业务角度和IT角度两方面出发分析自己的需求，根据自身现状和业务需求确定合适的SOA。 如果代码开发人员一直以来都不能为代码使用者提供真正需要的代码开发，那所谓的最佳“企业级架构”将永远无法实现。然而，在现实中，大部分从事代码开发的 人并不会把另外一些可能需要到这些代码开发的人当作使用者去对待。这也是面向服务架构(SOA)未能获得成功的原因所在。

　　SOA所能带来的价值已经是清楚的了，在这几年中我们也一直努力创造出SOA软件产品以供使用。我也知道COBOL(面向商业的通用语言，又称为企业管理语言、数据处理语言等，Common Business Oriented Langauge)应用曾经是建立在同样的原则之上。我曾作为一个项目的团队负责人参与了在遵从COBOL 74规范基础之上的超过700个核心功能服务的兴建工作，我们所编写的代码具有着高度的可重用性。当然，这也是我们为金融机构所建立起来的一个竖井中的大型系统。我们以这样的环境需求为基础构建了这一系统，并保证其可以在该企业的其他部门重复使用。

　　对于这份工作我当时是觉得非常自豪的，但是现在回想起来，我们却并不是一个非常好的使用者。我们乐于去试图找到一些非商业定制的应用从而满足我 们的主要功能需求，但是却并不是作为自身企业一个好的代码使用者而存在。我们甚至根本没有考虑过从企业现有软件应用的重用方向入手。这个问题直到现在也没 有真正改变，因为更多的时候我们只是专注于如何编写代码，并让其实现“可重用”。

　　问题的关键并不是说我们需要从代码的角度去考虑实现可重用。我们必须得明白，这些代码使用者即其他的程序开发人员和架构师。 我们必须把自己看作是服务的提供者，为这些使用者创造代码，并准确的提供给他们使用。这些代码必须是易于使用的，必须是很方便就能找到的，必须得到有效推 广和准确定位，同时也必须是能够满足使用者需求的，而在做到这一切的前提是我们应该首先成为一个好的使用者，学会如何去使用他们。

　　类似于这样对于使用者的认识以及整个企业和团队中服务的认识可能并不是一个主流的理念。就目前而言，我们对使用者还缺少足够的了解和反馈，仅仅只是感觉上的评断。

　　相对于我们的开发团队，在整个组织范围或者更广的范围内将会有更多的人能够接触到我们所能接触的使用者。如果我和我的团队是为这些使用者的服务提供者，也许在这个领域还 有更多的团队是这个使用者的服务提供者，那么我是不是应该提前就问自己一些应该被问到的问题：如果我的使用者能够自主的选择它所需要的服务提供者，那在所 有服务提供者都没出错的情况下，我应该怎样做才能确保我会是他唯一的选择，并且能持续不断的赢得这场业务?我应该怎么做才能让我的服务尽可能的便于使用?

　　在当前的市场上有不少杰出的工具可以用来支持这种对遗留应用的再次使用。这些都是资源管理中可以共同使用的内容。对于软件行业而言，这些工具能 够有助于度量之前的投资组合在实际消费的可重复使用资产的价值。而这些信息在过去一般来说是不会有的。我试图从这些工具的使用者中整理出一个具有说服力的 数字出来，但是，无法避免的是，这个数字绝不会很高。那么，如果我的统计没有出错的话，是什么阻止了我们对可重用代码的重复使用呢?

　　作为软件开发人员我们并不是好的使用者，相比之下我们的同事也许更好的处理好如何去“使用”的工作。当我们要寻找一些有用的东西或者是一些示例 的时候我们可能首先想到的是互联网而不是公司内部的资源库。当然，这其中可能的原因是企业内部缺少一个应用能够类似于网络中的搜索工具。但是，更重要的 是，当我们在编写代码的时候可能并没有想到会有别的开发人员可以使用这些内容。

　　我们并没有为我们所编写的代码内容创造接口以方便人们能够更好的使用，我们甚至根本就未曾考虑过这个问题。我们不提供设计层次的抽象内容从而有 助于其他程序员和架构师能够从我们的解决方案中选出合适的建议整合到他们的方案中去。我们并没有将代码整理给团队中没有参与的人员或者是整个企业范围的其 他团队。我们缺乏市场调研，不清楚那么没有使用我们代码的使用者究竟需要什么，无法将我们的代码开发发挥至最大效用。我们没有合理的将代码打包，使得即便 选择使用我们的使用者也觉得不易使用。

　　技术支持的工作正是因为我们的这些做法才发展起来并部分的存在于当前的工作之中。我们必须开始将我们的服务提供工作从代码层面转向到人的层面，并更有效的利用这些技术支持。紧接着我们可以利用这些工具更好的辅助市场，并能使我们的代码更广泛的提供给别人。

　　我希望在这些工作之后能够有一些好的度量重用的方式，真正显示出我们艰苦工作后所建立起的可重用软件在重复使用方面的回报。并且使用者的需求将会是真正放在第一的位置。同时，在整个SOA模型当中，服务的有效消费应该是占到一半以上的重要程度。

标签: SOA, 架构，技术趋势

标签: mysql, 开源

• 功能内聚（Functional Cohesion）：一个模块只做一件事。它们表现出了低耦合与高度重用。
• 顺序内聚（Sequential Cohesion）：一个模块包含多个需按一定次序执行的任务。
• 通讯内聚（Communication Cohesion）：一个模块包含多个基于相同输入的操作，但这些操作在执行次序方面没有任何要求。

• 过程内聚（Procedural Cohesion）：与顺序内聚相似，只不过各个任务所处理的数据各有不同。正如Steve所说：“这种内聚常常是‘为降低耦合度，人为把活动分组’的结果”。
• 时间内聚（Temporal Cohesion）：一个模块里的任务仅在时间上相关。“如果有任务要换在别的时间执行，那么这种模块会带来维护上的难题。”
• 逻辑内聚（Logical Cohesion）：一个模块里的活动由于“看似具有共同的实现”而被聚集起来。
• 偶然内聚（Coincidental Cohesion）：一个模块里的任务的唯一共同之处，就是它们均在此模块之中。

正如同耦合（coupling）一样，内聚（cohesion）对于分布式对象与服务来说仍然重要。例如，如果你仅仅因为一组方法具有相似的实现就把它们放在一个对象里，那么你将犯“创建逻辑内聚对象（logically cohesive object）”的错误。

考虑到向“新的”计算方式的转变常常伴随着对旧的方式的直接批评，所以如今对SOA的关注引起对分布式对象的激烈反对并不出乎意料。不幸的是，其实许多适合分布式对象系统的质量标准也同样适用于分布式服务与SOA。因此，有些人为了顺应潮流而被迫忽略它们是十分遗憾的。不过，也许不要紧，因为我们可以直接追溯到对象之前的时期，搞清楚像耦合和内聚这样的度量标准，并重新运用它们。

有 些软件是高内聚、紧耦合的。这意味着，尽管它经过合理的设计，但由于存在紧密的相互依赖关系，所以不容易被修改。那是很糟糕的；而且很不幸地是，这在企业 应用中很常见。还记得若干年前的确给你留下深刻印象，但如今维护起来却令你痛苦不堪的软件吗？原因就在于它是紧耦合的。

松耦合、低内聚的软件是另一种糟糕的软件。这意味着模块之间少有明显的相互依赖；但是，没有一个模块是在系统中某方面处 于权威地位的。这进而造成需用“散弹法（scattergun approach）”来解决持续的系统演化，因为即使很小的改动也会波及多个组件或系统。也就是我们今天所认识到的SOA。

一方面，我们倾向于（而且确实在SOA那 帮人的怂恿之下）认为这种架构是非常符合目标的，因为它是极度松耦合的。既然每个组件或服务都与其他别的组件或服务没有耦合，那么应该可以像玩乐高积木那 样、按无数种方式来组织或调整它们。书上教我们用一组基础服务来构建“业务服务（business services）”。事实上，我们甚至可以用BPM工具“选择-点击”来轻而易举地达到那个目标，从而避免了如开发者与一直伴随左右的变更管理这样的开 销。是吗？ 不。实际上根本不是。[……] 这是对架构的幻想，在真实世界的企业系统里是不可能的。实际上，一个不解决业务问题的服务根本没有资格进入SOA。

嗯，有人一直试图单枪匹马地用一种“面向其他架构（Something Else Oriented Architecture）”来推翻SOA， 那就是MEST支持者Jim Webber。[……] 我觉得他这篇文章纯属误导。也许有些地方我理解不当，但Jim说的是内聚与松耦合的关系。[……] 在我看来，内聚（cohesion）听起来是个不错的工程原则，它很像“依赖结构矩阵（Dependency Structure Matrix）”。[……] 松耦合（loose coupling）的目标正是降低内聚。一个互联的（connected）系统是不存在内聚的。内聚和耦合不可能同时存在。即使在英语里，把这两个词联系 在一起也是很糟糕的。

松耦合的目标，是使得在不同时间、用不同技术、具有不同安全模型的代码片断可以一同工作。

SOA是 要远离内聚的系统、转而支持更广泛的重用场景。多层内聚的系统提供“多层”（像库一样的）重用模型：上层可以重用下层。不幸的是，它强迫我们以一种与理想 的信息系统架构不兼容的方式来创建系统。问题出在内聚，而解决之道在于松耦合。Jim，你真以为人们都在试图“把东西放在一个模块里”吗？

有些人老拿他们5年前形成的观念来看“SOA”，而那只是被他们自己错误理解的SOA，这种情形让我觉得越来越不愉快。Jim所展现的是一幅陈旧的、并不能代表2008年的SOA的情景。

…… 对于服务的接口与实现设计，内聚（cohesion）完全是一种没有必要的约束，它实际上会降低一个服务的重用程度、并减弱它参与不同组装的能力。也许我 们该对现代松耦合的概念作一些了解了，比如：双向接口（bi-directional interfaces）、组装（assemblies）、编制语言（orchestration languages）、可扩展及语义可达的数据结构（extensible and semantically accessible data structures）。过去设计出那些古老的编程技巧，就是因为编程模型里没有这些概念。

但是争论仍在继续。内聚跟SOA是不是本质对立的？例如，我们是否需要重写软件工程书籍以涵盖跟SOA有关的内聚？当然，内聚本身并无坏处；不过，也许内聚跟耦合一样是分不同程度的，而且不能搞一刀切？

本文转自infoQ中文站  作者 Mark Little   译者 徐涵

标签: 技术趋势, SOA

　　由于 SCA规范面向企业应用集成，因此SCA构件的实现可以是Java，BPEL，EJB，WebService。从现有的已经实现的产品来看，OSGI更多 的被用来作为单一产品的整体架构，SCA规范更多的是被用在面向业务的构件的组装规范，至于SCA产品的架构如何则不是SCA规范所关心的。

　　最近一段时间先后看了SCA规范和OSGI的规范。看完之后再对二者作一个全面的比较。

　　首先，两个规范制定的出发点和初衷是不一样的。SCA规范是为了企业应用集成而制定，OSGI规范的初衷则是为移动设备计算而制定的。由于二者 的出发点不一样，导致了两个规范的侧重点不一样。SCA规范现在的版本是0.95，相对OSGI规范的4.0版本还显得多少有些稚嫩。

　　SCA规范中着重解决了现有企业应用之间的相互调用和企业应用如何以面向服务的思想来建立和部署。但是对于构件容器的实现方面的规定则有些不足，仅仅是站在使用者的角度描述了客户端API的规格。

　　而OSGI规范因为最初的出发点是为了移动设备的计算环境，因此更多的考虑了运行时框架和服务在运行时刻的动态匹配等问题。此外，提供了运行时刻应用程序的热部署、解析、运行、卸载等能力。应该说，OSGI规范发展到4.0已经是一个比较完善的规范了。

　　SCA规范中目前对SCA容器的实现尚没有一个指导性的意见，但是OSGI规范在这方面已经做的很完善了。OSGI规范中定义了 Framework、Start Level、Package Admin、Security，详细描述了不同组件之间的依赖规则(静态依赖，动态导入)，不同组件之间使用独立的类名称空间。

　　由于SCA规范面向企业应用集成，因此SCA构件的实现可以是Java，BPEL，EJB，WebService。而OSGI的实现只面向Java语言。这也是由于二者的出发点不同导致的。

　　对于SCA和OSGI的装配模型，二者是大同小异。二者都可以对外提供服务(Service)，但SCA更偏重设计时刻的构件组装，而且定义了灵活的构件装配模型，可以由最小的原子构件组装成一个大系统。

　　从现有的已经实现的产品来看，OSGI更多的被用来作为单一产品的整体架构，SCA规范更多的是被用在面向业务的构件的组装规范，至于SCA产品的架构如何则不是SCA规范所关心的。

　　从上边的比较可以显而易见的看出二者分别的缺点，SCA规范过于强调集成，但是对SCA构件的运行时刻行为描述太弱，所有的构件实现都是在设计 时刻绑定的。也许在SCA产品中可以实现运行时刻的动态绑定，但是作为一个规范，这是它所欠缺的。OSGI规范对组件的运行时刻描述很完备，但是所有的组 件必须运行在同一个虚拟机中，不同虚拟机中的组件服务互操作则稍显不足。

    原文链接：http://gocom.primeton.com/blog839_14.htm

标签: 技术趋势, SOA, SCA, OSGI

　　Web服务持续发展的时候，应用技术必须克服某些阻碍和困难。因为越来越多企业认识到了Web服务的巨大潜力，开始把它运用到他们的组织中，这时一些有争议的概念急需得到解决。

　　其中一个有争议的概念是关于B2B协同。Web服务本来并不是设计用来帮助标准商业流程的规划和建模，而ebXML(电子商务可扩展性标识语言)就是提出来解决这个问题的技术。在第一部分，我们将探讨ebXML的主要目标和基本组成。

　　ebXML和Web服务

　　乍一看，ebXML和Web服务可能看上去非常相似。但是事实上它们非常不一样。

　　是一个规范的模块组合，它让企业能通过国际互联网进行商务交易。这些规格由联合国贸易便利与电子商务中心(UN/CEFACT)和结构化信息标 准促进组织(OASIS)发起，Web服务是一种Internet上应用程序之间交流的共同操作的方式。Web服务也伴随一系列为实现不同任务的不同规 格。这就是Web服务和ebXML之间的不同。

　　尽管Web服务和ebXML都允许在Internet上进行商业交流，但ebXML是尝试提供一种体系结构，承认那些提供相似产品和服务的商业可以用相似商业交易过程来描述。

　　通过提供描述商业交易的规格和标准方式，ebXML就可以执行这些过程，让公司能用标准方式互相交流。通过Web服务，你被锁定到一个特定公司的API，而且必须分开操作多方商业伙伴的API。

　　ebXML体系结构的核心

　　ebXML规范的细节非常复杂，因为用一种标准格式来描述如何与其他企业进行商业交流不是一个容易的事。ebXML技术体系结构规范提出了以下七点来描述ebXML体系结构的核心组成。ebXML提出了：

　　1.描述一个商业流程及其相关信息模型的标准机制。

　　2.一个用来注册和存储商业流程和信息元模型以便于它们可以共享和重复使用的机制。

　　3.对每个参与者信息的探索，包括：他们支持的商业流程;他们提供的支持商业流程的商业服务接口。;在他们各自商业服务接口之间交换的商业管理;相关传送、安全和编码协议的技术配置。

　　4.一个注册上述信息以便于能让其被找到和提取的机制。

　　5.一个描述执行双方达成一致的商业安排的机制，它可以是来自上面第三点中各方提供的信息。(协作协议协定——CPA)

　　6.一个标准商业通信服务框架，它能让贸易伙伴之间信息进行可操作的、安全和可靠的交换。

　　7.一个单独通信服务配置结构，用来使商业流程和商业协定中规定的条件达成一致。

　　详细分析

　　为了理解一个企业如何使用ebXML，让我们进一步来分析以上每一点：

　　1.这个体系结构的关键部分就是提供了一套指南，来详细说明一个企业做了一些什么以及是如何做的。UN/CEFACT建模技术方法(UMM)利 用统一建模语言(UML)，描述了一个企业如何来实现它。结果就是得到一个元模型，描述某一特定企业如何开展其商业流程。然后同一类型的其他企业可以同样 再使用这些元模型。

　　2.为了存储元模型，一个UDDI的扩展被创建为ebXML，允许对商业流程元模型的探索和注册。

　3.ebXML描述了其他公司用来探索其他已注册公司描述性信息的处理过程。

　　4.作为一个像前面第二点提到的扩展，ebXML允许公司注册操作ebXML的细节。

　　5.CPA是用来描述企业如何链接他们商业流程元模型的关键文件。

　　6.通信服务描述了用来将商业流程信息打包并在企业间进行分发的XML扩展。

　　7.通信服务配置允许更改通信语义和传送协议(如：HTTP/S， FTP，SMTP等)

　　总结

　　ebXML是非常复杂的，但是它的执行效果又是非常吸引人和强有力的。总的来说，ebXML：

　　能让企业找到他们想与之进行商业往来的企业。

　　制定一系列规格来创建一个适应ebXML的标准环境，让企业能相对容易地整合应用程序。

　　描述可重复使用的商业流程，以达到迅速执行。

　　可以被扩展，以提供常规商业流程操作。

　　实施一个通信框架，描述企业之间如何根据不同的协议共同操作。

　　Web服务也开始采用规范，让想到没有联系的商业交易如WS-Coordination，WS-Transaction和WS-Choreography能一起工作。

标签: 电子商务, 技术趋势, ebXML

　　20多年前，电子商务的想法诞生，通过链接在一起的计算机系统，数据能从一个系统传送到其他系统，从而不再使用纸介 质文件来交换商业数据。这个概念就是EDI(Electronic Data Interchange，电子数据交换)的原型。EDI的出现大大提高了商业运作效率，但虽然全世界的前10000家公司中98%以上都在使用EDI，但 全世界其他公司中却仅有5%是EDI的用户。这是为什么呢?这是因为EDI虽然很有效，但启动费用很高。

　　近一段时间以来，人们一直在寻找EDI的替代方案，希望能够找到一种使全球不同规模的公司都能受益的简单、便宜的交换标准商务文档的方法。在这样的背景下ebXML应运而生了。

　　一、什么是ebXML

　　"ebXML是一组支持模块化电子商务框架的规范。ebXML支持一个全球化的电子市场，它使得任意规模的企业通过交换基于XML的信息，不受 地域限制地接洽和处理生意。ebXML是联合国(UN/CEFACT，贸易促进和电子商务中心)和OASIS(结构化信息标准发展组织)共同倡导、全球参 与开发和使用的规范。"

　　ebXML规范的最初版本于2001年5月发布。它的目标是使任何规模的商家能够和任何人开展电子商务。在现阶段，ebXML是一套文档，包含若干完善的原型，但是有许多企业现在正在建造支持它的系统。

　　二、ebXML的任务

　　由于XML本身不具备使其适应商务世界需求的所有工具，所以希望通过ebXML实现：

　　1) 使电子商务简单、容易，并且无所不在;

　　2) 最大限度地使用XML;

　　3) 为B2B和B2C提供一个同样的开放标准以进行跨行业的商务交易;

　　4) 将各种XML商务词汇的结构和内容一起放进一个单一的规范;

　　5) 提供一条从当前EDI标准和XML词汇表移植的途径;

　　6) 鼓励行业在一个共同的长期目标下致力于直接的或短期的目标;

　　7) 用ebXML进行电子商务活动，避免要求最终用户投资于专有软件或强制使用专业系统;

　　8) 保持最低成本;

　　9) 支持多种书面语言并容纳国内、国际贸易的通用规则。

　　三、ebXML的技术体系结构

　　ebXML的技术体系结构尽可能使用了现存的标准，建立在EDI经验之上，并利用了XML的灵活性和Internet的普及性，整个体系结构是模块式的。

　　▲　消息传送

　　ebXML消息使用SOAP(Simple Object Access Protocol，简单对象访问协议)规范。SOAP是一个XML应用程序，定义一种用报头表示发送者、接收者、路由和安全细节的消息格式。SOAP还可以附加任何数字内容(如图片、声音等)。

▲ 商务流程

　　ebXML体系结构最重要的一个基本特征，就是它强调商务流程，这也是与其它XML框架不同的地方。它通过使用建模语言和图表工具(如UML) 的使用，使得系统地捕获贸易伙伴间的商务数据流，并用标准格式表示成为可能。通过商务流程的定义，使其具备了跨行业的通用消息序列，互操作性的能力。

　　▲ 贸易伙伴草案和协定

　　ebXML的另一处重要特征是，通过使用CPP(collaboration protocol profile，合作草案档案)的文档系统地描述企业能够提供哪些电子商务服务。首先企业使用XML格式列出其所支持的行业、商务流程、消息和数据交换技 术，然后使用CPP将这些信息生成一个CPA文件(collaboration protocol agreement，贸易伙伴协议)，自动提供协定。

　　▲ 注册表/知识库

　　注册表(registry)包含行业流程、消息和用于定义贸易伙伴间交换数据的交易词汇表。企业通过注册表登记CPP，列出它们的电子商务服务能力供潜在的贸易伙伴检索，也可以通过注册表搜索合适的贸易伙伴。知识库(repository)则是用于存储这些内容的。

　　▲ 核心组件

　　ebXML领先核心组件提供行业间的互操作性和商务性能，核心组件作用于单个的数据元素级别。核心组件识别商家最常使用和跨行业的数据项，给它 们分配中立的名字和惟一的标识符。通过核心组件，企业能够将一个行业的数据同另一个行业中相似的数据对应起来，或从一个XML术语对应到早先定义的EDI 交易。

　　那么使用ebXML是如何完成整个电子商务活动的呢，下图就以两个先前没有接触的企业如何通过ebXML建立关系，实现电子商务数据交换为例，说明使用ebXML进行电子商务的整个过程。

标签: 电子商务, 技术趋势, ebXML

今天的同事没准又是明天的同事，今天的下属没准就是明天的上司，今天的乙方没准就是明天的甲方。

Tags: 职场, 管理

　 　最近兴起的云计算甚至可以让你体验每秒10万亿次的运算能力，拥有这么强大的计算能力可以模拟核爆炸、预测气候变化和市场发展趋势。简言之，云计算是一 种基于因特网的超级计算模式，在远程的数据中心里，成千上万台电脑和服务器连接成一片电脑云—一个浪漫的比喻—用户通过电脑、笔记本、手机等方式接入数据 中心，按自己的需求进行运算。

　　云计算被视为科技业的下一次革命，而它也将对工作方式和商业模式带来根本性的改变

　　IBM的创立者托马斯·沃森曾表示，全世界只需要5台电脑就足够了。

　　微软的创立者比尔·盖茨则在一次演讲中称，个人用户的内存只需640K足矣。

　　现在看来，这两间伟大公司的创始人在他们所熟知的科技和软件行业，均没能进行准确的预测。今天，即使是普通的个人电脑用户，也在不断追求更强的计算能力：处理能力更强劲的芯片，容量更大的内存，更大的硬盘空间……

　　最近兴起的云计算甚至可以让你体验每秒10万亿次的运算能力，拥有这么强大的计算能力可以模拟核爆炸、预测气候变化和市场发展趋势。简言之，云 计算是一种基于因特网的超级计算模式，在远程的数据中心里，成千上万台电脑和服务器连接成一片电脑云—一个浪漫的比喻—用户通过电脑、笔记本、手机等方式 接入数据中心，按自己的需求进行运算。

　　你或许有过以下体验：你把照片(或视频)从你的电脑上传到一个网站供朋友们分享;你拥有一个电子邮件，它的容量根据你的需求在动态变化;你把与 同学、朋友的联系方式存放在一个网站上，你每次上网而不是翻出纸质的通讯录与他们联系;你打开文字编辑软件，写下了一段文字，然后通过这个软件直接把它发 布到你的博客上……

　　你明白我上面提到的是什么，它们是：雅虎的图片共享网站Flickr，谷歌的视频分享网站YouTube，电子邮件Gmail，社交网络Facebook，微软的博客写作软件Writer……

　　所有这些网络软件、存储、安全等服务都只是云计算的一种体现，而非全部。云计算更多的是指，通过千万台互联的电脑和服务器进行大量数据运算，为搜索引擎、金融行业建模、医药模拟等应用提供超级计算能力。

　　下面这个具体例子便于你加深对云计算的理解：《纽约时报》租用亚马逊的云计算服务，使用基于云计算的开源软件Hadoop，将其自1851年以来的1100万份报道转变成可搜索的数字化文档，耗时仅一天。如果用传统方法，这项工作可能要数月才能完成。

　　计算云 商业雨

　　云计算被视为科技业的下一次革命，它将带来工作方式和商业模式的根本性改变。

　　首先，对中小企业和创业者来说，云计算意味着巨大的商业机遇，他们可以借助云计算在更高的层面上和大企业竞争。自1989年微软推出 Office办公软件以来，我们的工作方式已经发生了极大变化，而云计算则带来了云端的办公室——更强的计算能力但无须购买软件，省却本地安装和维护。

　　其次，从某种意义上说，云计算意味着硬件之死。至少，那些对计算需求量越来越大的中小企业，不再试图去买价格高昂的硬件，而是从云计算供应商那 里租用计算能力。在避免了硬件投资的同时，公司的技术部门也无须为忙乱不堪的技术维护而头痛，节省下来的时间可以进行更多的业务创新。

　　以亚马逊为例，其云计算产品价格便宜(当然利润丰厚)，吸引了大批中小企业，甚至纽约时报、红帽、晟碟等大型公司。亚马逊提供每1G的存储收费 15美分，服务器的租用则是每小时10美分。据称其“云”中的每台计算机投资仅为300美元，假设电力消耗也是300美元，而按此收费标准，在一年不间断 的情况下其收益为876美元，利润率约为45%—高于其销售书籍的毛利。

　　随着云计算的兴起，传统硬件制造商再次面临危机。戴尔、惠普、SUN等多年来一直担忧美国市场的衰退，或许这下硬件市场的衰退真的要来了。

　　云计算对商业模式的影响体现在对市场空间的创新上。哈佛商学院教授克里斯滕森认为，Google Apps是他关于创新的理论中的新市场创新。他在接受一家中国商业媒体采访时说：“我在哈佛商学院的学生做文字处理时用Google Docs，他们将文件存储在Google的服务器上，而不是自己的电脑上。这是一个典型的新市场破坏，当互联网变得越来越快和更可依赖，用户正从桌面电脑 上的软件应用转向基于互联网的应用。”

同时，云计算开发新产品拓展新市场的成本非常低。比如，如果用户对Gmail的需求突然出现猛增，谷歌的云计算系统会自动为Gmail增加容量和处 理器的数量，无需人工干预，而且增加和调整都不增加成本。依赖云计算，谷歌能以几乎可以忽略不计的成本增加新的服务。如果新增的服务失败了，那没关系，关 掉并且忘掉它就可以。如果成功了，系统会自动为它增加空间和处理能力。

　　谷歌CEO埃立克·施密特认为，云计算意味着从PC机时代重返大型机时代。“在PC时代，PC提供了很多很好的功能和应用，现在又回到大型时的时代了。现在的大型机看不见，摸不着，不过确确实实就摆在那里，它们在云里，在天空里。”

　　云的阴暗面

　　即使最引人注目的云也有其阴暗的一面。云计算也并非完美无瑕。

　　今年2月中旬，亚马逊的网络主机服务—简易存储(Simple Storage Service,S3)出现故障，持续时间约4小时。除了听到客户的抱怨之外，这一事件还让人们开始重新审视甚嚣尘上的云计算的安全性。

　　亚马逊开办S3服务以来，吸引了大批web2.0创业者将其网站托管、存储在亚马逊的数据中心，这些初创企业也因此节省了硬件投资费用。不过一 旦出现安全问题，这些初创企业的信心也极易动摇。由于正处于初创期，这些公司的品牌黏性还不大，如果服务出现中断，容易造成用户用脚投票。

　　这只是云计算的风险之一。其实最引人担忧的是云计算的隐私问题，目前网上最流行的基于网络的商业应用是工资和客户账户管理，这是最敏感的商业信 息之一。此类信息泄露事件已经发生了不止一起，并且每次都是大规模的数据外泄。去年，美国零售商TJX约有4500万份用户信用卡号被黑客盗取。英国政府 丢失2500万人的社会保障号码等资料。在线软件公司salesforce.com也丢失了100万份用户的Email和电话号码。

　　这不由得引起隐私专家的担忧。普林斯顿大学一位专家称：“谷歌将引发人类历史上最严重的隐私难题。”

　　《哈佛商业评论》前执行主编尼古拉斯·卡尔在新书《大转换》(The Big Switch)描绘了云计算不怎么光明的一面。他认为计算机既是解放的技术，又是控制的技术。尤其是当系统变得更加集中化时，个人数据被越来越多地暴露; 数据挖掘软件越来越专业时，控制之手将占上风。此时，系统将变成监视和操控人类的绝佳机器。

　　卡尔认为，谷歌为了实现最佳的搜索结果，将引领搜索最终走向人工智能。在这种人工智能的全自动搜索中，用户无需坐在键盘前面搜索信息，当他脑子里刚浮现一个问题时，谷歌立刻通过手机将搜索出的答案轻声传进了用户耳中。

　　卡尔总结说：“我所担忧的不是谷歌最后制造出机器人奴役人类，但它确实能制造出能代替人类一部分思考能力的机器，当我们开始依靠这些机器来记忆和作决定时，你不禁开始为我们的自由意志担忧。”

　　也许托马斯·沃森的预测并没有错，这个世界只需5台电脑——它们分别是谷歌、雅虎、微软、IBM和亚马逊——而谷歌将是最大的一个。

　　云计算的前世今生

　　云计算为大众广泛所知始于去年10月份。IBM和谷歌当时宣布的一个美国高校教育项目称，美国首批6所大学可以使用其基于云计算的数据中心进行远程研究。随后雅虎也宣布了类似的计划。

　　与以上的教育项目不同，IBM去年11月在上海向金融机构等行业客户推出蓝云计划(Blue Cloud)，使金融机构可以在远程数据中心进行复杂的大量计算，加快反应能力。

　　事实上，在此之前亚马逊已经向个人和中小企业用户开通了云计算服务。2006年3月，亚马逊开始向中小企业出租其冗余的空间提供数据存储服务，后来逐渐扩展至计算、数据库等一系列服务。

　　所有这些参与者中最引人注目的是谷歌和微软。谷歌目前推出的云计算服务包括：搜索、广告、Apps。而Google Apps便是通过一系列收购后，谷歌提供类似微软的办公套件的免费办公软件。这迫使微软发布了Office Live Workspace，即Office办公软件的网络版本。

　　其实，云计算并非新事物或一夜成名。早在24年前，Sun公司当时的首席技术官就提出了“网络就是计算机” (The network is the computer)的宣传语，较早地表达了云计算的工作模式：分散的个人电脑管理成本很高，维护、更新和配置都很不方便，随着网络的发展，个人桌面电脑可 通过网络共享网络上的计算能力等资源。

　　十几年后，软件公司甲骨文CEO拉里·埃利森为抗衡微软和英特尔主导的个人电脑，推出了网络计算机(Network Computer)，被看作是对Sun公司宣传语的一个回应。不过，这个计划无疾而终。

　　在此之后，又出许多新的概念，包括：无处不在的运算(ubiquitous computing)、瘦客户机、网络操作系统(WebOS)以及网格计算。

　　如果说，SUN只是描绘出了未来的前景，而谷歌今天正在将其变为现实。巧合的是，谷歌责任CEO埃立克·施密特曾经在SUN担任首席技术官，并负责制定互联网战略。

　　有意思怕是，谷歌两位创始人成立谷歌的目标就是“梳理世界上的信息，使之在全球范围内可得”，这正与云计算的工作方式不谋而合。

Tags: 云计算, 技术趋势

国外杂志《福布斯》近期发表分析文章称，“云计算”是一个相对较新的概念，但事实上它的起源可追溯到互联网诞生之初。就目前来看，云计算概念最具革命性 的并不在其本身，而是许多与之相关的条件，随着这些条件逐渐成熟，云计算已越来越成为经济发展过程中的一种必然选择和趋势。

云计算的概念其实相当简单：即通过互联网提供软件与服务，并由网络浏览器界面来实现。用户加入云计算不需要安装服务器或任何客户端软件，可在任何时间、任何地点、任何设备(前提是接入互联网)上随时随意访问，业界称这种服务模式为“软件即服务(SaaS)”，而对大多数用户来说，它不过就是一个网络。

事实上在过去15年里，云计算一直在不断地发展，没有人能够准确预期云计算将给我们的生活带来哪些巨大变化，但随着这一运动的不断推进，不管是作为消费者还是商业人士，他们都可以感受到云计算带来的巨大变化。

在推动云计算发展的诸多因素中，网络宽带发挥了重要作用，同时，谷歌等搜索引擎也使得云计算成为不可阻挡的发展趋势。今天通过搜索引擎几乎可以检索到所有格式的信息，包括网页、书籍、视频和图像等。

搜索引擎目前并没有发展到终点，而仅仅是一个开始，就如同爱迪生当初发明的第一只白炽灯，才仅仅照亮了一间屋子。最初信息是单向流动的，现在却 不受时空限制能够自由流动。随着云计算时代的到来，人们生活的交互性将越来越强，因此创建一个全球对话和多层面的协作已完全成为可能。比如，一名身在印度 的会计师可以和纽约的同事同时制作同一张表格，并随时进行讨论;一个遍布全球的设计师团队可在同一个文档中规划一件新产品。类似的交流本身就具有革命性， 因为在这一协作过程中地缘差别已经消失，创意和思想可自由共享与交流。

与许多类似的产业革命一样，云计算经济正在推动着不同产业改变旧有的模式。在今天这样一个信息时代，公司通常都要花费巨额资金用于开发或采用拥有版权的数据，同时还得花费巨资保护这些数据。然而现在有越来越多的公司将上述数据托管给云计算，因为这么做的优势非常明显，除可以节省大量硬件、软件和能耗开支之外，还具有高效和安全等特点。也许有人对云计算的安全性存有疑问，不过像谷歌这样的公司，其全球运营都采用云计算模式，因此不管自身还是用户的安全都是其首要考虑的问题。

云计算可能带来长久而真实的改变，而这一改变的迹象才刚刚显现出来。每一位关注未来经济发展的人士都可能会有这样的认识：即拥有信息将成为一种决定性的优势，而云计算正好为信息共享与协作提供了一种既廉价又简捷的方式。

在云计算时代，即便是一些小公司也可以与跨国公司一样拥有同样的网络影响力，毕竟网络浏览器的窗口都是同样的尺寸，不管是谁在提供信息。这场革命的发源地当初或许只是加州的一间车库，但革命的火种已经走出国界，飘洋过海传播到了全球。