招聘咨询顾问

临时发个招聘信息,希望给大家多提供一些类似机会。

1、工作地点:中国上海市。
2、熟悉微软技术和平台,包括:Active Directory,.NET 2.0/3.0/3.5,Visual Studio,SQL Server,Silverlight/WPF, WCF等。至少3年以上的.NET平台开发工作经验。
3、至少1年以上的项目管理经验。
4、良好的沟通能力和团队精神。

如果您对该工作感兴趣,请发送简历至:

——————邪恶的分割线——————
另外,在博客堂呆了快7年了,时间真快,从最早的.net 1.0至今.net 4.0,都已经7年了。不管如何,感谢开心提供了这么好的一个地方,见证了.NET蓬勃发展的历程。由于个人最近心血来潮,将博客迁移到 http://www.liuhuimiao.comhttp://blogs.msdn.com/liuhuimiao 了,以后这里就不更新了。谢谢开心,谢谢大家。

发表在 未分类 | 评论关闭

如何实施好基于MOSS的企业搜索项目(上)

【时间飞逝,在博客堂也常驻了6年多了。有感于经常有人反映说博客很久没更新了,加上近期确实也想把前几年做过的大大小小二三十个项目做个总结。于是决心每个月都花点时间来写点东西,长篇或随笔都好。前些日子讲了两三天关于如何交付好MOSS项目的课后,结合以前实施经验,又有一点心得,就以此作为开头,慢慢做一系列的原创总结了。】

文章目的:希望通过此文,能让读者了解搜索的本质和基于MOSS的企业搜索方案,在此基础上站在项目管理角度掌握如何实施好这类方案的项目的关键点,确保企业搜索项目成功交付。由于文章长度限制,本文分上下两部分,上部分包含搜索简介和基于MOSS的企业搜索的方案说明;下部分将涉及站在项目管理角度如何实施好这类方案。

一、企业搜索简介

    搜索,目前是个比较热门的词。一提到搜索,我们的第一反应就是Bing、Google或Baidu。事实上,搜索的定义范围更广。一般上按应用范围划分,我们将整个搜索行业分为互联网搜索企业搜索(局域网)桌面搜索(个人电脑桌面)三个层面。目前,每个层面都有许多知名产品占据着主要地位。如下图所示:

搜索行业层面划分图

    在这里我们就不重点去说各个产品的优缺点对比了。我们需要更加关注的是,所有的搜索产品具有的共性,或者说,搜索解决方案的核心运作模式。这点对我们后面的项目目标范围确定、方案设计、项目的具体实施等都具有非常关键指导作用。

    站在使用者角度,回想一下你通过Bing、Google或Baidu进行搜索的主要场景:输入关键字,按搜索按钮进行查找,然后搜索引擎罗列出找到的所有信息条目。然后,我们换个角度,站在搜索产品(或者说搜索引擎)的角度,思考下它的主要场景,将会得出所有搜索产品的核心运作模式内容源–>搜索引擎–>呈现结果。如下图所示:

image

    首先,内容源是基础。在客户内部,肯定事先有大量的数据内容以各种形式存放在各种地方(如存放于Web站点的网页、存放于共享文件夹里的各种文档、存放于业务系统中的业务数据等等),这种现象造成的各种问题(如数据难以共享、数据难以萃取成有价值的信息等)就是客户的烦恼痛点所在。换个角度说,也就是我们搜索解决方案项目要解决的问题。

    其次,搜索引擎是技术手段。用搜索引擎来对所有的内容源进行数据信息提取、清洗、分类整理乃至智能分析、相关度设置等,以形成各种有价值的信息提供给使用者。也就是说,搜索引擎是我们萃取数据为信息的一种技术手段。好的搜索引擎除了在性能上体现为更快,在数据的分析整理等涉及到数据质量问题的处理上也更加智能化、个性化。这也就是为什么说性能好坏和数据信息质量的好坏是判断搜索引擎好坏的两个主要标准了。因此,在我们实施企业搜索的项目中,这点是项目的关键技术点,需要进行比较多的技术攻关工作。

    第三,呈现结果是目的。通过搜索引擎进行数据萃取后,最终将结果呈现给使用者。呈现结果的机制也可以看成是搜索引擎的一部分,只是它表述更多的是一种用户体验,将搜索结果以更好的用户体验方式呈现给最终用户。就像上面提及的,站在使用者的角度,他所关心的就是“帮我寻找我要的信息”——既要找到信息,而且找到的信息是我要的。这两点也正好是搜索解决方案所要达到的的目标。

    在宏观上理解了搜索后,接下来我们简单了解下企业搜索。企业搜索自然也遵循上述搜索核心运作模式,同时具有自己的一些典型特征:

  • 内容源:企业局域网内的各种资源,包括位于企业内部门户网站、共享文件夹、FTP站点、Exchange公共文件夹等内的各式各样的文档资料及业务系统内部的业务数据等。
  • 范围:主要针对企业局域网内部的资源。
  • 数据量:中等(相对互联网搜索来说)。
  • 安全性:安全性要求高且灵活。
  • 爬网索引:依企业IT管理策略而定制。

