技术架构评估

技术架构评估

--主要对Java、Dotnet等技术进行综合评估
weide

2005 年 12 月17 日

在本文中我们将根据一个业务需求对当前流行的几种技术架构进行评估。

这篇文章的目的不是为了评价各种技术架构在单项指标上的优劣,仅仅根据我们描述的业务需求做出选择。同时,强烈希望大家发表自己的意见和建议,帮助我们做出这种选择。




业务场景描述

这是一个经典的业务场景,其核心问题是:作为一家行业软件提供商,要形成自己的企业应用框架[6],并在该企业应用框架上搭建行业的整体解决方案。

现状:经过多年的积累,我们形成了一个系列的行业软件产品,从几个方面分别描述如下:

  • 满足的业务需求: 服务于企业质量管理这一行业,同时为满足不同的业务需求,产生了相应的多款产品
  • 使用的数据库: SQL AnyWhere、SQLServer、Oracle
  • 开发语言(工具): PB、VC、Delphi、Dotnet(C#)、Java(JSP)
  • 发布形式: 核心业务仍以C/S为主,最新的项目根据企业需求也用Dotnet/Java实现了少量B/S应用。最终的产品线将会是B/S、C/S共存,包括单机版、网络版;标准版、定制版本的产品系列。
  • 经营模式: 定制开发与标准版软件升级并行,在标准版的基础上进行定制,同时把适用于多数企业的新功能合并到标准版中来。
  • 用户数许可规模:当前的数量级为N*10,可预期的上升空间为几百到几千。所以对应用服务器、并发等性能要求不算太大。

目标:
  将这些不同语言开发的,拥有不同发布形式,但却服务于同一行业的单个软件,统一到一致的技术架构下,并增加B/S发布模式的支持。最终形成B/S与C/S相结合的产品系列,形成行业的整体解决方案。
  举例描述:首先用Java(或C#)搭建企业应用框架,该框架包含认证/权限/组织角色管理、文件管理等通用性的功能。然后在该框架的基础上把现存 C/S版的--PB实现的财务管理系统,Delphi实现的库存管理系统,VC实现的局域网即时通讯系统的业务功能模块全部用Java或(C#)重写,并 增加B/S版本的实现。
  统一到一致的企业应用框架下,形成统一、规范的开发方式,使得我们不用再去维护多个技术团队;通过一致的企业应用框架,建立积累机制,逐步形成并完善整个系统的业务功能。

评价方法
根据上述业务场景的目标,我们根据如下几个因素进行评价,同时希望得到大家的意见和建议,最终将在这些数据的基础上形成一个综合性的评估结论。

社区文化
开发语言流行程度
技术体系和思维方式
成本
学习曲线




社区文化

Python和Ruby从技术角度也能够满足我们的要求,但由于在国内太“小众”,缺乏相应的技术支持和客户基础,现阶段不被考虑。Java和dotnet目前都拥有活跃和为数众多的开发社区,我们能够获得足够的交流空间和技术支持。

Ruby
知道Ruby是因为Ruby on Rails,一个相对较新的 Web 应用程序框架,构建在 Ruby 语言之上。它被宣传为现有企业框架的一个替代,而它的目标,简而言之,就是让生活,至少是 Web 开发方面的生活,变得更轻松。
但是,对于Ruby实在生疏的厉害,虽然知道也有相关的GUI库,但如果拿它来做一个系列产品,可能人手都找不够。基本没有交集,资源不列举了。


Python

http://python.cn,CPUG是中国第一个正式成立的Python用户的民间组织,在广大Python爱好者的推动下为宣传和发展Python而成立的。
http://www.czug.org,CZUG.org是一个 面向Zope/Plone用户、开发/设计人员及服务提供商的社区。
啄木鸟社区,是一个开放协作组织,关注Python语言的各种应用

Dotnet
Dotnet最大的社区是MSDN Home?MSDN中文网站拥有无数的中文Dotnet技术资源,这也是国内相比Java的一大资源优势。
Dotnet社区,其中最受关注的是多是关于控件以及和技术关系不是太大而在非技术上很有争议的随笔.在java社区已经普及的面向对象以及模式的概念,在.net社区鲜有提及. 在cnblogs的情况稍微好些. 不过通常局限在运用面向对象和模式来解决一些示例性的小问题.这样层次似乎太低了,这离企业级的应用差的还比较远。[4]
博客园,专著于.net技术的blog社区
MSDN Home
MSDN中文网站
http://www.codeproject.com
http://www.gotdotnet.com

Java
  Java由于时间的积累,项目的积累,社区资源多多。很多在实践第一线的开发人员、架构师活跃在各个社区之中。由于社区文化的不同,Java社区有N 多技术先行者,并乐于把自己的开发经验分享给整个社区。而Dotnet由于时间尚短,在这方面相对较差。
  Java开源产品多,面临的选择多,各开源项目文档充分程度各异,且文档又多以英文为主:( 好在国内的Java牛人自发组织了文档的翻译[5],并乐于分享自己的学习体验,这种方式对于技术的提高又有很大的帮助。

英文
TheServerSide.com http://www.theserverside.com/tss
http://java.sun.com
http://www.javaworld.com

中文
BlogJava http://www.blogjava.net/
Java视线论坛 http://forum.javaeye.com/index.php
Matrix http://www.matrix.org.cn
J道-专业的Java解决之道 http://www.jdon.com/
Java爱好者http://www.javafan.net/index.jsp
BEA dev2dev 在线 http://dev2dev.bea.com.cn/
IBM developerWorks 中国 http://www-128.ibm.com/developerworks/cn/java/index.html
http://www.javaresearch.org Java相关技术综合服务网站
http://www.javaworld.com.tw/jute/index.html


开发语言活跃程度

我们将引入两个排行榜,来评估开发语言的活跃程度和受欢迎程度。

TIOBE程序语言使用排行榜
下面列出2005年11月排行榜,最新排行请参考官方网站[1]。

近日来,在TIOBE程序员社区中公布了其2005年11月的程序语言排行榜。这得注意的是PHP即将超过C++成为了排行榜的老三!而Java作为开源先锋首当其冲的成为了龙头老大,并且仍然保持着很好的增长势头。 这个排行榜每月更新一次,其排名顺序按照世界范围内的技术工程师、讲师、第三方厂商的调查依据,并查询了目前流行的搜索引擎:Google,MSN, Yahoo,结合前两者的数据计算后得出的。根据TIOBE的观点,此排行榜是被程序员们用来检查自己的程序技能是否过时,或者作为建立新的软件系统时进行参考之依据,并非意味着哪种语言是最好的。

图 1. 2005年11月TIOBE发布:世界前20位语言排行榜



图示说明:
  • (Position):此列表明当前语言与去年位置的变化。
  • Ratings:在查询搜索引擎计算排名顺序时使用了 '+" programming" -tv -channel'公式,对上12个月内Google,MSN,Yahoo!和Google新闻组的数据进行查询。注意此公式应用于标准的Google web点击率、标准的MSN web点击率、标准的Yahoo!web点击率和标准的Google新闻组点击率。这里的“标准”意味着一次对前50位语言web点击率总和的查询是均匀分布的,即保证了排名的相对公正性和科学性。
  • (Ratings): 此列表明当前语言在上12个月内的排名变化。
  • Status:带有“A”的程序语言被认为是主流语言。带有“A-”和“A--”表示程序语言位于“A”和“B”之间。从支持能力的观点看,尽量在工业的、任务危机的软件系统中使用带有“A”的主流程 序语言。如果某种语言在上3个月内具有超过0.7%的增长率,则此语言将获得“A”状态。上两个月内具有超过0.7%的增长率的程序语言相应的将获得“A--”和“A-”状态。

    图 2. 2005年11月TIOBE发布:世界前10位语言在前五年内长期发展趋势图


  • sourcefage开源项目所用语言排行榜
    SourceForge.net,全球最大的开放源代码开发网站。对各个开发语言的开源项目统计,最新信息请访问官方网站[2]。
    以下列出2005.11.25数据,Java超过C++成为Sourceforge第一语言
    1. Java (16738 projects)
    2. C++ (16731 projects)
    3. C (15934 projects)
    4. PHP (12175 projects)
    5. Perl (6209 projects)
    6. Python (4542 projects)
    7. C# (2892 projects)
    8. JavaScript (2779 projects)
    9. Visual Basic (2192 projects)
    10. Delphi/Kylix (1926 projects)
    11. Unix Shell (1845 projects)
    12. Assembly (1608 projects)
    13. PL/SQL (1145 projects)



    技术体系与思维方式

    在同样满足技术期望目标的情况下,Java和dotnet的体系结构越来越近似,因此对于Java和dotnet架构的比较没有太大意义。

    二 者最大的区别是社区文化:Java是由各大公司一块儿制定规范,开源产品多,发展迅速,同时开源产品有些过多了;dotnet基本由微软控制,底层技术不 开放,但是对第三方软件开发商而言,也很友好,因此现在已经有众多的软件公司提供dotnet下的组件--这一点很类似于Delphi。Java由几大 IT公司共同制定和维护其规范,有着可选的若干方案;Dotnet由于微软的强势地位,只能是一支独秀的局面。其它公司采用 Dotnet开发产品,若微软也要插一腿,则其它公司很难竞争得过,最终难免衰败(Borland?)。比如金蝶最早准备用.net,现在改Java了 (?)

    给 个形象的比喻:走入Dotnet的世界,MS既是Dotnet世界的王,Dotnet世界规则的制订者,它就像太阳照亮了广阔的空间,大家除了仰望,谁能 与其争辉?Java世界,则是一个谁都能闪烁光芒的地方,能量小的是萤火中,能量大的就是恒星啊(IBM?BEA?)。

    转贴两篇C# vs. Java:相反的思维方式 (译文):
    Conflicting mindsets of C# vs. Java,Malcolm Davis,September 12, 2004

    我最近受邀对 C#/.NET 和 Java/J2EE 做一个对比。一开始,我比较了它们的功能特性、产品、技术,然后我发现 C# 和 Java 的战场并不在这些表面特征方面,而是思维方式层面的竞争。

    坐在办公电脑前,开发者脑袋中按两种相反的思维方式看问题:
    1.接受桌面上已有的工具并以此为标准。
    2.经常的搜索能够提高工作效率的机会。

    接受主义与探寻主义是两个社区的主要思维方式差异。什么是对开发者有益的,接受主义者放弃了对工具的控制,接受经理和卖主的选择。探寻主义者搜索、寻找正好对他们工作有用的工具。两种思维方式都有其正面因素和反面因素。

    工具的探寻(包括 IDE,组件,工具等)是正常的、预想的、首选的行为。作为开发者,应该寻找适当的途径,比如新的程序、自动生成重复的代码以及组件重用等途径,提高工作效率。可是,这对于一个 IT 公司来说,可能是一个不好的兆头。很多的 IT 公司限制随意安装新的软件,很多公司限制对外部网站访问,有的还限制对新闻组和 blog 站点的访问。(当然,很难想象有些 IT 公司甚至不允许访问 weblogs.java.net。)这些 IT 公司有很多适当的理由,比如对病毒、木马软件传播的担忧,以及由于缺少许可证而导致的法律问题,很多程序员并不清楚也并不关心引进新软件可能带来的这些后果。

    四年前,我向一家 IT 公司引进了 Ant,Tomcat 和 JUnit,这些工具简化并加快了 web 编程、测试以及制造的过程,极大的提高了公司的生产效率。现在几乎每一个 Java 开发者都已经掌握了这些技术。

    NAnt 和 NUnit 是仅有的一些开源的、对 Java 工具集的 .NET 移植。然而,Microsoft 并不是采纳这些已有方案、加以改进、并将它们集成到生产线中,而是自己重新创建了类似的产品 Visual Studio Team System。停下来想象一下,会不会有哪家 Java IDE 会声称“我们将不会支持 JUnit 或者 Ant,我们将推出我们自己的产品。”这简直是不可想象的!你现在知道 Java 和 .NET 之间的思维差异了吧:一个采纳社区已有的成熟工具,另一个则重新创造一套集成的方案。因为商业 IT 公司偏爱集成的解决方案,Microsoft Team System 给人感觉不错。可是,Team System 只是一个落后时代大约 5 年的产品。

    商业世界的人们已经开始使用 Jakarta 项目上发布的 Ant 和 Tomcat。思维方式凸现了商业运作和 IT 开发的主要差异。如果商业软件能够遵守和 IT 开发相同的规则,它们将压缩竞争对手的空间,同时失去他们最好的开发人员。

    由于 IT 公司需要以应用程序提供商(Application Service Provider, ASP)的等形式采用外部资源,Java 以及 Open Source 将成为 IT 的主流。Microsoft 的做法最终会伤害他们。ASP 的商业模式,将带领我们进入一个商业软件开发的新时代。Industrial strength development techniques, cutting edge technology, 以及经常性的探寻提高生产效率的机会,将成为标准,我们将看到“小鱼吃大鱼”的一幕,我们将看到 Java 吃掉 .NET 的午餐。




    Conflicting mindsets of C# vs. Java: Part II,Aaron Hohnson,September 21, 2004

    大家都看到了 Malcolm Davis 刚刚发表的那篇“C# vs. Java:相反的思维方式”了吧?你也注意到:sourceforge 上 Lucene.NET 的主持者关闭了项目,带着他们的玩具回家去了吧?我接着 Malcolm 的话题,说说这两件事之间的关系。

    大体而言,.NET 社区的参与者总是在谈论 Microsoft 推出的最新的、最强大的东西:MapPoint Location Server,SQL Server,Longhorn,ASP.NET 2.0,Visual Studio,所有来自雷德蒙(Redmond,微软总部所在地)的产品。相反的,Java 社区的程序员在那里谈论 JBoss,Hibernate,Struts,Eclipse,这些东西没有一个来自硅谷。

    Malcom 的文章说,.NET 开发者接受 Microsoft 提供的工具和服务,我想这在很大程度上是对的。.NET 开发者很少花时间,开发持续层方案(persistence layers),web 应用程序框架(web application frameworks)或者缓存解决方案(caching solutions),因为 Microsoft 已经为这些问题提供了 Microsoft 解决方案。但是仅仅是因为 Microsoft 提供了这些工具吗?那为什么 JSF,JDO,NetBeans 不能成为 Java 技术 Blog 站点的主流声音呢?拿 ASP.NET 和 JSF 作一个细致的比较,它们并没有太多的不同,但 ASP.NET 和 Visual Studio 一起被广泛应用,而 JSF 却很少人用并且饱受嘲弄。我认为 Malcom 是对的,的确是思维方式的差异早就了这一切。

    回过头来看看 Lucene.NET 的那群人吧:他们为什么关闭了开源的项目,他们为什么不再继续为这个很优秀的想法贡献他们的时间和精力呢?或许 .NET 社区对他们工作的反响,让他们无法继续维持下去了吧!使用 google 在 weblogs.asp.net 上搜索“lucene”只得到了 17 项结果,而在 jroller.com 得到了 2570 项结果。Lucene 已经存在很长时间了,但 Lucene.NET 的那群人们把东西包起来另起门户,其中一个原因可能就是:几乎没有人关注他们的工作:大家都在忙着研究 SQL Server 的全文检索,这才是 Microsoft 提供的解决方案(当然,需要为每个处理器花费成千的美元购买许可)。在 Java 世界,Lucene,Struts,Tomcat 之所以繁荣,也是因为为一个大的开源项目工作,给开发者带来了足够的威望。而当你投身于一个开源项目,却很少人注意时,沮丧的你也许也要寻找另外的动力。在 Lucene.NET 这个事例中,money 是他们的动力,所以他们关闭了项目,转而贩卖他们的个人版本和商业版本。他们或许能得到双倍的美元吧,但我打赌一年以内,不会有多少人谈论 seachblackbox.com 的。

    那么我的观点是什么呢?是说 .NET 开发者很贪婪,不关心社区吗?不是这样的。我认为,这两个社区有不同的司机:.NET 开发者盯着 Microsoft,关心 Microsoft 提供的解决方案,如果他们在车窗外看到了好东西并拿来使用,Microsoft 可能会最终进入这个领域,并发布产品或者提出解决方案,这样,以前的工作就完全被否定了。Microsoft 是 .NET 社区的司机。Java 开发者们看了看 Sun 推出的产品和语言规范,扭头去开发他们自己的工具、框架、应用程序。Sun 推出的东西,Java 社区的开发者只有他们确实喜欢才会去使用。Struts 的门庭若市,与 JSF 的门庭冷落,印证了这一点。在 Java 社区,开发者自己是司机。




    Eclipse联盟与桌面GUI

    目 前由IBM牵头,围绕着Eclipse项目已经发展成为了一个庞大的Eclipse联盟,有150多家软件公司参与到Eclipse项目中,其中包括 Borland、Rational Software、Red Hat、Sybase、SAS等。 作为一款企业信息化产品,服务端和客户端的技术应尽可能的保持一致,这样能够最大的限度的资源共用。Eclipse联盟的建立使得我们对于Java的桌面 GUI有着充分的信心。

    Eclipse的插件机制、扩展机制、自动升级、帮助系统等平台性的功能,使得我们拥有了一个现成的平台性软件,很多基础性工作可以不再重复去做。

    桌面GUI一向是MS的强项,在性能与界面美观方面占据优势,但没有现成可用足以媲美Eclipse的框架。


    成本

    开发成本
    另外一个非常重要的问题在于,用Java做为我们的软件架构,开源社区为我们提供了免费(或低价)的应用服务器,项目管理工具,开发工具,数据库系统。这 些足以满足我们的业务需求,而没有任何版权问题,而版权是我们软件产品经营中早晚要面对的问题。我们需要付出的代价就是了解并掌握这些开源的产品;若采用 微软的技术架构,则从开发工具、应用服务器、数据库服务器、工作流等整套系统全部正版的话,有着高昂的成本。

    用户实施成本
    用户既可以在现有Windows系统上安装,也可以安装在Linux系统上,伸缩性良好。同时,可以支持开源的数据库,降低用户的实施成本。Java由于有着良好的移植性,和为数众多的应用服务器产品,可以满足各种客户的需求。



    跨平台

    Java当然比之Dotnet要好很多。只是对于C/S应用而言,运行在国内几乎90%以上的Windows系统中,跨平台貌似没有任何意义。若干年后,如果Linux或其它系统在企业应用中被普及的时候,可能Dotnet也能够很好的跨平台了。

    学习曲线

    Dotnet入门容易,有着从服务器到开发工具的一站式解决方案;Java的入门曲线则相对较高,N多的技术、开源框架要掌握、要选择,服务器、开发工具的顺利使用要做很多的配置工作。
    对于企业级开发而言,其关键在于满足业务要求,合理的设计方案和架构,设计模式等,这些无论对于Java或Dotnet都是非常重要的。使用Java来学的话,由于整个社区对于架构、设计模式的普及,提升会比dotnet快。



    趣味观点


    以色列软件工程师Tamir Khason 揭示出了一个惊人的理论:有大胡子——有旺运;没胡子——只有干瞪眼![8]

    图 3. C#之父Anders Hejlsberg



    图 4. Java之父James Gosling




    结束语

    注意了,注意了!走过路过,千万不要错过下面的信息啊!

    感谢大家把这篇文章一直看到最后^_^
    既然已经看到最后,我诚挚地邀请您再伸出援助之手:请在这篇文章的最后给出您的宝贵意见,格式如下:

    我建议采用的平台是:(Java/Dotnet/其它)
    我的理由是:...
    我的补充意见:...


    参考资料


    [1] TIOBE程序语言使用排行榜
    [2] sourcefage开源项目所用语言排行榜
    [3] C# vs. Java:相反的思维方式(译文)
    [4] 质疑国内.Net社区
    [5] 满江红.开源
    [6] 理解企业应用框架,原载于《程序员》
    [7] 整理一下技术路线,robbin
    [8] 有胡子与没胡子的区别
    [9] 微软是如何输掉API之战,

    关于作者

    最近正在进行本文所描述的技术架构评估,对于Java和Dotnet有些举棋不定。热切希望得到大家的宝贵建议,再次感谢!


    posted on 2005-12-19 21:52 weide 阅读(22537) 评论(29)  编辑  收藏

    评论

    # re: 技术架构评估 2005-12-19 23:31 非鱼

    Glad to see your awesome work. :)

    Personaly, I think your article put too much energy on technical matter. But actually far from what you want. Maybe you should focus on Enterprise Application Integration than technology choice.

    From now, I can't see which tech is more suitable to your situation. Please check your problem and your purpose. I don't think they are corresponding to each other.

    Legacy apps mostly did not use component technology, thus you must think about to integrate them on persistence level. while you want them to be used continuiously, you should think of collecting information to build a publishing system, unless you are ready to replace them, do not focus on concrete technology/platform by now.  回复  更多评论   

    # re: 技术架构评估 2005-12-19 23:32 临海观潮

    单纯比较语言的优劣意义不大,针对特定的问题都能够找到合适的解决办法,这个解决问题取决于开发人员应用语言的能力而不是语言的本身。
    从风险驱动的角度考虑,个人感觉选择架构需要首先要考虑的是公司自身开发人员的的专长和公司的外部合作伙伴关系,比如和微软有非常好的合作关系应该首选.net,这样可以获得长期的价值保证。团队的开发能力也是重要的方面,如果都熟悉.net的话选择.net项目成功的可能性高。
    如果单从技术性角度考虑还是考虑未来系统的应用领域,大型的应用系统J2EE的成功经验多,相对风险小,此外相关的平台选择性比较多,使得最终产品/平台可以给用户提供多种价格选择。如果有跨平台的要求应该优先考虑J2EE。  回复  更多评论   

    # re: 技术架构评估 2005-12-19 23:36 xzer

    好吧,说两句

    我建议采用的平台是:java
    我的理由是:当你面临众多选择的时候,那既是痛苦,也是欢乐,当你被ms绑架的时候,只有痛苦。
    我的补充意见:虽然大家对hibernate评价很高,我也对它评价很高,但我仍然觉得它的配置过于烦琐了,ruby on rails的约定大于配置的思想是很值得学习的,为什么没有人做一个hibernate on rails呢。。。  回复  更多评论   

    # re: 技术架构评估 2005-12-19 23:44 非鱼

    @临海观潮

    Excellent perspective. I thought about it but forgot to wrote them down. Many cases, when you finished a system, you may find that marketing was more important than what you thought before. Since it do act an important role while developing, you should think about it, at least ask someone to do that.  回复  更多评论   

    # re: 技术架构评估 2005-12-20 00:16 weide

    @非鱼

    我想是“解决企业信息化中的信息孤岛,形成统一的整体解决方案”这句话,使你认为我应该focus on Enterprise Application Integration than technology choice

    实际上,我这句话并不是通常所言“信息集成”,和EAI关系也不大。我说的信息孤岛,是指我们现在几个产品之间,互相独立,各自有自己的组织机构和权限管理,开发语言又各不相同,这带来的问题是:我们需要用不同的开发工具(开发语言)维护多套产品中的组织机构和权限管理,多次重复劳动;且代码模块不能很方便的被新的系统所重用。

    现在要做的工作是,把PB写的产品A使用Java(或C#)重写,把用Delphi写的产品B也使用Java重写,把VC写的产品C同样也使用Java重写,同时把各个产品共用的模块,比如组织机构、权限管理等,只要维护一份代码就OK了。为企业实现定制功能的时候,由于全部功能模块都是由同一语言实现的,所以可以灵活组装成满足企业多个要求的“整体解决方案”。

    Do I make sense?  回复  更多评论   

    # re: 技术架构评估 2005-12-20 00:44 非鱼

    @weide

    Oh, Either you misleaded me or I miunderstanded you.

    Forget it. I think the platform choice mainly depends on the system scale. Of couse you should think about other issues. As I know (from friends), there's no successful Enterprise Level system (I mean very large scale) on .net platform. Try to identify your system scales:

    1. Is it a information collecting/organizing/OLAP system?
    2. Are you preparing to use Workflow in the coming system?
    3. Do you have any complex business process?
    4. Is it a real distributed system?
    5. Are the customers mature with IT, could they make full/less use of IT technology to help themselves?

    First of all, you should try to manage system change, then complexity. Also find out what design level you are in may help you to do better.

    Besides, environment influence may not be ignored and should be pay more attention to.  回复  更多评论   

    # re: 技术架构评估 2005-12-20 01:30 weide

    @非鱼

    Sorry,是我误导了你,修改了Blog中关于业务场景描述的部分。

    其中核心问题:作为一家行业软件提供商,要形成自己的企业应用框架[6],并在该企业应用框架上搭建行业的整体解决方案。也就是把各个系统中共性的、普遍性的问题提取出来,形成“企业应用框架”。其它的业务功能,用同一开发平台重新实现为业务功能模块。最后通过企业应用框架和业务功能模块,组装成产品系列。

    关于你上面提到的几个问题,由于现在我们服务的主要客户是中小企业,所以关于工作流等,考虑使用免费的方案;数据挖掘,以前没用,近期也没有打算...  回复  更多评论   

    # re: 技术架构评估 2005-12-20 12:07 Programmer's Life

    根据weide最近的这个回复:
    "其中核心问题:作为一家行业软件提供商,要形成自己的企业应用框架[6],并在该企业应用框架上搭建行业的整体解决方案。也就是把各个系统中共性的、普遍性的问题提取出来,形成“企业应用框架”。其它的业务功能,用同一开发平台重新实现为业务功能模块。最后通过企业应用框架和业务功能模块,组装成产品系列。"

    那我推荐你采用java
    理由:要形成自己的企业应用框架,那么必须自己能够根据框架的需求做出特定的框架,这个在.net上的实现难度远远大于java,而且.net的更新势必影响到整体框架的建设,而在java中则不是如此。
    Java界的开源产品确实众多,但以思想角度考虑则大多相同,只是在框架级别上各自有自己特性的地方,相对.net而言,有得选择就比没得选择好。
    以中小型企业项目这个角度去讲的话,我觉得采用哪种技术都无所谓,但想要形成一个自己公司的统一框架的话,java的优势无疑可以得到极大的发挥,但前提条件是有投入此框架研发的决心,如果没有的话,.net仍是首选,毕竟.net相当于已经提供了一套框架。
    另外一个角度就是从服务器端操作系统的竞争去阐述,这个角度去看仍然认为unix占有绝对的优势,从这样的角度的话无疑选择java对于企业会更为有利。  回复  更多评论   

    # re: 技术架构评估 2005-12-20 13:27 idior

    可以看出楼主在这篇文章上花了不少功夫,文章也确实不错。

    首先我先回避文章最后提到的问题,来评价一下文章的内容


    ---
    博客园,专著于.net技术的blog社区
    MSDN Home
    MSDN中文网站



    中文
    BlogJava http://www.blogjava.net/
    Java视线论坛 http://forum.javaeye.com/index.php
    Matrix http://www.matrix.org.cn
    J道-专业的Java解决之道 http://www.jdon.com/
    Java爱好者http://www.javafan.net/index.jsp
    BEA dev2dev 在线 http://dev2dev.bea.com.cn/
    IBM developerWorks 中国 http://www-128.ibm.com/developerworks/cn/java/index.html
    http://www.javaresearch.org Java相关技术综合服务网站
    http://www.javaworld.com.tw/jute/index.html
    ----

    从以上的数据来看,.net社区在国内是多么的弱小。

    ---
    学习曲线

    Dotnet入门容易,有着从服务器到开发工具的一站式解决方案;Java的入门曲线则相对较高,N多的技术、开源框架要掌握、要选择,服务器、开发工具的顺利使用要做很多的配置工作。
    对于企业级开发而言,其关键在于满足业务要求,合理的设计方案和架构,设计模式等,这些无论对于Java或Dotnet都是非常重要的。使用Java来学的话,由于整个社区对于架构、设计模式的普及,提升会比dotnet快。
    ---
    再配合这段话, 更加催发我得出一个建议:
    如果你有很好的基础(聪明,经过了系统的学习) 那么我建议你从java开始你的程序设计之路。(assembly,c++暂且不谈), 那样你会成长得很快。



    从ms对待nunit, nant的态度来看, 如果你想在developer的市场上和ms竞争, 那么或许结局会很惨, 无数的历史证明了这一点, 在.net平台下可能不久将上演的一场 JetBrains vs MS 好戏。

    但是如果你开发的是特定领域的应用(中国软件公司通常做的是这个), 似乎不会和ms发生竞争,而且他还会对你提供帮助。所以这种遭ms打压的问题,对于大部分中国公司来说应该是不存在的。



    ---
    举例描述:首先用Java(或C#)搭建企业应用框架,该框架包含认证/权限/组织角色管理、文件管理等通用性的功能。然后在该框架的基础上把现存C/S版的--PB实现的财务管理系统,Delphi实现的库存管理系统,VC实现的局域网即时通讯系统的业务功能模块全部用Java或(C#)重写,并增加B/S版本的实现。
    ---
    This is nearly impossible for us! 其实这里搂主提出了一个对遗留系统的整合,对企业内部应用和企业外部应用整合的想法。 有这种想法也不足为奇, 这也是最近SOA火热的原因, 不管在java还是在.net社区(国外) SOA都是最近很热的一项技术。

    最近刚好看到IBM的征文:
    http://domino.research.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/0fd9b681aadeffa1852570cf005fdc06?OpenDocument



    Now focus on the last question:

    我建议采用的平台是:(Java/Dotnet/其它)
    java .net 让他们做各自擅长的领域,让开发team选择自己熟悉的语言。

    我的理由是:...
    集成,整合 不能靠统一一个框架来实现, 这样你最多解决了企业内部的问题,而且重新实现原有的系统也是投资者所不能接受的。

    应该让SOA在其中发挥更大的作用。

    我的补充意见:...
    如果你有很好的基础(聪明,经过了系统的学习) 那么我建议你从java(而不是.net)开始你的程序设计之路。(assembly,c++暂且不谈), 那样你会成长得很快。








      回复  更多评论   

    # re: 技术架构评估 2005-12-20 13:33 idior

    另外对于楼主想让我转发本文到cnblogs上的意见, 我倒是想让大家看到这篇文章,不过cnblogs首页不提倡转贴,所以有3个方法:
    1. 在我的下篇随笔中给出本文的连接(最近可能会写一篇有关soa的随笔)
    2. 楼主到cnblogs注册 一个账号,然后发布该文
    3. 让dudu转一下 :)

    BTW: 个人比较头疼这种背景,字又很小 看得眼花了 :S  回复  更多评论   

    # re: 技术架构评估 2005-12-20 14:02 大维

    把开发工具升高到这么高的高度的,也只有程序员了
    从用户的角度,考虑的是价格和开发周期
    谁在乎你用什么  回复  更多评论   

    # re: 技术架构评估 2005-12-21 09:33 Ninputer

    .NET社区力量不够,我就要尽我的力量提高它,完善它
    .NET创新不够,我就更努力地提高,更多创新,让更多新思想从.NET社区产生,让JAVA社区来学习
    .NET有这样那样的缺陷,我们的职责就是努力改变这样的现状。

    .NET不行我们的目标就是让他行!不是转投JAVA。为什么?所有JAVA能举出的好处都是别人努力和创新的结果,只是选择和学习没有成功的可能。不可能复制成功  回复  更多评论   

    # re: 技术架构评估 2005-12-21 12:13 Fantasysoft

    存在即是真理,评估优劣似乎意义已不大。各种各样的技术都有它所适合的应用场景,否则它会被历史淘汰的。

    我更期待不同的技术能够相互学习,相互借鉴,毕竟尊重对手是很重要的。  回复  更多评论   

    # re: 技术架构评估 2005-12-21 20:13 errorter

    如果是中小型的 Web 应用,Rails 是一个很好的方案;重新学习没有你想的那么可怕  回复  更多评论   

    # re: 技术架构评估 2005-12-21 23:25 weide

    @Fantasysoft

    “各种各样的技术都有它所适合的应用场景”,说得好!
    本文虽然也描述了一个业务场景,只是之后的评估并没有直接针对这个场景的关键决定因素来展开--仅仅是对几个因素的宏观对比,这几个对比的结果,仅仅让我亲Java而远Dotnet。  回复  更多评论   

    # re: 技术架构评估 2005-12-22 00:30 weide

    今天化了一天的时间开评论会;邀请了其中一人是以前的同事,现在在微软中国。他有着对微软的强烈认同感、荣誉感,对dotnet的技术体系也非常熟,一整套分析方法分析下来,大家填写评估表的时候基本都选择了Dotnet...

    到场的Java开发者,缺少架构师级的能力,所以被比下去了;另外让我感到困惑的是:似乎使用Java同时做B/S版和C/S程序的公司并不太多?大多使用Java更多聚焦在Web模式的开发上,做Web开发使用的技术又不尽相同,即使选择了Java,还得在一堆Web框架里进行选择...

    请大家继续大力支持!(看完了,给出宝贵意见啊~~)

    公司在北京,有能力有时间的朋友想提供技术支持的话,欢迎与我联系 !  回复  更多评论   

    # re: 技术架构评估 2005-12-22 00:49 非鱼

    @weide

    If the application is not to be an Enterprise Level one, .net would not be a bad choice. Even so I want to state that .net is a "robber's boat" besides technology aspect. ^_^  回复  更多评论   

    # re: 技术架构评估 2005-12-22 00:56 weide

    ◎非鱼

    Enterprise Level的界定就是你上次描述的四条?

    1. Is it a information collecting/organizing/OLAP system?
    2. Are you preparing to use Workflow in the coming system?
    3. Do you have any complex business process?
    4. Is it a real distributed system?

    或者说Java比之Dotnet在Enterpise Level方面到底强在哪里?  回复  更多评论   

    # re: 技术架构评估 2005-12-22 01:07 weide

    @非鱼

    好半天才凿摸过劲儿来,"robber's boat",强盗的船,原来就是俗语的“上了贼船”啊,贴切

    英语也有这种说法?  回复  更多评论   

    # re: 技术架构评估 2005-12-22 10:00 非鱼

    @weide

    The 4 rules help you to identify a system's scale. Normaly a very large scale system can be called Enterprise Level. Many Enterprise Level systems consist of more than one organization and probably span a large physical area.

    PS: robber boat is my words.  回复  更多评论   

    # re: 技术架构评估 2005-12-22 10:49 idior,

    到场的Java开发者,缺少架构师级的能力.

    难道就因为这个你们放弃java?!
    何况那个了解.net架构师还不是你们公司的。

    .net下所有的分布式技术都是分散的。
    remoting, es, msmq, ws都是各干各的,完全没有一个统一的模型,至少要等indigo出来才会有所好转。  回复  更多评论   

    # re: 技术架构评估 2005-12-22 12:51 非鱼

    @weide

    看了你的网站。感觉你们发布了很多应用程序,这样看来似乎SOA比较适合,你们以后可以向ASP(Application Service Provider)发展。  回复  更多评论   

    # re: 技术架构评估 2005-12-24 15:06 jiniboy

    我们可以仔细想一想,其实我们更多的人还是生活在少数几个人的影子里。我们都知道这样的话,人民是历史的创造者,可真正描述起历史来还不是说某某人的时代,某某人的朝代。这也说明,微软式的专断,是自然的事情。java和dotnet的分别正是民主和集中的体现,你能说哪一种是优良的吗。  回复  更多评论   

    # re: 技术架构评估 2005-12-25 00:38 weide

    @errorter
    我们还有C/S应用的部分,也用Ruby,未知的陷阱太多了

    @idior
    把评价因素改了,长远的技术选择要兼顾,更重要的眼前,呵呵
    对于我们的项目而言,有两个因素:
    1.找到一个半成品(开源框架),解决企业应用中的一些共性问题,加快进度
    2.解决B/S与C/S下的图形绘制问题,目前Java和Dotnet下都在做这方面的工作。且图形的交互能力,比如拖动图片上的元素,暂不考虑

    当然到最后发现,真正决定因素:
    1.领导/开发团队喜欢什么
    2.开发团队熟悉什么
    3.哪种技术能让开发团队先熟悉起来  回复  更多评论   

    # re: 技术架构评估 2005-12-31 20:49 hawk_e2e

    路过。
    我是这样考虑的,希望有所帮助:
    1.先别谈用JAVA还是C#。
    2.楼主要先确定系统的当前目标(系统的市场优势和适用范围)和以后目标。
    3.在这些目标下系统的架构如何,如何演化。
    4.系统总有若干个关键的技术问题,无论用什么框架都需要论证可行性。
    5.用JAVA和C#,只要主体上合适就行了。主要看技术支持力度。

    另:不知道系统规模如何,6个月是否够?可否考虑稳妥的方法:先把目前各个部分的核心模块封装成组件。在新架构下进行整合。以后再重写呢?  回复  更多评论   

    # re: 技术架构评估 2005-12-31 20:53 hawk_e2e

    难以整合或整合不了的才重写  回复  更多评论   

    # re: 技术架构评估 2006-03-08 20:09 blueski

    我冒昧转摘了此文,http://www.sawin.cn/doc/SD/Architect/blueski411.htm
    多谢!  回复  更多评论   

    # re: 技术架构评估 2006-04-29 19:12 pc

    有意思  回复  更多评论   

    # re: 技术架构评估 2006-05-10 01:25 dvd

    我也正为此事苦恼之中
    对别人说上一句"这个问题要看你的项目而定"
    尔在自己定的时候就很难, 特别是我对2都还算喜欢
    了解的水平也都还差不多的时候.
    .. .. 无解之中  回复  更多评论   


    只有注册用户登录后才能发表评论。


    网站导航:
     
    <2005年12月>
    27282930123
    45678910
    11121314151617
    18192021222324
    25262728293031
    1234567

    导航

    统计

    公告

    需要做一些改变了

    常用链接

    留言簿(2)

    我参与的团队

    随笔档案

    搜索

    最新评论

    阅读排行榜

    评论排行榜