================

Dear Google Apps admin,

We're contacting you regarding your use of Google Apps with the domains listed below as a domain alias or aliases.  Google does not offer this product on .cn domains, including the use of .cn domains as domain aliases. Unfortunately, due to an error in our domain alias feature, your .cn domain was allowed as a domain alias.

On 10 January 2011 at 18:00 GMT, all .cn domains listed in the domain alias section of your control panel will be removed by our team. This action will not affect any existing data for any of your users.

If you would like to continue to receive email sent to accounts that belong to your .cn domain, we recommend securing a different email solution for your .cn domain. Email service for your non-.CN domain names will be unaffected.

We apologize for our mistake and the inconvenience caused by this change. We appreciate this transition may be disruptive, and are committed to helping you make it as smooth as possible.  If you require any assistance, please reply to this message so our team can help. Additionally, if you would like technical assistance via the phone, please provide your phone number and two convenient times when we can reach you.

Sincerely,

The Google Apps Team
1600 Amphitheatre Pkwy
Mountain View, CA, 94040

You have received this mandatory email service announcement to update you about important changes to your Google Enterprise product or account.

The following .cn domain aliases will be removed on 10 January 2011 at 18:00 GMT:

XXXXX.cn

尊敬的Google企业应用套件管理员：

您好！我们联系您是因为您正在使用下面所列的.cn域名作为您Google企业应用套件服务 主域名的别名（alias）。Google目前并不在.cn域名下提供Google企业应用套件服务，包括.cn域名作为域名别名（alias）的服务。遗憾的是由于我们注册流程上的疏漏，您的.cn域名被允许作为了Google企业应用套件服务的域名别名。

我们将会在格林威治时间（GMT）2011年1月10日18时删除您控制面板域名别名列表中的所有.cn域名。这个操作不会影响到您的用户的任何数据。

如果您希望继续收到发送到.cn域名的邮件，我们推荐您为.cn域名选择一个不同的邮件解决方案。您的其它非.cn域名的邮件服务将不受影响。

我们对工作疏漏导致的不便表示歉意。我们理解这次数据转移可能会给您带来不便，同时我们也致力于帮助您尽可能圆满的完成数据迁移。 如果您需要任何帮助，请直接回复本邮件，我们的团队会帮助您。如果您需要进一步的技术协助，请提供您的电话号码和两个方便的交流时间，我们会随后和您联系。

祝顺利，

Google企业应用套件团队
1600 Amphitheatre Pkwy
Mountain View, CA, 94040

电子邮件接收设置：我们向您发送这封必读的电子邮件服务通告，目的是让您了解 Google Enterprise 产品或帐户的重大变化。

下面的.cn域名别名将会在格林威治时间（GMT）2011年1月10日18时被删除：

XXXXX.cn

对大多数企业架构师来说，SOA（面向服务的架构）的价值主张是明确的：SOA提供了灵活性、敏捷性和可重用性，这些已在整个软件开发社区里得到了广泛的认可。然而，也许你会惊讶地发现，SOA实施并不像许多分析机构或Web研讨会所指出的那样普遍。原因很简单：尽管有那么多关于SOA的资料，尽管成功故事层出不穷，但SOA实施起来要比其推广者们所预料的要艰难得多。

大约10年前我就开始设计实行面向服务模式的系统了。我参加过各种各样的项目，从进行简单系统交互的服务，到涉及全套面向服务模式的复杂交互，等等。几乎所有这些项目都遇到了起初未曾预料到的挑战。在本文中，我将讲述一些关键挑战，并就克服这些挑战的最有效办法提出一些建议。

我们的任务是阐述各种方案，并寻找能够给企业带来效益的战略与战术方向，而不是鼓吹某种具体方法或架构。

[略]

挑战2：说服公司采用SOA

[略]

挑战3：设计最有效的SOA路线图

如果我们（架构师）的确看到了SOA的价值，那么下一个问题就是定义实现它的过程。我体验过很多不同的途径——各个途径都有自己的长处与短处。

[略]

重点在于：构建一个有效的SOA，是企业在软件方面为数不多的命令之一；然而，正如维持竞争生存能力是必需的一样，要实现这一目标，必须具有清醒的务实态度，以及对成功的实施步骤（及代价）有深入的研究和理解。

通过流程、实践与工具相结合，推动企业服务的生命周期，并提供方法来创建、传达、贯彻和管理目前对公司很重要的、关于非功能性服务特征的公司策略。

理想的情况下，SOA基础设施必须在设计上是可扩展的，以便可以根据机构的要求方便地增添新的策略。基于方面的SOA基础设施（Aspect- Based SOA infrastructure）正是这样设计出来的，它允许你往现有平台里增添额外的软件服务。据Alex称：

我们无法列举出SOA服务——作为适当的企业计算平台——所应具备的全部特征，是有其根本原因。这个原因就是：这些特征是基 于实际的业务、制度等需求的，而这些需求是因行业、地理、时间及各个客户的具体情况而变的。

