朝晖

从业中间件10年了,学了不少。下个10年该做点事了...
构客网首页  博客  论坛

 
  SOA我有话说
  用户信息
 
帐号:  新手必读
密码: 保存密码
 
  分类列表
全部类别(75 篇)
朝晖前瞻(30 篇)
朝晖文化(13 篇)
朝晖管理(12 篇)
朝晖营销(7 篇)
朝晖推荐(11 篇)
  按月归档
2005年-11月(6 篇)
2006年-05月(46 篇)
2006年-11月(6 篇)
2007年-09月(10 篇)
2007年-11月(2 篇)
2008年-03月(5 篇)
  SOA2007 - SOA实践
我们何时迈向SOA
——SOA在中国的整体发展现状究竟如何?
我们如何迈向SOA
——中国企业如何迈出实施SOA的第一步?
我们应采用何种技术
——SOA国际标准SCA/SDO的具体内涵?
我们还需要何种技能
——SOA将如何改变系统架构设计以及项目管理过程?

显示第 1-10 条记录,共 73 条记录 首页 前页 后页 尾页  到第 页,共 8

闲话不停

发布时间:2008年09月06日 作者:朝晖

阅读次数:563次 类别:朝晖文化 永久链接 Trackback 

My Philosophy:

1:走出舒适区

2:失败是成功之母、成功是成功之父,父母都有了才有了的成功,当然儿子还是姓了父亲的姓。

3:IQ决定了起点,SQ决定了终点,EQ决定了从起点到终点的时间

  IQ:

  SQ:

  EQ: 开放的倾听和思索、勇敢的面对和改变、勤奋的投入和实践、坚韧的精神和体魄

4:遵从本我,放下自我,倾听他我

5:《外部记分卡》vs.《内部记分卡》

 巴菲特在《滚雪球》/《The Snowball》这本书中提出了两种评价方式的观点,相信这两种不同的评价方式带来了每个人的人生道路的不同和快乐来源的不同。

《外部记分卡》:这类人是通过周围人的评价来评价自己,进而影响自身的判断和行为。"对利拉来说,最重要的是他人的尊重,这是巴菲特后来慢慢称为"外部记分卡"的东西。利拉总是担心邻居们的想法,然后唠叨着女儿们要穿着适当、言行得体。"

《内部记分卡》:巴菲特说:"如果内部记分卡"能令你感到满意,它将非常有用。这取决于人们年幼的时候父母的关注重点。如果父母忽视、抹杀你真实的行为,重视的是全世界怎么看待你,那么,你最终将使用"外部记分卡"。而我的父亲,他是个百分之百的"内部记分卡"使用者"。

6:快乐的源泉

在《巅峰销售》中讲到的三点我相信也是快乐的源泉:
a) 明确自己的目标;
b) 用困难和问题来激励自己的创新;
c) 通过20条方案的思考方式来找寻答案。

程朝晖:感性的构件者(作者:雷赫,摘自中国计算机用户)

发布时间:2008年06月26日 作者:朝晖

阅读次数:766次 类别:朝晖前瞻 永久链接 Trackback 1条评论

程朝晖:感性的构件者

对于构件的技术理念,他是理性的;对于自己的职业选择,他是感性的。理性做思考,感性做决断,程朝晖演绎着自己的构件人生。

 

“对于一家平台提供商而言,如果客户大会的规模能达到一千人以上,就表明成功的基础已经夯实了。”望着窗外一片忙碌的工地,刚刚从上海用户大会返回的程朝晖满心憧憬地说,“只要基础打好了,万丈高楼的建设就会很快。”

作为一名浸泡在中间件领域已十五年的人,程朝晖的过去可以一分为三:IBM的五年,BEA的五年,普元的三年。如今,程朝晖已是普元软件公司的副总裁,其描绘的成功基础和万丈高楼,则是普元一直专注的构件技术和EOS平台。

SOA越来越火热的今天,每一个中间件企业都在竞相呐喊,每一个都有自己实践SOA的方式。在程朝晖看来,普元走的则是一条“不同寻常路”。重要的是,普元的这条“不同寻常路”正是程朝晖所喜欢并认同的。相比IBMBEA的体面,他更期望能在普元这条路上找到成就感,否则,他就不会在三年前放弃BEA而转向普元了。

瞄准“第四次浪潮”

对于一个技术出身的人而言,敏锐把握技术的发展潮流,是获得长远发展的必备认识。程朝晖就是一个敏锐的潮流把握者。

当初大学毕业选择进入中间件行业工作,就是基于自己前瞻性的认识。在他看来,中间件是一个会持续充满魅力的行业。

因为,在IT技术的发展潮流中,80%90%的新技术都会融入到中间件里面来。无论是Web Services,还是最新的SAAS(软件即服务),都需要一个SOA的平台支撑运作。随着企业信息化的逐步深入,中间件出现越做越厚的发展趋势。从最初的交易中间件,到后来的应用服务器,再到现在的SOA中间件,在此基础上,很多行业又会延伸出各自的细分平台。也就是说,中间件的发展前景非常广大。

另外一个重要的认识是,程朝晖认为中间件一直在改变软件的发展方向。因为,中间件承载了整个计算架构的演变,从主机终端,到客户机服务器,到B/S架构,再到新兴的SOAWeb 2.0,每一次计算架构的演变都是对IT产业的一次重要机会。

“如果你跟不上,就会被市场立刻淘汰;如果跟上,那就可以‘鲤鱼跳龙门’”。对此,程朝晖拿自己大学毕业时的一件事举作例子。那是1993年,知名数据库企业Sybase刚刚进入中国,由于它是支持客户机/服务器最好的技术,抓住了当时企业信息化的主流需求,所以一下子就壮大起来,成为做数据库领域的领导厂商。

而当时的Oracle还停留在主机/终端的技术上,市场地位远没有今天这么强势。不过,后来Oracle及时跟进支持客户机/服务器,才得以逐步改变市场地位。