二、基于MOSS的企业搜索方案

    在搜索行业的三个层面里,微软都有相应的主流产品——互联网搜索的Bing,企业搜索的MOSS/FAST和桌面搜索的WDS。对于企业搜索,微软又分别做了市场细分,针对每种细分场景提供相应的企业搜索产品和方案。

image

    我们这里只谈基于MOSS的企业搜索解决方案,对于微软的其他企业搜索产品,如Search Server、FAST等这里就略过,其实站在“实施好企业搜索项目”这个方向上大致原理都类似,区别的仅仅只是其中具体技术细节。

    根据搜索的核心运作模式,结合MOSS特点,整个基于MOSS的企业搜索解决方案主要包括以下内容:

  • 内容源的梳理:内容源是搜索方案的基础。内容源的梳理工作做得好,将起到事半功倍的作用。这点在后面如何实施好搜索项目中将具体细化讲述。
  • 搜索引擎的定制:根据需求对MOSS搜索引擎做相应的功能定制,比如支持PDF和AutoCAD文档索引、支持爬FTP站点、相关度调整、用户权限的整合等。这方面的定制将涉及MOSS搜索引起的几个关键技术点,将在后面如何实施好搜索项目中进一步描述。
  • 良好的用户体验:根据用户对信息格式的要求和使用习惯设计搜索呈现结果相关页面。除了基本的搜索结果元素呈现外,还包括最佳匹配、热门关键字、关联提示、联合搜索等。
  • 部署方案:根据数据量、用户量及客户的实际IT环境设计部署方案。诸如需要多少台服务器、各种角
    色的服务器怎么安排、对网络带宽的要求等。同时应该提出在可见的未来,数据量持续增加或用户量增加的情况下,如何调整以适应新情况。
  • 持续的运维规范: 持续的运维优化,是所有基于MOSS的方案(包括企业搜索)必须涵盖的内容。只有通过一系列的管理、运营、维护规范来保证MOSS应用的正常运作,才能使得MOSS应用富有生命力。

    基于MOSS的企业搜索方案的系统架构图如下所示:基于MOSS的企业搜索应用设计成为既是一个企业搜索应用,同时是一个可以为第三方应用提供搜索服务的基础服务。

image

    由于篇幅考虑,针对基于MOSS的企业搜索方案的部署方案(大型、中型、小型三种部署方案)、MOSS企业搜索的技术架构等方案涉及的各个内容的细节就不做具体描述。这些均可以在MOSS SDK或MSDN相关文章上查阅到相关内容。

    【总结】:上半部分内容,主要掌握“内容源–>搜索引擎–>呈现结果”的搜索核心运作模式。以此来贯穿整个企业搜索方案的各个部分,甚至后面下半部分提及的如何实施好企业搜索方案项目也将会用这条主线结合项目过程交付管理来描述。

发表在 未分类 | 评论关闭

WCF 4.0 中的 Discovery – 动态发现服务

先讲一个寻人启事的故事。

很久很久以前,他想寻一人,不得不知道她的所在地址,方能根据地址过去找到她。不幸的是,找到她了,但因操着不同语言而无法沟通,他又不得不找一个翻译来保证他与她之间的沟通顺利。很久很久以后,他想再寻一人却不知道她具体地址,他先守株待兔,看看她会不会突然冒出来和大家Say Hello,然后自己再跑上去搭讪。这种可能性貌似很小,除非她和自己一个小区。他拍脑袋一想,她如果在本市的话,肯定事先在派出所那边登记过资料了,于是就到拥有全市户口资料的派出所去打探,看看派出所那边能否提供她的资料并帮他们搭线上。

