第章业务需求和设计方案模型

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

第1章业务需求和设计模型

摘要:本章讨论了指导如何设计<它属于企业对消费者 (B2C> 网站,采用 Microsoft 商务参考体系结构)的业务需求,并概括了在此应用程序设计期间确定的实际业务需求。本章还概要介绍了 Microsoft 解决方案框架 (Microsoft Solutions Framework,MSF> 三层应用程序模型和阶段式设计过程。

请注意:尽管此处提到的业务需求仅仅局限于一个可轻松安装的参考示例所具有的能力,但是本“开发人员指南”提供的信息线索非常有用,通过这些线索,您可以对该应用程序进行升级,使其满足生产环境的需求。

简介

请 Web 用户给电子商务站点定义时,一般用户可能会回答电子商务站点就是可以用信用卡购买商品的在线商店。尽管这个定义相当正确,却没有充分说明目前为 Internet 开发的各种电子商务站点的特点。在迅猛发展的 Internet 商务时代,一个高效率的电子商务网站绝不仅仅是基于 Web 的商店。

用户对电子商务站点的要求越来越高,如果某个站点无法满足他们的要求,他们就将弃之而去。那么,用户对电子商务有哪些要求呢?下表列出了一些影响应用程序设计的主要问题。

∙易于使用/导航

∙性能高

∙匿名购物

∙维护用户配置文件

∙安全性好

∙能够通过多种设备访问站点

∙通过可管理性提高竞争优势

粗略一看,在上述问题中,有些应由应用程序设计人员负责解决,有些似乎应由企业决策者或基本结构专家负责解决。不过,如果您仔细思考这些问题,就会明白这些问题为什么都与应用程序的设计有关。

易于使用/导航

网站理所当然地应该易于使用和导航。毕竟,企业不希望消费者在购买自己的产品时遇到困难,而消费者也更愿意在自己能轻松找到结帐页的站点消费。

使站点易于使用的一种方法是确保在常见任务上使用大家熟悉的类似方法。这意味着在消费者完成购买<或“结帐”)之前,可将其选购的商品存储在购物篮或筐中。这种比喻可便于不熟悉计算机的人理解站点是如何工作的,从而开展购买活动。

使站点易于导航比您最初想象的要困难得多。Web 完全是以一种非线性方式工作的,用户单击链接的顺序经常无法预料。因此,您应该确保无论用户目前在查看哪一页,站点向用户展示的始终是完全一致的界面,并确保只需单击一个链接即可访问重要网页<如主页、

购物篮所在页以及用户帐户信息所在页等)。在 站点上,顶部的标帜始终包含到购物篮所在页、消费者帐户所在页和主页的链接,而左侧的面板上始终包含搜索和目录链接。

还有一种方法可以确保用户能在站点中找到所需内容,这就是要以逻辑方式编排产品清单或目录。如果将目录分成几个类别和许多可能的子类别,即可让消费者轻而易举地找到他们感兴趣的产品。此外,还应给用户提供搜索功能,以便他们在不太清楚某种产品的陈列位置时可以进行搜索。

如果您的站点易于使用和导航,消费者将乐意使用。相反,如果使用起来比较困难,消费者可能就会弃之而去,另择站点。

性能高

在网站的设计当中,影响其性能的因素很多。由于不同的人对性能的要求各不相同,因而,对于什么才是可接受的性能水平也将因人而异。

尽量减少响应时间

大多数人认为:提供可接受的响应时间的站点才是性能良好的站点。响应时间是指用户在请求了某个操作之后、能够看到结果之前需要等待的时间量。在理想情况下,我们都希望站点上的操作瞬时就能得到执行;但在实际生活中,我们需要接受这样一个事实:有限的带宽、数据库并发性和业务处理任务通常都会导致轻微的延迟。因此,设计电子商务站点时,应尽量减少那些对响应时间有负面影响的因素<尽管不能完全排除它们)。

电子商务优化的关键在于减少执行诸如结帐之类的操作所耗费的时间,这样,消费者就不会因排队等待而放弃自己选购的商品,您也就不会因此而失去订单。

尽量增强可扩展性

性能的另一个重要方面就是“可扩展性”。这是指添加资源时站点容量增加的能力。从用户角度来看,这意味着当大量用户同时访问站点时,站点仍能提供可接受的响应时间。许多开发人员经常会得到这样令人沮丧的消息:当访问的用户达到一定数量<这个数量是实际生活要求达到的数量)后,在开发机上性能卓越的测试站点就无法应付。

那么,如何才能最大限度地增强站点的可扩展性呢?两种典型的方法就是“向上扩展”和“向外扩展”。

向上扩展

第一种方法<“向上扩展”)就是通过采用更好和/或更快的 CPU、更大的 RAM、更快的磁盘等等来增强服务器的处理能力。这种方法非常有效,尤其是在数据层上,该层上的一些大型数据库需要相对较强的处理能力。不过,由于硬件成本随处理能力的加强而按指数增长,因此,服务器越接近顶端,这种方法就愈加不合算。

向外扩展

“向外扩展”则从另一个方面来解决问题,即由“群集”<或服务器集合,也称为“Web 领域”)中的多个服务器来分担处理工作量。Web 领域在硬件方面的花费更为合算,而且提供了更为灵活、可扩展的解决方案。当站点上的负载增加时,可以很轻松地将服务器添加到 Web 领域中。

Microsoft® Windows® 2000 Advanced Server 和 Windows 2000 Datacenter Server 以及 Windows 网络负载平衡 (Windows Network Load Balancing,NLB> 服务一起,将整个 Web 领域作为一个具有单一 IP 的逻辑服务器显示在 Internet 上。收到请求之

后,会根据负载情况将请求分发给领域中的服务器,这些服务器可使用主干网络进行通信,也可以与数据库服务器进行通信。图 1-1 显示 Web 领域的基本体系结构。

图 1-1:Web 领域

管理 Web 领域中的状态

对于商务站点设计人员而言,最重要的问题之一就是 Web 领域中的应用程序状态问题。状态就是在两个用户请求之间必须保留的会话数据;例如,在用户继续浏览站点期间,必须一直维护该用户购物篮中的物品原状。即使每个用户请求可能是由 Web 领域中不同的服务器处理的,也须如此。

许多 ASP 开发人员使用“会话”对象来存放状态数据。不过,通常应避免使用此方法。为了优化站点的软件体系结构以便在服务器领域中加以实现,Web 前端禁止维护内存中的用户状态。如果前端服务器维护用户状态,将出现以下问题:

∙用户会话将依附于特定服务器<会话相关性),这会破坏动态地将请求分配给服务器的网络负载平衡策略。此外,还会破坏服务器领域的可靠性,因为当原服务器发生故障<并丢失了其内存中的会话状态信息)时,就无法将用户会话转移到其他服务器。

∙内存资源被前端服务器耗费在存放用户会话状态的细节上,从而减少了可用于处理请求和高速缓存内容的内存。如果一个受欢迎的站点能够在短时间内吸引大量的用户,则状态维护方面的内存需求可能非常大。为了部分解决内存需求问题,Commerce Server 大量使用了高速缓存。对配置文件架构、折扣和商业活动都将进行高速缓存。

相关文档
最新文档