Application Architecture Guide 2.0 - CH 19 - Mobile Applications(2)

简介:

本文翻译Authentication and AuthorizationCachingCommunicationConfiguration Management部分。

 

Authentication and Authorization

Designing an effective authentication and authorization strategy is important for the security and reliability of your application. Weak authentication can leave your application vulnerable to unauthorized use. Mobile devices are usually designed to be single-user devices and normally lack basic user profile and security tracking beyond just a simple password. Other common desktop mechanisms are also likely to be missing. The discoverability of mobile devices over protocols such as Bluetooth can present users with unexpected scenarios. Mobile applications can also be especially challenging due to connectivity interruptions. Consider all possible connectivity scenarios, whether over-the-air or hard-wired.

认证和授权

对于你应用程序的安全性和可靠性来说,设计一个有效的认证和授权策略是非常重要的。相对来说较弱的认证可以让您的应用程序容易受到未经授权者的使用。移动设备一般是设计为单个用户使用的,除了一个简单的密码以外,经常缺少基本的用户配置文件和安全追踪策略。同时,在移动设备上,其他通用的桌面安全机制也容易被忽略。通过诸如蓝牙等协议,移动设备容易被发现,这就给用户带来了意料不到的情况。连接的中断可能性也会给移动应用带来极大的挑战。无论是通过无线或者是有线,我们必须考虑所有可能的连接场景。

 

Consider the following guidelines when designing authentication and authorization:

 Design authentication for over-the-air, cradled synchronization, Bluetooth discovery, and local SD card scenarios.

 Consider that different devices might have variations in their programming security models, which can affect authorization to access resources

 Do not assume that security mechanisms available on larger platforms will be available on a mobile platform, even if you are using the same tools. For example, access control lists(ACLs) are not available in Windows Mobile, and consequently there is no operating system–level file security.

 Ensure that you require authentication for access by Bluetooth devices.

 Identify trust boundaries within your mobile application layers; for instance, between the client and the server or the server and the database. This will help you to determine where and how to authenticate.

在设计认证和授权时,考虑以下几点指导方针:

•为无线连接、插座同步、蓝牙发现和本机SD卡设计认证。

•在编程安全模式上,不同的设备可能有所差异,这就会影响资源获取的认证。即使使用了相同的工具,也不要认为在大平台上的安全机制就可以用在移动平台上。例如,在Windows Mobile平台上,访问控制表是不可用的,因此就没有操作系统级的文件安全机制。

通过蓝牙接入设备时,确保使用了认证机制。

•明确您移动应用层中的信任界限。例如,是客户端与服务器之间的,还是服务器与数据库之间的。这有助于你确定在何处以何种方式进行认证。

 

Caching

Use caching to improve the performance and responsiveness of your application, and to support operation when there is no network connection. Use caching to optimize reference data lookups, to avoid network round trips, and to avoid unnecessarily duplicated processing. When deciding what data to cache, consider the limited resources of the device; you will have less storage space available than on a PC.

缓存

利用缓存来提高应用程序的性能和响应,并且在没有网络连接可用的情况下,支持程序的操作。使用缓存来优化参考数据的查询,避免网络往返时延的影响,减少不必要的重复操作。在决定缓存哪些数据时,必须要考虑设备有限的资源;与PC机相比,移动设备具有更少的可用存储空间。

 

Consider the following guidelines when designing caching:

 Identify your performance objectives. For example, determine your minimum response time and battery life. Test the performance of the specific devices you will be using. Most mobile devices use only flash memory, which is likely to be slower than the memory used in desktop machines.

 Cache static data that is useful, and avoid caching volatile data.

 Consider caching the data that the application is most likely to need in an occasionally connected scenario.

 Choose the appropriate cache location, such as on the device, at the mobile gateway, or in the database server.

 Design for minimum memory footprint. Cache only data that is absolutely necessary for the application to function, or expensive to transform into a ready-to-use format. If designing a memory-intensive application, detect low-memory scenarios and design a mechanism for prioritizing the data to discard as available memory decreases.