不得不承认,这是一个无聊的故事,和下面这个有的一拼。

WCF 3.5 中,当我们要调用一个服务时,必须事先知道该服务的地址,然后通过服务代理用双方约定好的契约与远程的服务进行交互。现在,WCF 4.0中提供了发现服务的支持,当我们再想调用一个服务时,没必要去知道该服务的具体地址,只需要利用 System.ServiceModel.Discovery 命名空间下的相关类就可以实现两种方式的动态发现服务:

Ad hoc Mode:简单理解,就是服务启动时就向网络广播Hello消息,调用方收到后进行回应建立通讯的模式。

Managed Mode:简单理解,就是所有服务事先在一个叫 Discovery Proxy 的地方登记,然后所有调用方发送查找请求给 Discovery Proxy 来查找并调用相关服务的模式。

这个故事到此为止,比喻不是很恰当,但至少可以有一个比较感性的认识吧。更详细,可以看下下面原理说明:

WCF 4.0中要动态发现服务,用 Ad hoc Mode 实现起来还是比较简单的,下面就以代码方式先看下如何实现。对于Managed Mode,就需要继承 System.ServiceModel.Discovery.DiscoveryProxy 抽象类去实现自己的 Discovery Proxy 了,这里先跳过不说了。

服务端:

  • 在服务的Behavior中加入 System.ServiceModel.Discovery.ServiceDiscoveryBehavior。
  • 添加一个服务端点 System.ServiceModel.Discovery.UdpDiscoveryEndpoint。

image

调用方:

  • 如果使用生成的服务代理时:
    • 用 System.ServiceModel.Discovery.DynamicEndpoint 根据服务契约和绑定来发现服务端点
    • 通过生成的服务代理类调用服务。

image 

image

  • 如果使用 ChannelFactory<> 时:
    • 通过 System.ServiceModel.Discovery.DiscoveryClient 去查找获取服务端点地址
    • 用 ChannelFactory<> 根据绑定和服务端点地址调用服务。

image

发表在 未分类 | 评论关闭

VS 2010 Beta2 编辑器字体问题

顺利装好 VS 2010 Beta2 后,新建项目,打开.cs代码文件,结果报错误。不仅仅是代码文件,只要是相关的文件,如 xml, .config等均报此错误。

clip_image002

按照提示,用 /Log 参数启动VS IDE,查阅Log说是 Editor 问题导致此错误。后来核对了半天,才发现原来我在 VS 2008 中设置编辑器字体为 Fixedsys 字体,安装完 VS 2010 后将这个设置也带来过,结果目前 VS2010 Beta2 好像还不支持编辑器字体替换,换回“新宋体”或 Arial 等其他字体后,就没有再出现此错误了,所有代码文件都顺利打开。

造成这个问题的原因是因为VS 2010 整个 IDE 已经基于 WPF 重写,因此只支持 True Type 字体,而之前用的 Fixedsys 字体并非此类型,所以就报错导致所有文件都无法打开。后来了解到在更新版本里头,如果碰到不是 True Type 字体,就会自动转换成默认字体显示了。

发表在 未分类 | 2条评论

2008.8 SharePoint & WPF 资源

【SharePoint】:

SharePoint (MOSS) 2007 有了一个 SharePoint Online 服务了。这个是 Microsoft Online Services 的一部分,也是微软的“Everything could be hosted” 口号的具体落实。除此之外,还有 Exchange OnlineOffice Communications OnlineCRM Online

msonline

CheckList for custom code (MOSS 2007): 采用对象模型的自定义开发方式,使得开发人员可以在MOSS 2007平台上进行各类扩展方案开发。但是同时,一个粗糙不当的设计或实现,都将把MOSS自定义应用带入深渊,轻则慢得比乌龟还慢,重则异常不断经常出错。这个时候,或许该下载一份 Code Checklist 给开发人员,好好对这 checklist 一条一条检查看看是否符合,以此在避免不必要的风险下,尽情享受到MOSS2007各种好处。

