按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
系统、组件系统等应用。各位读者可看到了未来所需求的人才？
组件架构使用趋势
Java的EJB和Microsoft的＋都想在企业市场竞逐，成为企业对象应用系统的核心组
件架构。但是EJB和＋却选择了两个不同的发展方向。对于EJB，SUN只是定义出其
标准功能规格，再由各个EJB厂商根据标准EJB规范来开发EJB服务器。而＋却是由
Microsoft定义标准规范并且自己实现。正由于EJB和＋采取不同的策略，因此EJB
获得了较多厂商的支持，推出了许多不同的EJB服务器，但是＋却凭借着内建于
Microsoft的操作系统而拥有较多的使用者。
目前EJB的功能规格已经发展到2。x版本，Microsoft也准备推出＋1。5版。SUN和
Microsoft推广了许多年的EJB和＋，到底这两个组件架构在业界被使用的状况如何？
两者是不是雷声大雨点小呢？
根据去年调查的结果显示，EJB的确已经开始在企业生根，已经有19。3％的企业在使
用EJB技术；另外有15。3％的企业准备开始使用EJB。这个趋势和Gartner Group对于
EJB的预测非常符合，估计到了2004年，有40％左右的企业会使用EJB。从这个现象来
看，EJB实在可以说是已经成功了，其实用性也获得了证明。台湾EJB的实用性正日渐
普及，许多的大型企业、ISV都已经开始使用EJB作为关键企业应用系统的核心技术，
EJB的人才需要也日渐升高。
由于＋是内建在Microsoft的Windows的操作系统中，理所当然地其使用率应该是不
低。只是＋的前身/MTS等由于其延展性受人质疑，因此使用/MTS作为企业核
心技术的并不多，大多数是使用作为客户端的可重复使用软件组件。但是＋推
出之后，由于其执行效率和延展性都大幅精进，再加上Microsoft在TPCC上显示的惊
人效率也都是使用＋组件，因此＋逐渐打入企业市场，成为Windows平台核心的
组件架构，被许多企业的应用系统所采用。
根据2002年调查结果显示，＋使用率已经超过了34。5％，同时还有13。9％的企业有
兴趣采用。Microsoft在努力推广技术数年之后终于有了一定的成果。不过Microsoft
现在面临的挑战是对于＋的影响，由于Microsoft的平台正从原生窗口转换到
的阶段，许多人也开始困惑起来，中的组件架构仍然是＋？还是有其他的
组件架构来代替？如果仍然要使用＋作为组件架构，那么纯的开发工具又
无法开发原生的＋组件，如此一来在中＋不就又不是First Class的组件架
构了吗？如果纯粹使用的组件，那么纯组件的延展性尚未经过实际的验证，
也不提供Two…Phase mit和分布式mit的能力，又如何能用来作为企业应用系统
的核心组件呢？看来Microsoft在这方面还有很长的一段路要走。
CORBA呢？在EJB/＋的强攻之下，CORBA似乎失去了原有的光彩，但是不可否认的是，
CORBA仍然是架构/服务最完整、经过最长时间验证的组件模型。根据2002年的调查结
果显示，CORBA仍然有相当数量的使用率，而且未来也仍然保有稳定的使用率，可见
CORBA仍然受到相当的欢迎。
随着Microsoft 的出现和成长，CORBA似乎反而可以在平台有更大的潜力，
相关的讨论请参考下一章〃EJB对抗CORBA？有趣的假设〃。
信息技术到了现在的阶段可以说是〃平台逐渐整合，但是程序语言则呈现百家争鸣的
情形〃。再加上UML等Modeling的技术和软件愈来愈贴近软件人员，数据库和SQL技术
更已经成为软件人员最基本的技能，因此软件人员本身也自然朝向身通18般武艺的阶
段。只是好的软件人员耍起来虎虎生风，而一般的软件人员在愈学愈多的情形下则一
无精通，到最后反而是害了自己。
回到前面的问题，目前的信息技术的确是朝着多元化的方向发展。太多的技术、产品、
架构、程序语言、数据库、客户端种类等技术，造成了许多软件人员的困惑和焦虑，
这是很自然的现象。但是另一方面，平台在收敛，系统开发正走向整合阶段，对软件
人员的要求也走向整合。因此，除了焦虑之外，软件人员在了解了软件趋势之后，更
应该提出疑问：
你准备好了吗？
快速的开发周期
上大学时，要学习系统分析和设计（System Analysis and Design）课程，正好看到一
个统计，说程序员一天只写一行有效的程序代码，当时我简直乐坏了。心想一定要进
入信息行业，又有高薪又有地位，更重要的是工作如此轻松，一天写一行代码，闭着
眼睛都可以做到。没有想到，在真正进入了信息行业之后，情形却大为不同。不但工
作繁重，每日更需撰写成百上千行的程序代码，这哪里是一天写一行的日子？不禁心
生感叹，自己似乎入错了行。
所有的读者都可以感觉到，现在系统开发的时程要求得愈来愈快。我记得5/6年前，
系统和项目开发的速度还是1年到1年半左右，到了3/4年前已经缩短成10个月左右，
在Internet/Intranet快速兴起之后，许多系统和项目甚至缩短到了3个月就要推出的
迫人时限。信息机构的调查显示，系统和项目的开发时程将持续地缩短，到了2012年
居然只有一天的时程，这种超高标准的要求可能会吓坏许多的软件人员。不管这份调
查的数据是否100％正确，但是从这份信息调查趋势以及我本身的经验来看，愈来愈
短的开发时程却是不争的事实。
面对愈来愈短的开发时程，软件人员应该如何适应？这是许多人面临的困扰。其实许
多的程序语言、开发工具、软件工程都强调帮助软件人员提高生产力，以适应快速开
发的要求，只是随着时程的要求愈来愈高，许多传统的程序语言和开发工具都已经呈
现力不从心的现象。既然如此，那解决问题的方案是什么呢？
数年前，业界对于软件开发的速度要求愈来愈快，这造成了软件品质的下降。许多软
件在完善率尚未达到一定的水准下便仓促推出，造成了更多的问题，因此软件业曾经
被许多人讥笑为〃不可靠行业〃。为了改善这个现象，许多软件工程技术相继出现，以
求提高软件品质。其中最为突出的是以面向对象的各种软件工程，强调软件IC、可重
复使用的软件组件为特质，以加快软件开发的速度并且提高软件品质。面向对象的大
旗造就了3位面向对象大师，也让UML等模型工程独领风骚，进而让Rational公司成为
近年来最重要的软件公司之一。不过几年下来，UML对于软件开发的贡献一直受到争
议，许多软件人员对于UML过于复杂的流程和过多的UML图形产生怀疑，因此前一阵子
又兴起了Extreme Programming的热潮，强调轻便、动态、快速开发的特性。其实这
个现象正反映了软件业界对于开发〃速度〃的要求已经超越了过份强调软件工程流程的
重要性。现在的信息业界需要的是〃灵活的〃开发速度。
右边的图片明确显示了从2002年下半年起，许多企业和软件公司对于软件开发特性的
要求，其中列为最重要的特质就是〃灵活性〃，接着仍然是强调速度的Extreme
Programming的特质。其实，这些对于软件开发的要求也正回应了上一张图形显示的
对于开发速度的要求。
我认为UML/RUP和Extreme Programming/Agile Development之间并没有冲突，反而是
相辅相成的。对于大型、复杂的系统开发，UML/RUP仍然是目前为止最好的方法之一，
只是需要适当的修正，不要过份强调所有的形式流程。而Extreme Programming/Agile
Development则特别适合中/小型系统，需要快速反应时间的开发要求。
既然快速开发已经成为现在最重要的软件开发要素之一，那传统软件人员应该如何适
应呢？其实这个原理也不难了解，答案就隐含在上图中Developer…Centric包含的意
义。想想看，现在的许多企业是如何增加效率的呢？答案之一就是组织扁平化，尽量
减少不必要的重复浪费。软件开发也是一样，软件工具应该尽量以开发人员为中心，
让开发人员使用较少的循环能够完成更多的开发阶段，并且提供更可靠的软件。例如，
新一代的开发工具允许开发人员在一个开发环境中，同分析/设计人员以UM