这种直接支持SOA治理的基础设施：

通过实现跨SOA参与者控制域边界的合理重用，把企业服务从数字制品转变为现实业务制品。

欲了解更多信息，请阅读完整文章：《探求真正的SOA》。

全文请看InfoQ中文站：http://www.infoq.com/cn/news/2008/10/quest-for-true-soa

SocialSite的REST API最近因Roy Fielding称其不符合REST风格而受到批评。Roy说，它是众多自称符合REST风格而实则不然的系统之一。

OpenSocial的REST API是RPC式的，而且是公然宣誓其RPC本性。它在如此多的方面存在耦合，所以理应将它评为“差”。

从OpenSocial网页上提供的信息来看，你不难同意Roy的观点。例如：

• 在服务端为OpenSocial风格的REST和JSON-RPC提供支持
• 在客户端为JSON-RPC批量请求提供支持
• 服从OpenSocial对扩展的需求

另外，我们都知道REST跟RPC是紧密相关的。 鉴于已经见过很多自称符合REST风格而实则不然的网站，Roy接着就如何构建真正符合REST风格的网站（及API）给予了指导。现部分摘录如下：

• REST API不应依赖于某一个通信协议。如果一个协议元素（protocol element）要将URI用于标识的目的，那么它必须允许采用任意URI方案（scheme）。[做不到这一点，就意味着标识与交互没有分离。]
• 媒 体类型（media types）是用于表示资源和推进应用状态（application state）的，REST API应将绝大部分描述精力用于定义媒体类型，或者是为现有的标准媒体类型定义扩展的关系名称（relation names）和/或基于超文本的标记（markup）。如果要就“对所谈及的URIs采用什么方法”进行定义的话，那么应完全把它放在媒体类型的处理规则 范围内进行定义（不过在大多数情况下，现有媒体类型都已经定义好了）。[做不到这一点，就意味着交互不是由超文本、而是由外部信息（out-of-band information）推进的。]
• REST API一定不能定义固定的资源名称或层次。服务器必须可以自由控制它自己的名称空间（namespace）。应该像HTML表单（HTML forms）和URI模版（URI templates）那样，通过媒体类型和链接关系（link relations）给出指示，使得服务器可以指导客户端如何构造正确的URIs。[做不到这一点，就意味着客户端在根据外部信息（比如跟领域相关的标准）假定资源结构——相当于面向数据方法里的RPC功能耦合。]
• 要 使用REST API，应该只需知道初始URI（书签）和一套适合于目标用户（即可被任何使用该API的客户端所理解）的标准媒体类型。这样的话，所有的应用状态迁移， 都必须以“客户端在服务器提供的选项里挑选”这样的方式进行；服务器提供的选项，或者直接出现在用户收到的表示（representations）里，或 者在用户对那些表示进行处理后得到。客户端可以根据自己所掌握的关于媒体类型与资源通信机制的知识来决定（或限制）状态转移，客户端可以即时增加对媒体类 型与资源通信机制的支持（比如通过代码请求）。[做不到这一点，就意味着交互不是由超文本、而是由外部信息推进的。]

Roy的这篇文章收到了很多反馈，有的是直接回复评论，有的是另发文章，其中有人提出了一些关于超文本/超媒体使用的问题，对此Roy回答道：

Tim Bray上周写了一篇关于云计算采纳的文章。他觉得存在两大主要问题：

• 我们还没有找到最佳的云平台（cloud platforms）架构方案。是采取Amazon的EC2/S3“裸虚拟白盒（Naked virtual whitebox）”模型？还是采取像Google App Engine那样平台即服务（Platform-as-a-service）的风格？我们尚不知晓。
• 如果云平台要受到大家欢迎的话，那么它必须做到绝对不能出现厂商依赖的情况。

Tim最后说道：

在21世纪的今天仍然步桌面套件和私有SQL的后尘、重演厂商依赖的悲剧，我们“脑残”到这个地步了吗？你知道，那等于把IT预算控制权交给平台厂商了？

Dare Obasanjo不明白能够避免厂商依赖将意味着什么：

与Web开发平台的切换相比，从一个应用切换到另一个应用是一个类似且更容易的问题。

他认为，对于基于“云”的办公套件：

由于有ODF和OOXML这些标准，因此应该很容易对业务文档进行迁移。

但是他也敦促大家考虑以下问题：

有没有自动化批量执行导入导出的办法？

是不是大家只能手工进行在线文档与标准格式间的导出/导入？

若数据迁移导致指向公司数据的链接和引用失效，会有什么影响？

你们公司迁移数据需要多大的代价（包括公司因切换服务而停工，以及IT部门迁移所有数据的实际开销）？

[以下略]

全文请看InfoQ中文站：http://www.infoq.com/cn/news/2008/10/cloud-architecture

