有人问了Cloud Computing的7大安全隐患。

  回答：不是所有的应用都适合部署到云端，有些企业关键业务应用，出于安全、网络、心里的问题，都还是部署在企业内部。比如银行内部的账户管理。但是有些企业的服务性系统就可以利用云计算了，最典型的就是邮件，还有 CRM系统。还有一些网站可以基于云计算来开发。

  比如： 经营一家自己的网上花店，平常的日子里，每天的订单量也许就200~300左右。可是到了节假日，比如母亲节，也许当日订单量激增10倍，或者更多。这个时候我原有的服务器数量就不能满足当前数据并发和交易处理的要求。为了保证业务正常处理，一般的情况，我有两个选择：一个选择，就是对超出处理能力的请求，暂时停止对其服务；另一个选择，就是购买更多的硬件设备来满足当前需求。但是，两个选择都不是我们希望看到的。第一个选择会失掉我的客户，第二个选择的投资也许比这几天的利润还要大，而且平日里这些设备又是闲散资源。

  然而，基于云计算平台的解决方案就可以帮助我们解决此类问题，基于Windows Azure的应用，在开发阶段就已经考虑好伸缩性的要求。随着业务量的变化而修改Windows Azure的配置文件，就可以随意的增加或者减少所需服务器实例的数量，做到了按需分配。

  最后，做一下总结吧，从ESB到ISB，再到现在的Azure Serivce Platform。服务+软件的概念应该说越来越清晰了。企业也开始不再满足于企业内部信息系统间的数据，应用，流程上的整合，所以提出了ISB，希望在企业外部也能够实现与业务伙伴的网络服务以及信息共享。因此企业也必须建立授权规则和审查机制，才能为业务伙伴提供互联网服务。企业还必须支持用户身份管理，建立关联，比如：雇员在企业内部和航空公司、酒店都有各自的用户身份。

  ISB更象一个无所不在的结构。ISB可以是设备间的互联，可以是设备和本地服务间的互联，可以是站点对站点的互联，也可以是ESBs和ESBs的互联，ISB本身就是一种ESB。ISB是一个是可以自己定制复合应用和业务流程的平台。ISB也是软件即服务(SaaS)的一个例子。如下图：

  而核心ISB概念是建立在统一资源标识符（URI）的基础上的。每个应用服务都会被登记，并“拥有”一个类似于URI：http://ISB.net/DaveAndTeam的标识符。以便于发布/订阅。开发人员通过连接URIs的策略和功能来开发的一个ISB应用。ISB提供了一个身份和接入功能，可以控制何种信息可以被发送到URI上，以及由谁来发送。身份和访问功能就是URI的联合策略的一个例子。

  最后引用微软在“互联网服务总线”文档中的一段话来结束今天的内容：

  总的来说"软件即服务（SaaS）"是一个神话。所有有意义的SaaS解决方案，最终将包括一些含内部部署（企业内部部署）的混合结构。某些元素的一个实例化的解决方案将被融入到总线里（例如工作流程），有些元素会融入到和总线连接的服务器里（例如XML内容管理系统），而有些元素则被安装到内部部署里。几乎所有的方案中使用了ISB，而SaaS实际上是一种内部部署和外部部署的组合软件。