[翻译作品]2008年11月《Web 3.0:语义网进入主流》

业界也许还在忙于Web 2.0,但有些权威人士已经预见到Web 3.0涉及的新技术与新货币化战略了。 Web 2.0给诸如社会化网络(social networking)和用户创造内容(user-generated content)等领域带来了革新,其下一代将围绕语义网(Semantic Web)技术带来的潜在优点及真实案例而产生,出席Web 3.0博览会的公司们如是说。 <



2008年10月《探求真正的SOA》

SOA架构师Alex Maclinovsky在一篇新文章里讲述了一种方法,该方法可用于构建直接支持SOA治理的可扩展SOA基础设施。按Alex的话说: 通过流程、实践与工具相结合,推动企业服务的生命周期,并提供方法来创建、传达、贯彻和管理目前对公司很重要的、关于非功能性服务特征的公司策略。 理想的情况下,SOA基础设施必须在设计上是可扩展的,以便可以根据机构的要求方便地增添新的策略。基于方面的SOA基础设施(Aspect- Based SOA infrastructure)正是这样设计出来的,它允许你往现有平台里增添额外的软件服务。据Alex称: 我们无法列举出SOA服务——作为适当的企业计算平台——所应具备的全部特征,是有其根本原因。这个原因就是:这些特征是基 于实际的业务、制度等需求的,而这些需求是因行业、地理、时间及各个客户的具体情况而变的。 这种直接支持SOA治理的基础设施: 通过实现跨SOA参与者控制域边界的合理重用,把企业服务从数字制品转变为现实业务制品。 欲了解更多信息,请阅读完整文章:《探求真正的SOA》。全文请看InfoQ中文站:http://www.infoq.com/cn/news/2008/10/quest-for-true-soa



2008年10月《如何实现真正的REST风格?》

Roy Fielding查看了SocialSite的REST API,发现它并不十分符合REST风格。

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。[做不到这一点,就意味着客户



[翻译作品]2008年10月《厂商依赖是云计算采纳的障碍?》

Tim Bray、Dare Obasanjo和Dewitt Clinton就厂商依赖对云计算采纳造成的影响相互交换了意见。你觉得厂商依赖是一个重大问题吗?或者,你觉得一个厂商在提供更受欢迎的产品的同时,会不会为你解决迁移问题。
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









[原创作品]2008年10月《分布式数据挖掘:应付分布式海量数据的现代方法》

人们面临的挑战不再是收集信息,而是挖掘数据以回答特定研究问题。Benjamin Lieberman在最近的一篇developerWorks系列文章里向大家介绍了用分布式数据挖掘来处理这些分布式海量数据的技术。Benjamin Lieberman认为拥有分布式数据的组织面临着如何发现、访问和有效地使用分布式海量数据的挑战,而这可以用分布式数据挖掘技术来解决: 发现信息:包括静态发现和动态发现。静态发现是手动确定数据源系统,并预先把处理系统配置好,以便其在处理过程中使用发现的源,此方法最常见但最不灵活。动态发现是UDDI及OGSI(Open Grid Service Infrastructure)背后的基本思想,数据源将其功能和内容在中央注册中心进行注册,以便你可以在运行时查询中央注册中心以寻找符合处理需要的数据源。 安全地访问信息:获得访问权限需要对用户进行身份验证。对于分布式数据库,每个源可能使用的是不同的安全机制,这是分布式处理模型里的一个主要难题。 有效地传输与使用数据:数据源的庞大使得通过远程连接获取数据变得不切实际。你有两种选择:批量获取数据,然后在本地处理(如SETI@HOME项目);或者在远程平台上执行处理。 [略]

“网格计算已出现一段时间了,并正开始被看作是大规模计算的未来趋势。管理大型分布式数据集的能力是网格工作的关键问题,”Benjamin Lieberman总结道。随着世界上最大网格(大型强子对撞机计算网格)的投入使用,这篇关于分布式数据挖掘的文章也许可以给我们带来了不少启发。感兴趣的朋友请进一步阅读全文。

全文请看InfoQ中文站:http://www.infoq.com/cn/news/2008/10/distributed-data-mining



[翻译作品]2008年10月《是否该重新衡量SOA产品了?》

Gartner分析师Roy Schulte是SOA方面的专家,他参与编写了1996年那份为业界引入SOA这一术语的Gartner报告。前不久Susan Hall对他进行了采访。此次采访试图回答这样一个问题,即是否应该重新调整对SOA的期待了? 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),即取走一个模块、用一个新模块取代它的能力。如果你从不重用它,那么你就获得模块性了。”
[以下略]

全文请看InfoQ中文站:http://www.infoq.com/cn/news/2008/10/rebalance-soa-portfolio





[翻译作品]2008年10月《比较各JAX-RS实现》

现在JAX-RS有四种以上的不同实现供大家选择。哪个实现最好?可以这么问吗?Solomon Duskis不仅对几种最重要的JAX-RS实现进行了比较与对比,他也试图解答这个问题。

正如某人在别处说的,关于公交车,有一个奇怪的现象:你等了很久一辆不来,最后却一下来了三辆!JAX-RS实现貌似也碰到了类似的问题。目前我们有:
CXF——XFire和Celtix的合并(一个由IONA赞助的开源ESB,最初寄存在ObjectWeb上)。 Jersey——Sun公司的JAX-RS参考实现。 RESTEasy——JBoss的JAX-RS项目。 Restlet——也许是最早的REST框架了,它JAX-RS之前就有了。 尽管围绕着REST存在各种各样的争论,但JAX-RS提供了Java语言所需的REST支持这一点是无可争议的。如果你是REST新手,你会选择哪种实现呢?嗯,Solomon Duskis试图解答这一问题。他还在dzone上指出: 我想就以下几个“纯”JAX-RS以外的方面对各JAX-RS实现进行比较。 这些方面包括:
产品成熟度
服务端集成策略
Java客户端API 可配



[翻译作品]2008年9月《克服SOA实施过程中的障碍》

在本文中,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





[翻译作品]2008年9月《WOA与SOA之争》

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

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




[站务信息]即将更新博客程序,征集广大用户建议 

不知大家希望新程序具有哪些功能?

大家可以在此说说自己的想法和建议,我们将尽量满足大家的要求。

谢谢!



« 1 2 3 4 5 6 7 8 9 10 »

日历 | CALENDAR

«April 2020»
1234
567891011
12131415161718
19202122232425
2627282930
blog名称:World Wide Web Watch
日志总数:193
评论数量:664
留言数量:75
访问次数:5743606
建立时间:2004年10月30日
站点首页 | 联系我们 | 博客注册 | 博客登陆

Sponsored By W3CHINA
W3CHINA Blog 0.8 Processed in 0.047 second(s), page refreshed 144387390 times.
《全国人大常委会关于维护互联网安全的决定》  《计算机信息网络国际联网安全保护管理办法》
苏ICP备05006046号