• 发现信息：包括静态发现和动态发现。静态发现是手动确定数据源系统，并预先把处理系统配置好，以便其在处理过程中使用发现的源，此方法最常见但最不灵活。动态发现是UDDI及OGSI（Open Grid Service Infrastructure）背后的基本思想，数据源将其功能和内容在中央注册中心进行注册，以便你可以在运行时查询中央注册中心以寻找符合处理需要的数据源。
• 安全地访问信息：获得访问权限需要对用户进行身份验证。对于分布式数据库，每个源可能使用的是不同的安全机制，这是分布式处理模型里的一个主要难题。
• 有效地传输与使用数据：数据源的庞大使得通过远程连接获取数据变得不切实际。你有两种选择：批量获取数据，然后在本地处理（如SETI@HOME项目）；或者在远程平台上执行处理。

Gartner分析师Roy Schulte是SOA方面的专家，他参与编写了1996年那份为业界引入SOA这一术语的Gartner报告。前不久Susan Hall对他进行了采访。采访原稿可以在IT Business Edge上找到。

据Roy Schulte称，Gartner对大约250家大型企业调查后发现，准备近期开展SOA项目的企业较去年相比少了；对效益感到失望，是这些企业疏远SOA的一个原因。

Roy Schulte发现，重用或共享程度低下是最不能令人满意的方面。他说“我们曾见过的最好的情况是40%的重用，我们Gartner认为介于10%与40%之间就算成功了”。他解释道：

SOA的启动成本相当大。你必须培训人员、改变开发方法和治理方法，而且你常常需要设立一个企业级卓越中心（center of excellence）来跟踪所有元数据，所以启动阶段是有些痛苦的。另一方面，你发现你所构建的服务都只跟一个业务功能相关，于是，由于没有别的业务功 能需要它，所以你无法重用它。

他说，“SOA更普遍的好处是模块性（modularity），即取走一个模块、用一个新模块取代它的能力。如果你从不重用它，那么你就获得模块性了。”

• CXF——XFire和Celtix的合并（一个由IONA赞助的开源ESB，最初寄存在ObjectWeb上）。
• Jersey——Sun公司的JAX-RS参考实现。
• RESTEasy——JBoss的JAX-RS项目。
• Restlet——也许是最早的REST框架了，它JAX-RS之前就有了。

我想就以下几个“纯”JAX-RS以外的方面对各JAX-RS实现进行比较。

• 产品成熟度
  
• 服务端集成策略
  
• Java客户端API
• 可配置能力
• 安全性
• 性能

在本文中，Jonathan Mack分享了从业务、技术和组织角度来应付SOA挑战的第一手经验。他指出了成功实施SOA的关键要素、主要障碍以及克服这些障碍的方法。

Jonathan Mack说，现在SOA实施“并不像许多分析机构或Web研讨会所指出的那样普遍”。原因很简单：成功的SOA实施是颇具挑战性的。Jonathan Mack概述了三大挑战：

• 解决早于SOA的架构——将现有企业资产整合到SOA里去。
• 说服公司采用SOA——用具体的事实（而不是总体的陈述）阐述为什么SOA能够产生与其成本相称的效益，得公司涉众（stakeholders）信服。
• 设计最有效的SOA路线图——定义实现SOA愿景的过程。

虽然大部分SOA实践者们提倡在现有企业应用之上构建一个瘦服务层、尽量重用已经存在的功能，但这样实施的挑战性常常比通常认为的要大得多。Jonathan Mack指出：

过去构建的遗留系统（legacy systems）是一些零散的批处理或在线处理程序，它们必须按特定的顺序组合起来才能产生有意义的业务功能。那些遗留的处理程序是用于满足实际需要的， 它们常常是根据实际开发流程得到的、而不是与具体的功能相对应。从服务的观点来看，这些程序缺乏一致性和含义。

关于解决这一问题的实际办法，Jonathan Mack概述如下：

[以下略]

全文请看InfoQ中文站：http://www.infoq.com/cn/news/2008/09/SOAObstacles

Gartner副总裁Nick Gall是首个使用WOA一词的人，在一次访谈中，Loraine Lawson请他向商业和IT主管们谈谈WOA与SOA之争的重点内容。

当被问及WOA一词的由来时，Nick Gall说

我所能找到最早的记录是在2005年的秋天，当时我是在一个大会上发言时用到这个词的，然后我们公司的另一位副总裁Whit Andrew在他的博客里记录下了我用到这个词这件事。

他说，REST风格是跟WOA最为接近的架构风格，但“REST引起了太多的争议，而且关于REST的实际含义存在着诸多误解”，于是他就发明了一个新术语。他说道：

在我看来，WOA意味着一种更加以Web为中心的Web服务风格，它更简单、不怎么复杂、也不怎么受厂商驱使，它代表的就是这种新出现的风格。

接着，他用公式简洁地描述了这个架构风格“WOA = SOA + REST + WWW”。他通过为SOA添加架构约束的方式描述了WOA。

[以下略]

全文请看InfoQ中文站：http://www.infoq.com/cn/news/2008/09/woa-soa-debate