分类： 项目管理
2012-04-29 16:26:06
软件架构
软件架构：没有最好只有最适用
如何规避软件架构风险
固化需求
完善的业务原型
完整架构规范
80%的经验架构+20%的创新架构
软件架构通用的服务模式
类工厂服务
缓存服务（内存服务）
配置服务
异常处理服务
日志服务
加密服务
验证服务和授权服务
消息队列
部署服务
事务处理服务
帮助服务
数据验证服务
成功的软件开发
1、开发技术 （面向对象分析与技术、结构化设计方法、基于构件的开发方法）
2、开发过程（RUP、CMM、XP、瀑布模型、螺旋模型）
3、CASE 工具（Rational ROSE 、RUP Builder）
UML+RUP=最佳软件开发方法
几种常见架构:
1、 MVC
•M表示模型
•V表示视图
•C表示控制器
2、C/S
•客户端向服务器发送数据请求
•服务器返回数据
•客户端处理数据的展示
•服务器需要处理通讯、并发等等
服务器
•一个线程用来监听来自客户端的连接
•用一个独立的线程来处理一个客户端的连接
•线程池、线程重用
•并发控制
•负载均衡
进程间通讯
•TCP/UDP进程间通讯
•命名管道
•共享内存
•命名事件
•命令行参数传递（用于父子进程）
3、B/S
•Web服务器
•应用服务器
•数据库服务器
Web服务器
•标准的Web服务器
•简化了应用服务器的开发
Web服务器架构
•JAVA (JSP)
•.NET (ASP)
•LAMP
Linux+Apache+Mysql+Perl/PHP/Python,一组常用来搭建动态网站或者服务器的开源软件,本身都是各自独立的程序,但是因为常被放在一起使用,拥有了越来越高的兼容度,共同组成了一个强大的Web应用程序平台。
HTTP
•基于TCP
•客户端发送HTTP Request
•服务器处理后，发送HTTP Response
•每次连接只处理一个请求
•HTTP协议定义了Request和Response的内容格式（基于文本）
•HTTP是应用协议
•定义了GET、PUT、POST、REMOVE等操作
•操作的对象是资源，由URI定义
•无状态
HTTP作为传输协议来使用
•基于HTTP的Request和Response
•应用协议在Request和Response中定义
形式一
•
•....
•可以使用GET和POST
•在Response中使用xml作为返回
形式二
•使用POST
•在Request中使用XML指定方法名和参数
•在Response中使用XML作为返回
•XML-RPC
形式三
SOAP, WebService
4、SOA
SOA 是一种 IT 体系结构样式，支持将您的业务作为链接服务或可重复业务任务进行集成，可在需要时通过网络访问这些服务和任务。这个网络可能完全包含在您的公司总部内，也可能分散于各地且采用不同的技术，通过对来自纽约、伦敦和香港的服务进行组合，可让最终用户感觉似乎这些服务就安装在本地桌面上一样。需要时，这些服务可以将自己组装为按需应用程序——即相互连接的服务提供者和使用者集合，彼此结合以完成特定业务任务，使您的业务能够适应不断变化的情况和需求.
5、SaaS
软件即服务,它是一种基于互联网提供软件服务的应用模式。随着互联网技术的发展和应用软件的成熟，SaaS作为一种创新的软件应用模式逐渐兴起。
SaaS提供商为企业搭建信息化所需要的所有网络基础设施及软件、硬件运作平台，并负责所有前期的实施、后期的维护等一系列服务，企业无需购买软硬件、建设机房、招聘IT人员，即可通过互联网使用信息系统。就像打开自来水龙头就能用水一样，企业根据实际需要，向SaaS提供商租赁软件服务。
对于广大中小型企业来说，SaaS是采用先进技术实施信息化的最好途径。但SaaS绝不仅仅适用于中小型企业，所有规模的企业都可以从SaaS中获利。
目前，SaaS已成为软件产业的一个重要力量。只要SaaS的品质和可信度能继续得到证实，它的魅力就不会消退。
6、Open API
Open API实现技术
•SOAP
•XML-RPC
•REST
7、开源框架
Struts+Spring+Hibernate
•Struts：实现UI层
•Spring：实现业务层
•Hibernate：实现数据持久层
Jboss
客户端展示技术:
•标准Windows控件界面（MFC、.NET、WinForm）
–复杂性：界面受局限，很难把程序员与美工的工作分离
•内嵌WebBrowser
•用本地HTML来描述界面（美工）
•采用脚本进行操作
•从容器调用脚本的函数
•从脚本中调用容器的函数（.NET可以直接支持）
•内嵌Flash控件
•界面使用swf描述
•Swf中使用ActionScript进行控制
•与容器的交互
•SliverLight
1、SOA介绍
SOA 是一种 IT 体系结构样式，支持将您的业务作为链接服务或可重复业务任务进行集成，可在需要时通过网络访问这些服务和任务。这个网络可能完全包含在您的公司总部内，也可能分散于各地且采用不同的技术，通过对来自纽约、伦敦和香港的服务进行组合，可让最终用户感觉似乎这些服务就安装在本地桌面上一样。需要时，这些服务可以将自己组装为按需应用程序——即相互连接的服务提供者和使用者集合，彼此结合以完成特定业务任务，使您的业务能够适应不断变化的情况和需求（在有些情况下，甚至不需要人工干预）。
这些服务是自包含的，具有定义良好的接口，允许这些服务的用户——称为客户机或使用者——了解如何与其进行交互。从技术角度而言，SOA 带来了“松散耦合”的应用程序组件，在此类组件中，代码不一定绑定到某个特定的数据库（甚至不一定绑定到特定的基础设施）。正是得益于这个松散耦合特性，才使得能够将服务组合为各种应用程序。这样还大幅度提高了代码重用率，可以在增加功能的同时减少工作量。由于服务和访问服务的客户机并未彼此绑定，因此可以完全替换用于处理订单的服务，下订单的客户机-服务将永远不会知道这个更改。所有交互都是基于“服务契约”进行的；服务契约用于定义服务提供者和客户机之间的交互。通常，您将通过创建“基于消息的”系统来实现此目标。
从业务的角度来说，面向服务的体系结构的重点在于开发能帮助您完成业务任务的技术，而不是通过技术约束来规定您的行动。例如，销售过程（制造、运输和收到货款）可能会涉及数十个步骤和若干不同的数据库和计算机系统。但就其实质而言，此过程包含一系列人工活动，例如：
﹡销售人员找到潜在客户
﹡客户订购产品
﹡生产部门制造产品
﹡生产部门发出产品
﹡收款部门开具产品帐单
﹡客户支付产品货款
面向服务的体系结构基于这些实际活动或业务服务进行组织，而不是形成公司所维护的不同的信息竖井 (Silo)。通过实现 SOA，可以带来大量好处，包括以下各个方面：
﹡更高的业务和 IT 一致性
﹡基于组件的系统
﹡松散耦合的组件和系统
﹡基于网络的基础设施，允许分散于各地且采用不同技术的资源协同工作
﹡动态构建的按需应用程序
﹡更高的代码重用率
﹡更好地标准化整个企业内的流程
﹡更易于集中企业控制
MVC模式是"Model-View-Controller"的缩写，中文翻译为"模式-视图-控制器"。MVC应用程序总是由这三个部分组成。Event(事件)导致Controller改变Model或View，或者同时改变两者。只要Controller改变了Models的数据或者属性，所有依赖的View都会自动更新。类似的，只要Controller改变了View，View会从潜在的Model中获取数据来刷新自己。MVC模式最早是smalltalk语言研究团提出的，应用于用户交互应用程序中。smalltalk语言和java语言有很多相似性,都是面向对象语言，很自然的SUN在petstore(宠物店)事例应用程序中就推荐MVC模式作为开发Web应用的架构模式。MVC模式是一种架构模式，其实需要其他模式协作完成。在J2EE模式目录中，通常采用service to worker模式实现，而service to worker模式可由集中控制器模式，派遣器模式和Page Helper模式组成。而Struts只实现了MVC的View和Controller两个部分，Model部分需要开发者自己来实现，Struts提供了抽象类Action使开发者能将Model应用于Struts框架中。
MVC模式是一个复杂的架构模式，其实现也显得非常复杂。但是，我们已经总结出了很多可靠的设计模式，多种设计模式结合在一起，使MVC模式的实现变得相对简单易行。Views可以看作一棵树，显然可以用Composite Pattern来实现。Views和Models之间的关系可以用Observer Pattern体现。Controller控制Views的显示，可以用Strategy Pattern实现。Model通常是一个调停者，可采用Mediator Pattern来实现。
现在让我们来了解一下MVC三个部分在J2EE架构中处于什么位置，这样有助于我们理解MVC模式的实现。MVC与J2EE架构的对应关系是:View处于Web Tier或者说是Client Tier，通常是JSP/Servlet，即页面显示部分。Controller也处于Web Tier，通常用Servlet来实现，即页面显示的逻辑部分实现。Model处于Middle Tier，通常用服务端的javaBean或者EJB实现，即业务逻辑部分的实现。
一、MVC设计思想
MVC英文即Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层。
视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。
模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。
业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。
控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。
模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。模型、视图、控制器三者之间的关系和各自的主要功能，如图1所示。
二、MVC设计模式的实现
ASP.NET提供了一个很好的实现这种经典设计模式的类似环境。开发者通过在ASPX页面中开发用户接口来实现视图；控制器的功能在逻辑功能代码(.cs)中实现；模型通常对应应用系统的业务部分。在ASP.NET中实现这种设计而提供的一个多层系统，较经典的ASP结构实现的系统来说有明显的优点。将用户显示（视图）从动作（控制器）中分离出来,提高了代码的重用性。将数据（模型）从对其操作的动作（控制器）分离出来可以让你设计一个与后台存储数据无关的系统。就MVC结构的本质而言，它是一种解决耦合系统问题的方法。
MFC
微软所推出的MFC Document/View架构是早期对于MVC实现，MFC将程序分成CView以及CDocument两大类，其中的Document对应MVC中的 Model，View相当于MVC中的View＋Controller，再加上CWinApp类，合成三大项。但是基本上MFC是一个失败的MVC作品。
由于MFC之下的Document/View定义过于模糊，未将Controller（MessageMap）部份取出，因此Controller可以置入View或Document，但不管置入哪一方面，都会与View或Document绑死，没有弹性。
Java
Java 平台企业版 (J2EE)和其他的各种框架不一样，J2EE为模型对象(Model Objects)定义了一个规范。
视图(View)
在J2EE应用程序中，视图(View)可能由Java Server Page(JSP)承担。生成视图的代码则可能是一个servlet的一部分，特别是在客户端服务端交互的时候。
控制器(Controller)
J2EE应用中，控制器可能是一个servlet，现在一般用Struts实现。
模型(Model)
模型则是由一个实体Bean来实现。
2.1 视图
视图是模型的表示，它提供用户交互界面。使用多个包含单显示页面的用户部件，复杂的Web页面可以展示来自多个数据源的内容，并且网页人员，美工能独自参与这些Web页面的开发和维护。
在ASP.NET下，视图的实现很简单。可以像开发WINDOWS界面一样直接在集成开发环境下通过拖动控件来完成页面开发本。本文中介绍每一个页面都采用复合视图的形式即：一个页面由多个子视图(用户部件)组成；子视图可以是最简单HTML 控件、服务器控件或多个控件嵌套构而成的Web自定义控件。页面都由模板定义，模板定义了页面的布局，用户部件的标签和数目，用户指定一个模板，平台根据这些信息自动创建页面。针对静态的模板内容，如页面上的站点导航，菜单，友好链接，这些使用缺省的模板内容配置；针对动态的模板内容(主要是业务内容)，由于用户的请求不同，只能使用后期绑定，并且针对用户的不同，用户部件的显示内容进行过滤。使用由用户部件根据模板配置组成的组合页面，它增强了可重用性，并原型化了站点的布局。
视图部分大致处理流程如下：首先，页面模板定义了页面的布局；页面配置文件定义视图标签的具体内容（用户部件）；然后，由页面布局策略类初始化并加载页面；每个用户部件根据它自己的配置进行初始化，加载校验器并设置参数，以及事件的委托等；用户提交后，通过了表示层的校验，用户部件把数据自动提交给业务实体即模型。
这一部分主要定义了WEB页面基类PageBase；页面布局策略类PageLayout，完成页面布局，用于加载用户部件到页面；用户部件基类UserControlBase即用户部件框架，用于动态加载检验部件，以及实现用户部件的个性化。为了实现WEB应用的灵活性，视图部分也用到了许多配置文件例如：置文件有模板配置、页面配置、路径配置、验证配置等。
2.2 控制器
为了能够控制和协调每个用户跨越多个请求的处理，控制机制应该以集中的方式进行管理。因此，为了达到集中管理的目的引入了控制器。应用程序的控制器集中从客户端接收请求（典型情况下是一个运行浏览器的用户），决定执行什么商业逻辑功能，然后将产生下一步用户界面的责任委派给一个适当的视图组件。
用控制器提供一个控制和处理请求的集中入口点，它负责接收、截取并处理用户请求；并将请求委托给分发者类，根据当前状态和业务操作的结果决定向客户呈现的视图。在这一部分主要定义了HttpReqDispatcher(分发者类)、HttpCapture(请求捕获者类)、Controller(控制器类)等，它们相互配合来完成控制器的功能。请求捕获者类捕获HTTP请求并转发给控制器类。控制器类是系统中处理所有请求的最初入口点。控制器完成一些必要的处理后把请求委托给分发者类；分发者类分发者负责视图的管理和导航，它管理将选择哪个视图提供给用户，并提供给分发资源控制。在这一部分分别采用了分发者、策略、工厂方法、适配器等设计模式。
为了使请求捕获者类自动捕获用户请求并进行处理，ASP.NET 提供低级别的请求/响应 API，使开发人员能够使用 .NET框架类为传入的 HTTP 请求提供服务。为此，必须创作支持 System.Web.IHTTPHandler 接口和实现 ProcessRequest() 方法的类即：请求捕获者类，并在web.config 的 ＜httphandlers＞ 节中添加类。ASP.NET 收到的每个传入 HTTP 请求最终由实现 IHTTPHandler 的类的特定实例来处理。IHttpHandlerFactory 提供了处理 IHttpHandler 实例 URL 请求的实际解析的结构。HTTP 处理程序和工厂在 ASP.NET 配置中声明为 web.config 文件的一部分。ASP.NET 定义了一个 ＜httphandlers＞ 配置节，在其中可以添加和移除处理程序和工厂。子目录继承 HttpHandlerFactory 和 HttpHandler 的设置。 HTTP 处理程序和工厂是 ASP.NET 页框架的主体。工厂将每个请求分配给一个处理程序，后者处理该请求。 例如，在全局 machine.config 文件中，ASP.NET 将所有对 ASPx 文件的请求映射到 HttpCapture类：
＜httphandlers＞
...
...
＜/httphandlers＞
2.3 模型
MVC系统中的模型从概念上可以分为两类――系统的内部状态和改变系统状态的动作。模型是你所有的商业逻辑代码片段所在。本文为模型提供了业务实体对象和业务处理对象：所有的业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装了具体的处理逻辑，调用业务逻辑模型，并且把响应提交到合适的视图组件以产生响应。业务实体对象可以通过定义属性描述客户端表单数据。所有业务实体对象都EntityBase派生子类对象，业务处理对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。通过业务实体对象实现了对视图和模型之间交互的支持。实现时把"做什么"（业务处理）和"如何做"（业务实体）分离。这样可以实现业务逻辑的重用。由于各个应用的具体业务是不同的，这里不再列举其具体代码实例。
三、MVC设计模式的扩展
通过在ASP.NET中的MVC模式编写的，具有极其良好的可扩展性。它可以轻松实现以下功能：
①实现一个模型的多个视图；
②采用多个控制器；
③当模型改变时，所有视图将自动刷新；
④所有的控制器将相互独立工作。
这就是MVC模式的好处，只需在以前的程序上稍作修改或增加新的类，即可轻松增加许多程序功能。以前开发的许多类可以重用，而程序结构根本不再需要改变，各类之间相互独立，便于团体开发，提高开发效率。下面讨论如何实现一个模型、两个视图和一个控制器的程序。其中模型类及视图类根本不需要改变，与前面的完全一样，这就是面向对象编程的好处。对于控制器中的类，只需要增加另一个视图，并与模型发生关联即可。该模式下视图、控制器、模型三者之间的示意图如图2所示。
同样也可以实现其它形式的MVC例如：一个模型、两个视图和两个控制器。从上面可以看出，通过MVC模式实现的应用程序具有极其良好的可扩展性，是ASP.NET面向对象编程的未来方向。
四、MVC的优点
大部分用过程语言比如ASP、PHP开发出来的Web应用，初始的开发模板就是混合层的数据编程。例如，直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小，很难满足用户的变化性需求。MVC要求对应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可以得到更好地体现。
首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下，可能有多种方式访问应用的要求。例如，订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说订单的处理是一致的。按MVC设计模式，一个订单模型以及多个视图即可解决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。 其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。
再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。
控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。
最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。
五、MVC的不足
MVC的不足体现在以下几个方面：
（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
（4） 目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。
SaaS是Software-as-a-service（软件在线服务）的简称，它是一种基于互联网提供软件服务的应用模式。随着互联网技术的发展和应用软件的成熟，SaaS作为一种创新的软件应用模式逐渐兴起。
SaaS提供商为企业搭建信息化所需要的所有网络基础设施及软件、硬件运作平台，并负责所有前期的实施、后期的维护等一系列服务，企业无需购买软硬件、建设机房、招聘IT人员，即可通过互联网使用信息系统。就像打开自来水龙头就能用水一样，企业根据实际需要，向SaaS提供商租赁软件服务。
对于广大中小型企业来说，SaaS是采用先进技术实施信息化的最好途径。但SaaS绝不仅仅适用于中小型企业，所有规模的企业都可以从SaaS中获利。
目前，SaaS已成为软件产业的一个重要力量。只要SaaS的品质和可信度能继续得到证实，它的魅力就不会消退。
2、SaaS模式与传统许可模式的区别
SaaS服务模式与传统的销售软件永久许可证的方式有很大的不同，相比较传统服务方式而言SaaS具有很多独特的特征：SaaS不仅减少了或取消了传统的软件授权费用，而且厂商将应用软件部署在统一的服务器上，免除了最终用户的服务器硬件、网络安全设备和软件升级维护的支出，客户不需要除了个人电脑和互联网连接之外的其它IT投资就可以通过互联网获得所需要软件和服务。此外，大量的新技术，如Web Service，提供了更简单、更灵活、更实用SaaS。
另外，SaaS供应商通常是按照客户所租用的软件模块来进行收费的，因此用户可以根据需求按需订购软件应用服务，而且SaaS的供应商会负责系统的部署、升级和维护。而传统管理软件通常是买家需要一次支付一笔可观的费用才能正式启动。
诸如ERP等企业应用软件，软件的部署和实施比软件本身的功能、性能更为重要，万一部署失败，那所有的投入几乎全部白费，这样的风险是每个企业用户都希望避免的。通常的ERP、CRM项目的部署周期需要一两年甚至更久的时间，而SaaS模式的软件项目部署最多也不会超过90天，而且用户无需在软件许可证和硬件方面进行投资。传统软件在使用方式上受空间和地点的限制，必须在固定的设备上使用，而SaaS模式的软件项目可以在任何可接入Internet的地方与时间使用。相对于传统软件而言SaaS模式在软件的升级、服务、数据安全传输等各个方面都有很大的优势。
3、SaaS的客户价值
SaaS服务提供商为中小企业搭建信息化所需要的所有网络基础设施及软件、硬件运作平台，并负责所有前期的实施、后期的维护等一系列服务，企业无需购买软硬件、建设机房、招聘IT人员，只需前期支付一次性的项目实施费和定期的软件租赁服务费，即可通过互联网享用信息系统。服务提供商通过有效的技术措施，可以保证每家企业数据的安全性和保密性。企业采用SaaS服务模式在效果上与企业自建信息系统基本没有区别，但节省了大量用于购买IT产品、技术和维护运行的资金，且像打开自来水龙头就能用水一样，方便地利用信息化系统，从而大幅度降低了中小企业信息化的门槛与风险。具体来说saas可以为客户带来如下的价值：
a) 服务的收费方式风险小，灵活选择模块，备份，维护，安全，升级
b) 让客户更专注核心业务
c) 灵活启用和暂停，随时随地都可使用
d) 按需定购，选择更加自由
e) 产品更新速度加快
f) 市场空间增大
g) 实现年息式的循环收入模式
h) 有效降低营销成本
i) 准面对面使用指导
j) 在全球各地，7*24全天候网络服务
k) 不需要额外增加专业的IT人员
l) 大大降低客户的总体拥有成本
二、企业与SaaS
1、企业如何选择和应用SaaS
SaaS模式能显著降低企业的前期投入。它可以通过互联网在任何时间、任何地点进行访问，不必再受到软件升级和补丁更新的困扰。基于对SaaS未来发展的憧憬，诸如甲骨文和微软等大型企业软件厂商都义无反顾地加入了这一阵营。
SaaS企业管理软件分成两大阵营，平台型SaaS和傻瓜式SaaS。平台型SaaS是把传统企业管理软件的强大功能通过SaaS模式交付给客户，有强大的自定制功能。傻瓜式SAAS提供固定功能和模块，简单易懂但不能灵活定制的在线应用，用户也是按月付费。
2、如何解决数据在SaaS模式下的安全问题
鉴于安全问题的关键地位，故将SaaS模式下的安全问题单独作为一个话题来讨论：
毋庸赘言，软件即服务最近成为了流行的趋势，整个SaaS的范畴涵盖了广泛的用户可以获取并利用的应用，而SaaS的普及也代表着在未来随着互联网的发展，用户不必再投资于任何服务器或是自己的设备上安装任何软件。
从包含了在线Office应用程序的Google Apps到Adobe的Buzzword服务，以及通过LiveOffice和Hotmail提供的电子邮件及即时消息服务都是很好的SaaS的例证。同时，你还会发现大量的在线备份和数据保护服务，无论是IronMoutain还是AmeriVault，当然，其中还包括一些规模较大的供应商，如EMC、IBM、HP，也加入到了这个市场中来，正在日益将其发展方向转向服务以扩大他们的市场。
通过提供这些软件，企业们提供了SaaS服务或是将你的数据存放在他的服务器上，以及获取捏计算机系统，所以，引伸出一个问题：用户使用这些服务的安全性到底如何？
"中小型企业必须非常谨慎的挑选供应商以存储他们宝贵的数据。"分析机构IDC的分析师Laura DuBois表示，这位分析师一直关注在线存储服务以及SaaS领域的发展动向，去年在一篇文章中曾表示，由于在线存储服务来势汹汹，IDC甚至没有为其准备好一个相应的分类方法。
很明显，可取的做法是尽可能多的了解该公司是如何提供SaaS服务的，他们为了您的信息的安全做了什么？如果你需要恢复数据，需要多久才能收到？该公司是否能够在低迷而又不稳定的市场中长久生存下去？这些都是你应该问问自己的关键问题--只有做出满意的答案才能够任何选择SaaS供应商的决定。
SaaS能够节省用户在部署应用时捆绑的软件许可、硬件以及管理成本，但是这并不意味着SaaS就是每一个人都是使用的。当打算选择一家SaaS供应商时，你应该深入了解这家供应商到底能够提供多少实质性内容，反面的典型就是不愿意向用户提供详细的参考资料或是只有很低用户口碑度。
"在SaaS的世界里，留住用户的数字是一个非常重要的宣传。"LiveOffice公司的总裁Matt Smith这样认为，他的公司提供电子邮件、即时消息以及其它SaaS产品，"一个可靠的公司的客户保持率应该至少在98%。"
如果这是一家刚刚成立的没有太多用户听说过的初创厂商，你就需要进行更加彻底的调查，以核实其原有的一些用户是否成功交付了。
从另一个角度来看，评价一个SaaS提供商还要看用户的支持度，也许有些供应商的设备看起来是豪华的，但是却可能是华而不实的并不中用，尤其是可能会很薄弱的售后支持，虽然在某些情况下，熟练的服务人员和专业的顶尖的技术支持可能与其高昂的价格相比并不值得。
"这实际上取决于公司想要什么，"Iron Mountain公司Digital Record Center for Images服务的总经理Tom Meyer认为，"一些供应商并不具备高度安全的内容管理系统，所以他们提供的在线存储空间价格低廉而且简单易行，但是这确实可能会被罚款的。"
（1）感受安全
很清楚的一件事是，安全应该是供应商在选择SaaS标准之前就应考虑的问题并且应该一直放在核心位置，这些在线服务提供商的一个重要的工作就是如何保持其数据的安全，并且确保保护这些数据的保障系统的安全，以免使其遭受灾难。
"小型企业的拥有者应该问问供应商如何存储他们的数据，"Smith认为，"一个好的供应商应该有多个镜像数据中心，这也就意味着客户端的数据备份在多个地点和多个时间内总是可以用的。"
SaaS厂商现在在利用各种方式来保障他们的数据，他们其中的一些喜欢使用提供了数据加密功能的磁盘阵列，另外一些供应商的方法更加机械化，他们将数据存放在一个大的仓库中，并给予起一个孤立但是安全的位置。
Iron Mountain公司提供了一项名为Digital Record Center for Images的服务，这项服务为用户提供了数据加密传输、用户访问路径控制以及确保位于地下200英尺的数据中心的安全的服务。
备份和存储SaaS提供商Elephant Drive通过将数据存储在多个基于硬盘的存储池并进行复制的方法来保证用户数据的安全，数据复制保护功能被集成到其产品系统中，所有的数据都可以让用户在位于至少两个不同地点的独立站点进行访问。
AmeriVault也是一家在线备份服务提供商，其帮助用户在三个地点保存用户的备份数据，每个用的数据都存放在两个不同的磁盘系统中，第三份备份则放置在1000公里之外的保证业务连续性的站点中。
在线备份提供商DS3则使用EMCClariion作为主存储设备，为了保证备份方便，他们将备份的数据保存在其他的高端磁盘系统中，在DS3的三个数据中心中，有一个数据中心专门用于保存用户的信息的备份。
"任何一家有个良好信誉的SaaS供应商都应该采取必要合适的措施确保他们服务器的安全，并且为每个用户都展现出所有的操作。"Smith表示。
（2）SaaS服务的满意度
服务级别协议是我们通常用来判断一个SaaS服务是否令用户满意的工具，SLA是一项针对提供某种程度上的稳定性的厂商的合同义务，Smith认为，目前使用SLA协议的用户达到了99%以上。
此外，SLA协议还包括如果合同到期的话，SaaS服务提供商应该如何处理用户数据的条款，在这种情况下，用户应该确保拥有这些信息的所有权，并且确认是受到法律保护的。
例如，Prince Street Capital Management公司采用了由Data Storage公司提供的备份服务，这项服务可以对企业的电子邮件系统实施保护，并对离线数据存储池进行保护，确保远程存储安全以及信息的快速恢复，SLA协议在其中也是一个重要的组成部分。
该公司的首席财务官Peter McKown表示，"在你寻找一款适合的备份和恢复解决方案时，对Microsoft Exchange的快速恢复是一个重要的考查标准，在选择了Data Storage服务作为我们的备份和恢复服务管理合作伙伴之后，我们的业务获得了充分的满足，服务水平超过了我们的想象。"
（3）从安全角度看SaaS的未来
用户质疑SaaS是很正常的，但是从多个方面来看，在十几年前业界关于电子商务的不休争论时，这些质疑就已经存在了。过去，很多中小企业对于数据安全都有所顾虑，他们不知道是不是可以信任那些初创厂商，或是不太确定电子商务是一个稳定的业务模式，但是在10年之后，似乎每个人都多多少少和电子商务有所联系，不过，要是想让企业也接受这个全新的技术还要等一段时间。
同样的，SaaS服务也需要经历这样的循环，赢得人们的信任是SaaS服务提供商们不得不面对的一项日产共工作，但是对于那些只有几个技术人员或是根本没有IT部门的中小企业来说，SaaS确实有很重要的作用，能够为企业提供他们必须要完成的工作。
同时，如果你是Prince Street公司的话，或许你需要和多个厂商合作，DuBois认为，在判断究竟哪一个供应商才是可信的时候，用户需要问自己三个问题：谁是技术提供商？谁是管理他们数据的供应商？谁负责建设数据中心和他们的基本数据架构？
她认为："在很多情况下，这些问题的答案指向不同的三个厂商，因此每个层次都会有危险存在，在任何情况下，用户要认真的了解隐私性、加密、可用性、恢复时间、SLA协议、成本以及合同期限等细节情况。"
总之，安全问题不容小觑，解决安全问题是SaaS模式继续存在并发展的前提，而周全的考虑各方面的安全性则是中小企业在选择SaaS服务商时必须注意的问题。
4、 Open API 的介绍
Open API的发展
互联网应用最重要的就是创意和及时响应变更这两点。传统软件拚专业化和服务质量，但盗版，同质竞争，对用户个性化需求的服务支持，使得客户和软件生 产商都没有得到满意结果。SAAS模式的提出，其实部分也说明了市场和客户对于互联网应用的需求日趋增强，长尾理论更是让很多草根开发者看到了未来。但互 联网应用是否仅仅就把传统软件搬上网就算是适应潮流，改制创新了呢？其实不然，互联网开放带来的模仿远比盗版可怕，软件的开发周期长，版本迭代周期长，让传统软件开发模式下的开发人员疲于满足用户需求。而最重要的创意，传统软件专注于专业化，而专业化带来的就是我们过去说SOA需要解决的那些信息竖井，只 有将不同行业的信息串联打通，原有的数据资源才会体现出其更大的商业价值。因此Open API出现了，起初也许仅仅是互联网企业内部的一种需求，因为企业规模日趋庞大，组织内部的协作也需要模块化和服务接口化，随着业务的梳理以及抽象，服务 逐渐不仅仅可以满足内部交互，同时对外开放给一些商业合作伙伴，随之而来的就是数据资源价值的体现让开放服务的企业得到了回报。当越来越多的互联网企业将 自己内部的业务作为服务提供给外部使用者的时候，服务的发布，流程的规范化也逐渐形成。REST作为一种轻量级服务交互规范也得到了新一代互联网企业的认 同，加上RSS，JSON，XML已经广泛使用的多种数据格式，让Open API有了公共的基础，也为Open API的开发者集成开发提供了最基本的保障。
当前国外的Open API不论是种类，提供商的服务质量，规范化和使用情况都在这一年里面有了很大的提升，可以说已经由初期的发展转到了较为成熟的发展。而国内，就开放的企 业，提供商的服务提供成熟度，以及安全等方面的措施，都仅仅只是起步，不过好处在于有可借鉴的模式。不过，明年随着Open API带来的商业价值逐渐体现，会让更多的人加入到互联网这种新的应用开发模式中来，同时也会给很多开发者，特别是个人和小团队开发者带来机遇。互联网行 业就是一个以小博大的行业，当面对成千上万的新兴资源的时候，创意加行动才是成功的基石。
Open API的形态
就现在互联网上Open API的形态来看，主要分成两种：标准REST和类REST(也可以叫做RPC形态)。
RPC形态其实就是Web Service的一种延续，只是少了繁重的解析、安全规范等。Flickr的Open API大部分就是这种形态，看看下面的服务请求URL：
http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value
服务请求地址包括了两部分：1. 服务的总入口地址http://api.flickr.com/services/rest/。2.服务方法以及参数。这和过去的RPC模式就是一样的，只是通过Http方式请求，返回的是可以指定格式数据内容。
REST形态主要有这么几点特点：1.服务地址就是资源定位地址。2.服务操作就是Http请求中的方法类型（GET,POST,DELETE,PUT），这其实是抽象现实当中对于服务的增删改查操作。Google大部分的REST API就采用了标准的REST风格，服务请求地址URL如下：
http://www.google.com/calendar/feeds/wenchu.cenwc@alibaba-inc.com/allcalendars/full
这个服务请求地址是用来定位以我阿里巴巴邮箱注册的Google帐号的所有日程安排，通过在Http消息头中配置Get、Post、DELETE、 PUT可以对我的日程进行操作，而无须登陆到Google上去操作。（后面部分的实践中会有部分介绍如何通过后台Java代码直接操作）
对于REST形式的讨论在网上一直有，但其实这种讨论没有什么意义，其实就好比争论吃饭是否一定要用筷子，没有什么技术是“万能药”，也没有什么技术好于不好，只有使用它的人是否有足够的智慧把它应用到适合的场景中。
对于类REST的形态来说优点在于对于原有系统的改造较小，“当前”用户使用接受度更高一些，对于逻辑抽象来说更加容易。而REST风格的优点在 于，资源容易管理，系统扩展容易，权限控制可以部分依托于已有的传输协议。两者的缺点其实就是对方的优点。采取什么模式，其实还是要根据企业本身情况来 看，类似于淘宝采用的就是类REST方式，而未来支付宝将会采用REST的方式，前者要改造整个系统架构和资源数据结构基本是不太可能完成的任务，后者对 于业务逻辑梳理以及在现有内部SOA架构体系下抽象出REST风格的API并不是一件难事。但最后还是那句话，形态仅仅只是外在，练功之人修炼好内力才是 根本，没有必要为了迎合一种所谓的潮流而去盲目的选择形态，因为服务提供商将要面对的是高过网站上百甚至更高流量的访问调用，如何满足开发者业务以及非业 务（稳定，高效，安全）的需求，才是最大的挑战。
Open API的类型
这里指的类型，主要从提供服务本身内容来看。当前服务类型主要可以分成三种：数据型，应用型，资源型。
现在很多SNS网站的Open API就是属于数据型，也就是将自身的数据开放，让应用开发者根据已有的数据进行二次应用开发。
应用型其实应该是数据型结合的比较紧密，Flickr的图片搜索，Google的日程，地图（地图数据其实可以自己定义）等等都是属于应用型。应用型的数据输入可以是外部的数据，也可以是基于已有的数据资源进行处理。
资源型的代表就是Amazon，Amazon S3就是典型的资源型，当然Flickr的图片存储服务等也可以属于资源型。其实今年还有一个被炒得火热的话题就是云计算，在云计算的背后就是需要提供这 么一个资源型的服务，Amazon EC2如果离开了S3，也就无法存在。其实这种类型的服务也是一种未来的趋势，未来互联网应用如果要培植草根级开发者，就需要有这样的温室，Google 的App engine如果在多一些语言环境版本，那么会让更多的开发者有梦想实现的空间。
