InfoPath,你不需要吗?

Microsoft Office以及Windows应该是微软的两个最大的盈利产品,所以它们的一举一动,最能牵扯广大最终用户的心。

Office System 2003的推出,让我们感受到其受为一个System的强大协作功能,但相信很多用户,对于Office 2003之外的InfoPath、OneNet等组件还不太了解。我在这儿想先讲讲啥是InfoPath。开心很难使用官方语言去为一个产品下定义,所以还是想到哪说到哪吧。

在几个PoC里面,简单的应用了InfoPath。最简单的,如果你开发了一个Web Service,在你不愿意为其编写ASP.NET的UI的时候,使用InfoPath是最佳选择,其操作就那么几步:

  1. 选择一个Web Service作为提交数据的数据源;
  2. 将数据列表中的Schema拖到表单设计器上;
  3. 再加一个Button按钮,就可以提交了,如果想美化一下,还有多种配色方案可供选择。

一切大功告成,就这么简单。做为一个表单设计工具来讲,InfoPath简单超强!!!有了它,你公司的部门秘书MM甚至不用学习任何编程,就可以做出一个像模像样的报销表单或者会议记录表单出来,供大家填写,甚至直接入库。所需要的就是拖拉而已。当然,再花哨一些的,就需要使用JavaScript编程了。

对于我来说,InfoPath让我感觉最不爽的有两点:

  • 不支持.NET 语言编程,作为一个.NET时代出生的产品,不支持这.NET简单太不可思议了,竟然还使用老套的JS以及老大的VBS;
  • 做出来的表单不能发布到Web上,再往前一步,如果像FrontPage一样,直接就设计出来生成ASP.NET网页,那不是超爽?那样,我们为什么还使用VS.NET来设计ASP.NET表单呢?

第一条不爽,估计下一版本就会有所改善。第二条不爽,估计不会有所改善了,至少MS官方不会提供类似的产品,因为这是Business,是By Design。

