透视和调整你的企业和商务系统（Ⅴ：Solution、Architectures）
小气的神 2001-10-15
好了，我想在这一篇之后结束整个的话题，似乎应当有些结论，但可能每个人面临的具体情况不同，环境也是不同的，所以只能算是感想吧。dotNET中有些特性让人非常振奋和喜欢，但我们不可能总是利用新技术重新开始构架我们的需求和应用，无论是迁移还是改造都需要我们认真的审视和考察，构建程序和代码，往往开始的一个决定是重要的一个。不过这一点，往往是陷入泥潭中才想到的(haha)。
先交代一下整个的环境和需要用的的软件：
1． Windows 2000 Advanced Server SP2(英文版)
2． Windows 2000 Advanced Server SP2(中文简体)
3． Microsoft SOAP Toolkit 2.0 SP2
4． Microsoft Visual Studio 6.0
5． Microsoft SQL 2000 (中文简体企业版)
6． Microsoft Visual Studio.NET Beta 2 (英文版)
7． Microsoft Visual Studio.NET Beta 2 (中文简体)
8． Microsoft IE 2600 （英文版）
三部机器前面我已说明了，henrysvr上是英文的W2K和VS.NET，Dereksvr上面是中文简体的W2K和VS.NET.
最后的体系结构也被调整成这样（如下图），在我想像中这样似乎对目前的系统影响最小，原来的应用的构架不用发生变化，新的需求可以有一个新的起点。而且如何实现WebService这一层，你可以根据上面的讨论来具体决定。MS的Mary Kirtland（很熟悉吧）有一篇文章《A Platform for Web Services》非常不错，特别是结尾的那幅roadmap_1.gif一定不要放过，藏宝图一张。
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/websvcs_platform.asp
http://msdn.microsoft.com/library/en-us/dnwebsrv/html/roadmap_1.gif
至于最终的dotNET的体系结构我认为还在变化的，但有一些是可以肯定的，比如dotNET比以前DNA结构更加分布式而且更加松散；对程序员来说实现DB和Biz层也有了更多的自由度，不会象以前那么生硬。大凡应用程序的体系结构都如此，提出一种新的需要时间，深入理解需要时间，开始应用需要时间，真正应用广泛被人们接受又需要一段时间。
说明和结论：
1． 上面所讨论的都是基于这样一个前提：你已有一个系统或应用系统（最好是Window DNA结构的），你是想改造和做调整使之利用上dotNET技术。如果对你来说，一切都是全新的，那么上述中互操作的部分对你有帮助，毕竟Window DNA结构和新的dotNET的程序体系结构是不同的，请按新的体系结构考虑，两个体系的数据层和商业逻辑层的划分已有了很大的不同。
2． 我没有考虑或说针对防火墙进行考虑和测试，实际应用中，忽略防火墙可能是致命的。也就是说特殊的防火墙部署可能导致上面所说的结构不能成立。比如单防火墙，防火墙内又关闭Http和DCOM的端口。
3． 由于dotNEt和VS.NET目前都是测试版，所以有关安全、性能和发布时间都是保密和受条款保护的，那么也将无法针对性能等与已有的COM+/DCOM或Java做比较或测试。
4． 整个的讨论没有涉及到dotNEt的另一项技术:Remoting,这也将是一个考虑的因素和技术热点，不过上面的讨论覆盖了Remoting服务于所有可能的客户端和服务器端的组合情况，效果上是类似的，但具体实现上是有许多不同的。Remoting技术对于远程的对象或组件可以控制得更加深入和具体一些,交互性更好。
5． 比较明显的感受是dotNET体系下，不同平台之间的通讯和跨平台访问似乎已经解决了。XML重要性加强。那么以后可能带来的问题是：如果你是开发人员，你将如何选择自己的平台。你将在什么平台上编程？
6． Windows平台下的dotNET和目前的COM、COM+、DCOM等的互操作性很好，在兼容性上MS放弃了一些，但是互操作方面替用户考虑了很多，同一个问题可以有几种方式来完成，关键是你采取那一种方式来达到。这让我想起Anders Hejlsberg有关”Interoperability”的那段描述(http://www.csdn.net/develop/read_article.asp?id=9615)。凭这一点MS还是可以赢得众多的程序员肯定。
7． 对于模型的选取上，我只用了最基本的逻辑来模拟，实际情况远比这个复杂。再说没有考虑部署，整个Windows环境下的COM+和组件部署其实是最麻烦和需要足够勇气的事情。另外有些组件的逻辑应当复杂一些（比如多些组件）或实际环境复杂些（比如多分布到几台机器上）这样可能会更好一些。
8． 整个过程我们考察了Server是dotNET，客户端可以是VB或目前的技术；服务器端是COM/DCOM，客户端是dotNET的等各种组合，害怕离题太远，所以少了客户端和服务端都是dotNET的情况。不过焦点似乎最后还是回到了WebService。
感谢你花时间看了这篇文章，希望在你面对新老系统，做一些很重要的决定：维持原状还是重写；如何构建如何开始这样进退两难又必须做决定的问题时有所启发和帮助。最后让我用Anders Hejlsberg的话作为结尾吧：
“We've tried not to take an "ivory tower" approach to engineering C# and the .Net framework. We can't afford to rewrite all of our software. The industry just can't afford it, especially now when we're moving on Internet time. You've got to leverage what you have, and so I think interoperability is just key. We focused hard on giving programmers all of the right solutions for interoperating with Internet standards, such as HTTP, HTML, XML, and with existing Microsoft technologies, so you don't fall off a cliff the minute you find that something isn't provided by the new .NET environment, or when you realize you want to leverage some existing API or component. You've seen all the COM interoperability that we have built into the language and into the common runtime;”
---- Anders Hejlsberg
特别：
以上文字和图片涉及其他人的隐私和个人权利，如非被授权或经本人同意，任何网站或期刊请不要刊登、转载、改编、转贴或已其他形式进行传播。以上所有文字和图片只用于内部交流，不作任何新闻发表和商业用途。
