西游记是个团队项目。一个团队的核心是人，这些志同道合者聚集一起并对目标达成共识（西天取经），利用自身力量的同时依靠外部资源克服困难（81难），最终胜利完成任务。很多公司企业常常对内部员工或外部媒体说企业文化，他们却常忽略企业文化应该起源于公司上中下各级人员的核心精神共识，兴盛于企业整体团队运营项目过程中，传承于新老员工并最终体现于大至企业整体小至职员个人思维行动上。在管理范围里，企业都在追求企业文化，却忘了领导层和员工是企业文化的主体，造成“我们的企业文化是XXX……”永远停留在口头上的尴尬局面。
VS2005Beta1出来也有阵子了，最近才有空偶尔拿出来看看玩玩。大部分想接触ASP.NET2.0的人，大概都跟我一样，第一个问题是：ASP.NET2.0比1.x多了些什么？建议看下这篇《What's new in ASP.NET Whidbey》。如果你是1.x开发人员，看完那文章后还得做好心理准备：变化之大远远不是一篇文章能写出来的。就拿ASP.NET内部来说，你看看《ASP.NET 2.0 Internals》就知道其代码模型、编译、页面生存周期等等都发生了变化。外观来看，Master Page、验证控件、GridView等等新的或改进后的WebControls。在安全、缓存、数据操作、国际化等等都有了让人兴奋的改进。
就拿国际化来看，利用资源文件的方式创建一个多国语言版本的World-Ready ASP.NET Web Application，甚至可以不用编写任何代码就可以实现。你没有看错，我也没有说得太离谱。在ASP.NET1.x里，要完成这个功能是比较费劲的。ASP.NET 2.0里，利用资源文件本地化一个WebApp有两种方式：Explicit Localization（显式本地化）和Implicit Localization（隐式本地化）。Explicit Localization针对Application-Level Resources（应用程序级的资源文件。这些手工创建的资源文件存放在根目录下的Resources子目录里，Resources目录类似Code目录为ASP.NET2.0里WebApp的特殊目录。），而Implicit Localization则对应Page-Level Resources（页面级的资源文件。这些资源文件存放在LocalResources特定目录里。）
- Explicit Localization的资源绑定格式：
<%$ Resources:[filename prefix,]resource-key[,"designerdefault" %><%$ Resources:[filename prefix,]resource-key[,"designerdefault" %>
例如： <asp:Button ID="Button1" Runat="server" Text="<%$ Resources: ClassName, ResoureKey, Default value %>">
用代码读取资源：
string ApplicationLevelResource = (string)GetAppResourceObject("ClassName", "ResourceKey");
或者直接：
string ApplicationLevelResource = Resources.ClassName.ResourceKey.ToString();
- Impilicit Localization的资源绑定格式：
<asp:Label ID="Label1" runat="server" meta:resourcekey="LabelResource1" />
用代码读取：
string PageLevelResource = (string)GetPageResourceObject("LabelResource1.Text");
[提示]：打开一个.aspx页面，点Tools菜单上第一项Generate Local Resources，整个WebSite将自动增加LocalResources文件夹，并自动为每一个.aspx页面创建一个resx文件，对页面内部控件自动增加 meta:resourcekey 属性。
本地化具体操作步骤细节及具体编码，你可以参考：
从上面链接中，你也可以看出，有两个官方性质的站点是非常值得收藏的：
近些日子也听说VS2005 Beta2要到明年才能出来了，ASP.NET Group Program Manager先给了我们ASP.NET2.0在Beta2中将会有什么变化的信息。OK，明年的事明年再说吧。
推荐篇开发高性能ASP.NET应用程序的文章〈Developing High-Performance ASP.NET Applications〉作为这段的结束。希望上面的ASP.NET信息对你有所帮助。
对于这样的信息〈演算法安全加密功能露出破绽（MD5） 密码学界哗然〉，不知道你看了有什么感受？我的反映通常是看着惊讶，想着可怕，最后还是不管它。J 当然，如果事情真如文章所说，那么我们唯一能做的就是改进改造它或重新找其他的加密算法了。
雅典奥运开幕式即将开始，google今天也换上奥运新装了，看来挺有气氛的。J
最近晚上时间玩了点VisualStudio2005，发现在.NET2.0类库里，对AD操作的部分增加了不少新功能，这下我们基本可以在完全托管的世界里操作活动目录了。我也整理了下自己接触后的点心得：《使用System.DirectoryServices.Protocols实现对AD的简单操作》。
另外，有几个站点不错：
最近，为手机加了个彩铃服务，在挑选歌曲时居然找不到自己想要的，而我的电脑里却有该音乐文件。于是，有个Idea，不知道能不能提供各服务，把原本由彩铃提供商负责制作彩铃的过程，变成由用户根据彩铃提供商提供的网络Service来实时制作并实时发布提供出来。也就是说，我只需要把我的音乐文件上传到服务器上，服务器对该文件处理转换成提供出来的彩铃；或者我输入汉字，然后服务器把汉字转换成语音并提供成彩铃；或者……。呵呵，反正就是让我更加自由点，主动点去搞定我的彩铃就行了，不知道这样的想法可行不可行。我对这块完全是个门外汉。如果真的可以实现，那样才能真正叫“个性化移动服务“嘛。J
System.DirectoryServices.Protocols.dll是.NET2.0新增加的一个针对目录服务访问协议处理的组件，其下只有一个System.DirectoryServices.Protocols命名空间。在该命名空间下，主要有LDAP、DSML两种国际标准协议的一系列实现类。通过这些类，完全可以很方便地实现对目录的操作管理，这个实现步骤就有点类似你利用ADO.NET操作数据库一样方便。
在System.DirectoryServices.Protocols命名空间里，主要有这样几个类：LdapConnection（LDAP协议方式的目录连接类，负责创建LDAP连接并绑定LDAP服务器）、DsmlSoapHttpConnection（DSML协议方式的目录连接类、负责创建DSML连接并绑定DSML服务器）、AddRequest/AddResponse、ModifyRequest/ModifyResponse、ModifyDNRequest/ModifyDNResponse、CompareRequest/CompareResponse、SearchRequest/SearchResponse、DeleteRequest/DeleteResponse、DsmlRequestDocument/DsmlResponseDocument。这些类在实际编程应用中的关系如下图：
用户利用LdapConnection/DsmlSoapHttpConnection跟LDAP服务器/DSML服务器建立连接并绑定后，即可创建一系列相应的操作请求（如增加一新对象请求AddRequest），然后通过连接对象的SendRequest方法把请求命令发送到服务器，服务器根据请求进行相应处理后，把应答信息传回给客户端。需要指出的是，对于DSML方式的请求，还可以利用DsmlRequestDocument将AddRequest、ModifyRequest、ModifyDNRequest、CompareRequet、SearchRequest和DeleteRequest的任意几个请求组合组装起来，一并发送到DSML服务器进行处理。
LdapConnection的使用：
- 创建LDAP连接并进行绑定：
NetworkCredential credential = new NetworkCredential("Administrator", "password");
LdapConnection ldapConnection = new LdapConnection("192.168.0.6");
ldapConnection.Credential = credential;
ldapConnection.Bind();
- 创建一个请求，使其达到增加一个OU，其名称为MyOU的目的。创建后的MyOU其DN为OU=MyOU,DC=mydomain,DC=local：
string targetDN = "DC=mydomain,DC=local";
// 增加一个名为MyOU的组织单元
string ou = "OU=MyOU," + targetDN;
string objectClass = "organizationalUnit";
AddRequest addRequest = new AddRequest(ou, objectClass);
- 把请求发送到服务器进行处理：
ldapConnection.SendRequest(addRequest);
执行完SendRequest()后，如果没有出现异常，那么MyOU已经成功增加了。当然，如果你还需要进一步对SendRequest()操作后的应答信息进行处理的话，也可以类似下面这样写，其中将在屏幕上输出“Success“的结果码：
AddResponse addResponse = (AddResponse)ldapConnection.SendRequest(addRequest);
Console.WriteLine(addResponse.ResultCode.ToString());
至此，一个LDAP请求已经处理完毕。上面的完整代码可以点这里进行查看。
|
using System;
using System.Net;
using System.DirectoryServices;
using System.DirectoryServices.Protocols;
NetworkCredential credential = new NetworkCredential("Administrator", "password");
LdapConnection ldapConnection = new LdapConnection("192.168.0.6");
ldapConnection.Credential = credential;
ldapConnection.Bind();
string targetDN = "DC=mydomain,DC=local";
//增加一个名为MyOU的OU
string ou = "OU=MyOU," + targetDN;
string objectClass = "organizationalUnit";
AddRequest addRequest = new AddRequest(ou, objectClass);
AddResponse addResponse = (AddResponse)ldapConnection.SendRequest(addRequest);
Console.WriteLine(addResponse.ResultCode.ToString()); |
类似上面增加操作，还可以利用DeleteRequest进行删除操作、ModifyDNRequest进行重命名或移动操作、ModifyRequest进行修改对象属性操作、SearchRequest进行查询操作、CompareRequest进行验证比较操作。
DsmlSoapHttpConnection的使用：
- 关于DSML for Windows，可以通过http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/dsml.asp进行下载。简单理解DSML，就是利用标准的HTTP/SOAP/XML对活动目录进行读写等一系列操作的技术。安装完DSML for Windows后，还需要执行“Microsoft DSML“程序组里的“Configuring DSML Services“。该程序里有三个步骤，很好理解和操作，这里省略。但需要指出，如果你不需要进行SSL连接服务器的话，需要在Step 1中把“Require SSL to connect to DSML server“取消。另外，如果你还需要执行除读取以外的权限，如写操作权限，还需要在Step 2中把“Make DSML Server readonly“取消。
- 建立DsmlSoapHttpConnection连接：
NetworkCredential credential = new NetworkCredential("Administrator", "password");
Uri dsmlServerUri = new Uri("http://192.168.0.6/dsml/adssoap.dsmlx");
DsmlSoapHttpConnection dsmlSoapHttpConnection = new DsmlSoapHttpConnection(dsmlServerUri);
dsmlSoapHttpConnection.Credential = credential;
- 创建一个请求，使其达到增加一个OU，其名称为MyOU的目的。创建后的MyOU其DN为OU=MyOU,DC=mydomain,DC=local。可以看到，这部分跟LDAP操作时一致的！
string targetDN = "DC=mydomain,DC=local";
//增加一个名为MyOU的OU
string ou = "OU=MyOU," + targetDN;
string objectClass = "organizationalUnit";
AddRequest addRequest = new AddRequest(ou, objectClass);
- 把请求发送到服务器进行处理：
DsmlResponseDocument dsmlResponseDocument = dsmlSoapHttpConnection.SendRequest(addRequest);
Console.WriteLine(dsmlResponseDocument[0].ResultCode.ToString());
可以看到，DsmlResponseDocument可以包含多个应答信息，应该还需要指定下标，才能得到具体返回的结果码。
至此，一个DSML请求已经处理完毕。上面的完整代码可以点这里进行查看。
|
using System;
using System.Net;
using System.DirectoryServices;
using System.DirectoryServices.Protocols;
NetworkCredential credential = new NetworkCredential("Administrator", "password");
Uri dsmlServerUri = new Uri("http://192.168.0.6/dsml/adssoap.dsmlx");
DsmlSoapHttpConnection dsmlSoapHttpConnection = new DsmlSoapHttpConnection(dsmlServerUri);
dsmlSoapHttpConnection.Credential = credential;
string targetDN = "DC=mydomain,DC=local";
//增加一个名为MyOU的OU
string ou = "OU=MyOU," + targetDN;
string objectClass = "organizationalUnit";
AddRequest addRequest = new AddRequest(ou, objectClass);
DsmlResponseDocument dsmlResponseDocument = dsmlSoapHttpConnection.SendRequest(addRequest);
Console.WriteLine(dsmlResponseDocument[0].ResultCode.ToString()); |
另外，对于DSML的多条操作请求一起发送的情况，可以创建DsmlRequestDocument对象去包含各种操作请求，具体可以参考这里的代码。
|
using System;
using System.Net;
using System.DirectoryServices;
using System.DirectoryServices.Protocols;
NetworkCredential credential = new NetworkCredential("Administrator", "password");
ri dsmlServerUri = new Uri("http://192.168.0.6/dsml/adssoap.dsmlx");
DsmlSoapHttpConnection dsmlSoapHttpConnection = new DsmlSoapHttpConnection(dsmlServerUri);
dsmlSoapHttpConnection.Credential = credential;
string targetDN = "DC=mydomain,DC=local";
string ou = "OU=MyOU," + targetDN;
string objectClass = "organizationalUnit";
DsmlRequestDocument batchRequest = new DsmlRequestDocument();
AddRequest addRequest;
ModifyRequest modifyRequest;
addRequest = new AddRequest(ou, objectClass);
addRequest.RequestId = "Add1";
batchRequest.Add(addRequest);
modifyRequest = new ModifyRequest(ou, "description", new string[]{"This is description of MyOU"}, DirectoryAttributeOperation.Replace);
modifyRequest.RequestId = "Modify1";
batchRequest.Add(modifyRequest);
DsmlResponseDocument batchResponse = dsmlSoapHttpConnection.SendRequest(batchRequest);
foreach (DirectoryResponse response in batchResponse)
{
Console.WriteLine(response.GetType().Name + ": \tId=" + response.RequestId + ",\tResultCode=" + response.ResultCode);
} |
感觉怎样？我想肯定舒服了很多，毕竟这样的编程逻辑对我们来说，是再熟悉也不错的了。另外，对于目录这块，.NET2.0还在System.DirectoryServices.dll组件里也增加了一个新的命名空间System.DirectoryServices.ActiveDirectory。顾名思义，该命名空间完成的功能就是对活动目录进行更完整的处理操作，比如对域林、域树、域、域控制器、目录复制、活动目录架构、域信任等的操作，让你尽可能完全在纯托管的代码中实现对活动目录的操作。
前些阵子外出了，一直也没网络可上。虽然已经回来两三天了，但还是觉得非常累。由于外出又坐飞机又坐火车的，所以就买了几本书在旅途中看。其中有本《软件工艺》，最近新出版的，熊节翻译。原著是Pete McBreen的《Software Craftsmanship》，该书在Amazon上总的评价为四星级半，应该还算是受欢迎的。看看Amazon上的书评：Alleman给了它三星级，并评论之为Dated examples, needs be focus on the problem。Heath给了五星级评价，但他指明One Size Doesn't Fit All For Software Development。众多评论中，我还是最喜欢Matthew Heusser的评论，原因当然是我的想法和他不谋而合。
我喜欢这样的说法：软件工程总的来说还处在探索阶段。对于我来说，更宁愿把软件工程里的规则当作项目实施的参考指南，而非一套SOP(Standard Operation Procedure)或者Bible。从这个角度看，似乎软件工艺更能符合我的想法，也可能是我比较喜爱敏捷开发所导致对它的认同。如果你看过《人月神话》，再看《软件工艺》时你会更有“擦出火花”的感觉。其实，软件工艺的提出并非为了“颠覆”软件工程，相反地，它试图去纠正过分强调软件工程所带来的「软件开发过程中轻视甚至忽视一线开发人员技艺」等问题。尽管它和软件工程侧重点不同(有这么一个说法：软件工艺侧重商务应用领域，而软件工程更加侧重大型的政府或军事应用领域)，但总的来说它和软件工程还是不矛盾的。软件工艺强调把“人”从软件工程中的“开发流水线”解脱出来，重视开发人员的开发技艺，提倡学徒机制，让软件在拥有实用价值的同时，更加体现开发者的心血结晶、具备开发者的艺术灵魂。软件工程强调的是组织和管理，软件工艺则从人本主义出发强调了开发人员个人技艺的学习、锻炼及传承。正如Pete McBreen说的“Software development is a craft skill that subtly blends art, science and engeering.”。说到这里，忽然想起2年前关于“软件蓝领”的故事。现在回想起来，真感觉那是业界急于求成和媒体热衷炒作的典型，最后伤害的是大部分无辜的程序员在他们的父母可怜的问他：“听说只要进行几周简单技能培训都可以写好程序，你打算以后怎么办？”后，一脸茫然。
在国内，〈软件工艺〉中文版书籍也引来热潮。其中就有张恂对熊节在翻译序言中对原著的“误解”进行了批判。为此，他还特别撰文《软件工程乎？软件工艺乎？》。真是精彩的辩论。从每个人的评价及辩论中，我们总能学习到对方可贵的想法，这种交流方式未尝不是一件好事。当然，条件是火药味不要浓到伤人就OK了。
前天看到开心说准备制作博客堂的T恤衫，真是一百万个支持。在这里，除了感受到强烈技术氛围，还感受到了社区的魅力。在博客堂，其实重要的不是他是哪家公司的人或哪类的技术群体，而是在日新月异的技术里乐于分享自己知识，用热情和激情坚守技术本份，让大家知道程序员其实是很美好的。
最后，顺手整理了个《活动目录.NET编程Tips》，希望有帮助。有空就把那ADHelper改完再发布了。接下去，奥运会也快开始了，这下可有得“忙”了。J
- 为什么要有活动目录，什么是活动目录，它有什么用：活动目录主要用在分布式的环境中。在分布式环境中，要求有各种信息可以被各种应用很方便地访问读取。活动目录正式为分布式环境中的信息提供一种访问途径。它提供了一个公共的区域来保存分布式环境中的各种信息，并且对这些信息进行定位。从开发人员角度看活动目录，可以理解活动目录是一种存放了应用程序所需要的特定资源信息的“数据库”。活动目录还对这些资源信息的读取和查询进行了优化。
- 容器和非容器：活动目录中的资源信息被组织成一个层次结构。这个层次结构中的每一个实体都被简称为对象。换句话说，活动目录中创建对象时，是把它们创建在一个层次结构中的。该结构由两种类型的对象组成：Container(容器)和非Container(非容器)。容器可容纳非容器或下一级的容器。而非容器则不再包含其他对象，因此也常被成为叶或叶子对象。在安装完活动目录后，操作系统已经默认自动创建了很多的Container，如Users, Builtin等。
- ADsPath、DN、RDN：在活动目录中层次结构的路径被称为ADsPath，可用来唯一标志一个对象(另外唯一标志对象的方法是使用GUID)。ADsPath常用的表示为：LDAP://DC=microsoft,DC=com。例如，有域被命名为mydomain.local，则它的ADsPath表示为：LDAP://DC=mydomain,DC=local。其中DC是Domain Component(域组件)的缩写，它只用于表示域的根。DN是Distinguished Name(唯一标识)的缩写，RDN是Relative Distinguished Name(相对唯一标识)的缩写。DN用来在一个完整的目录信息树中唯一表示一个对象的名称，而RDN是指在该对象的父容器中唯一表示它的名称。下面看个示例：在mydomain.local域中用户容器中超级管理员帐号的ADsPath为：LDAP://CN=Administrator,CN=Users,DC=mydomain,DC=local，其DN为(注意没有了LDAP:// 这个前缀)：CN=Administrator,CN=Users,DC=mydomain,DC=local，其RDN为(即在Users容器中的名称)：CN=Administrator。其中CN是Common Name(公用名称)的缩写。
- OU：OU是Organizational Unit(组织单元)的缩写。OU是容器对象，它主要从逻辑的角度来管理和组织活动目录域。例如，当你公司内部打算让销售部经理有权限管理自己整个销售部门资源信息时，一种方法就是为销售部门单独创建一个名为Sales的OU，然后让销售部经理在受限条件下实现其部门资源信息的“自治”。
- 更多基础概念，可以参考这里?。
- 关于LDAP及其语法，可以参考《理解LDAP》(上，下）。
- Naming Context：活动目录被分成许多部分，称之为分区或者Naming Context，简称NC。其中主要有三个部分：Domain NC，Configuration NC，Schema NC。这也就是你打开ADSIEDIT.msc时首先看到的已经加载的三个活动目录分区。Domain NC用于保存用户、组和组织单元的相关信息。Configuration NC用于保存整个域森林中的配置数据信息。而Schema NC负责保存与在活动目录中能够创建的所有的对象和属性集相关的数据。例如，在mydomain.local域中，Domain NC的ADsPath为：LDAP://DC=mydomain,DC=local。Configuration NC的ADsPath为：LDAP://CN=Configuration,DC=mydomain,DC=local。Schema NC的ADsPath为：LDAP://CN=Schema,CN=Configuration,DC=mydomain,DC=local。
- AD/ADAM程序访问接口示意图：
- System.DirectoryServices：System.DirecotryServices命名空间下有两个主要的类：DirectoryEntry和DirectorySearcher。其中DirectoryEntry类用于表示活动目录中任何一个对象。你可以通过DirectoryEntry对活动目录里的对象进行修改其属性、移动、重命名、列举其内部子对象、创建子对象、删除子对象、获取起父对象等等操作。例如：
using System.DirectoryServices;
DirectoryEntry entry = new DirectoryEntry(ADsPath);
Console.WriteLine(entry.Path);
Console.WriteLine(entry.Name);
Console.WriteLine(entry.GUID);
对于活动目录对象的绑定路径ADsPath，你可以用 LDAP://ServerName/DN 来绑定指定服务器和DN的活动目录对象。另外，DirectoryEntry还可以进一步指定用户名和密码，或者用户名和密码外加安全验证方式进行对象绑定。
- DirectoryEntry的属性示意图：
活动目录对象的属性分为单值属性和多值属性两类。例如上图中，CN就是单值属性，而memberOf则为多值属性。对于多值属性，可以用循环语句for或foreach进行列举。
- DirectorySearcher目录查询：DirectorySearcher实例有两个主要方法：FindAll()和FindOne()。FindAll()是获取该对象的所有子对象集合；而FindOne()则获取查询到的第一个子对象。对于DirectorySearcher实例，其也有SearchRoot、SearchScope、Filter三个主要属性。其中，SearchRoot表示在AD层次结构中要开始搜索的节点；SearchScope表示搜索范围；而Filter则表示LDAP查询语句的过滤命令字符串，例如 (&(objectCategory=person)(objectClass=user)) 表示列举所有用户对象中的人员对象。而对于搜索范围SearchScope，则又分为 Base、OneLevel、Subtree三种。其中，Base表示要那个搜索的根节点；OneLevel表示在同一个层次中搜索；Subtree则表示在包括根节点的所有节点的搜索。其示意图如下：
- 使用SQLServer查询分析器查询活动目录数据的实现方法：为AD创建一个链接服务器（你可以在企业管理器的具体SQLServer服务器里的“安全性”里看到该项）。在查询分析器中执行下面命令即可：
sp_addlinkedserver 'ADSI', 'Active Directory Service Interfaces', 'ADSDSOObject', 'adsdatasource'
现在你就可以在查询分析器中查询AD数据了。例如下面查询语句：
SELECT * FROM OpenQuery(ADSI, 'SELECT title, displayName, sAMAccountName, givenName, telephoneNumber, facsimileTelephoneNumber, sn FROM ''LDAP://DC=mydomain,DC=local'' where objectClass = ''User''')
- ADAM--活动目录应用程序模式：ADAM，全称为Active Directory Application Mode，它是一个可运行在WinXP Professional和Win2k3上的目录服务，可简单的看作是AD的一个简化版本。但是，ADAM和AD是无法比较的，因为它们的侧重点和应用领域是不同的：AD是主要侧重网络基础构造，它是以系统服务运行，并需要配以DNS。而ADAM则主要是为应用程序服务的，它是以用户服务运行，且不需要DNS。同一台计算机上可以运行多个ADAM实例，例如可以为每个应用程序配置一个ADAM实例。你可以在 这里 下载到ADAM。