透视和调整你的企业和商务系统（ Ⅰ ： Analyzing 、 Requirement ）
小气的神 2001-10-09
对于 dotNET ，这是一项新的技术，一个为适应变化的应用系统体系。你可能不屑一顾还是测试版而已，宁愿观望；你可能已经开始接触它，透过这些新的技术开始思考现在和未来的企业或商务的应用程序结构。它们会是怎样的呢，呈现在你面前的将是一幅怎样的情景？一般你会问自己这样的问题：
**_ Why _ ** －这项新技术是什么？是用来干什么的，和现有的技术有什么优劣。
**_ Who _ ** －谁会用这项技术？对我或我的应用有用吗？
**_ When _ ** －什么时候可以应用它？什么时候开始调整我目前的系统或应用。
**_ Where _ ** －从何处开始？何处将会受到影响，调整从哪里开始和继续下去。
你也许和我一样，在接触 dotNET 之前就有 Windows DNA 的一些应用或一个系统在运行。老实说，它们有些问题，但基本上运行良好；另一个角度看，对 dotNET 又很感兴趣，因为从目前看它确实可以解决以前的一些问题。好吧，来假设一下目前的系统和构架：
我假设它运行在 Windows 2000 环境下，标准的 Windows DNA 构架，如下图：
需要的数据在在 SQL Server 中，假设它是 Windows 2000 ADV+ MS SQL 2000 ；所有的 db 和 Biz 组件安装在 App Server 中，也假设它是 Windows 2000 ADV 即 COM+ 1.0 环境中； Web Server 也是 Windows 2000 ADV 即 IIS 5.0 ； Web Client 假设它是 IE5 ； Exe Client 是 VB 或 VC 生成的 EXE 程序。中间的红色虚线是防火墙。 Web Server 和 Exe Client 上都将安装 App Server 的 Proxy 程序包。
如何加入 dotNET 技术改善目前的结构和功能呢？是否可以象下图：
再让我们看看从中我们可以获得什么好处，同时为获得这些益处又必须做些什么呢？
好处：
1． 显而易见开始运用了 dotNET 技术，体系结构发生了变化。
2． Client 丰富起来，几乎可以是现在流行的任何形式，只要兼容 WebService 规范和格式。
3． 防火墙问题，这样的体系结构下不会有 COM 或 DCOM 穿越防火墙的问题了。
4． 有了 WebService 你可以迅速的将你以前的应用 Show 出去，比如你原来的是一个股票系统或是一个航班查询系统或是一个价格查询系统等等。
5． 其它另外的一些，比如可以告别以前痛苦的 COM 组件 +ASP 的方式，特别是那些夹在 HTML 中的杂乱代码，开始使用 Web Form 和 Mobil Form 等等，我想开发人员喜欢的许多改善和用户界面方面。
那么为获得这些改善和好处又要做些什么呢？
1． 我不愿意把目前已有的组件重新写一遍（会不会太痛苦重写！）；老实说 dotNET 并不是围绕目前的 COM+ 和 DNA 来设计的所以想依靠迁移工具整体迁移几乎是不现实的，再说众多的商业逻辑还要重新实现，那又会产生多少错误，一定会影响目前还算正常的运行， 99.8% 的人不会这么做。
2． 也不想对照每个 Biz 组件另写一个封装的 WebService ，因为这样不仅加大以后的维护工作而且这些“封装 WebService ”，性能低下，同样条件下比起以前性能一定会降低很多。
3． 调整可以，必须保证不影响目前的运行情况下，局部的进行调整和编写一些代码。
4． 要连接老的体系结构，同时如果可以，新的需求和功能考虑用 dotNET 来实现，也就是保证平稳的慢慢的切换到 dotNET 的新体系结构下，而且老的代码不用改动或重写。
5． 其它另外的一些，比如调整的方式，今后的升级维护等等，调整可能带来的其它风险。
之后我想最好的是办法是模拟一下目前的环境，产生一个模型。开始时，可能是一个很简单的念头，但之后我发现整个的过程是一个体验过程，很有趣也很有意思。不知你是否会同意我在这篇文章最后的观点或结论（如果真有什么结论和观点 haha ），但我想有一点可以肯定，那就是平台 , 你在什么样的平台上编程？选择不同的平台，你所处和面临的环境将是截然不同的，开发和思考的视角也将是完全不同的，也许今后你思考的第一个问题将是：你要站在那个平台上？。
下面是后面几篇要讨论和涉及到的，也是我模拟的整个过程：
1． 产生一个 COM+ 的 DB 和 Bus ，模拟目前现有的应用或功能。分布在两部机器上。一个是 SQL Server （ Ericsvr ）一个是 APP （ Henrysvr ），将 DB 和 Biz 组件放在一起，而且 IIS 也在这部机器上。 IE 和 EXE 的客户端也在这部机器上或是另外一台机器 (Dereksvr) 。
2． 针对上面的 Biz 即商业逻辑使用 Microsoft SOAP Toolkit 产生 WebService 。有趣的是我发现实际应用中不是像 Sample 上那么简单的 Add （ A,B ） Return (A+B) 的应用，而是存在大量的 ADODB.Recordset 的返回和应用，于是很想知道这些 Recordset 在 WebService 中将变成什么？最后我分别用 VB 和 VS.NET 产生一个 VB 和 dotNET 的 Client 在另外一部机器（ Dereksvr ）上调用这个 HenrySvr 上的的 WebService
3． MS SOAP Toolkit 产生的 WebService 特别是带有 ADODB.Recordset 的 WebService ，可以说已经是一个不错的 WebService ，但也许不是最优的，然后我用 VS.NET 产生另外一种形式的 WebService(ASP.NET WebService) ，这样 Recordset 被封装和看不见了，因为有了你很熟悉的 .asmx ，对于客户端来说，接近上面 dotNET 构架图展现的。最后我只简单的用了一个 Web Form 调用了这个 WebService 。
最可怜的是 Ericsvr 只有 64M 还要跑 MS SQL 2000 ， Henrysvr 也是几年前的 P Ⅱ350，倒是借来的Hub和网卡表现都不凡，还好它们用“实力”证明了它们能够完成这些过程。
特别：
以上文字涉及其他人的隐私和个人权利，如非被授权或经本人同意，任何网站或期刊请不要刊登、转载、改编、转贴或已其他形式进行传播。以上所有文字和图片只用于内部交流，不作任何新闻发表和商业用途。