SharePoint Governance:貌似Governance这词比较酷还是怎么的,越来越多人喜欢用这个词了。比如 IT Governance,翻译为IT治理;那么 SharePoint Governance,就叫SharePoint 治理吧。按官方翻译过来,所谓SharePoint治理,就是使用基于SharePoint的产品和技术来指导开发和方案应用的,集角色、职责和过程于一体的套件。听上去应该是“上层建筑”,不过可以用 SharePoint Governance Tools 来辅助实施看看。至于用后的效果如何,“谁用谁知道”。

除此之外,MS还公布了一些协议规范(协议技术规范),SharePoint发烧友可以去下载回去烧烧。

【WPF-Silverlight】:

.NET 3.5 中新增了一个新的 WebBrowser 控件用于 WPF 应用中。以后在 WPF 程序中就不要用以前的 WinForm WebBrowser 了,直接在XAML中写<WebBrowser>标签即可。

这里还有一个酷酷的 WPF 资源站点 Blendables.com,可以下载到很多酷炫的 WPF 范例。比如,这个鹰眼缩放功能的WPF Demo,就是一个非常酷的Demo。一看 Blendables 名称,估计大家也应该猜到站长是位 Blend 粉丝了。关于 Blend,网上发现一个相对完整的网上教程,虽然是Beta版本的,但仍然值得一看。

DataGrid 这个东西还在 WPF 中吗?嗯,看看 WPF Toolkit 这个玩意儿,不过之前你得打个 .NET 3.5 SP1。

最后,show 几个demo养养眼:

wpf001

hardrock

发表在 未分类 | 评论关闭

SharePoint News

MOSS里的CMS/Portal,需要进行高度的自定义,除非你觉得MOSS默认的“款式”就是你要的。PixelMill,我觉得它所发布的SharePoint SimpleCMS就是一款不错的应用。你可以观看 Video: Simple CMS for WSS,看看这个应用的一些具体使用方式,吸收下实例经验。我个人比较喜欢其中自定义的图片上传方式和新闻发布方式,这些符合用户操作习惯的应用才能生存。

image

MOSS里的Search,也是很好很强大的。在Codeplex中已经有了一个Search Community ToolKit,可以让你如虎添翼。比如其中的Smart Search,可以做出常见的相关搜索、搜索排行等,上海科技网站的搜索就是其中一个示例。

image 

SharePoint Team Blog上介绍了一个很酷的SharePoint应用Wonders。在那个Virtual Earth Flash上标注的各种颜色的小点,实际上是读取SharePoint List中的数据信息动态显示的。这是一个非常好的SharePoint数据整合范例,就像文章说的:"IDV Solutions’ Visual Fusion software extends SharePoint to create a visual composite application platform, empowering users and the enterprise to consolidate data and services surfaced in SharePoint and then compose them in the context of location and time".

image image

对于SharePoint,Web Site是一个很关键的概念,其不被关注很让人奇怪。对于Web Site,上有Farm、WebApp,下有List、Library,外有Template、Theme,内有Feature、Content Type等等。对于开发人员来说,Web Site意味着:

1、内容存储容器:List存储各类数据、Library存储各种文档、Sub WebSite用于区分和组织内容。

2、UI呈现:MasterPage母版页定义界面风格、Layout Page定义页面排版、Form Page定义List/Library的增删改查页面、Web Part定制化页面、Application Page提供全局访问页面、Site Page提供站点级访问页面、各式各样的Web Controls、Field Controls定义页面内部数据元素。

3、安全模型:User/Group定义用户和用户组的权限、对Web Site、List、Library、ListItem提供权限设置。

对应一个普通的ASP.NET Web应用的开发模式和方式,对照下SharePoint Web Site,好像能得出点什么,当然这个需要自己去体会了。在此之前,推荐 Ted Pattison 里的一些例子,那可是很好很强大的范例。

发表在 未分类 | 5条评论

关于 OBA

不知不觉之中,又有一个新概念逐渐充斥在各个技术社区中。OBA,全称为 Office Business Applications,较早之前,Javed Sikander在MSDN中发表了一篇名为《Building Office Business Applications: A New Breed of Business Applications Built on the 2007 Microsoft Office System》的文章中定义它为“a new breed of easily customizable solutions that address real-world business problems through the 2007 Microsoft Office system”。但在我能看到的大多数介绍OBA文章中更接近Justin的定义——“Office Business Applications can be defined as a class of applications that connect Line of Business systems with the people who use them everyday”,简单理解就是,OBA 是用来连接用户生产力工具软件(比如MS Office)和 LOB 系统的一种应用类型。从定义看,就是业务用户从原来直接使用LOB转换到尽量通过用户日常使用的办公软件(可以是MS Office System,也可以是其它应用软件产品)来使用LOB。