设计缓存时,考虑以下指导方针:

•明确性能目标。例如,制定最小响应时间和电池寿命后,在你将要使用的特定设备上进行测试。大多数移动设备只使用闪存,与桌面机器相比,它的读写速度更慢。

缓存有用的静态数据,而非易失性的数据。

在间歇性网络连接的场景下,考虑缓存那些应用程序需要的数据。

选择合适的缓存地点,例如是在设备上、移动网关或者是在数据库服务器上。

•设计所需内存最小的程序。缓存那些实现程序功能所必须的数据,或者是转变成可用格式的数据。如果设计一个内存密集型的程序,就需要检测内存大小低的情况,并设计一个机制,在可用内存减小的情况下,决定数据丢弃的优先级。

 

Communication

Device communication includes wireless communication (over the air) and wired communication with a host PC, as well as more specialized communication such as Bluetooth or Infrared Data Association (IrDA). When communicating over the air, consider data security to protect sensitive data from theft or tampering. If you are communicating through Web service interfaces, use mechanisms such as the WS-Secure standards to secure the data. Keep in mind that wireless device communication is more likely to be interrupted than communication from a PC, and that your application might be required to operate for long periods in a disconnected state.

通信

设备通信包括无线通信,与主机的有线通信,和更加特殊的诸如蓝牙或者红外线通信。在使用无线通信的情况下,必须考虑数据的安全性,防止敏感数据被盗或者被篡改。如果通过网络接口进行通信,那么就使用诸如WS安全标准机制来保护数据。牢记设备的无线通信与PC机相比,被中断的可能性更大。那样,你的应用程序必须在长时间没有网络连接的情况下正常工作。

 

Consider the following guidelines when designing your communication strategy:

 Design asynchronous, threaded communication to improve usability in occasionally connected scenarios.

 If you are designing an application that will run on a mobile phone, consider the effects of receiving a phone call during communication or program execution. Design the application to allow it to suspend and resume, or even exit the application.

 Protect communication over untrusted connections, such as Web services and other over-the- air methods.

 If you must access data from multiple sources, interoperate with other applications, or work while disconnected, consider using Web services for communication.

 If you are using WCF for communication and need to implement message queuing, consider using WCF store and forward.

在设计通信策略时,考虑以下指导方针:

•设计异步的线程通信来提高间歇性网络连接场景下的可用性。

•如果设计一个运行于移动电话上的应用程序,考虑通信或者程序执行期间来接电话的影响。将应用程序设计为可暂停,继续,或者是退出。

•防止设备在不可靠的连接上进行通信,例如网络服务和其他无线方式的服务。

•如果你必须从多个源来获取数据,与其他应用程序协作,或者在未联网的情况下工作,那么就考虑使用网络服务来进行通信。

•如果你使用WCF进行通信,同时需要实现消息队列,那么就考虑使用WCF存储和转发。

 

Configuration Management

When designing device configuration management, consider how to handle device resets, as well as whether you want to allow configuration of your application over the air or from a host PC.

Consider the following guidelines when designing your configuration-management strategy:

配置管理

在设计设备的配置管理时,考虑如何处理设备复位,是否允许通过无线方式或者主机方式来配置应用程序。在设计配置管理策略时,考虑以下指导方针:

 

 Design for the restoration of configuration after a device reset.

 If you have you enterprise data in Microsoft SQL Server 2005 or 2008 and desire an accelerated time to market, consider using merge replication with a “buy and configure” application from a third party. Merge replication can synchronize data in a single operation regardless of network bandwidth or data size.

 Due to memory limitations, choose binary format over Extensible Markup Language (XML) for configuration files

 Protect sensitive data in device configuration files.

 Consider using compression library routines to reduce the memory requirements for configuration and state information.

 If you have a Microsoft Active Directory® directory service infrastructure, consider using the System Center Mobile Device Manager interface to manage group configuration, authentication, and authorization of devices. See the Technology Considerations section for requirements for the Mobile Device Manager.