但官方不会,非官方就不会了吗?类似于.NET的跨平台,虽然MS没有提供官方实现,但Mono实现了呀。InfoPath也是同样的,有非官方提供的InfoView(http://infoview.uniqueworld.net/)。

可惜呀可惜,这个InfoView不像Mono那么慷慨,它不是免费的,其价格竟然是$12,000,而且还竟然是per CPU的。

世上无难事,只要肯登攀,老外能赚这钱,我们有五千年文明的老中们就不能赚这笔钱了吗?下载InfoPath的SDK,翻翻里面的内容,嘿嘿,还真有咱们需要的,那就是Downlevel工具,这是一个以三种外貌出现的工具,分别是cmd形式,JS形式以及xls形式。它可以将您的InfoPath表单给降格成HTML,为什么说是降格呢?因为在生成HTML后,所有的文本框都不再能填写呢悲伤的脸,看来此路不通呀。

我们再来分析一下InfoPath的文件内容吧,InfoPath表单设计完后,其后缀名是一个XSN文件,其实如果你再深究一步,这是一个cab文件,你可以从InfoPath的文件菜单中选择“提取表单文件”将里面的文件全部提取出来,里面会有一个XML以及一个XSL(根据你定义的视图而定),XML是数据Schema,而XSL则是表现,主要是配色方案。此XSL其实也是Downlevel的,但如果转换一下思路,再用另外一个XSL,将里面的<span>转换为<asp:TextBox>也不是很难吧?再从js文件里面读取出来相应的验证,做一个InfoServer,相信几个人用半年时间也可以开发出来了笑脸。到时候,大把的钱不是到手了吗?

可惜呀,我没有时间去做这个研究及开发,哪位感兴趣,赶快动手做起来,成功后,我就收取一点提成就是了,$100 per CPU,便宜吧?笑脸

Microsoft SharePoint Portal Server做外网门户

SPS真的是一个非常好非常好的东西,不是吗?我相信N多人跟我一个想法。里面的很多概念都给微软的其它产品很多启发。比如Web Part的概念,就在Whidbey里面有了体现,当然,Whidbey更进一步,至少比SPS的Web Part有了可视化设计界面。在我看到的SPS Web Part Wish里面,大家把“提供可视化Web Part的设计工具”放在了第一位,我想在SPS 2004的时候,这个愿望得借助Whidbey来实现了。在目前,你只能通过一些“歪门邪道”来借力Web User Control来做这个工作,这方面的详细资料可以参看Kaneboy的精彩连载,或者我提供的这个PPT

另外,FrontPage其实是我一直不看好的工具,但自从开始做SPS的PoC(很多人问我啥是PoC,其实就是Proof Of Concept,说白了,就是Demo)之后,FrontPage就成了我的必备利器,因为通过它,可以非常方便的定制SPS的界面细节。前段时间,使用Frontpage并且配合CSS的功底,在不到一天的功夫,我们将SPS进行移头换面,将某政府网站移植成了SPS界面,如果不事先做心理准备,估计很难看出来这是SPS做的网站。

政府网站,当然不能只是内网办公这么简单了,其中遇到的最大问题,就是如何在允许匿名访问的情况下,仍然能够对SPS进行管理。

大家知道,SPS 2003是基于AD的,必须在AD环境下进行安装。它的用户身份验证等功能全部来自于AD。在安装SPS后,默认会把Portal所在Virtual Server设置为不允许“匿名访问”,所有人员都需要有一个登录过程。如果你启用了SPS的匿名功能,那么更不幸的事情发生了:即使你是域管理员,你会发现你的身份自动Downlevel成了匿名用户,根本不再具备管理权限,这可如何是好???

嗯,让我们再看看一个活生生的在外网的SPS网站吧:靠近我(http://www.run2me.com),这是刘润大哥做的SPS网站,同样的,上面也都是MS的员工。从第一天看到它开始,我就一直在疑惑,它是如何在启用匿名后,仍然可以对其进行管理的?而且很显然,每个人的身份还都不一样。

恰巧这次PoC的时候,同事正好有刘润大哥的电话,于是我们就用电话向刘润大哥请教了一下,在得知其机理后,才发现,一切都是那么简单:IIS中两个Virtual Server(一个匿名,一个非匿名),一个SPS。在SPS当中设置两个代理访问Url,即可以起到此效果,一切得来都是不费功夫。

虽然说起来简单,但设置起来还是需要一定技巧的,因为SPS过于庞杂,想要玩转,也需要一份功夫,如果您在做SPS开发,并且对这种做法感兴趣,可以联系我,我会将具体资料文档发送给您。

另外,很多公司在内网部署了SPS,但是访问者的机器都没有加入到AD中,所以更改密码也成了问题,我恰巧也做了一个显示登录者信息并且能够更改登录者密码的Web Part,有需要者也可以与我联系,Free。

BTW:仔细看看下面的留言,不要再留您的邮件了,您应该知道在哪儿找到下载了。唉:'(

 

谈谈工作流引擎及面向服务编程

相信很多人对于BizTalk Server 2004(简称BTS)都有一种误解,认为这是微软出品的工作流引擎。包括我在内,从没有进入MS以来,一直在围绕着BizTalk Server 2004做开发,而加入后,所做的大部分PoC都是基于BizTalk Server 2004的。当然,我做的都是一些外围开发,而不是一些核心性的BizTalk开发。

所谓的外围开发,就是为工作流做一些UI界面,以便驱动整个工作流能够进行下去。做得久了,经常会有一些疑问,我相信大部分做过BizTalk Server开发的人员都会遇到类似的疑问,因为在我与Partner的研发人员闲聊时,也遇到类似的困惑,那就是为什么有了BizTalk Server 2004这么好的工具,我们做工作流开发还这么累呢??很多时候,为了完成一个简单的公文流转功能,我们用ASP.NET可能几行代码就搞定了,但加上了BizTalk Server 2004后,却发现工作量成倍的增加。

经过这一个月以来,与同事探讨,终于找到了一个原因。因为我们错了,BizTalk Server不是微软的工作流引擎。这话似乎有一点惊世骇俗,但我相信,我们的观点没有错误。

博客堂前段时间一直在探讨SOA(面向服务编程),其实在我看来,BizTalk Server 2004正是为了SOA而做准备的,它是为了整合各个System的Service,而建立的自动流程功能,同时,由于各个System的Service所传递的消息的Schema的不统一,所以BTS里面提供了Mapping的功能。在BizTalk Server 2004的文档中,其功能就列了两点:(1)EAI,企业应用整合;(2)B2B的消息传送。

这种EAI的Service整合,在流程运行时,没有人为因素的干扰,没有UI的驱动,非常适合BTS这种无角色流程引擎进行驱动(BizTalk Server还是有角色的,不过非常淡化)。而类似于OA这种公文工作流的引擎,则BTS根本不适合。

前段时间,非常有幸看到了ADOBE Workflow Server的介绍(本来也想去看看点击科技王志东老大的工作流系统,可是无缘),对此我更有感悟。ADOBE的这套东西,才是真正基于公文工作流的,我们可以比较它的流程图与BTS流程图的异同。BTS的流程图更像我们的软件逻辑图,在这个图中,你很难一眼就从中找到哪个点应该是一个UI,这个UI上应该有哪些单元。但ADOBE的流程图则不一样,它每个节点就是一个UI,在这个节点旁边可以罗列一些选项,比如“同意”、“不同意”、“退回秘书”之类的,然后从这些选项到它们应该到的下一个节点间连一点线。非常清晰的就把这个工作流的UI都给清晰化了。再配合ADOBE Form Server以及Form Designer,则能够很简单的做出来一个公文工作流系统。

且慢,难道微软真的没有工作流软件吗?非也非也。加入微软之前,也很有幸接触到了Teamplate的工作流产品,这是一个微软的全球合作伙伴,它的TeamPlate产品基本上把MS的所有Server都包含进来了,比如BizTalk Server 2004、SharePoint Portal Server 2003、Exchange Server 2003,那么这个工作流产品使用了BizTalk Server 2004的什么特性呢?原来使用的是HWS(工作流服务,Human Workflow Service)。

HWS,翻开BTS的随机文档,发现关于HWS的文档真的是非常珍贵,打印出来估计不到十页纸(估计其中大部分还是HWS的UI方面的,介绍哪个按钮做什么的)。估计没有人能够看得明白,但是再去MSDN Online上找一下,好多了,因为我们发现了BTS的SDK,在Sample里面还是一些料的,不过,我估计再没有人指引的情况下,没有几个人会对这东西能够上手。

HWS,实现的就是ADOBE Workflow Server所实现的东西,但是在目前,它缺少一个Workflow Desinger的设计工具,所以会造成它的曲高和寡的局面。你必须自己手动写代码去完成你的工作流设计,虽然在SDK里面有Step By Step的指导,但似乎还是很难(想想BizTalk Server 2004本身,本来设计流程就是画画那么简单,但MS还是怕很多人不会,还提供了一个免费的Visio插件,供大家做图玩)。

可能很多人读了上面的文章,会认为我在贬低BTS,其实不然。我觉得做BTS始终是MS的大智慧所在,它早在2000年就预示到了SOA的到来。只不过由于其流程图画得那么“好看”,导致大家有一些误解,从而杀鸡用坦克,既不顺手,还劳民伤财。在SOA服务来临之日,BTS更能突显其危力。我们想想Longhorn,那里面有一个Indigo。仔细思考一下,其实Indigo的很多功能似乎与BTS有交集,所以有理由相信,在未来,BTS下一版本又有新的面貌了,至于新貌如何,还请各位看倌拭目以待。

BTW:讲到SOA,想到前段时间博客堂对于SOA中传递消息的讨论,一派人认为SOA应该只传简单类型,一派人认为SOA可以传递复杂自定义对象,甚至包括DataSet在内。我搜集到的材料让我确认第二派会在未来占上方,有时间大家再一起聊聊吧笑脸

个人拙见,欢迎斧正(没有想到会出现在首页上:()

Whidbey抢先预览(视频)

为庆祝本人即将到来的二十八岁大寿(又要写二十八岁祭了),在征得微软中国开发合作部张炜先生的同意后,将其录制的Whidbey的视频上传到博客堂站点上,供大家抢鲜预览Whidbey强大的功能。该压缩包共包括四个独立的视频,均是使用Windows Media Encoder捕获屏幕生成的。分别包括:

  1. 使用C#创建ASP.NET应用程序;
  2. C#语言的改进以及类图设计;
  3. ClickOnce简介(VB.NET);
  4. WhiteHorse的SOA应用;

以上的视频介绍已经涵盖了Whidbey的方方面面笑脸

下载地址: 已经过期

Visual Studio 2005 Community Technology Preview (For MVP)

如果您是Whidbey的Fans,如果您是MVP,那么您现在可以使用MSDN宇宙版订阅权下载Visual Studio 2005 Community Technology Preview 了。

孙展波在上一个随笔中曾经提到过Whidbey将会被推迟到2005年发行,当时引用的是路透社的报道,而现在,基于MSDN 订阅者下载站点中的文件名称,我们可以看出,这个预言已经变成了现实。

这是一个Full DVD的镜像文件,大小共有2.67GB,想下载起来并不是非常容易,让我想起了N年前,下载VS.NET 2002的情景,和一个哥们在他们公司里面,半夜两点使用ISDN进行下载,中间断了无数的线,还好我们有网络蚂蚁笑脸

 

新浪短信Web Service

上一篇文章中,提到了在我的流程监控系统中应用了新浪发送短信的Web Service,得到了大家的响应。很多人对此非常感兴趣。

在得到该资源的推荐者张炜先生(开发合作部的同事)的允许后,我决定公布此资源,并且提供如同鸡肋般的示例代码。

该资源的该问地址为:http://smsinter.sina.com.cn/ws/smswebservice0101.wsdl,这是一个WSDL文件格式,您可以直接在您的VS.NET环境中直接添加Web引用,把该地址输入即可。

该Web Service就只有一个方法,即string sendXml(carrier,userid,password,mobilenumber,content,msgtype)。各个参数全部为string类型,其含义基本如下(可能不正确)。

  • carrier:运营商名称,这里面可以随便输,不过似乎没有任何显示,不知道里面有没有其它奥秘。
  • userid:您在新浪无线上注册的手机ID,即http://sms.sina.com.cn
  • password:您在新浪无线上注册手机时所使用的密码。
  • mobilenumber:对方的手机号码;
  • content:发送短消息的内容;
  • msgtype:发送短消息的类型,我估计支持彩信,不过我目前仅使用文本短信方式,似乎随便输什么都可以,我使用的是“Text”。

示例如下:

Sina.SMSWS ws = new Sina.SMSWS();
   string result = ws.sendXml(“Sina”,textBox1.Text,textBox2.Text,textBox3.Text,textBox4.Text,”new”);

 

资费标准请参看新浪无线网站上的相关说明,应该是一条一角钱,不过也或者是一条两角线。由于其后台可能使用了消息队列机制,在繁忙的时候,可能会有几秒钟延迟。

工作流监控及短信子系统

周六接到任务,协助我们公司的几位同事开发一个POC(Proof of Concept)项目,给我们的开发时间是四天,使用BizTalk 04 & .NET来开发。而我们的对手已经开发了一个多月。

任务非常紧张,周六从早上十点钟加班到周日凌晨五点左右,回家睡了一小觉,上午十一点赶到客户处继续开始工作。

我的任务主要是做一些外围工作,不参与具体的工作流编制任务,所以不需要理解具体的业务,主要的工作有以下两部分:

  • 工作流程图形监控:由于BizTalk提供的图形监控具体普遍抽象性,不牵涉具体的业务环境,而且仅提供WinForm方式,还需要安装BTS Server,所以根据客户的需要,需要一个基于Browser的图形监控系统,可以查看到系统中所有的流程,并且可以可以标志当前流程的进程的状态,以及查看某一具体环节的详细信息;
  • 工作流程通知系统:当有新任务分配到具体的工作人员时,通过手机短信或者MSN Messenger方式,将该通知发送给相关的业务人员;

对于第一个任务,由于经常碰到类似的客户需求。所以我决定做一个比较通用的系统,利于以后重用。

所以在开发中,我把绘图的核心类包装了一个单独的Assemly。利用此核心类,我们可以组织出来基本的流程图。左图中的开始结点、中间结点、判断节点以及结束结点均是对象,根据节点的状态从对应的色彩模板中选择颜色进行绘制,做为一个整图输出(由于开发时间比较紧张,我还做不出来特别复杂的流程图,比如两线相交、曲线等,以后慢慢整理)。

图形绘制出来后,通过Response.OutStream将其直接绘制为一个jpg图形,再在另外一个ASPX页面中使用Image控件引用它,使用Map元素为其添加Tooltip以及Href等功能。这个功能到今晨两点左右已经比较完善了。

第二个任务比较简单,我直接调用了新浪的SMS的Web Service,只用了几行代码就加以实现。而使用MSN Messenger则的确难为了我一阵子,最终的方法是使用了DotMSN程序集,并且在里面实现了机器人功能,通过输入相应的命令,可以查看当前处理的订单、监控系统运行状态、启动或者关闭监控系统。在有新任务到达时,主动发送消息通知用户。这个功能今晚十二点左右也比较完善了。而且客户反应,已经远远超过他们的期望。另外,还有一个监控系统,是一个Windows Application,可以以列表方式查看当前正在处理的订单信息。

等本周Demo完系统后,准备抽时间把这套子系统进行细化,在未来的项目中加以复用。上周还一直应另外一个客户要求,做一个SharePoint Portal Server 2003的插件,在文档库中的右键菜单中增加一项右键菜单,如果是Word文档,则查看其“索引及目录”,而如果是PowerPoint,则查看其所有Slide的标题。不过还未做完,可能要等到周末左右才能完成了。

SharePoint Portal Server & Office Research Service

自从得知Kaneboy兄编写了一个基于SPS的信息检索服务之后,就在大功完成的时候,看了一眼SPS的SDK,却发现这东西其实本来就已经有了。看来我又犯了“想当然”的错误。

在开发之前,我一直想寻找SPS是否具有这个功能,但是在看完Kaneboy的文章后,我想当然的以为这东西需要自己开发,于是摩拳擦掌,开始写代码进行实现。中间还遇到种种的问题,分别向moslem以及kaneboy进行了求教。

不过虽然SPS原来就有这种功能,但通过这几天的摸索,还是了解了很多原来不了解的知识,如在SPS上如何开发部署自己的Web Service等等。

大体来说有以下几步:

(1)在Web站点的属性中新增加一个MIME类型,即“.tmp”,并且将其对应到“common/type”;

(2)新建一个Web Service项目。注意,其所选的路径应该为http://portalServer/_layouts/ProjectName。(我是新建了一个虚拟目录,并且在SPS管理中心将其设为排除的路径);

(3)增加Microsoft.SharePoint.dll的引用,然后开始开发其功能;

(4)开发完毕后,将其部署到[driver name]:\Program Files\Common Files\Microsoft Shared\web server extensions\60\ISAPI当中,并且可以使用http://portalserver/_vti_bin/[Name].asmx来访问;

(5)此时使用VS.NET注册会出现HTTP错误,你应该使用命令行工具咧嘴笑脸isco http://portalserver/_vti_bin/[name].asmx来建立一个disco以及wsdl文件,并且按照SDK中的描述对其进行修改及重命名,再部署过来。

恶魔的脸现在就可以像普通的Web Service进行访问了。

另外,SPS自带的信息检索功能其实就在http://portalserver/_vti_bin/search.asmx中,大家可以试一下笑脸

Whidbey & WhiteHorse & 博客堂清理帐号

看到大家这两天都对SOA以及Whidbey非常感兴趣,讨论得热火朝天,其实,在Visual Studio.NET的下一版(Whidbey,或者是Visual Studio.NET 2005)当中,提供了一个SOA的设计工具,即WhiteHorse。

在PDC版本的Whidbey当中,应该没有提供WhiteHorse组件,不过现在互联网上关于这个组件透露的信息越来越多,我也找到几个相关介绍,给大家先睹为快。

先让我们看两个截图:


相信大家在VS.NET 2002以及VS.NET 2003当中都用过Rational XDE以及Borloand Togther或者MS Visio for VS.NET等建模工具。不过单就界面特性来说,Whitehorse更加酷,而且更加直观。

不过如果仅仅是一个支持UML类图的建模工具,WhiteHose就似乎只是酷了一点。其实它还有更酷的特性,就是它支持MDA以及SOA的设计方式。下面是Keith Short先生所给的WhiteHorse的定义:Whitehorse is a suite of graphical design tools to be delivered in ‘Whidbey’ that supports the design and validation of service-oriented applications based on web services, and is targeted at architects, designers, developers and operations analysts. Whitehorse is an early deliverable from the Distributed Systems Initiative, aimed at improving the design, deployment and management of enterprise-class distributed applications.

再让我们看一个WhiteHorse在SOA方面的设计截图。

更多信息:

关于博客堂最新更新:

  1. 博客堂最近成立了管理团队,我们通过内部管理团队对所有问题进行统一管理,管理团队大部分成员为博客堂的堂主以及部分其他人员;
  2. 为了继续维护博客堂作为精品技术社区的氛围,将于最近一段时间内对于博客堂帐号进行清理,本次将清除十余名帐号(名单基本上已经确定),由于是集体决定,不再给予申诉权力;
  3. 所清除帐号予以冻结,冻结期为一周,在一周内,如果您需要您的数据,可以与开心就好说明,我们将把您的数据以XML方式传送给您;
  4. 基于您的意愿,我们可以将您的数据平滑迁移到博客园,或者博客.CN;
  5. 博客堂仍然是一个刚起步的技术社区,我们需要您的任何建议及意见,如果您有建议或者意见,可以通过“联系”向我们提出,但任何关于申请帐号的邮件我们将不再进行回复。

如何通过需要验证的邮件服务器发送邮件?

在.NET Framework 推出以后,大家一直在为这个问题而伤脑筋。的确,在1.0的时候,我们是不能实现此方案的,大部分人选择了使用Socket底层自己重写。但是,在1.1的时候,其实Microsoft已经提供了验证功能了,只是一直没有公开。

恰好我在读.Text 0.95的源代码的时候找到了这段代码,感觉应该提供给大家咧嘴笑脸

private void Page_Load(object sender, System.EventArgs e)
{
       MailMessage mail = new MailMessage();
       mail.To = “[email protected]”;
       mail.From = “[email protected]”;
       mail.Subject = “this is a test email.”;
       mail.Body = “Some text goes here”;
       mail.Fields.Add(“http://schemas.microsoft.com/cdo/configuration/smtpauthenticate”, “1”); //basic authentication
       mail.Fields.Add(“http://schemas.microsoft.com/cdo/configuration/sendusername”, “my_username_here”); //set your username here
      mail.Fields.Add(“http://schemas.microsoft.com/cdo/configuration/sendpassword”, “super_secret”); //set your password here

    SmtpMail.SmtpServer = “mail.mycompany.com”;  //your real server goes here
    SmtpMail.Send( mail );
}

参考资料:

http://vaultpub.sourcegear.com/VaultService/VaultWeb/Blame.aspx?repid=7&path=$/Dottext/Dottext.Framework/Email/SystemMail.cs&version=1&includedversions=20 (用户名及密码为guest)

http://www.systemwebmail.com/faq/3.8.aspx