所以,“把握技术的发展潮流非常重要,现在的SOA就是第四次浪潮。” 程朝晖如此断定。

在上个世纪八十年代,美国未来学家托夫勒写了一本名为《第三次浪潮》的书,把人类历史的过去分为农业社会和工业社会两个阶段,把未来的则定位为信息社会,一切生产关系和生产力都将围绕此而发生变化。对比如今网络化的社会现实,每个人都对《第三次浪潮》感叹万千。

程朝晖也是如此。他不仅感叹于社会发展的浪潮,更深思于IT技术的发展浪潮。“与其十年后感叹,不如今天就全力投入进去,走得领先,才能收获更多。”

用“构件壁画”布道

在普元公司的办公室里,有一条非常引人注意的走廊。在走廊的墙壁上,悬挂着一系列似是而非的壁画,五颜六色的配搭,各式各样的图形,普通人很难看懂其表达的内容是什么。如果给这些壁画归类风格的话,大概属于抽象派那类,至于其中表达的内容,记者实在也无法用语言形容。

不过,这些抽象费解的壁画在程朝晖眼里,却是一目了然。因为,这些是程朝晖亲自参与设计的“构件壁画”。也就是说,这些“抽象派”壁画传达的内容是构件理念。

在程朝晖的脑海里,构件壁画分为两个主题:Component is magicComponent is art

什么是Component is magic呢?意思是说,构件技术可以把企业信息化过程中业务、技术和管理三个维度的矛盾统一起来,使业务人员、技术人员和管理人员能够使用同一种语言顺畅沟通。

对于软件的理解,人们已经形成的共识是一大堆代码,业务人员只熟悉业务,管理人员只熟悉管理,很难和技术人员相互理解,甚至有时候出现“鸡同鸭讲”的尴尬局面。

而构件技术则可以使三者用同一种语言沟通。从技术人员的视角,可以用构件来表达计算、数据、流程、展现等。而从业务人员的视角,构件则表达了业务的功能模块和业务服务的。当然通过构件平台让其图形化展示,技术人员也可以玻璃复杂的代码,业务和管理人员也可以在业务管理场景下配置应用。

也就是说,构件使得软件脱离了原有的代码概念,而用一张业务逻辑图展示具体应用,大家都很容易明白,彼此间的沟通就更加顺畅有效。

应该说,尽管这些构件壁画很难看懂,但给人的整体感觉还是相当唯美。这也正是程朝晖设计构件壁画的第二个主题:Component is art。构件技术和艺术都会有两个共通点,抽象和唯美。

程朝晖解释说,抽象,正是软件的本质所在。最早的软件通过机器语言控制操作,这种语言离机器很近,但离人很远。于是,后来把机器语言抽象成汇编语言,汇编语言再抽象一层就是高级语言。构件技术则是更高一级的抽象,把软件从复杂的代码层面抽象成更贴近业务的表达,表达复杂的业务流程,以及管理策略,从而使之更容易被理解和操控。

至于唯美,程朝晖则把构件与软件的变化联系起来。当软件代码达到十万行以上时,就是一件很难控制的事情;如果达到一百万行,甚至类似Windows的一千万行,基本已经没人能控制了。这时候,如果做任何一小点改动,都可能带来灾难。在程朝晖看来,业务需求在变,组织流程在变,软件系统也应该在变,而变化可能是魔鬼也可能是天使。构件技术正是让软件更容易适应变化,并达到一种变化的美。构件技术让软件真正体现了‘简单就是美’的哲学思想。

 

一半感性 一半理性

对于这些外人看来似是而非,程朝晖看来则清晰明确的构件壁画,背后体现出的其实是程朝晖思想中坚定的技术理念——构件。

事实上,在过去十五年的职业生涯中,程朝晖对于构件理念的理解存在一个变化的过程。

IBM的时候,构件技术还没有出来。转到BEA时,企业信息化的现实发展和业务需求出现了迅猛的变化,曾经,BEA推出了一种名为Workshop的框架技术,其实这就是用构件的思想来做软件。那时,作为BEA中国区的技术发言人,程朝晖对于构件技术开始了深入认识。

但同时,程朝晖对于BEA发现了一个重要问题。在那几年,BEA的收入状况已经呈现一个明显趋势,License下滑而服务在不断上升,这对于一个技术平台厂商的未来是有问题的。

这说明BEA的上升空间已经到头,只能走向被并购的道路。而这,正是程朝晖离开BEA,选择专注做构件的普元的原因之一。“虽然BEA也做构件技术,但已经没有我的发挥空间,去普元,我想我可以创造更多。”

其实,真正促使程朝晖做出放弃BEA而加入普元这个决定的,更多是其性格使然。“我这个人是跟着感觉走的,但同时也有自己的逻辑判断,这是双子座人的特点,一半感性,一半理性。”

与大多数技术狂人的理性至上风格不同,程朝晖在判断一个相对重大事情的时候,整体上首先是凭感觉做判断,感觉判断后再回家用逻辑推一推。他觉得,理性的逻辑判断终归只能是个推断,未来的事情不可能用逻辑完全推出来,因为影响因素千千万万,所以,最终还是得依靠感觉来做判断。

追求成就感

“如果要体面,就去外企;如果要成就感,就到民企。”这是过去十五年职业经历给予程朝晖感悟和总结。如果你问他现在最想选择什么,他的回答坚定且明确:“我选择一个可以让自己充分发挥的空间,从而追求其中的成就感。”

在大学毕业后的第二年,程朝晖从第一份工作跳到IBM,薪水一下子涨了五倍以上,而且社会给的面子也随之提高了,一时间,各方面的基本需求都得到了满足,自己感觉非常兴奋。