•考虑设备复位后的配置参数恢复。

•如果你在Microsoft SQL Server 2005 或者2008拥有企业级的数据,同时期望缩短上市时间,那么就考虑使用第三方“buy and configure”的应用来进行合并复制。合并复制可以通过单步操作来同步数据,而不管网络带宽或者数据大小。

•从配置文件存储所需的大小来看,选择二进制格式,而非XML格式。

•保护设备配置文件中的敏感数据。

•考虑使用压缩文件来减小配置和状态信息的存储空间大小需求。

•如果你拥有Microsoft Active Directory®服务基础设施,那么就考虑使用System Center Mobile Device Manager接口来管理设备的群组配置、认证和授权信息。请参考Technology Considerations节中关于Mobile Device Manager需求的部分。



本文转自施炯博客园博客,原文链接:http://www.cnblogs.com/dearsj001/archive/2009/01/13/1374941.html,如需转载请自行联系原作者

相关文章
|
6月前
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替"Greater Seattle Area"),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
60 6
|
6月前
|
XML NoSQL 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 概念 + 数据模型
【6月更文挑战第5天】本文探讨了数据模型的分析,关注点包括数据元素、关系及不同类型的模型(关系、文档、图)与Schema模式。查询语言的考量涉及与数据模型的关联及声明式与命令式编程。数据模型从应用开发者到硬件工程师的各抽象层次中起着简化复杂性的关键作用,理想模型应具备简洁直观和可组合性。
42 2
|
6月前
|
SQL 人工智能 关系型数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展,允许节点有多重父节点,但导航复杂,需要预知数据库结构。关系模型将数据组织为元组和关系,强调声明式查询,解耦查询语句与执行路径,简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据,提供弱模式灵活性,但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系,适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read,写入时不校验,读取时解析,牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
50 0
|
6月前
|
SQL JSON NoSQL
【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型
【6月更文挑战第6天】关系模型是主流数据库模型,以二维表形式展示数据,支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战,如网状和层次模型,但关系模型仍占主导。然而,随着大数据增长和NoSQL的出现(如MongoDB、Redis),强调伸缩性、专业化查询和表达力,关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题,ORM框架缓解但未完全解决。文档模型(如JSON)提供更自然的嵌套结构,适合表示复杂关系,具备模式灵活性和更好的数据局部性。
54 0
|
6月前
|
敏捷开发 存储 缓存
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可维护性
【6月更文挑战第4天】本文探讨了Twitter面临的一次发推文引发的巨大写入压力问题,指出用户粉丝数分布是决定系统扩展性的关键因素。为解决此问题,Twitter采用混合策略,大部分用户推文扇出至粉丝主页时间线,而少数名人推文则单独处理。性能指标包括吞吐量、响应时间和延迟,其中高百分位响应时间对用户体验至关重要。应对负载的方法分为纵向和横向扩展,以及自动和手动调整。文章强调了可维护性的重要性,包括可操作性、简单性和可演化性,以减轻维护负担和适应变化。此外,良好设计应减少复杂性,提供预测性行为,并支持未来改动。
62 0
|
6月前
|
缓存 关系型数据库 数据库
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可扩展性
【6月更文挑战第3天】可扩展性关乎系统应对负载增长的能力,但在产品初期过度设计可能导致失败。理解基本概念以应对可能的负载增长是必要的。衡量负载的关键指标包括日活、请求频率、数据库读写比例等。推特的扩展性挑战在于"扇出",即用户关注网络的广度。两种策略包括拉取(按需查询数据库)和推送(预计算feed流)。推送方法在推特案例中更为有效,因为它减少了高流量时的实时计算压力。
59 0