对于OBA的桥梁作用有多少种实现模式呢?MS Office System的OBA应用给出了比较齐全的实现模式

比如Direct integration Pattern,可以是Outlook直接调用远程LOB的WebService,也可以是MOSS Portal直接用HTML嵌入LOB System信息。

再比如,Embedded LOB Information Pattern,直接在Office文档中嵌入LOB数据元素,最终直接通过Office客户端与LOB System交互。

当然,也可以直接反过来从LOB System生成含LOB Data的Office文档,然后提交到MOSS文档库进行工作流流转等。这一系列模式之间的关键理念就是,把用户平常最常使用的MS Office客户端直接与公司中LOB System实现各种方式整合,并引入Office服务端(如MOSS)的各类应用和服务,为整个整合提供更全面的支持。

也许你会理解OBA为一个框架,但从我理解上,我更倾向理解OBA为一种桥梁性应用,通过OBA应用我们可以有相关解决方案框架。比如atanu的OBA Solution Framework系列是目前这方面比较全面的介绍说明了。

MS的OBA架构如下所示。

发表在 未分类 | 一条评论

AD 用户组类库中增加几个功能

以前弄个了用于AD OU、帐号和组等对象的几个类(见《活动目录操作类更新》),现在对这个再进行一点改进和增加一些功能。貌似gotdotnet workspace已经无法使用,过些日子我把更新后的类库发布在codeplex上再发布个具体链接出来。

修改/增加的地方:

1、权限机制:摒弃在配置文件中配置域管理员帐号密码的方式,而采用重新用COM+安全身份来执行整个AD操作。

2、用户:修正Lock/UnLock和Enabled/Disabled,Mail-Enabled/Mailbox-Enabled的用法。

3、组:修正创建组时无法指定Group Scope/Group Type的问题,增加对各类型组的创建支持。同时支持更改组Owner,和设置管理Membership list的属性。

其中更新Membership list属性的更改比较有意思。因为在AD中并没有一个属性与之对应,只能通过修改访问规则来设置:

ActiveDirectorySecurity ads = myGroup.ObjectSecurity;
ActiveDirectoryAccessRule accessRule = new ActiveDirectoryAccessRule(
          new NTAccount(Domain, samAccountName),
          ActiveDirectoryRights.WriteProperty,
          AccessControlType.Allow,
          new Guid(“bf9679c0-0de6-11d0-a285-00aa003049e2″));

ads.AddAccessRule(accessRule);
myGroup.ObjectSecurity = ads;
myGroup.CommitChanges();

4、Mail相关:增加了对Exchange Server/StoreGroup/MailStore/Mailbox的各类操作(相关见《枚举Exchange Server, StoreGroups, MailStore》)。同时支持对proxyAddresses等属性的修改设置。