他认为,对于刚踏入社会的人,会越看中眼前实际的东西,比如薪水高不高,打工的公司在同学之前有没有面子等;而随着自身的成长,则会更看中自己的发展空间,一些实际的东西可能不会有太大的差别感受。在他眼里,一年的薪水多拿个1020万,其实对他意义不大,因为该打车还是打车,该下馆子还是下馆子,最多就是可以买辆更豪华的车,但这些都是差别不大的内容。

也就是说,相比长远的发展空间而言,资历深的人可能更愿意牺牲一些实际的东西,而把握长远的东西。这也正是程朝晖作为一个资深人士的当前心态。

另外,对于之前工作过的IBMBEA这些成熟外企来说,他们一般都是一个萝卜一个坑,事物流程有板有眼,企业需要的,就是非常职业化的、有职业技能的、能把自己岗位做好的人。

但程朝晖不甘满足于此。相比IBMBEA那些成熟的外企而言,程朝晖更喜欢正处于成长上升中的普元。在他看来,普元没有太多的条条框框,更多的是一种开放的空间,每个人都是在自己认同的理念道路上,激情投入,从而追求工作中的那份成就感。


建立良好的SOA体系至关重要

发布时间:2008年06月24日 作者:朝晖

阅读次数:1505次 类别:朝晖前瞻 永久链接 Trackback 2条评论

SOA到底是什么?

SOA到底是什么?当大家对SOA开始有所了解后,往往有种雾里看花的感觉,看上去很美,可就很难摸透和落地。业界有些人把SOA说成是解决业务问题而不是技术问题,也有些人把SOA看成是解决IT资产的复用和管理问题,当然更多的人还是从心里把SOA当作新的技术架构。那到底我们应该建立怎样正确的SOA全景图呢?
SOA从概念到实践已经有了10多年的时间,随着技术本身的进步和应用需求的发展,SOA肩负的时代使命也变得愈加清晰起来。简单来说,SOA是新一代的企业应用架构,它通过对业务、技术与管理这三个维度的架构模型,统一解决我们企业应用面对的挑战。具体来说,首先SOA通过业务维度的构件化业务模型对业务进行模块化设计和流程梳理,从而在业务维度至上而下打破应用系统的障碍,形成企业业务服务的共享;其次SOA通过技术维度进一步对流程、服务及具体实现的剥离和标准化,将应用的信息、流程和交互进行了更加有效的逻辑梳理,从而在技术上打破各种现有技术带来的障碍,实现应用在各层资产(信息、流程和交互)的标准化和最大化复用;最后SOA通过从管理维度上提升对于服务的监控和策略管理从而为IT和业务层面带来全面的管控和治理能力。SOA以统一的架构解决了我们面对的业务、技术和管理的应用问题,从而带来了业务上的灵活性,技术上的高效率和管理上的可治理。
众多平台厂商、开发集成商和企业用户都希望可以随着这次SOA的大潮,加强自身的竞争优势,从而提升业绩和赢得更多的市场。

 

如何建立良好的SOA体系?

建立良好的SOA体系需要从我们自身的发展现状和需求看起。我们不难发现,欧美国家的业务和管理流程通过这几十年下来已经相当的成熟和稳定,应用内的需求变化相对较少,应用内的业务操作也都已基本稳定。而随着部门和业务整合的需要,则更加需要企业级跨部门的流程改造和流程管理。而中国的企业客户的现状却很不相同,我们还处在信息化的快速发展阶段,我们中国客户的各种应用还在通过一期、二期、三期的不断建设过程中发展成熟和逐步稳定下来。因此也注定了中国客户的SOA实施策略和SOA体现的价值会和欧美有较大的不同。中国客户需要通过SOA更多地解决应用内的服务构造、服务再造和服务稳定,同时借助SOA的架构技术和标准达到各种业务模块间和应用系统间的互联互通。
从下图IDC的统计分析可以看到,中国客户已经从概念的接受到局部的实验,有一些行业的领头羊企业更已开始进入到全企业规划和部署阶段。我们所接触到的绝大部分的企业,无论是金融行业、电信行业还是电子政府、制造、能源等都已经走到了实践SOA的道路上。并且,他们也不再轻信SOA的一种实施策略可以包打天下,而更多地从自己的处境和想要解决的问题开始,寻找适合自身发展的SOA实施策略。
 
应该说,要想在中国发挥SOA的最大效用,把SOA用到实处,就必须建立符合中国企业发展的正确的SOA体系架构、技术规范、业务模式、开发方法、治理策略和实施路线图。目前中国客户期望SOA解决的问题不少,有技术架构和规范的,也有业务开发模式和管控治理的,我们需要一次为基础梳理出需要解决问题的轻重缓急。在有明确建设目标的前提下,规范和标准化企业统一的SOA架构和工具平台,并通过分步实施的策略逐步在实际的项目中建立起行之有效的开发方法论和组织级共享的各类基础构件库和业务服务库。这样就可以依托SOA的时代大潮,走上良性健康发展的道路。
如下图,就是普元提出的建设SOA体系的总体应用架构的规划模型:
SOA应用架构模型从业务、技术和管理的三个维度,实现了三者矛盾的有机统一体。
首先是应用的业务逻辑,通过业务构件化的模式可以自顶向下从企业的业务规划蓝图开始到梳理业务流程,再到业务领域功能和业务逻辑,直到基础技术构件;当然也可以自下而上从平台提供的或是组织积累的基础技术构件开始,在项目中不断组装出更粗粒度和共性的业务领域构件,直到组装出我们的业务流程。这两种方法相辅相成并不矛盾,自上而下的方法是在业务规划明确和清晰的领域使用,而对于那些还很模糊的业务域则更多采用自下而上的方法,通过项目实践来积累各个层面的构件。所以构件化的业务模型,就是把业务分层的过程。有了这样的模型以后才可以说达到了更佳的业务专业化分工和业务需求的灵活应对。
接着就是应用的技术架构,同样也是通过技术分层的架构方式来对应用的各层资源进行分层解耦和规范标准化。SOA与以往不同的技术架构在于把具体的构造技术与服务及流程的分离。举例来说,具体构造一个业务逻辑的时候并不局限于一种实现技术和语言,既可以用现有的Java技术,Spring技术,C++技术等,也可以用普元提供的高效的图形化逻辑组装开发技术。这些都在构件层解决了对于各种实现技术的支持。到了服务层则与构件层的具体逻辑实现和实现技术无关,通过SCASDO等技术标准实现了企业应用的服务松耦合、服务标准化、服务灵活装配和服务资产管理。应该说SOA的五层技术架构在企业的整个组织层面实现了‘人’、‘流程’和‘信息’的解耦、标准化、灵活复用、动态配置和管控治理能力。
最后则是应用的管理框架。在上述SOA的应用业务逻辑和技术架构的模式下,企业需要有手段和工具能够持续不断的监控、治理、优化其业务逻辑与应用资源。因此就有SOA应用架构的管理纬度来承担此项。通过一个服务的管理框架,监控、治理到业务逻辑与应用技术的各个层面,比如应用技术上的数据操作、构件操作、服务操作、流程操作等等,比如业务逻辑上的运营效率、绩效管理、风险管理、运营策略等等。当然应用的管理框架也是一个动态可扩展的框架,可以不断把各种IT和业务的策略加入进来,从而达到不断提升业务和管理水平的目的。
 

