面向资源与面向活动的 Web 服务 REST 样式与 SOAP 样式 Web 服务之间关系的概览
http://shenhh.blogbus.com/logs/48278178.html
http://xiaogui9317170.javaeye.com/blog/311590
amazon architecture
http://xiaogui9317170.javaeye.com/blog/276053
综合各种变化的技术和强耦合的客户服务端环境,AJAX提出了一种新的开发方式。AJAX开发人员必须理解传统的MVC架构,这限制了应用层次之间的边界。同时,开发人员还需要考虑CS环境的外部和使用AJAX技术来重定型MVC边界。最重要的是,AJAX开发人员必须禁止以页面集合的方式来考虑Web应用而需要将其认为是单个页面。一旦UI设计与服务架构之间的范围被严格区分开来后,开发人员就需要更新和变化的技术集合了
主要包含的技术
基web标准(standards-based presentation)XHTML+CSS的表示;
使用 DOM(Document Object Model)进行动态显示及交互;
使用 XML 和 XSLT 进行数据交换及相关操作;
使用 XMLHttpRequest 进行异步数据查询、检索;
使用 JavaScript 将所有的东西绑定在一起。英文参见Ajax的提出者Jesse James Garrett的原文,原文题目(Ajax: A New Approach to Web Applications)。
类似于DHTML或LAMP,AJAX不是指一种单一的技术,而是有机地利用了一系列相关的技术。事实上,一些基于AJAX的“派生/合成”式(derivative/composite)的技术正在出现,如“AFLAX”。
AJAX的应用使用支持以上技术的web浏览器作为运行平台。这些浏览器目前包括:
Google Chrome、Mozilla、Firefox、Internet Explorer、Opera、Konqueror及Safari。但是Opera不支持XSL格式对象,也不支持XSLT。
业务逻辑分散
Ajax技术之主要目的在于局部交换客户端及服务器之间的数据。如同传统之主从架构,无可避免的会有部分的业务逻辑会实现在客户端,或部分在客户端部分在服务器。由于业务逻辑可能分散在客户端及服务器,且以不同之程序语言实现,这导致Ajax应用程序极难维护。如有用户接口或业务逻辑之更动需求,再加上前一个JavaScript/DOM/CSS之兼容性问题,Ajax应用往往变成程序员的梦魇。针对业务逻辑分散的问题,Ajax开发框架大致可分为两类:
将业务逻辑及表现层放在浏览器,数据层放在服务器:因为所有的程序以JavaScript执行在客户端,只有需要数据时才向服务器要求服务,此法又称为胖客户端(fat client)架构。服务器在此架构下通常仅用于提供及储存数据。此法的好处在于程序员可以充分利用JavaScript搭配业务逻辑来做出特殊的用户接口,以符合终端用户的要求。但是问题也不少,主因在第一,JavaScript语言本身之能力可能不足以处理复杂的业务逻辑。第二,JavaScript的执行效能一向不好。第三,JavaScript访问服务器数据,仍需适当的服务器端程序之配合。第四,浏览器兼容性的问题又出现。有些Ajax开发框架如DWR企图以自动生成JavaScript之方式来避免兼容的问题,并开立通道使得JavaScript可以直接调用服务器端的Java程序来简化数据的访问。但是前述第一及第二两个问题仍然存在,程序员必须费相当的力气才能达到应用程序之规格要求,或可能根本无法达到要求。
将表现层[2]、业务逻辑、及数据层放在服务器,浏览器仅有用户接口引擎(User Interface engine);此法又称为瘦客户端(thin client)架构,或中心服务器(server-centric)架构。浏览器的用户接口引擎仅用于反映服务器的表现层以及传达用户的输入回到服务器的表现层。由浏览器所触发之事件亦送回服务器处理,根据业务逻辑来更新表现层,然后反映回浏览器。因为所有应用程序完全在服务器执行,数据及表现层皆可直接访问,程序员只需使用服务器端相对较成熟之程序语言(如Java语言)即可,不需再学习JavaScript/DOM/CSS,在开发应用程序时相对容易。缺点在于用户接口引擎以及表现层通常以标准组件的形式存在,如需要特殊组件(用户接口)时,往往须待原框架之开发者提供,缓不济急。如开源码Ajax开发框架ZK目前支持XUL及XHTML组件,尚无XAML之支持。