DasBlog: 构建一个分布式.NET 协作系统
本文详细说明了weblogs 作为一种知识共享方式的优点，同时通过使用Microsoft .NET 技术描述了设计和实现一个已构建好的weblog的一些经验教训。
本页内容
第一部分：Weblog 现象
软件商业中的Weblogs
Weblogs作为一种企业交流和协作工具
第二部分: Weblog 技术和应用
RSS 以XML形式表达与集合信息
推荐热门的讨论和相互交流
dasBlog: 实现一个 Weblog 引擎
dasBlog: 要求，考虑和解决办法
存储
内容管理
翻译引擎和地方化
线程模型与 Hosting
总结
资源
生 活中，写日记似乎主要是十几岁小女孩，政治家和那些打算写一些论文集的人的一个困扰。日记用来记录那些每天或每周个人的思想而不是其它别人的事情。无论这 个日记是被一个失望地爱上摇滚名星Robbie Williams的15岁小女孩保存，还是被德国的大臣保存，所有的日记都有一个共同的方面----他们是最高的秘密，封存起来永远不与任何人分享。
看一下网上最新的倾向，我们可能必须要改变一下，或者至少要扩展一下我们对日记的定义。Weblogs（通常缩写成'Blogs'）已经成为私人日记的数字化等价物，在过去的两年里在国际上已经刮起了一场风暴。Mid-2003对blogcensus.net 和 blogcount.com进 行了估算，某些地方weblogs的总数量已经处于130万和220万之间，这些数字正在快速地增长。日记与weblogs之间最显著的两个区别是 weblogs不仅仅只为十几岁的小女孩或是政治家，weblogs根本就不是什么秘密。相反，weblogs是开放的，每个人都可以看到。
那 么为什么在一本有关软件结构与信息技术管理的期刊中会讨论这个主题呢？有两个主要原因：首先，有许多体系结构的经验结论可以从weblog现象和能够对 weblog领域产生影响的技术中得到。事实是，现有的weblog空间作为一个整体已经成为最大的分布式XML和Web services应用程序。其次，weblogs正在变成一种战略性的工具用于在企业内部改善交流与协作，weblogs最终可能和email一样重要。
在本文的第一部分，我会分析并解释weblog现象，同时给出一些在商业环境中weblogs如何被当成一个协作系统来使用的例子。在第二部分，我会着重于weblog相关的技术，检查一个WebLog 引擎具体的例子，这个引擎是以一种基于免费的Microsoft® ASP.NET dasBlog应用程序的newtelligence形式而存在的，同时分享一些newtelligence体系结构的经验，这些经验都是通过在这个平台上实现、部署和运行weblogs来得到的。
第一部分：Weblog 现象
以前我们研究更多的是技术方面，我们应该花费一点时间来分析为什么weblogs会变得如此受欢迎，为什么一些人在网络上发表他们以前的秘密日记呢？在什么地方每个人都可以读到它？
写 日记，写weblog 确实是一个很好的想法。以写的方式详细地叙述思想和想法需要更认真更热情地研究这个主题。而不仅仅是考虑一下它就可以了。保持对思想，观点，问题及解决方 法在时间上的跟踪有助于个人经验的不断增长，通过这些经验体会你可以查看以前仔细考虑过的但现在想不起来的一些细节。
然而，写 weblogs是一个很好的想法还不能足以解释weblogs为什么如此受欢迎。使weblogs真正受欢迎的原因是他们为每个人提供了一种近乎完美的个 人表达空间。甚至随着HTML编辑工具最新一代的产生，对于大多数人来说维护个人网站是如此复杂而与由专业网页设计人员所设计的优美网站相比结果却令人很 失望。即使设计技术上的难题能够被解决，那也经常会有一种相关信息是否应该被包含在主页里这样进退两难的事情。除非拥有者是一个狂热的执迷者，渴望将他的 经历进行共享，创建主页的努力通常会导致与大量的图片没有什么差别，个人的问候比如'欢迎来到我的主页'和一些特别喜爱的链接----相反使人感觉到灰心 就不会再有人来访问了。
Weblogs---更精确来说，被用来创建weblogs的工具---可以帮助克服这些个人表达的障碍。事实 上，大多数受欢迎的weblog工具都是一些相当老炼的个人信息管理系统了，这些系统负责将个人信息转换成一种专业的HTML模板。他们经常会提供内容的 分类以及主题，历史导航能力。这个功能，与方便使用的特性结合起来似乎解决了内容难于选择的局面。如果在一个网站了发表只有三行的简短想法不比写 email所花费的努力大的话，那么写weblog就更有可能发生了。想法表达的方便性以及随意表达想法的能力导致了个人主页与weblogs之间的差 别：主页能够帮助显耀一下HTML技能或者是对一具体主题的知识面；weblogs则展现出个性人格同时告诉一个正在进行的故事。
此 外，weblogs已经变成了一个公共讨论的平台，在这个平台上人们可能进行思想与观点的交流。因为weblogs是以超文本的形式进行安排格局的，他们 允许链接到其他的weblogs上，也能够使weblog的创作者公开地评论别的创作者，对于任意一个其他的网页来说，其创建者都想突出一下他们的读者。 很多weblog工具也方便了每个主题读者的评论的收集，这样就允许每个人，而不仅仅是'博客们'，加入到这个讨论中。
Weblog工具不仅可以作为网站描述内容，也可以用XML来描述。最普通的使用格式是真正简单联合供稿系统(RSS) 2.0格式（也就是所涉及到的RDF Site Summary 或者Rich Site Summary）。
XML 和 RSS允许weblog的读者使用具体的工具将感兴起的内容放到本地的内容仓库中，这个仓库方便信息的查找，同时提供下线也能够使用的观点的每个类别。Microsoft Outlook®的一个插件NewsGator甚至将这种能力集成到你每日电子邮件的客户端上。
软件商业中的Weblogs
最 近，Weblogs已经转变成一种流行的工具用来个人发表见解和进行社区讨论。为社区提供知道和信息的工作者们已经从作为当今信息源泉的Weblogs中 获得了很大的收益。软件的开发者和架构师以及销售者、市场职工都会经常发现Weblog几乎链接了查询结果中前10个网站的入口---有时Weblog入 口似乎对于确定的信息是一个好的资源。
技术公司像微软和Sun甚至已经致力于入口的研究，通过这个入口他们的员工能够管理他们的 weblogs。然而，微软的入口对于weblogs是很开放的，它提供一系列的链接指向他们员工自己的blogs，这个blogs只反应他们个人的观点 而不代表'官方' Redmond的立场，Sun的入口和weblogs大多数是带有个人想法的市场开发者和培训工具的开发者。这两种方式差不多少，不能说哪个比较好或是比 较差。Sun主要感兴趣的是一种协调的，优美的外部社区信息，而微软的方式是以一种非正式的，个人级别的形式获得和保留与客户间的交流联系，同时给他们一 个不经审查就可以对这个场景之后将会发生什么来阐述自己的见解。
微软和Sun这两种针对公众社区weblogs的方式都弥补了社区信息的 缺陷。Weblog格式，个人的气质以及表达信息的方便性都允许创建者布置小的可以提供情报的关于一个产品或是一个解决途径的记录片段，这已经被很开放的 微软方法所证实了，有时甚至没有经历通常的社区讨论，没有编辑和表达这些讨论。很明显，象微软这样大的公司也不能通过使用'官方渠道'证明每个问题的解决 方法和工作区，随着对地方化、一致性和表达过程的需求—--让员工们用他们自己的见解增加对官方文件的理解这是一个完善描述和弥补缺陷的明智的方法。
在 软件行业中，使用weblogs的社区是最明显易见的，但是这不是对它的限制。这有一些迹象表明weblogs开始在其他的一些行业履行类似的角色，比 如：法律行业，媒体行业，时尚行业，和大量的工程领域。Weblogs有助于引进大量的对社区信息的一些个人观点，weblogs是一个很有价值的市场， 它也是证明个人能力和那些作为一个公司推动者的才干的公众关系工具。
Weblogs作为一种企业交流和协作工具
对于一个企业来说，一个极有魅力的weblogs应用是信息的分配与企业网内部的相互合作。虽然许多企业已经实现了入口的解决方案，同时也实现了长期用于信息的分配与讨论平台的'组件'，但是还是有潜力来充分地提高企业信息的生态系统和养成一种更显著的企业文化。
让我们看一下weblogs和相关的技术是如何在一个协作的环境中被使用的一些例子以及不同于已确定的方法的使用价值。
-
个人 weblogs. 个人weblogs是最显而易见的应用，但是---依赖于社区文化----也是最有可能发生冲突的。个人 weblogs是一个 '个人入口' 同时允许个人进行跟踪他们自己工作的结果和他们从第三方信息源（比如外网）那里收集到的信息。由于它按时间年代顺序排列的属性，它也提供许多方式来存档讨 论过程的历史记录和对未来事物的设想，因此它提供一种功能对成功，重要或是失败的事情进行后期分析研究。冲突的潜在性就会导致一些问题，比如：内容的所有 权问题，监督管理问题，个人表达的自由问题，规律推理问题以及一些相类似的问题。
-
中心知识主题 weblogs (K-Logs). K-Logs 不是以个人为核心的，而是以一个主题为核心。他们是建立在相同的技术如weblogs的基础上的，但是有多个创建者，这些创建者一般都来自一个团队，有时 也可是垮团队甚至是彼此分开的。K-Logs集中于特定问题区域能够将信息和相关的主题内容集合起来作为一个不断增长的按时间排列的知识库。 在这个功能里， K-Logs与杰出的知识入口解决方案有重叠的地方。使 K-Logs吸引人的是相对低廉的软件获取成本，使用的方便性，以及分配和集合via RSS 内容的能力。这些优点在本文的后面会有详细的说明。
-
团队 weblogs. 团队weblogs是团队的核心，它跟踪着一个特定产品或项目开发的过程。
-
自动化的 weblogs. 利用类似于'Mail-To-weblog' (本文后面讨论)的特征或者与由weblog 引擎软件所引发的Web 服务相结合，weblogs就能够作为一个易于安装和易于维护的表达要点来为自动化信息的产生服务。在软件产业中，这种信息里包含由自动构建和测试过程所 产生的日常报告，在制造加工行业，它可能还是一种统计上的信息，等等。自动化weblogs 的好处在于以一种易于理解的方式来表达这样信息所花费的努力已经降到了最小，同时对于信息的提供者来提供一个很简单的纯文本框架是很充足的。
你自己对社区知识的获取和分配的一个分析可能需要产生更可能的weblogs 应用。除此以外，基于RSS的订阅信息服务能够帮助改善公司内部信息的分配，而不是通过泛滥的电子邮件。这些例子就是自动化产生有关系统或核心组织活动每 日或每小时的报告，但是，也会产生平凡而重要的一些事情，比如：今天公司酒店里的菜单或者公司足球队的最新分数。
第二部分: Weblog 技术和应用
'Blogosphere'作为weblog空间也经常被称为weblog迷，它是由一系列核心技术推动着，在我们能够继续解释一些newtelligence's dasBlog上具体实现的细节之前，我们需要解释一下这些核心技术。
RSS 以XML形式表达与集合信息
最重要的weblog 技术不可否认的就是Real Simple Syndication (RSS) XML 格式，在本文的前面早就涉及到了。RSS最初是由Userland软件公司和Netscape公司以XML的形式创建的，Netscape导航6.0 '工具条'的特征是延续了第四代Netscape产品的技术。RSS可以当成是一个微软基于XMLChannel Definition Format (CDF)的'激活的渠道' 和'激活的桌面'，这些在微软的IE4.0里已经介绍了，它们几乎为同样的目的而服务的。
在RSS 和CDF之后的普通想法是为站点提供机器可读的索引，这些站点可能是Netscape Navigator和IE精选出来的，并且允许浏览器列出当今站点的集锦和标题，在Netscape工具条中或者在IE最受人喜爱的意见里，也或者是在微 软公司的'活动桌面'上。许诺就是一个用户对感兴趣的全部新闻标题和文章可能被输入到一个迅速的联机的会议中，然后这些东西脱机也可使用----主要是作 为一种便利的工作区来支付每分钟互联网的费用。长期不用的Pointcast Network有 类似的办法，它也正在使用CDF格式从它的来源那里获得信息，同时使用这种格式来捐赠渠道作为他们的客户软件。令人遗憾，这些产品和特征都没有得到任何大 的成功；为Netscape 或者IE 建造的'渠道'已经成为一个绝种的种类。 RSS由于Userland软件和一些其他供应商(集中于小的规模内容管理体制)的继续努力幸存， 今天的weblog 工具最终逐步形成。
尽 管它的流行程度和RSS已经聚积了大量重要的技术这一事实是很难被代替的，但我们应该认识到RSS还有许多重要的不足之处需要改变或是增加。RSS缺少对 XML命名空间的支持，不能使用由XML说明书统一规定的国际标准化时间格式， 没有标准化的XML模式或者甚至文档类型定义，说明书本身就是不明确的，缺少正式格式。这些问题已经促成了以IBM工程师Sam Ruby 为核心的工作团队的形成，随着将大量weblog 技术合并到一系列说明书Atom名称下面，他正致力于取代RSS的工作。
推荐热门的讨论和相互交流
出现在Blogosphere 上的一些博客之间的公开交流是它最大吸引力与促进因素之一。对一确定主题的讨论通常会聚集很多作者，他们在自己的weblogs独立地发表他们的观点，但 是通过引用其它作者观点和链接到各自weblogs上，他们就可以创建一个这些观点，信息和对确定主题看法的超级链接。
很多 weblogs上的讨论都是以没有规则的方式形成的，并不是混乱。这与互联网上新闻组间的讨论，关于邮件列表的讨论，以及组件系统中公开文件夹的评论是有 区别的。在这些情况下，讨论的参与者必须积极地成为一个讨论组的贡献者，本组的讨论通常会被组外的人所忽略。在某种程度上，Google新闻组就将他们的 的讨论放到WEB上，但是用户还是要以具体的新闻组或是特定的关键字来进行更精确的查询。
早先的辅助于混乱的讨论和交流形式的工具是一个简单的众所周知的由所有普通Web浏览器（HTTP参考报 头）支持的机制。当某人偶尔遇到一个感兴趣的话题，一个由一篇文章所引发的思想或是他们表达他们欢呼的看法，关心的事情或者是相对于自己weblog的支 持信息---他们就增加一个超级链接到所引用的weblog中，同时将它发到其它的weblog上。 由于几乎所有的weblog工具都认可HTTP参考报头，因此通知原始登录的作者就象在浏览器中点一下链接那么简单，这是因为参考报 头保留了超级链接所设计的页面的URL地址。大多数流行的weblog引擎都会跟踪和巩固列表中所推荐的条目，这些条目以通过外部链接和作为一个能占击的 超级链接URL地址进入到weblog上的访问者数量的多少来排列---一些weblog引擎能够以电子邮件的方式通知他们自己。以这种方式，一个作者就 可以学到关于外部注释和引用的一些东西，同时他能张贴他自己的回应或是附加的注释----- 在链接返回，链接的引用，以及第三方weblog 链接的处理过程中导致主题的形成和展开。
由于推举的超级链接一直需要人为的干预来触发通知这一事件，因此两个附加的更紧迫的通知机制已经获得了weblog社区与构建工具的支持，即Pingback 和 Trackback。
Pingback 允许在weblog 引擎间实现自动化的通知，而没有必要依赖于HTTP推举的东西。Pingback 定义了一个Web service 接口 (使用XML-RPC Web services 协议, 而不是它的后继SOAP)和两个auto-discovery机制。原理的功能是很简单的：当weblog创建者为他们的weblog开放一个新的入口 时，引擎就查看已提交的HTML框架同时作为一个超级链接扫描它。 然后它就会引发一个HTTP GET请求给每一个链接，使用auto-discovery 机制中的一种或两种，查找一个HTTP标题或者一个包含在HTML里的具体的标签，目的是为了查出链接目标是否支持Pingback协议。如果一个 Pingback终点被发现，引擎将会提交一个a ping Web service 的命令，支持两个URL地址，the pinged 和the pinging weblog entry。Pingback 有关于引用紧急通知的优点，就象关于改变这些引用的重要性一样。
Trackback 的目标是提供类型的功能，但是有一点微小的不同。协议不仅会提供pinging入口的URL地址，而且也可以延着weblog名称随意地提供标题和来源入 口的简短引用。与Pingback相比，它就是完全自动化了，Trackback被典型在当作一个清晰的，随时请求的布告机制来使用。
Trackback 与Pingback之间最主要技术差别是Pingback使用了一个XML-RPC Web service接口，而Trackback ping是在浏览器上提交一个表格的技术上的等价物---所发送的信息通过使用HTTP POST 请求来处理的，确实这是有HTML 形式的情况。 虽然不同，两份协议成功达到他们的目标： 改进合作和通讯。
为了使那些还没有自己的weblog的人们也加入到weblog的讨论中，大多数weblog引擎支持用户使用一个网上的接口增加的他们的意见。 另外，一个广泛采用的Web服务接口是存在的；如Comment API。Comment API是被一些流行的RSS收购商象RSS Bandit 直接提供支持的，这就允许读者直接从工具里张贴他们的议论。
dasBlog: 实现一个 Weblog 引擎
早 在2003年时候，在newtelligence我们决定建造我们自己的weblog 引擎将是要做的一件好事情。 这里有一些动机。 作为在newtelligence最活跃和最著名的weblog 作者， 我真实想要有我自己的对我以前的weblog工具的一次替换，由于另一方面的影响在newtelligence的其它同事也能使用它。 写我们自己的 blog 引擎也许诺给我们一套大的例子代码使用在教育平台的开发上来试验新技术。 最后，开发一个用于支持所有被描述和更需要合作的Web服务的解决办法好象要参加的一个大的实验，同时允许我们研究已经实现很多Web服务的一个分布式系 统的现实。
在那时我实现在2003年7月提出的dasBlog，随着数周分配的仅仅5本日历完成了工作，对于微软公司.NET结构存在的 两台主要的weblog引擎，我们的默认平台：引擎动力来源于http://weblogs.asp.net(现在叫'.Text')，代码在那时是空 的，以及引擎BlogX，这是微软公司的两个人在一些社区贡献者的帮助下利用他们的余暇时间来完成的。
'做或者接受'决定是相对容易的， 因为BlogX已经开始工作了并实现了与一家基于文件的后端存储，就现有特征提供比较容易的增加新特性的框架还是相对轻便的。此外，BlogX的许可条件基本上相当于BSD 许可证，我们也支持为我们免费出版的工作，并且用源码形式。
当我们的最初目的是将我们后面的变化溶入到原始的BlogX 编码基数时，随着项目的进展，事实表明refactoring过程消除几乎所有的初始BlogX 源码。因为把结果合并进编码基数可能等于错误在接管了那个社区工程项目，我们已经决定给它一个新名字并且保持它作为一项不同的工程，因此dasBlog诞 生了。新编码基数的第1.0 版本在3 周之后公开，5周后包含有完整特征的后续1.2版本发布了，这是很及时的， 甚至在工程早期，就有许多bloggers抛弃他们的老的工具并且转向dasBlog 引擎。
dasBlog: 要求，考虑和解决办法
基本上，dasBlog是直接被绑在一台引擎上的一种小的内容管理系统，它已经及时翻译了全部内容并且建立在一位访问者选择的意见基础上。
存储
一 个weblog系统的主任务是捕获并且提出事件的年代表。 因此weblog的首页提出weblog 入口的可配置数目，以顶部最新的入口按年代来排序。这个基本原理也要求访问者能容易按日期管理weblog的历史记录。 这个主功能直接影响后端存储的设计，为此最通用的查询标准是以日期或者时间为间隔。 同时，为了附上’跟踪’信息(例如介绍，pingbacks和trackbacks)，必须有可能通过他们的标识有效地访问个人的weblog 入口， 并且象早在这篇文章里解释的那样联系和展示意见。
因为weblog是一个以人为核心的，而不是以一个主题为核心的，它也要求通过实施一个类别表单使按主题导向的内容更容易一些。创建和维护类型应该在很在程度上是自动化的，而不应该需要用户花费很大努力来管理。
使 用一个关系型数据库和一些简单的索引来实现这些要求是很容易的事情。但是，任何人用低成本想要达到被要求的便于最初的部署和将来的升级需要花费一些管理上 的努力，ASP.NET能够使在一网站托管公司和一台运行着本地WEB服务的社区桌面机器上的账目作为他们自己的出发点，取决于一个充分的数据库系统的存 在不是一种好想法。相反，如果需求出现了，后端就会以数据库可能被支持的一种方式被代理，但是最好的和主要的存储机制是很简单的文件系统。 这可能通过使用象微软公司著名的Jet或者FoxPro引擎一样的基于文件的数据库才能够实现， 但是当他们出现时，这样的内置的从属物将限制软件的可扩展性，同时会影响到将软件升级到一个新的版本。一旦沿着数据库路线的方法被采取，任何变化或者对存 储的附加都要求计划为数据库补充新的资料，实质上增加管理的精力。
体系结构的结果已经被原始的BlogX编码提前定义好了，因此我们决定 继续在应用的子目录下的XML文件里存储所有的信息。因为查找标准是基于时间的， 或者至少是时间间隔， 内容按照‘一天，一个文件’的计划来存储，索引仅仅是文件系统目录信息： 文件名字包含日期。种类的附加索引和入口唯一的标识都被存储到一个单独的文件里。附加信息例如跟踪数据(介绍，pingbacks 和trackbacks)和说明被储存在也以日期命名的文件里(这样就被索引到了)， 但是为了限制并发问题和处理他们特性的差别，他们应该被保持在与实际内容分开的文件里：
核心的内容更新频率很低的(一天几次)，它有很多 的读者，一定不能弄丢了。跟踪信息经常被更新，也有很多读者，并且不那么重要。无论核心内容什么时候发生变化，引擎都会保持他们同步以能够将错误直接反馈 给用户。这些变化也引起高速缓存中的信息丢掉以及重新构造附加索引。然而，全部的跟踪信息都会在一个通过内存队列供给信息的二级线程上被处理。这样做是可 能的，因为跟踪的时间线要求是不严格的：他们最终需要被反映在weblog上，但是当事件发生时，他们不需要出现。
因为每天都有一个新的文件被创建，导致文件的大小是很小的（通常上少于100KB)， 同时写因为最小锁而变得迅速。尤其为了信息的跟踪，一种积极的隐藏方法允许同步更新高速缓存和后台存储器中的内容， 因此更进一步降低并发问题。然而，应当指出的是所选择的存储模型、高速缓存与后台存储器间的交互限制了群聚或者相反让多台引擎分享一家共同的存储器。那是 一个故意的且可接受的限制，因为甚至受欢迎的weblogs通常只得到每天一万的点击率。 虽然RSS收购商为大多数读者提供了阅读weblogs是事实，但由于很少去更新核心内容，RSS流很容易地被隐藏在服务端甚至向上代理。
内容管理
当我们已经讨论存储策略时，我们还没有理解被提交的内容是如何到达引擎的。这里再次说明，dasBlog必须满足多种不同的用法脚本的要求。
把 内容提交到基于WEB的应用端的最明显的方法是在一个网页上使用一种形式。对于所有的浏览器dasBlog都支持，但是由于一些很简单的原 因，dasBlog首选微软公司的IE来进行处理。通过使用微软的IE来获取WEB页面编辑器的用户被提供了一个页面，这个页面里包含一系列客户端脚本和 一个框架，利用IE特有的能力来伪装成一个HTML编辑器。接着，用户就得到了很多关于文本编辑器兼容性的东西，用户还可以通过使用一些字体、印刷上的效 应和颜色来设计这个文本。编辑器也支持附上文件并且嵌入图片。 在内容一览表下面或者在内容一览表旁边，二进制被通过使用标准的HTML上载控制来进行上载与存储到一个具体的目录里。 一旦上载是完成的，图片或者超链接就被插入当今的正文中。
对有其他浏览器的用户来说，例如Opera或者Mozilla 浏览器，不幸的是，网上的编辑的能力在很大程度上被限制。有这些浏览器，用户只能获得一个标准的多行文本，同时他们必须精确在写了HTML标记。决定和非 微软公司的浏览器的这样的一个有限的版本一起去分享IE的市场份额，假定dasBlog的用户将在他们的台式机上运行Windows，以及编辑支持的 HTML没横跨浏览器标准化的事实。 但是，这种限制没有它乍看起来出现时那么重要， 因为使用网页形式只是把内容提交进引擎的三种方法之一。
通过一个浏览器来提交内容的第一个可选之处是使用各种各样脱机weblog编辑器（比如Zempt或者 w.bloggar） 中的一个就可以实现，这些编辑器直接支持Web services API,这是由比较流行的weblog环境'Blogger'的制造者所开发的。任何能瞄准Blogger服务器的编辑也能瞄准dasBlog。随着为了 竞争MovableType weblog 软件而做的扩展以及由Userland 公司所做的扩展，dasBlog实现了Blogger API，以便大范围的工具都可以用来提交新入口或者是编辑从客户那里得到的现有入口。
Blogger API 和它的各种各样的扩展把Web服务定义为不能使用SOAP协议的终端，但可以使用XML-RPC。在以前有关RSS讨论中所提及的原子工作组正计划加强3 个API部分重叠的功能，同时定义API结果是基于SOAP的。但是，server-side XML-RPC 协议终端是很容易被客户应用端获取的， 因为有许多pre-built libraries支持几乎全部的平台， 即使这些库不太为人们所知道。 内容管理后端的这个入口点不仅很适合交互式的编辑工具， 而且它也可以做为一个接口从其它的应用端将自动产生的内容放到dasBlog上，甚至协调weblogs之间的内容。
通 过一个浏览器来提交内容的第二个可选之处是email（到目前为止是最好的选择）。当dasBlog web应用开始时，它就会向上旋转成一个专注的线程，在配置期间，这个线程监视由weblog所有者所定义的一个POP3邮件帐号。无论引擎何时选中这个 帐号，它都会处理帐号内的每个email项目，同时寻找主题线的前缀是一个已配置的passphrase的那些电子邮件。与一个passphrase相匹 配的电子邮件被增加给内容存储器。 这显然已经是最低限度的安全测量，passphrase甚至可以是空着的，同时允许发表任意电子邮件。dasBlog能够处理HTML和plain- text格式的消息，这显而易见是一个最简单派艺术家安全措施和passphrase 甚至能是空的，并且能够提取、存储和链接附件， 处理嵌入的图片，和通过一个构造开关为图片附件创建和嵌入极小的东西。
电子邮件支持提供最灵活和迅速的可共同操作的模型为weblog 增加信息，在每一个平台上都容易得到支持。它在任何地方允许内容创造和提交，用熟悉的工具包括SMS 和MMS消息经过一个电子邮件网关从移动电话发送出去。随着对HTML 和图的支持，使用象Microsoft Office Outlook 2003这样的最新型的电子邮件工具，将丰富的内容发布到网上要比以前容易的多了
翻译引擎和地方化
翻译引擎负责为网页介绍格式化内容。 核心要求容易确定：通过站来导航对所有的访问者来说是容易的也是很明显的，站点应该在任何平台的浏览器上都是可以访问的，上是可达到的使用的实际上一切当今的Web浏览器，同时它应该方便定制与提高站点的视觉设计
这些需求就会产生一种dasBlog从那些受欢迎Radio Userland借用weblog 工具的通道， 并且的确基本上与为那件工具创造的设计模板相容。采用这种通道的原因是有很多免费和易于使用的设计模板对于Radio Userland公司都是很有用的，而且也适用于Userland's Manila的内容管理系统，同时允许那些直接提供为众人所知的且吸引人的理论（适合很多个人品味）的公司重新使用。 除有一种易于使用的主题的广泛选择之外， 基本的导航计划因此也与许多其他公众weblogs一致，提供快速熟悉的方便性同时便于使用。
dasBlog 的可安装的版本产生了一系列的模板来配置应用---从一开始就使用户集中于内容而不HTML详细描述的技术。尽管如此，因为很多用户想给他们的 weblogs一次个人触摸并且他们并不担心HTML，在customisation之外仅仅选择一个模板一定非常简单。
dasBlog 的设计模板使用简单的HTML 、CSS和被发动机实现的一套宏三者的结合。 一个设计模板(或者主题)总是由3 个简单的HTML 文件组成： homeTemplate.blogtemplate(或者.txt或者.html)，dayTemplate.blogtemplate和 itemTemplate.blogtemplate。 homeTemplate用来翻译每页的内容框架， dayTemplate 被用作具体某一天内容的一个框架，itemTemplate用来实施个别的入口。引擎也为每个内容种类支持单独的模板。
通过使用一个带有CSS支持的标准HTML编辑器，这些模板本身是相当容易定制的。 那些支持宏观是well documented 同时通过使用特别的顺序就能够被插入到页面中。因为他们的复杂性，全部动态的要素，例如日历或者种类目录都被部分地放入到翻译引擎中，但是通过使用CSS他们的外观就可以自由地被定制。
dasBlog 的另一关心和要求是对地方化有一个好的支持。 因为newtelligence是在整个EMEA 地区一家德国公司，对我们自己来说，用德语和英语以及整个EMEA 地区的语言来支持地方化是很重要的，包括对我们的客户来说左右为难的希伯来和阿拉伯语。为了进行地方化工作，dasBlog结合几种技术。
引 擎查看全部主要的浏览器因为每个请求发送表明用户使用更喜欢的语言来接受HTTP报头。当前ASP.NET处理请求的思路是设置语言标志符，接下来从最适 当的资源表中装入所有的资源，默认返回一个用英语包含所有资源的中性文化。 这引起日期格式化和.NET框架本身的日历只限于局部使用，引起weblog 引擎需要发送出去的全部硬连接strings以最合适的语言翻译过来。对于这些模板，引擎提供了一个允许在HTML资源内详细说明使用多种语言的宏。转换 线程到一个适当的位置也能够使right-to-left支持阿拉伯语和希伯来语，因为这些位置的资源表包含了一个具体的标记，这个标记能够促使引擎将一 个适当的附加dir属性注入到HTML流中。
除这些一般的地方化技术之外， 明确地为每个weblog设置确定语言是可能的， 以便只让人在他们偏爱的浏览器 (因此表明他们能理解它)里列举这种语言的访问者看见这个内容。如果一入口使用不变的文化缺省设置，则所有的访问者都可以看见，与语言的选择无关。如果一 种语言被设置成个别的入口，这也被反映在dasBlog翻译的XML数据流上，那些各自元素被贴上带有适当xml的标签：属性语言。
这些技术的结合证明通常灵活的地方化对于网站非常可能，同时我们发现当使用.NET框架时，它实现完整的地方化支持付出的努力非常低。 实际上，要求使地方化工作的代码已经被增加到现有的应用中而且不到两天就可以部署。
线程模型与 Hosting
在Windows 2000和Windows XP上，dasBlog被在ASP.NET过程里面的一个应用领域内举办， 或者在Windows Server 2003上，在Web 应用因特网信息服务器6.0的运行时间内。 因为集中于单个用户weblog 和以限制的通信量为结果，通过使用积极的隐藏使I/O 工作量减到最小是安全的，在第一个请求时增长装载的内容同时保存它作为更进一步的请求。 因为用户极少浏览weblog的历史，通常只有上个月的内容被隐藏起来和甚至对于一个很忙的weblog意味着内存中的数据最好不到2MB。二进制和图象 的请求可能通过WEB服务直接处理了，因此引擎并不关心这些事情。
因为这些考虑，在多台服务器作用于相同的内容存储器的一个Web Farm的操作并没有明确地被支持，因此并非试验要求。也就是说，全部内容更新引起一个共享文件被更新。无论这个文件的时间戳何时改变，都标志着文件的内 容得到了更新，内部的高速缓存被丢掉并且重新装载，因此成群的操作在没有引起高速缓存连贯性问题情况下是可能。failover群聚和负载平衡可能通过把 站点的贮存目录指到网络驱动而被实现， 但是象解释的那样对它的支持是并非主要关心的。
一个更应考虑的是设计一个合适的线程模型来处理引 擎内部的工作。当然，引擎的主要目的是对同步HTTP要求Web服务引用作出反应，对HTML资源作出反应，因此我们能依赖ASP.NET的线程模型来进 行大多数工作：每一个请求都会得到从ASP.NET线程池中分配的一个线程给的服务。
不过，为了最大化请求/应答的性能，这里有一些活动是引擎能够异步执行的。因为异步动作在他们的实行特性方面稍微地不同，dasBlog使用了线程的三个变量：
第 一个线程模型是Mail-To-weblog特征，另一个特证称为Xml存储系统的特征更新服务(XSS)，我们没在这篇文章里讨论因为它主要能为用户从 Radio Userland中转向dasBlog提供一条更容易的迁移道路，两个共享相似的特性。这两个特征的线程定期执行动作。Mail-To-weblog定期 选出一个POP3帐号，XSS线程则定期地增加一个当前RSS文件的静态拷贝给一个远程WEB服务，这个WEB服务处理着一个分布式文件存储系统。在他们 之间的唯一的差别是XSS线程可能被明确地通过说明一次事件而引发，以至于内容更新被迅速同步地进入到远程存储器里。这些线程都对时间不关键， 因此都用低于正常线程的优先权运行，表明当系统不忙时，他们只获得服务。当应用领域启动时，这两个线程就会被设计以立即开始，同时只要应用领域在运行线程 就会不停地运转。两个线程对内部的失败是坚固的，在应用领域关闭并且拆毁全部运转的后台线程时，线程就会优美的失败了。除了XSS线程信号通知的事件，主 要应用并不积极与两个线程中的任意一个联系，但是线程宁愿调用一些他们本身之外的一些功能。
第二个有点不同线程模型用来处理引入的跟踪痕 迹(在Trackback 和Pingback中有介绍)。进来的踪迹是重要记录，但是没有迫切使他们加入数据仓库。 与详细的跟踪有关系的一个稍微关键的因素是， 它导致为一切进来的请求执行一次写操作，这在文件上就产生了并发问题。因为必须的堵塞导致了对文件存储器的连续访问，全部踪迹被写进一个由单独线程所监视 的内存队列里，这个线程运行在整个应用领域的生命周期内，同时它会按顺序地处理所有的跟踪信息，消除了并了问题。相同的策略用于把通知电子邮件送给管理 者。当这技术方便分离前台和后台的工作时，这个模型的主要动机是连续地访问有限的资源。
第三种应用的线程模型是 Pingbacks，Trackbacks和变化dasBlog积极发送到其他站点的通知。请求的Serialization这里没被要求， 因为通知通常在几个不同的站点都成为目标，但是从主线程里分离出来是必要的，因为站点可能非常慢或者不能到达，引起几秒的延迟，在一个单独的位置上当一系 列自动化的Pingbacks需要被发布时，这几秒的延迟就会快速地合计出来。在处理需求的线程里这样做（提交一个新的或者改变的贴子）将意味着应答在为 通知需要的总时间以前就被延迟了，这显然不可接受。 因此，要求执行这些外部通知的数据被包装进被用于实行提交.NET线程池的工作里。
一旦线程为服务提供了方便，使用.NET 线程池就允许并发的执行操作，但是一直通过再产生新的线程并不能够产生不适当的压力。相反，在池中激活的线程正被重新使用。这个线程池与ASP.NET运 行时间同享，独自将一只全球节流阀放在可能被并发执行的线程上，限制了过分强调机器的可能性。同时，这种方法造成使ASP.NET完全干涸的有限的危险， 同时外部的一些需求排队等待----在最后，它甚至会导致ASP.NET应用领域的再循环 (关闭和重新开始)。象在很多应用过程中设计的那样，这是一种情况，在那里优势(容易的编程模型)必须被权衡不利条件和危险。这里具体使用情况确实证明被 选择的模型是正确的， 但是如果这些行动没被限制在不断改进和增加内容的稀有的情况上，用于处理早期描述的引入跟踪模型将是更好的选择。
总结
Weblogs 是特别有前途的，但是这也引出大做广告这样一种新现象。这里有一些极度热情的申称，说weblogs会改变同时对新闻业和民主政治会产生动荡。然而这些观 点戏剧性地夸张了他们的重要性，weblogs提出了一些现实的优点和用于合作的机会，以及以一种有组织的形式快速方便地表达内容。
但 是，正如我们所显示的那样，建立一台能够担当变化的、增长的、分布式的同时是垮平台的网络应用中的一个节点的weblog引擎会带来一些结构上的挑战，即 使结果应用是相对小的。 部署一定是容易的， 易于使用， 并且容易定制，导航必须是简单的，直觉的和可感应的，它必须能垮很多平台相互作用并且和多种系统结合起来。
Weblogs事实证 明，Web服务的第1代正运行着同时在外国系统之间的相互作用，在将来也会有很好的前景，当今的一个现实是，大多数的服务都运行着Unix, Linux, MacOS X, Windows 的更多的平台。 他们也证实了承诺垮所有的技术阵营来综合工作确实产生明确的结果。 在这篇文章里强调的weblog 技术都不曾有一个正式的标准委员会。
资源
一个可安装版的dasBlog和最新版的源代码可以从项目的文档网站上下载。http://www.dasblog.net.。
关于作者
Clemens 是newtelligence AG的共同创办人和执行团队的成员，是总部设在德国的服务公司的开发者。他是一个知名的开发者和架构培训师，是一个很受欢迎的讨论会发言人，许多书的作者 /合作者，他主张广泛地阅读和引用集中了体系架构与开发主题的weblog。在http://staff.newtelligence.com/clemensv 上可以找到。可以写信与Clemens 联系clemensv@newtelligence.com