SOA的实施全生命周期

有了SOA的应用架构之后,我们又怎样把这个能力融入到具体的应用当中去呢?也就是如何通过一个生命周期,应用和服务能够从无到有和成长消亡?要知道资源和服务都是有生命的,它们都会经历孕育、诞生、发展、和消亡的整个过程。如下图,就是普元提出的SOA的实施全生命周期模型:
在介绍这套生命周期的模型前,我们先看下埃森哲CTO最近的一个观点:“现在如果说我没有足够的业务构件的时候,我绝对不会采购ESB的。”正如他所言,如果违背了生命的客观规律,那就变成了一种随波逐流的投机行为。我们有些客户也采购了ESB,但是却基本没有用起来,ESB在那里空转。SOA不是要往脸上贴金,而是要确实知道企业采用SOA的目标是什么?策略和愿景是什么?业务规划蓝图是什么?流程如何梳理?业务逻辑如何构造?最终了解这些之后,需要采用相应的技术平台来帮助在应用实践中不断构造业务服务,不断构造业务流程,并在应用实践中稳定这些构造出来的服务和流程、复用这些服务和流程。当业务服务和业务流程积累到一定程度时,我们就需要在组织级管理它们,上图模型中的运营和管理的第三个阶段将开始发挥作用,我们的服务和流程在企业范畴内就会更为有效地共享和被管理起来,它们的价值也会更大程度地被显现出来。
所以了解了这样的一个SOA实施生命周期的时候,就会知道应该从哪里开始。有了这样的一套方法的时候,我们就知道应该选择怎样适合的平台来承载,来帮助我们的服务、流程和应用的开发和运行。
 

企业计算架构的发展推动业务与创新

SOA似乎正代表着新一代的企业计算架构,也代表着新的先进的软件生产力的方向,它的高效、灵活和管控能力是我们的价值诉求。
让我们再来了解下历史,以更加明白现在的处境和未来的趋势。
我们可以看到企业的计算架构已经发展到了第四个阶段。对于我们现在司空见惯的在银行业的通存通兑的业务模式往往在二十多年前是不可想象的,这正是当时的计算架构所限;对于我们想在司空见惯的24小时的在线服务往往在十多年前也是不可想象的,这也正是当时的计算架构所限。可见我们现在看似平常的业务功能由于计算架构的问题而带来了业务发展上的限制。现在新的问题又来了,我们希望专业化社会分工,不同的开发商提供的CRM、HR、ERP和各种业务系统都可以协同工作,但是目前不同的软件模块间却做不到无缝地协同工作,这也正是我们现在架构带来的问题。所以很明显SOA架构的诞生,正是要让我们更为创新新的业务模式的推出成为可能。
让我们一起期待和努力,一个更为专业化分工、高效协同和标准化运营的竞争力社会的到来。我们也期待更多业务的创新能够在SOA的计算架构下不断地涌现出来,把我们带到一个崭新的世界。

幸福学转载 + 朝晖评语

发布时间:2008年06月23日 作者:朝晖

阅读次数:405次 类别:朝晖文化 永久链接 Trackback 

前段时间看到华为任正非关于自我解放的话题,前几天公司CEO也表达了公司不能简单以员工的幸福感为公司目标,我想他们都在说幸福感是靠自身来实现的。

幸福学     by邵忠(摘自周末画报)
最近看了一篇报道说哈佛大学最受欢迎的选修课是幸福课,非常值得与大家分享。教授这门课的是一位名不见经传的老师,名叫泰勒-本-沙哈尔。他说:"我曾不 快乐了30年。为此,我专心去研究幸福快乐的秘诀。我坚定地认为,幸福感是衡量人生的唯一标准,是所有目标的最终目标。"
长期的抑郁,可以被看成是一种情感破产。"整个社会,也有可能面临这种问题,如果个体的问题不断增长,焦虑和压力俄问题越来越多,社会就会走向幸福的"大萧条"。
沙哈尔认为人的幸福感主要取决于三个因素:遗传基因、与幸福有关的环境因素以及能够帮助我们获得幸福的行为。而积极心理学,可以帮助人们活得更快乐、更充实。幸福,是可以通过学习和练习获得的。