其中更新proxyAddresseses并设置 Primary proxyAddress也比较有意思,摘出供参考:

       private void UpdateProxyAddresses(DirectoryEntry userEntry, ArrayList emailAddresses)
        {
            PropertyCollection properties = userEntry.Properties;
            PropertyValueCollection proxyAddresses = userEntry.Properties[“proxyAddresses”];

            if (proxyAddresses != null)
            {
                for (int i = 0; i < emailAddresses.Count; i++)
                {
                    string emailType = emailTypes[i];
                    string emailAddress = emailAddresses[i].ToString();
                    int schemaIndex = Array.IndexOf(emailTypes, emailType);

                    if (schemaIndex > -1)
                    {
                        // Is it the primary address
                        if (schemaIndex == 0)
                            userEntry.Properties[“mail”].Value = emailAddress.ToString();

                        string emailPrefix = emailPrefixes[schemaIndex];
                        bool found = false;

                        for (int j = 0; j < proxyAddresses.Count; j++)
                        {
                            string proxyAddress = proxyAddresses[j].ToString();
                            if (proxyAddress.StartsWith(emailPrefix + “:”))
                            {
                                proxyAddresses[j] = emailPrefix + “:” + emailAddress;
                                found = true;
                            }
                        }

                        if (!found)
                            proxyAddresses.Add(emailPrefix + “:” + emailAddress);
                    }

                    userEntry.Properties[“proxyAddresses”].Value = proxyAddresses.Value;
                }
            }
        }

        public void MakePrimaryProxyAddress(DirectoryEntry userEntry, string newMailAddress)
        {
            System.DirectoryServices.PropertyCollection properties = userEntry.Properties;
            PropertyValueCollection proxyAddresses = userEntry.Properties[“proxyAddresses”];

            if (proxyAddresses != null)
            {
                bool found = false;

                for (int j = 0; j < proxyAddresses.Count; j++)
                {
                    string proxyadd = proxyAddresses[j].ToString();

                    if (proxyadd.StartsWith(“SMTP:”))
                    {
                        found = true;
                        string[] proxyparts = proxyadd.Split(‘:’);
                        proxyAddresses[j] = “smtp:” + proxyparts[1];
                    }
                }

                if (!found)
                {
                    proxyAddresses.Insert(0, “SMTP:” + newMailAddress);

                    userEntry.Properties[“proxyAddresses”].Value = proxyAddresses.Value;
                }
            }
        }

BTW, Workflow Foundation又有2篇经典文章值得一品:

发表在 未分类 | 标签为 | 2条评论

Workflow

1. 关于Check-out 锁定的错误:

当针对表单库关联Workflow后,用InfoPath客户端打开表单填写表单,填写完直接用Save保存回表单库。按设置,一保存回去就自动触发了工作流。但是触发后,有时可以,有时却报了Occured Error的错误,工作流加载失败。

由于有存在成功的现象,因此怀疑哪里环境出了问题。后来在Central Administration v3中配置了记录Workflow Infrastructure的详细日志,才发现出现了说该表单被Check out,然后已经处于锁定状态,所以工作流无法启动的异常信息。

这是个非常奇怪的问题。一直无法找到真正问题根源,不知是否为Bug。最后只能绕过该问题,在表单最后放了一个提交按钮,自动提交后自动生成唯一文件名保存在SharePoint Form Library中,然后马上关闭表单即可。

2. 用SPD 2007设计Workflow的建议:

记得,开发人员不到万不得已不要用SharePoint Designer 2007来开发工作流。这种事情让业务人员(如果有这种业务人员)去干这活吧。毕竟我个人以为SharePoint Designer 2007应该是定位在业务人员使用上的。开发人员老实开发Activity让业务人员用SPD 2007去设计工作流,或者直接用VS2005开发设计工作流才是正确的做法。

SharePoint Designer 2007和Visual Studio2005两者用来设计工作流的初衷都是为了让技术人员尽量管技术,让业务人员尽量分析处理业务。对此,DSL是用于沟通IT人员和业务人员的一个不错的选择;但Visual Studio 2005下的设计工作流更适合于开发人员,只不过通过DSL来缩小了与业务人员之间的Gap。而SharePoint Designer 2007,经过我这段时间作为开发者的快乐并痛着的经历,我觉得它完全是为业务人员而定制的一个产品,而非开发人员。最有力的证据就是——对SPD 2007设计的工作流的部署!你在测试环境用了SPD 2007进行设计了工作流,那就别指望能完全正确的直接部署到正式环境中,最有效的做法就是完全用SPD 2007再在正式环境中实施一次,或者用了站点模板部署后起码你还得用SPD 2007再打开正式环境的Workflow“编译”一次。这是一个另人抓狂的动作。

3. 基于Silverlight的Web Workflow的想法:

以前,有一个想法,就是做一个基于WPF的MOSS Document Sync工具。用于本地文件夹与MOSS Document Library做同步的一个TrayIcon小软件,主要功能当时就做了几点:

  • 任务栏界面
  • 集成和管理AD身份
  • 设置本地和MOSS文档库同步目录(可对应到文档库或文件夹)
  • 支持私人文档库和共享文档库
  • 支持单文件下载或多文件、文件夹打包下载
  • 集成MOSS Search