为此,泰勒-本-沙哈尔简化出10条基础小贴士:
1.    遵从你内心的热情。选择对你有意义并且能让你快乐的工作。(注:遵从本我,以前和同事分享过,如果我觉得这个公司没有了未来,我就会离开,不然我所有细胞都会死去)
2.    多和朋友在一起。亲密的人际关系是你幸福感的信号,最有可能为你带来幸福。(注:看过古龙的一本书,对于朋友的定义太过神圣,这点给了我负面的影响,其实有亲密人际关系的朋友对自己真的很重要)
3.    学会失败。成功没有捷径,不要让对失败的恐惧绊住你尝试新事物的脚步。(注:重要的还是在内心要承认自己的差距,比如视野不高、心胸不宽、勤奋不足,认识到了往往就有了新的动力)
4.    接受自己全然为人。失望、烦乱、悲伤是人生的一部分。接纳这些,并把它们当成自然之事。(注:也就是设好期望值吧,幸福感想必也是相对而出的)
5.    简化生活。更多并不总代表更好,好事多了,也不一定有利。(注:好事多了也是包袱吧,起码没时间享受和回味)
6.    有规律地锻炼。体育运动是你生活中最重要的事情之一。(注:前天我还和同事说我想像viacom的老大一样工作到70多岁还精力旺盛,我不喜欢吃年轻饭昙花一现,我希望自己能精力充沛地工作到80岁,因此我还是不停地在运动)
7.    充足睡眠。充足的睡眠是一笔非常棒的投资。(注:一年总有1-2次睡个回笼觉,简直让一天的脑袋清新,能够用最棒的大脑智慧皮层思考,那里思考出来的绝对是创造性的)
8.    慷慨。当我们帮助别人时,我们也在帮助自己,当我们帮助自己时,也是在间接地帮助他人。(注:助人为乐是自然人的需要,也是满足了自身存在意义和价值的证明)
9.    勇敢。勇气并不是不恐惧,而是心怀恐惧仍然向前。(注:我时常也是边相信边怀疑,最后豁出去地往前走出一条路来,世事难料,躲只有放弃机会,所以放下包袱总是对的)
10.    表达感激。记录他人的点滴思想,始终保持感恩之心。(注:在遵从本我的基础上,放下自我,倾听他我;俗话说改变自己总是最难的)

后SOA时代,企业Web大爆炸

发布时间:2008年03月08日 作者:朝晖

阅读次数:145次 类别:朝晖前瞻 永久链接 Trackback 
         在浦东机场等待去往三亚参加SOA技术圈子之“天涯论剑”活动的时候,机场正在放着周星驰的‘Mashup’电影。之所以称之为‘Mashup’电影,正是因为他的电影中最为经典的就是采用mashup的思想和手法把过往的历史故事(如西游记等)和现代生活中流行的故事场景(生活元素、工作关键词等)有机混搭(mashup)起来,达到启发大家和娱乐大众的目的。这种创新的手法可为独特、有创意和吸引观众。
         REST、Mashup可谓是最近互联网技术圈子中的流行语,可是这又与我们这帮企业技术圈子里的人有啥关系呢,很有浮躁和赶时髦的嫌疑。所以我们需要尽快把观点摆出来。
         软件业总在创造者新的技术,但是很多的思想确是来源于传统的行业,如构件化流水线生产的汽车业,模块化定制组装的家具业(IKEA),以业务元数据为基础来混搭创造的音乐和电影行业。

构件化与SOA,推进软件生产力

发布时间:2007年12月26日 作者:朝晖

阅读次数:2843次 类别:朝晖前瞻 永久链接 Trackback 5条评论

引子:

伴随福特流水线模式的百周年,回顾软件业也已经走了近四十年的光景。而全球软件行业似乎已进入到了中年期,成熟的商业模式,缺乏雨后春笋般的创新型小公司,大公司增长乏力进而带来诸多的并购等。这些都让我们感受到软件行业早已今非昔比,大部分的软件公司都变成了鸡肋。软件从业人员也都从梦想的憧憬回到了实际的运营成本控制中。即使近几年炒得火热的SOA也无法为软件公司带来多少的利润和股价提升。难道软件业真的就这样了,还是在等待新的一次飞跃?

我们小时候都读过这段“生产力的提高会促进生产关系的改变,而生产关系的改变又会反过来促进生产力的发展”,所以我们看待软件业的未来发展还得要从最为本质的提升软件生产力和改变生产关系入手。

 

构件化通过模块化、层次化和专业化,质变软件生产力

工业化相比较之前的生产方式,给了社会生产力质的提高,而福特的流水线模式正是工业化的代表作。这让我们清晰地看到对于复杂业务的高效处理方式,就是通过层次化设计和模块化分工把复杂的问题分层和模块分解,然后通过‘流水线’协同的方式再层层组合,完成整体的任务。而处于某个层面的被分解的模块,就会有相应领域的专业份子来解决,这个模块又可以再继续递归细分到更小的模块来分解问题。这样某个层面的模块就可以专注于自己所处的相对环境和自身的目标问题。这种模式从本质上改变了模块之间的生产关系,专业化解决相对的问题,从整体提升了解决问题的能力,尤其是解决复杂问题的整体能力。

由此,我们要提升我们的业务和管理生产力就得从此着手,软件世界中的构件化(Componentization)正承担了这一使命。原来的应用系统则不断地被构件化所打破,企业逐渐走上‘一个应用’的进阶。企业渐渐不再有固定的应用系统,取而代之的是处于各个层面的模块构件来实现某个层面的相应功能。下图是构件化企业应用的一个范例。

企业应用通过底层的技术构件来作为实现应用的基础技术功能,技术构件的适用性往往是最为广泛和跨行业的,在各种应用中都会被高度复用。而再上一层的则是企业根据业务总体模型设计出来或是在不断的应用项目实践中不断提炼归纳出来的某个业务或是管理域的业务构件,这些业务构件往往是企业最为重要的资产和竞争能力。有了这些业务构件,企业就可以根据具体要实现的业务和管理流程,组成具体的应用实现,满足业务的需求。