后来很郁闷的我的移动硬盘丢了,该工具源代码连同很多积累多年的宝贝一起从人间蒸发了。装了Vista系统后就懒得再去重新整理这块代码,所以以前和人提起过这个咚咚,但后来友人跟我要去尝试时,一时糗大,只好用其他好处打发之 -_-|| 当时之所以开发这个工具,主要是得益于虚拟了一个磁盘来和远程FTP同步的一些工具软件的想法的激发,同时也是作为长期不在Office的人之间基于MOSS互相交流文档的一个补充。

现在WPF/E终于Release了版本Silverlight出来,正好以前接触过一个Web上拖拉设计Workflow的业务型应用,也看过http://www.netfxlive.com/之类的 Web工作流设计器,于是有个想法,想在Silverlight和Workflow Foundation上做一个偏向公文或普通文件流转业务的可拖拉的Web Workflow应用。目前还在构想中,有三四个技术点还在验证。因为个人编程属于爱好,所以兴致来了连夜写着就很快,没来或忙时就会显得拖拉点,所以这个应用在时间长度上会显得长点,一有任何进展会随时跟大家沟通,也欢迎有任何这方面兴趣或经验的人一起交流。

发表在 未分类 | 3条评论

WCF, WF, EPM

对WCF的了解还停留在2006年初看Indigo的地步。当时看了一本MS 2005年出版的《Programming Indigo》电子书,是一本非常棒的书,我只记得当时作为初学者我看第一遍的时候,对其中每个章节中的相关概念定义都能心领神会,这就说明这本书是一本非常棒、值得收藏的书。因为WCF的核心就是接口协议定义,而它做到了让初学者能迅速理解这些接口协议。

对于学习WCF,我个人理解是一定要理解WCF中的接口协议定义和规则约束!了解这些远远比你去看看Code,写写Sample来得重要许多。从某种意义上,学WCF就是学概念、学定义、学规则、学接口协议,而不是让你像学C#或ASP.NET那般追求深入实际应用,然后再去反过来体会C#/ASP.NET原理。

一晃,Indigo更名为WCF并入.net3.0概念中。天天念叨着WCF、WPF、WF,可是除了WF还顺应潮流接点轨外,WCF就停在Indigo阶段,WPF更仅仅只了解其相关的XAML知识。正好最近越忙越是精力充沛,抽空花了两三个小时翻了2007年2月刚出版的《Programming WCF Services》一书,算是在Indigo基础上重新认识了下WCF,感觉还OK,各类细节变来变去,但只要它的接口协议、概念定义没变就好办,剩下的就是从《Programming WCF Services》新书中挑几章自己兴趣的或感觉变化比较大的再细细品味下,也算完成本书的阅读工作了。

昨天我说花了一夜用HTML+Photoshop+Javascript搞了个系统原型,于是有人开始质疑我这个做法是否值得,理由是让美工或其他人搞个比自己搞既快又好。我承认自从99年接触Photoshop 3.0/4.0以来,我的美工水平一直停滞在满足图片的修修补补,让专业美工搞这个自然是快而好。但我想做一件事情,更多的应该是看做这件事情的目的。系统原型相当于建筑行业的图纸,其更多的价值在于迅速构建一个与用户沟通的管道,确保做出客户想要的东西,同时为后面的系统设计提供了基础约束。由于业务复杂,加上时间紧张,自己也弄过ps,就凑合了,最终效果也不错。

 MS发布了个Windows Workflow Foundation Web Workflow Approvals Starter Kit,算是给了ASP.NET开发人员一个交待。

最近在做EPM,不过这个EPM没有用Project Server,却是完全用ASPNET + SQLServer搭建,这也是各种原因造就。不然利用 Project Server,一个小时应该可以搭建出一个简单却实用的 EPM 应用出来。恰巧上次和网友讨论过一些 MS 企业服务器产品的主要应用业务,这里也稍微整理下一些我接触过的MS服务器产品,不对的地方还请指正。

  • Project Server:  EPM
  • SPS: Portal
  • WSS: Team Work (Document Mgmt)
  • BizTalk:  EAI
  • Commerce Server: EBusiness
  • Content Management Server:WCM
  • Exchange:Mail, Message platform 
  • LCS:IM
  • MOSS:Portal+WCM+ECM+BI+Search+BPM
发表在 未分类 | 标签为 , | 一条评论