业务构件化和技术构件化的逻辑模式首先让企业可以开始不断规划设计、项目积累和梳理回归不同层次上的技术构件、业务构件和业务流程,通过专业化分工和流程协同达到组织级能力的提升。并且在此过程中和基础上可以更为精细化地运营和管理。企业根据需要灵活注入对于业务和技术构件的管控和治理策略,从而找到自身的核心能力模块,找到自身的高利润业务职能模块。进而不断投入、扩展和优化自身的核心优势能力,限制、调整和外包自身的劣势能力,达到不断提升企业整体竞争能力和赢利能力的目的。

构件化通过模块化和层次化,梳理优化生产关系;通过专业化和流程协同提升组织级生产力。

SOA通过构件标准化和服务契约化,推进软件生产力

构件化在不同的技术背景和时代有着不同的能力表现,在SOA到来之前构件化只能有效实现技术层面的模块化、层次化和专业化的能力水平。而SOA时代则真正带来了业务和管理的模块化、层次化和专业化。下图就是SOA编程模型SCA中定义的标准原子构件。

很显然它的技术无关性和消费使用(Consume)特征,如:服务、引用、属性、实现,是实现业务构件化的关键所在。原子构件就可以是一个事实上的业务构件,当然也可以在原子构件的基础上进行业务组装形成更大粒度的组合构件(Composite)。进而若干个组合构件和资源配置文件形成构件包(Contribution),成为独立可部署的业务功能模块。业务功能模块有了SOA标准下的逻辑构件形态和物理构件形态后,就可开发、可部署、可运行和可管理了,也就真正实现了标准的业务构件化。

下图是一个构件化SOA应用的范例。

由业务模块形成的标准化构件(Component/Composite)实现各自分工的业务功能,并通过契约化的SOA服务和引用互相协作,从而实现了一个典型场景下的业务应用。这样构件化的SOA应用,业务分工明确,组织协同关系清晰,可管理性、业务复用度和组织级灵活性都更为高效。

这就是SOA从面向构件开始,梳理优化生产关系,协同专业化发展组织能力,进而实现软件生产力的跨越。

后注:1969623日,美国司法部通过了著名的反托拉斯法案后,IBM不得不宣布不再免费随机提供软件,从而开始为其硬件和软件分别定价。那一天可以称为软件业的官方元年。


Gartner对于金融行业客户在实施SOA时遇到的问题的分析

发布时间:2007年11月21日 作者:朝晖

阅读次数:2360次 类别:朝晖推荐 永久链接 Trackback 12条评论
Gartner对于金融行业客户在实施SOA时遇到的问题的分析。

Key Findings(主要发现)
• Common challenges are faced by many financial services firms in pursuing SOA.
(金融客户在推进SOA时遇到的挑战具有共性)
• Organization and service definitions are bigger challenges than technology itself in defining services and achieving reuse.
(在服务定义和实现重用上,企业组织本身和服务的定义比技术本身更具挑战性)
• Both veterans and newcomers to SOA share similar issues in achieving governance and buy-in.
(不管SOA领域的老人还是新人,他们在实现治理和获得认同上所遇到的问题是类似的)

Recommendations(建议)
• Begin by defining a long-term development and acquisition architecture; then decide if SOA is an appropriate part of your future and determine what role it should play.
(起点要从定义长期的开发和包容性架构开始;然后决定SOA是否对你的未来合适并决定它应该扮演什么角色)
• Ensure that sponsorship is committed and able to bridge the business and IT divide.
• Create and empower a centralized function, such as an enterprise architecture group, to support centralized responsibilities, roles and resources. Ensure both business and IT
participation.
(组建和授权一个中央职能部门,例如企业架构组,来支持组织级的职责,角色和资源。保障业务与IT的共同参与)
• Focus on defining processes and workflows to match service requirements and interdependencies.
(专注与定义流程和工作流来满足服务的需求和相互的依赖)
• Improve governance, and provide incentives and rewards to encourage creation of reusable services, and then encourage their reuse.
(加强监控和治理,对于创建可重用服务的要鼓励和激励,并鼓励他们多多复用)
• Communicate value in business terms — not technical terms — to gain business buy-in.
(多用商业的语言沟通价值—尽量不要用技术的词汇—要获得业务的认同)
• Use early wins to gain experience that can be shared across development teams.
(通过早期的尝试来获得经验,并在开发团队中分享)


SOA从面向构件开始

发布时间:2007年09月28日 作者:朝晖

阅读次数:3686次 类别:朝晖前瞻 永久链接 Trackback 6条评论

SOA从面向构件开始

主要观点阐述

  • 构件:是构造应用软件的标准基础单元
  • 面向构件:是基于构件的软件开发方法和技术,用于构造应用
  • SOA面向服务的企业总体架构,服务成为企业应用的新资源层
  • 是与非:一切从应用出发,以应用为根本
  • 远景:SOA成就企业架构,应用软件都用构件来造

构件:是构造应用软件的标准基础单元。

Component

作为标准的应用软件构造基础单元,有两方面的作用和功能:

  • 应用软件可以通过构件中的Services(服务), References(引用)和Properties(属性)来构造更为高层和更粗粒度的应用软件模块(如后面要讲到的组合构件(Composite))
  • 也可以通过构件中的Implementation(实现)来封装更为低层和更细粒度的逻辑实现。

构件的编程语言无关性特征,得以在更高层次抽象、屏蔽了具体的底层实现技术。基于构件来构造应用的时候更多地脱离了底层复杂技术和它们的差异性,而是站在更高层的构件和服务的层面来构造。其中构件的几个基本概念和元素解释如下:

  • 服务(Services):服务是构件的一种组成元素,是构件功能的暴露和被使用的方式;构件是服务的载体,构件也会需要依赖(References)其他构件的服务,构件的具体实现(Implementation)也可以是个其他软件实现的服务。
  • 引用(References):构件自身需要用到的其它构件的服务。
  • 属性(Properties):构件自身运行时的可注入参数。
  • 实现(Implementation):构件具体实现时支持各种具体的逻辑实现技术,如Java, C++, PHP, Java Script, BPEL, SQL, XQuery, Composite等。

暗示:服务是构件与生俱来的,而以前的编程语言却不是;因此以构件为基础单元的应用软件就与生俱有了服务的能力,也就是服务别人的能力和享用别人服务的能力。这就是“SOA从面向构件开始”的第一层逻辑验证。

 

 

 

面向构件:是基于构件的软件开发方法和技术,用于构造应用。

Composite

构件封装和实现了我们更低层次的代码和逻辑实现,而面向构件则在此基础上开创了我们全新的应用软件的开发模式。应用软件的开发不会再是无休止的重复性的低层次编码劳动。而是基于构件的高度复用的软件图形化组装的开发方式。这就是面向构件所带来的软件工程和开发的革命。任何的革命实际都是要解决这个时代遇到的关键问题。面向构件正是关注和解决了我们现代应用软件开发中的三个核心关键问题:

1:全流程管理(Process)应用的流程实现是通过构件的组装(Wire)来完成,而且是支持全流程的实现。全流程也就是对于三层不同逻辑资源的一体化使用:

  • 代码逻辑(Code Logic)也称为功能逻辑,可以支持细到各种语言(Java, C++, BPEL)编写的代码逻辑的流程,它们一旦被封装到标准的构件中,就可以被用来组装成更高级的业务构件(Composite),或是被暴露成构件中的服务(Service)而被使用。在业务组装开发环境中,原来的实现技术和语言已经被屏蔽了,对于应用开发来讲具体的实现技术和语言已经变得透明和不再重要了。
  • 构件逻辑(Component Logic)也称为应用逻辑,可以支持到基于构件的逻辑组装,而开发出更粗粒度的业务构件(Composite),业务构件实现了具体的业务模块和流程。
  • 服务逻辑(Service Logic)也称为集成逻辑,同样可以在构件或是业务构件中访问和使用外界的服务资源,以实现更高层次的业务构件。具体可以通过构件中的实现(Implementation),或是依赖(References),也或是业务构件(Composite)中的依赖(References)来访问外界的各种服务(Services),甚至是企业服务总线(ESB)上的各种服务。

2:无缝访问各层资源(Access) 对于各种资源的无缝访问是现代应用的索求。而构件正是实现了标准的无缝访问。无论是访问逻辑/流程,还是访问数据/信息,甚至是访问页面/展现。构件可以封装任何已有的和新建的模块功能,通过暴露构件的服务可以被更多的使用者访问。构件的服务(Services)提供了被人访问的能力;构件的依赖(References)提供了访问别人功能的可能;而构件的实现(Implementataion)则把底层的代码、逻辑和服务一并纳入构件的标准体系中,供应用软件来无缝访问。构件提供的标准化访问能力让我们应用中遇到的集成(Integration)问题得到迎刃而解。过去那些专有化的集成和访问方式将一去不复返了,取而代之的是构件和服务的与生俱来的无缝访问和集成能力。

3:易于根据需求而改变(Change)变化是现代应用的主要特征,尤其是在中国。很多客户的需求还没明确,项目就已开始,一切都在应用开发的过程中不断沟通、不断实践、不断改变而成。因此面向构件技术必须更好地解决这个应用的关键问题即‘变化’,才能有真正的实际使用价值。构件和业务构件(Composite)可以让改变易如反掌,应用的改变可以通过重新的属性(Property)注入,重新的绑定(Binding)调整和依赖(Reference)调整,甚至于重新的实现(Implementation)及组装(Wire)。这些构件和业务构件(Composite)的属性和特征,这些面向构件的组装(Wire)、绑定(Binding)带给了我们过去任何开发技术所无可比拟的改变能力。

 

暗示:面向构件这个开发方式是最好的服务的制造方式,它所造出的构件和业务构件是全粒度的服务,为我们应对新一代应用的需求游刃有余。这就是“SOA从面向构件开始”的第二层逻辑验证。

 

SOA:面向服务的企业总体架构,服务成为企业应用的新资源层。

SOA

服务是新的一种企业应用资源,而SOA的总体企业架构成就了这种企业资源的共享、复用和被应用。各种粒度的服务通过面向构件的方法被不断地复用和应用,它们的价值也同时被得到了量级的提升。

暗示:面向构件的开发方式可以很好地利用SOA所带来的企业级服务资源的共享,并为应用所用这就是“SOA从面向构件开始”的第三层逻辑验证。

 

是与非:一切从应用出发,以应用为根本。

在我们所处的纷繁复杂的技术世界中,任何技术和产品只有被应用,并且应用的价值得到了展现,那么它本身才是有真正的使用价值,不然再好的技术和产品都不会有市场,都不会获得商业的成功,SOA和面向构件技术同样如此。所以首先我们要抓住根本,那就是‘应用’。

我们现在的业务和管理应用真正需要的是能解决他们所遇到问题的技术和产品。全流程、无缝访问和易于改变是我们提升软件生产力和质量的关键策略,这也正是在SOA的企业总体架构下,以服务为标准接口和资源,通过面向构件的应用建设方法和技术的实实在在应用价值、市场价值和商业价值。

暗示:一切从应用出发来看,这才能抓住本质。我们不难看到构件必将成为应用软件的标准构造单元,而面向构件就是最好的应用软件构造方法,并能把SOA企业架构下的企业服务资源很好地应用起来。这正是SOA从面向构件开始”。

 

远景:SOA成就企业架构,应用软件都用构件来造

把我们的时间轴放到未来的5年,SOA将从面向构件开始。利用构件这一应用软件的基础标准单元,利用面向构件的方法,才能不断构造出符合与满足SOA企业架构下的统一服务和管理。

当我们把时间轴放到更长的时间,那么面向构件将从SOA开始,从SOA开始展露面向构件的生命力。


庄子谈’Think Liquid’缺乏内容,SOA一场时装秀

发布时间:2007年09月28日 作者:朝晖

阅读次数:5517次 类别:朝晖前瞻 永久链接 Trackback 7条评论

庄子谈’Think Liquid’缺乏内容,SOA一场时装秀

 

2005年12月7日,首次以合作伙伴和观众的身份聆听了BEA公司创始人、董事长兼首席执行官庄思浩(Alfred Chuang)先生的主题演讲‘Think Liquid’。应该说我听‘庄子’先生的演讲也不下10次了,可是坦白来讲这次是最让我失望的。之所以称之为‘庄子’,表达出我对其的敬佩和尊重,可是我又在担心他的思维创新力的衰退。

CEO是公司远景和战略的制定者,又是战略执行的责任人和推动者。‘庄子’抓住了3-Tier TPM客户机/服务器的机会,又最早进入Web架构,现在开始拥抱SOA。目前我还无从判断SOA何时进入企业应用的主流技术,但是‘庄子’带领BEASOA的推动,却显得有点弱,今天的演讲未见与1年前的差别。一年前的BEA eWorld 2004已经在讲‘Deploy SOA Now/‘现在就来部署SOA’,可是今年又回到了更虚的‘Liquid,而且在过去的一年中未见在客户与合作伙伴的实际绩效出来,未见SOA的应用出来。

同样地,会上中国的两位客户代表的如实报告中也未给SOA增添什么色彩,演讲内容基本上与主题关系不大,还是TuxedoWebLogic ServerWebLogic Portal的老产品应用,也未谈到SOA和‘Think Liquid’的未来规划。可以看到中国的这些IT领先客户还是非常务实地在构建自己的业务和管理系统,而BEASOA似乎与中国还很遥远。

在绚丽的T台上,中国客户千万不要急急忙忙地穿上了华丽的标有名牌IBMBEAOracleMicrosoftSOA外衣,以期赶上世界时装界的步伐。那些对于中国客户来讲终究是美丽的外衣,我们中国客户目前阶段更需要的是自己的强身健体,把内在核心业务和管理系统建立起来。等到了强身健体的那么一天,中国客户自然需要更时尚的外衣(Service),到那时候才会有SOA在中国市场的需求。

也可参见全球IT领先杂志《信息周刊》的SOA负重前行》,了解更多大客户对于SOA的反馈,如联邦快递FedEx,花旗集团CitiGroup,平安保险等

(http://www.primeton.com/zh/marketing/WEB.ViewContent.do?blk=&subBlock=false&contentID=1552&parentBlockID=&la

SCA,软件开发的3G时代:新十年解决客户关键问题的主流技术

发布时间:2007年09月28日 作者:朝晖

阅读次数:3707次 类别:朝晖前瞻 永久链接 Trackback 4条评论

SCA,软件开发的3G时代

---新十年解决客户关键问题的主流技术

面向构件,新一代的软件开发模式和方法。那么它的规范和标准又是什么呢?现在这个答案越来越清晰:SCA。回答这个问题的时候,可能现在绝大部分的人都会说SOA,其实‘SOA’这个回答是错误的!(似乎现在的软件界不提SOA就落后了?!)但是在这个问题上‘SOA’的的确确是个错误的答案。SOA不是软件开发的方法,不是软件开发的标准。他只是一个更大的软件架构概念,有着不够明确的内涵和超强的外延,就像‘中间件’这个词一样。而SCA则不同,它有着清晰的内涵和规范标准,当然SCA也是在SOA的巨大范围之内,不过更有现实的意义。

可以这么说,随着7月初SUN公司的加入SCA/SDO国际构件标准组织,标志着Java和JavaEE将在未来五年内逐渐退出‘解决客户关键问题的主流技术’的地位。也随着SUN加入SCA/SDO组织的这一刻,Java/JavaEE的客户价值领导地位大势已去,JavaEE应用服务器将进入低价值和同质化的时代。SUN公司晚于普元软件(Primeton Technologies)加入这一组织,正说明了两点:一就是在激烈的思想斗争中,加入代表了承认领导地位的失去;二就是将逐步放弃自己的JBI。但是明眼人一看就知道,不加入就等于再造一个十多年前的Novell,进入边缘化的市场。

JavaEE在市场上的努力也有了一段时间,在新一代(SCA/SDO/BPEL)技术还没有成型前,他们还在扮演着‘解决客户关键问题的主流技术’的脚色,可是近几年来越来越显出力不从心。直接导致一大堆五花八门技术的出现来弥补其不足:Spring, Struts, Hibernate, AOP......。这些属于2.5G的技术在一段时间内解决了一些问题,不过也在带来更多的问题(彼此的集成,开源的问题等等)。

SCA/SDO/BPEL就是新十年的软件开发的主流技术,是软件开发的3G时代,之所以是主流正是他是在彻底的解决新十年客户的关键问题。将来Java/JavaEE就会成为一个企业运营需要的同质化的平台,解决分布式计算的问题,也是一个成熟的平台,就像PC机、操作系统一样,发展缓慢。另外‘2.5G’的那些技术 (Spring, Struts, Hibernate, AOP......)将会融入到‘3G’ (SCA/SDO/BPEL)中,并将逐渐退出独立发展的市场,而SCA/SDO/BPEL则发展迅猛,不断解决着客户的关键性问题:

  • 应用开发与集成的效率 -〉 业务响应能力低成本
  • 应用模块复用、变化性维护和管理 -〉 应用资产价值提升和随需应变
  • 开放性、标准化、高性能和应用监控 -〉 企业级运营管理能力


显示第 1-10 条记录,共 73 条记录 首页 前页 后页 尾页  到第 页,共 8