肥而不腻 我认为雷锋是一个伟人，所以我向雷锋学习。 我认为雷锋是一个伟人，所以我鄙视那些宣传雷锋，要别人向他学习的人。 http://ozzzzzz.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 REST讨论刚要第二版 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/200295  发表时间: 2008年06月04日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

REST讨论刚要 第二版

一年前，我推出《REST讨论刚要》第一版 。时隔一年以后，随着REST技术的推广，情况发生了变化，有些内容已经有了比较统一的答案，而另外一个内容咋原先的版本中根本没有涉及到，因此在基础进行更新。

 

A、REST是什么，这个问题虽然现在已经讨论过很多，并且多数人都会有比较统一的答案。但是其中很多内容依然还不清晰，比如是关于URI和URL的差异；REST的中的操作和业务操作究竟是什么关系；一个REST框架是应该尽量来以显式方式实现业务操作，还是应该只实现http内在的操作；如此等等。当然这些问题，我不认为有绝对的答案。但是区分其性质和应用的范围，可以让我们在实际的使用中权衡把握。

1、REST的优势是什么，哪些优势更加值得我们去珍惜。这个问题，是目前最迫切需要搞明白的。

2、由上问题的讨论，我们可以产生一个新的疑问——REST的应用究竟是应该全方位的，无所不在的；还是应该受到限制。如果有限制，那么这些限制的权衡条件是什么。

3、紧跟着，由问题2会产生另外一个十分重大，但是几乎还没有什么人意识到的问题——是不是叫REST应用在程序的内部结构和外部接口等所有地方，才是可取的；难道我们仅仅把REST的思想应用在程序直接的交互接口方面，就不行吗？这样做就成本付出如何？

4、而进一步来说，更加重要的一个问题是——当我们在使用REST技术设计我们程序的内部构造的时候，一个资源的究竟在什么粒度上用URI表达更加合适。这个问题同问题3有很多相通的地方。

5、REST的无状态约束下，如果实现状态。可以说随着REST使用的经验增多，对于REST基本理念的认识，带来的问题显得更加重要了。并且这些问题已经不仅仅是理念问题，也可以说很多其实就是一个技术问题和实现的策略问题。

 

B、REST同现在流行技术的关系，这个问题的重要性随着使用的推广有所下降。

1、REST同MVC的关系，我们已经认识到MVC虽然同REST一样可以是程序整体的组织形式，但是MVC更加关注于与显示和界面相关的部分，可以说更加关注程序的层次结构。而REST则更加关注各个模块间的协作问题。而进一步有一个问题，是不是在MVC的层之间，可以使用REST接口的方式进行衔接呢？

2、Rails中对REST的支持策略究竟是一个什么水平，其策略对开发者造成的影响究竟如何。这个方面的讨论在国外已经非常多，并且怨言也非常多。比如Rails的Routes形式，URL的构造形式，Helper的内容形式等等都有所涉及。

3、REST同Ajax的关系。虽然大家认为，Ajax同REST的配合会起到十分好的效果。但是两者并没有内在的必然联系，更不能说REST天生是绑定在Ajax上的。但是正是由此我们可以看出，REST的显示同内容的分离，使Ajax的应用更加可以得心应手，也更加值得我们去在具体的应用中使用。因此这个方面的讨论，已经进入了如果更加有效的使Ajax技术应用到REST风格的框架中去。

4、REST同数据库结构的关系。虽然关系数据库理论的开创者Codd，从一开始就强调数据同应用无关的思想，但是在使用过程中，我们一直受到性能和开发效率以及习惯的影响，从来没有完全实现这个思想。而今即使在REST这个技术中，这样的情况一定也会再次出现。而这里其实涉及一个比较隐晦的问题，那就是我们常用的MVC模式下，M所代表的是对象；而REST则强调的是资源。那么资源同业务对象到底是什么关系，是不是有所区别。而假若有区别，那么使用的ORM方式是不是也该有所不同，数据的存储方式是不是也该有所不同。这个方面讨论的不多，但是今后一定会成为一个比较微妙的讨论点。

5、REST同模板的关系。显然REST技术是同web绑定的，而模板无疑是一种最常见的关联技术。这个方面讨论也不多，但是如果将REST的URI同对象技术比较，就会有许多的地方产生影响。这个地方的讨论，现在也不多，但是并不是说这里不重要，而是说应用的深入程度还没有到达这里。

 

C、支持REST实现的技术手段。

1、Routes技术无疑是首先会被提及的。而这点在国外对Rails在这个方面上的怨言就可以看出来。而Merb的实现思想则显然同Rails不同，也是一个证据。同时其他的几种框架，也都在这个地方有自己的特点。这些方面都需要我们去认识这些框架设计者的最初设计动机进行观察和认识。

2、URI的产生方式。这个方面虽然讨论不多，但是却十分的微妙。考虑到REST更多的时候是用来规定接口，那么其命名规则就是一个问题。同时由于存在一个设计的灵活和自动生成的问题，URI究竟是手动指定，还是自动产生也是一个问题。而如果可以自动生成，那么使用什么方式也是一个问题。

3、URI和URL之间的映射关系，也十分微妙。究竟是直接的一一显式对应，还是通过某种机制间接对应呢？两者的特点是什么，应用范围又如何呢？

 

D、如何将业务映射到REST模型上去。显然一个技术必须要考虑如何同实际的商业应用挂钩，也就是如何使这个技术更好的反应业务关系。

1、资源和业务模型的关系，是不是需要建立一个业务资源模型以替代业务对象模型。

2、如何在需求分析的早期，就有意识的对将来使用REST技术构造程序做准备。

3、在使用REST技术的程序中，应该如何将业务逻辑用组合的形式实现。这个方面现在还没太多的进行过讨论，但是这个方面其实才是REST能否应用于商业应用首先需要解决的问题。

 

E、REST方式下的编码技术。

1、当然是命名约束。

2、REST方式下，自然从构架层面来说，同其他技术会有所不同。那么更加适合REST的技术构成形式是什么样的呢？

3、而进一步，REST构架下，模块的划分原则是什么。

 

F、REST下的测试。

1、如何使用现有的技术对REST程序更好的进行测试。

2、如何设计出更适合REST技术的测试工具和手段。

3、REST的性能测试手段是不是会与其他的性能测试应该有所不同，这一点是几乎还没有有任何的讨论，但是一定会出现的一个重要问题。

 

G、使用REST的团队应该如何适应这个技术。

1、SCM是不是需要做专门的调整。如果需要如何调整。

2、虽然REST的接口更加友好，但是如何控制和把握住还是需要团队内部的磨合。

3、而重构在REST也将会是一个比较微妙的问题，这是由于REST下的接口硬约束必然的后果。

4、在REST下应该如何划分任务，人员分配的策略是不是会有不同。

 

H、REST下的安全问题。这个方面有一些讨论，但是还不多。但是如果REST要普遍被接受，这个问题就显得特别突出了。可以说现在的根本问题还是在REST的基础理念的理解和认识问题，几乎所有的分歧和争论最终都可以归结到对于REST究竟该如何理解这个根本问题上来。

 


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 04 Jun 2008 23:42:28 +0800 http://ozzzzzz.javaeye.com/blog/200295 http://ozzzzzz.javaeye.com/blog/200295 把我问住了 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/198898  发表时间: 2008年05月31日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

今天晚上给小孩子们上最后的一节课，其实就是大家交流交流彼此的看法。 他们问我一个问题，你为什么很少说自己，更加很少说你自己做过什么？我一下子不知道如何回答。只好说：我确实没做过什么，也没啥值得说的。不能自夸吧，会叫你们觉得我太那个。也不能多说自己的丑事吧，也叫你们觉得我太那个。然后赶快转移话题。 其实我是怕自己管不住自己真的开始自夸，说一些自己做不到的事情。这个方面我摔过跟头，自然不能再摔。不过很多人却分不清楚这里面的轻重，或被环境、或被人所迫说一些话，虽然不能算是自夸，但是至少也是自我标榜。而既然说了，自己如何如何，不免就会有些顾及，活得就不免有些不畅快。 而我觉得除非是真的要别人接受我这个人，跟我做最最贴心的朋友，否则就没必要把自己搞的太累了。而如果是最最贴心的朋友，那些事情又没啥必要说。 而另外还一个原因，就是最近忽然发现自己这个人很冷酷无情，而刚好表面上有显得多愁善感。又加上近来又总是反思过去，不免觉得以前对别人太有些过分的举动。不过这样东西如果表达出来，又未必不是一种伪善跟做作。 大概因此，形成一种总是说观点和看法，却很少解释这个观点和看法背后的人。如此如此，不说也罢。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sat, 31 May 2008 02:50:19 +0800 http://ozzzzzz.javaeye.com/blog/198898 http://ozzzzzz.javaeye.com/blog/198898 送一句话 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/198057  发表时间: 2008年05月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

朋友要去应聘了，信心不是很足。
我有一句话：对自己没信心无所谓，只要对自己的代码有信心。

我很久之前认识一个人，他几乎不符合所有的做成功程序员的必要条件：不勤奋，不学习，不喜欢交流，不遵守纪律，不注意团结。总之你可以想到的会令他失败的条件，他都具备了。唯独他能写出好的代码，令几乎所有人都满意的代码。在出国前我们喝酒，他说：我其实对自己没啥信心，但是我对自己的代码有足够的信心。现在他还就职在NASA。依然是狂放不羁，到处树敌，依然是不可替代。

一个程序员归根结底还是要写出好的代码，所谓语言能力，社交能力，阅读能力，学习能力，等等的能力，如果没有代码能力做基石就只能是扯淡。当然如果有了代码能力，加强些别的能力会叫你更加成功。
作为一个程序员，最要紧的就是对自己的代码有信心。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Thu, 29 May 2008 00:32:17 +0800 http://ozzzzzz.javaeye.com/blog/198057 http://ozzzzzz.javaeye.com/blog/198057 愿他们这刻能够想着还有希望 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/192430  发表时间: 2008年05月13日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

愿道路早点通畅
愿他们能够继续保持希望
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 13 May 2008 00:10:46 +0800 http://ozzzzzz.javaeye.com/blog/192430 http://ozzzzzz.javaeye.com/blog/192430 自省的发现 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/190564  发表时间: 2008年05月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近在对自己的思想进行整理，同时也再次对CMM的理论和实践进行研究。而忽悠发现，其实自己的思维方式和研究问题的方法，在各个层面都打着十分深重的CMM的烙印。
这点似乎很奇怪，因为我给别人的印象似乎一直是对CMM无情批判，绝不留情的。但是其实回想起来，比较我的软件世界观的形成是随着对于CMM的研究和操作展开的。所谓三岁看小，七岁看老。思维方式一旦形成，就会成为一种最不容易改变的习惯。
同时我也发现，目前在国内推广CMM的人水准之低超乎想象，比前几年更不如。不管是民间还是企业的推广者，大多数都还不足以领导任何的流程改进。叫他们这群人去搞任何事情，不完蛋才怪。
而进一步也发现，现在的scrum也在有CMM化的趋势。很可能敏捷方法在崩溃就是从scrum这里开始的。可以说敏捷目前已经走上了前几年CMM走过的老路。
当然敏捷总有一天会成为过去，重要的是我们必须一直以一种务实和注重实际操作的态度去面对软件开发这个事情。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 07 May 2008 13:31:50 +0800 http://ozzzzzz.javaeye.com/blog/190564 http://ozzzzzz.javaeye.com/blog/190564 答复: 对比丰田生产方式，敏捷原则和实践还太嫩 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/190558  发表时间: 2008年05月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

实际上在国内由于历史原因，具有一种天生的喜欢做官的民族习惯，造就出一种总是希望做“管理”而不去做实事的“人才”。如果能抛开这个问题，专门的对管理和计划进行讨论无疑才是理想化的途径。但是可惜的是，离开这个大背景我们的讨论很可能就成了纸上谈兵。
而就XP来说，它并不是一种完全化的软件工程方法，很多开发过程中的问题并没有涉及，这也是为什么当初搞XP的那些人后来又去搞scrum的一个内在原因。也就是他们现在需要使用scrum在组织和管理方法方面于XP相协调配合。而实际上我们考察现在几乎所有的软件方法，除了RUP，即便是PSP、TSP这样的大家伙，也并没有将所有的方面都包括在内。也就是说你在实施这些方法的时候，总是要找一些这些方法外的东西将这些地方补充起来。
但是就是丰田方法来说其思想和语言同普通的管理方法是很不同的，比如它说说的质量同我们平时说的质量的概念就差别很大。但是他终究是一种组织和管理方面的方法论，自然比XP在管理和组织方面阐述的问题更多。但是说他对管理和组织就更加重视我看也谈不上。实际上丰田方法，最核心的实践是现场管理，这一点倒是和XP很类似。

我再来说说财务分析的问题，这个问题十分重要，但是我却不能充分的阐述清楚，毕竟我也才对这个问题思考和研究了一年多的时间。
引入财务分析首先并不是对公司内部的开发细节进行的，而是应该首先应用财务分析的方法去对需求和领域进行分析。比如对于项目的规划，版本发布的规划，客户协调和资源调配的规划，客户利益的预估，等方面进行财物的分析。这个分析对客户，毋庸置疑是很重要的。而通过这个分析，也可以叫开发者能够更好的理解领域和需求，更加好的衡量需求的重要性。特别是可以叫开发者，能够从各种相互矛盾的需求中选择合适的入手点。而有了这个基础，也可以事后将开发的结果进行量化分析，从而确定其开发的成果究竟如何。只有在做好这个的前提下，才谈的上去对开发流程内部进行量化和分析。
实际上在这个方式下，客户需要提出要求是战略目标和战术策略，而对于具体的需求仅仅提供的是一种参考实现。开发者做的是依据客户提出的战略目标，使用他们制定的战术策略，去分析和评估他们的具体需求实现。也就是说这个事后，需求并不是来着客户，而是来自客户定义、由开发者实现的一个判断系统。这点同传统的软件开发方式有十分重大的区别。
具体的实例可以参考http://www.douban.com/subject/1239617/ 《价值驱动的软件开发》。当然这本书说的内容仅仅是我要表达的内容的一个部分。
在此基础上，下一个环节是对开发流程的财务分析。其使用的方法，也是价值链的方法，这一点同丰田方法一致。也就是以最终提交客户的产物为参照，首先确定价值增值流程，然后确定辅助流程。并以此我基础，对各个流程进行整体分析，从而寻找价值流程最大化的途径，消除在辅助流程上的浪费。
最终我们将进入价值增值流程，对流程内部进行细分，优化环节链接，改善价值流转。也仅仅是在这个时候，那些开发团体内部产生的类似bug数之类的数据才产生效果。
当然这现在仅仅是我的一个想法，还没有应用到实际的操作中去。这是因为这个方法要求的东西太多，操作起来需求分的步骤也多。当然每一个步骤并不是复杂，只是反馈和负反馈比较多而已。
我希望我的这个答复能够叫大家能概要的明白，我最近很多言论的动机和背后的思考问题的方法。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 07 May 2008 13:11:35 +0800 http://ozzzzzz.javaeye.com/blog/190558 http://ozzzzzz.javaeye.com/blog/190558 答复: 忽悠，继续忽悠，组团忽悠... ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/188089  发表时间: 2008年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

hongsoft 写道
ozzzzzz 写道
to hongsoft
看来你对普元的历史了解还真少，有时间你去看看普元设立初期在程序员杂志上发表的文章以及在其他地方的各种宣传吧。某些人早即该反思反思自己的作为。
本身招人这个事情，是一次典型的普元操作的习惯性表演。初始的想法可能是纯真的，希望即找到合适的人，又起到宣传的作用。但是做法是愚蠢的，暴露了公司的勤于吹牛，少于思考的老毛病。而最后的结果也是悲惨的，叫人觉得普元真的真的很傻很天真。其实吹牛本没什么，在自己的一亩三分地，小声吹吹也就罢了。你们偏偏要吹的震天响，来考验大家的智商。
还有就是如果你们认为soa的技术因素要占50%，那你们就更加没啥搞头。因为以你们的开发能力，和资源根本就不足以搞这个事情。看看今天的ERP，就明白国外的大型ERP公司由于对国内的环境把握不够，产品没有针对性，基本上在国内的市场上占不了啥便宜。而类似的情况我相信在soa领域内也会再次发生，只不过就是看谁先明白过味道来，主动的先将业务分析这块搞好了。普元的问题在于其一直就没有业务咨询和行业研究这块，所以很多的地方需要补课。当然普元也有这样的想法，只不过还看不到啥行动。这个事情也不归你们管，你们也管不了。
然后就是你们必须要明白，中国的环境同国外有巨大的差距，这点IBM之流非常清楚。他们目前的重点还没有放到中国来，因为他们还需要一个研究和考察的过程。因此你会觉得他们的能力也没啥。但是一旦他们研究确定了方向和方法，也就没什么戏留给你们唱了。
还有就是soa其实对技术人员来说要学习的东西少的很，主要还是财务和商业逻辑方面的东西，你们内部搞培训，这个方面一定不会是重点。因为对你们这些技术人员来说，从头开始学一门完全不同的学科是没有太多必要的，但是基本的理念和概念应该清楚。这一点你们做的还很不好，可以说从上到下的不好。而客观的说国内的企业在项目规划和信息系统规划方面都做的不好，不能给客户提供强有力的支撑，这也是实事。这一点不是普元一家公司独有的问题，是普遍存在的问题。
还有就是你们的那个工作流很有特点，但是其实它跟soa的关系不大。这个是因为soa的资源更加成元形态，流程更加看重的是可跟踪和扩张行以及高度的伸缩性。而工作流产品的特点在于可以将流程定义的更加便宜，更加舒服。但是soa的流程更加强调其环境适应性，强调的是即时的可调整性和高度的可变性。说白了soa的目标是打破企业以流程定经营，以流程定岗位，以流程定管理的这个经营模
式。从而建立其一个类似生物体的，高度协调，高度多进程协作，高度组合型的新类型企业。只不过在国内用户还没这个意识，也没有这个准备搞这个事情。而即使搞，跟工作流产品的关系也不大。而且说白了，soa就是要把工作流产品送回坟墓，而不是加强工作流产品的市场份额。可以说soa的基础技术更多的是商业BI和撮合系统。


1）招人的事情：我们的确是需要这些人，分配到每个部门都有定额；从研发的定额人数来推测，全公司是需要100人的。
2）soa的技术因素要占50%，我们的确很难独立搞。所以我们现在的策略是：我们自己主要做技术基础平台，联合国内的
行业软件公司，他们在我们
平台上做业务层的 “小平台”（这个才是真正和SOA相关的技术部分）。 OEM策略是我们公司去年下半年推广的，已经有了部分效果。
3）是的，国外公司很强大。实际上我认为这个才是 primeton存在的唯一理由。去做一个SI，老板赚几千万，意思并不大。
4） 我部分理解你说的“soa就是要把工作流产品送回坟墓”的意思，这个问题我们内部讨论过。没有改变的原因是：a)现在还需要现在的产品 b)现在并没有找到做出更好产品的思路（实际上我认为给现在的工作流产品打80分是没有问题的）


BTW： 本帖 我说的全部话，都是我个人的理解，并不代表公司。

第一招人这个事情，你们搞的不好。这里不是说你们缺少不缺少这些人，而是你们招人这个事情运作的不好，给人一种很蠢的感觉。其次你们其实并不缺人，因为你们内部的人的能力都还大大的没发挥出来。说白了soa其实核心思想是最大化企业资源的利用度，最高效的执行业务，最大限度的减少浪费。这个方面你们自己做的就很差，至少内部员工的内力根本就没得到啥大部分的发挥。
第二你们这个想法就很有问题。你们希望做平台，然后给别人来唱戏。而你们好好看看这几年你们在市场上的销售业绩。其实你们的市场能力还是很强的，销售能力也很强，产品也还不错。但是为啥这么读能人，搞这么一个好产品，最后年年亏损呢？其实根本上来说还是你们这个战略定位存在问题。你可以设身处地的把自己放在一个小软件公司的位置，想想为啥他们要用你的产品，他们真的有必要用你们的产品吗，他们真的能用你们的产品吗？这些事情根本就不需要思考。说白了你们公司的战略头脑还停留在当初搞cmm前的状态。
第三国外公司很强大，这其实就是普元这样公司没有必要存在的一个根本理由。一个国家需要信息系统的安全和掌控能力，依靠的是实际的积累和内在的能力，而不是依靠概念的炒作和烧钱的运作形式。特别是在国内的soa这个事情上，跟着国外的公司炒作是根本没前途的。而你看看你们的资料和各种说法，又有哪一点是自己具有国内独特的针对性的呢？归根结底是你们这个公司到现在还没搞清楚应该如何经营，如何运作。说白了就是对软件行业理解太差，对自己的领域理解更差。
第四个问题其实是你们长期依赖于外界的潮流，而没有自己的战略高度的必然结果。

其实普元的问题最后归结起来就是战略问题，而不是战术问。可以说普元的绝大部分员工都是出色的，特别是那些做事情的人都是很有些能力的。但是问题在于普元想事情的人能力有缺陷，战略布局和战略目标有问题。这些问题你们这些基层人员也解决不了，也影响不了。
其实你们应该好好研究研究公司的发展历史，看看公司的这么短短的几年中都发生了什么事情。可以说你们真的有时候傻的可爱，傻的无与伦比。总是做别人偷驴你们拔蹶的事情，是搞不好企业的。其实你们自己也知道这个问题，但是一遇到机会就总是自觉不自觉的在老地方犯老错误。真得拿你们的公司没办法评论。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 29 Apr 2008 15:42:02 +0800 http://ozzzzzz.javaeye.com/blog/188089 http://ozzzzzz.javaeye.com/blog/188089 答复: 忽悠，继续忽悠，组团忽悠... ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/188088  发表时间: 2008年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

to hongsoft
看来你对普元的历史了解还真少，有时间你去看看普元设立初期在程序员杂志上发表的文章以及在其他地方的各种宣传吧。某些人早即该反思反思自己的作为。
本身招人这个事情，是一次典型的普元操作的习惯性表演。初始的想法可能是纯真的，希望即找到合适的人，又起到宣传的作用。但是做法是愚蠢的，暴露了公司的勤于吹牛，少于思考的老毛病。而最后的结果也是悲惨的，叫人觉得普元真的真的很傻很天真。其实吹牛本没什么，在自己的一亩三分地，小声吹吹也就罢了。你们偏偏要吹的震天响，来考验大家的智商。
还有就是如果你们认为soa的技术因素要占50%，那你们就更加没啥搞头。因为以你们的开发能力，和资源根本就不足以搞这个事情。看看今天的ERP，就明白国外的大型ERP公司由于对国内的环境把握不够，产品没有针对性，基本上在国内的市场上占不了啥便宜。而类似的情况我相信在soa领域内也会再次发生，只不过就是看谁先明白过味道来，主动的先将业务分析这块搞好了。普元的问题在于其一直就没有业务咨询和行业研究这块，所以很多的地方需要补课。当然普元也有这样的想法，只不过还看不到啥行动。这个事情也不归你们管，你们也管不了。
然后就是你们必须要明白，中国的环境同国外有巨大的差距，这点IBM之流非常清楚。他们目前的重点还没有放到中国来，因为他们还需要一个研究和考察的过程。因此你会觉得他们的能力也没啥。但是一旦他们研究确定了方向和方法，也就没什么戏留给你们唱了。
还有就是soa其实对技术人员来说要学习的东西少的很，主要还是财务和商业逻辑方面的东西，你们内部搞培训，这个方面一定不会是重点。因为对你们这些技术人员来说，从头开始学一门完全不同的学科是没有太多必要的，但是基本的理念和概念应该清楚。这一点你们做的还很不好，可以说从上到下的不好。而客观的说国内的企业在项目规划和信息系统规划方面都做的不好，不能给客户提供强有力的支撑，这也是实事。这一点不是普元一家公司独有的问题，是普遍存在的问题。
还有就是你们的那个工作流很有特点，但是其实它跟soa的关系不大。这个是因为soa的资源更加成元形态，流程更加看重的是可跟踪和扩张行以及高度的伸缩性。而工作流产品的特点在于可以将流程定义的更加便宜，更加舒服。但是soa的流程更加强调其环境适应性，强调的是即时的可调整性和高度的可变性。说白了soa的目标是打破企业以流程定经营，以流程定岗位，以流程定管理的这个经营模式。从而建立其一个类似生物体的，高度协调，高度多进程协作，高度组合型的新类型企业。只不过在国内用户还没这个意识，也没有这个准备搞这个事情。而即使搞，跟工作流产品的关系也不大。而且说白了，soa就是要把工作流产品送回坟墓，而不是加强工作流产品的市场份额。可以说soa的基础技术更多的是商业BI和撮合系统。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 29 Apr 2008 15:40:53 +0800 http://ozzzzzz.javaeye.com/blog/188088 http://ozzzzzz.javaeye.com/blog/188088 答复: 忽悠，继续忽悠，组团忽悠... ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/188087  发表时间: 2008年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

hongsoft 写道
ozzzzzz 写道
fins 写道
其实普元如何看待soa 如何利用soa 这个往往不是客户关注的问题
客户关注的是 普元的产品是否能够开发出帮助企业解决实际问题

目前 普元的产品主要还是在开发和维护方式上带给了客户很大的价值.

正如o6z所说, "soa的前提条件更多的是商业分析方面的，更多的是对企业资源以及资源信息化测算的能力".所以普元的产品到底是不是SOA的,以及用这个产品开发出来的东西到底是不是SOA的, 不取决于普元的技术和产品 而是取决于客户的业务和资源,以及对自身业务和模式的分析.

而普元在帮助客户梳理业务 规划服务这方面 确实还有很长的路要走.
不过庆幸的是普元自身也已经意识到了这个问题.


其实普元里面的人可以自己反思一下，看看这个所谓的高科技公司最近几年的业绩同普通的制造也比较比较，是不是有脸红的感觉。一个公司如果联给自己创造价值的能力都如此，还说什么给客户提供价值呢？
我是衷心希望普元能够在这条务实求发展的路上好好的发展下去，而不希望还跟那些所谓的国产软件核心企业一样的套取人民的税收过日子了。
归根结底soa就如同erp一样是一种具体而非纯概念，应用广泛而深入，对企业的经营和社会的发展会带来深刻影响的一种潮流。这样的东西，需要的是务实而协作的人去完成，是要靠做具体的事情去完成的。现在就看普元是否有这个魄力和能力来个大调头，勇于否定前几年自己的做法和说法了。



这个是应该让我们去反思的。我认识的一个卖衣服的公司，直营部4个人，去年一年的sales额和 primeton全年的一样。
但是，我认为要看的 发展前景，希望今年和明年的数字可以说明一点问题。

我待的第一个公司是HK上市的，电信行业的SI。 这个月听到 它的 广州分公司 解散了。
其实 软件行业，企业级应用方面，能够有很好营利的，并不多，国内情况基本如此。



这个就是你了解的少了。其实国内有很多软件公司的盈利能力很强的。至少我知道几家公司人比你们少很多，年应用额跟你们不相上下，以至于可能还比你们多一点。
这些公司都是小公司，在一个狭小的行业内部，不为多数人知道。但是他们的日子过得很舒服。只不过他们定位，决定了他们只能在一个狭小的空间生存，不能扩大到一个更大的环境。这一点在国外其实也很普遍存在。
而你们的公司在开办的时候定位就有问题，布局也有问题。形象还有问题。你们制定了一个宏伟的目标，但是缺少实现这个目标的能力和计划。更加严重的问题是前几年因为你们的背景，你们过多的希望通过政府解决问题，而较少的在技术和实际的运营上下功夫。

听别人说自己的公司不好不会很舒服，但是已经不是一个普元内部的人跟我说，普元就应该骂，不骂到一定程度，某些人就是不清醒。这个事情昨天有人跟我说，今天有人跟我说，但愿明天不要再有人跟我说了。
说实际的我是不想太多的说普元的问题，但是一看到普元的做法，听到普元的言论就觉得那么刺耳。并且我骂一次，最终还就有人鼓励我一次，你说这事情奇怪不奇怪。

比如我给你举了谁都看的见的例子，叫你看看普元的形象是咋被你们公司内部的人破坏的。
普元不是在招人吗，号称要招100位java人才。开始在csdn上的说法是，要招100为高手。这点叫不叫你想起了top？现在这个说法改了，叫招100名java人才。不管怎么说，你们给人的感觉还是要招一些水平不错的人。
那么你可以给我们算算涨，这100人到位后一个月的工资是多少，办公费是多少，其他成本支出又是多少，管理费用又是多少。再考虑考虑用于安抚原有职工的费用是多少，这样一年下来你们又要投入多少。而你们去年一个整年的营业额又是多少。你自己可以比照比照。
就这么一个最最简单的小事情，你们都搞出这么大的漏洞来，捅娄子的能力真的让人无法相信。
而你们这个公司这样搞了几年，你觉得在人们心目中的形象会是一个什么样子。就更别提你们搞的那个论剑，叫人背后如何评价你们公司了（花钱找骂的公司在软件这个行业可以说是绝无仅有的了）。
这样的事情你们普元内部其实早就有人有看法，只不过大家都不说而已。这样的事情一天不停止，一天你们普元就不会有啥好形象展现给大家。即便你们再努力，就这么一搞两搞，也就都白搭了。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 29 Apr 2008 15:40:19 +0800 http://ozzzzzz.javaeye.com/blog/188087 http://ozzzzzz.javaeye.com/blog/188087 答复: 忽悠，继续忽悠，组团忽悠... ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/188086  发表时间: 2008年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

hongsoft 写道
ozzzzzz 写道
fins 写道
其实普元如何看待soa 如何利用soa 这个往往不是客户关注的问题
客户关注的是 普元的产品是否能够开发出帮助企业解决实际问题

目前 普元的产品主要还是在开发和维护方式上带给了客户很大的价值.

正如o6z所说, "soa的前提条件更多的是商业分析方面的，更多的是对企业资源以及资源信息化测算的能力".所以普元的产品到底是不是SOA的,以及用这个产品开发出来的东西到底是不是SOA的, 不取决于普元的技术和产品 而是取决于客户的业务和资源,以及对自身业务和模式的分析.

而普元在帮助客户梳理业务 规划服务这方面 确实还有很长的路要走.
不过庆幸的是普元自身也已经意识到了这个问题.

意识到了，不等于就开始着手解决问题了。
实际上提供企业的业务咨询需要具备一些外在的素质和形象的，这就是为啥成功学的老大只能去给那些小商业上课，而不能去给那些大企业做咨询一个道理。也就是说想进入这个领域，就要表现出足够的务实和追求实际效果的精神，追求价值而不是追求响动的做派。至少目前普元还没有这个能力，也没有这样的给人的感觉。在这个时候搞唱soa，仅仅就是一种蹩脚的宣传罢了。
实际上普元在转向，在务实，在追求实际效果。但是普元中不是所有的人都看到了这一点，也不是所有人都希望这样做。普元是不是能够克服这些内部的阻碍，从而真正的成为一家高科技公司，还需要我们再观察。不过我可以断定，有些人就是不能适合这样的转变，最终的结果不是他们离开，就是普元从新回到原来的老路上去。
其实普元里面的人可以自己反思一下，看看这个所谓的高科技公司最近几年的业绩同普通的制造也比较比较，是不是有脸红的感觉。一个公司如果联给自己创造价值的能力都如此，还说什么给客户提供价值呢？
我是衷心希望普元能够在这条务实求发展的路上好好的发展下去，而不希望还跟那些所谓的国产软件核心企业一样的套取人民的税收过日子了。
归根结底soa就如同erp一样是一种具体而非纯概念，应用广泛而深入，对企业的经营和社会的发展会带来深刻影响的一种潮流。这样的东西，需要的是务实而协作的人去完成，是要靠做具体的事情去完成的。现在就看普元是否有这个魄力和能力来个大调头，勇于否定前几年自己的做法和说法了。


应该说，我们是意识到了，也开始着手在解决这个问题。
我们07年给 建行做过一个SOA方面的咨询，是全行级的，不知道能否如o6z的“大企业”的法眼。
实际上，我在这里的技术开发工作，最大的一个感觉就是“ 足够的务实和追求实际效果”，我们所有的设计，包括每
一个eclipse插件中的操作，都是从 用户的角度去考虑问题的；去年搞了一个 MSF的过程学习，我作为一个PM，也是努力做到“从用户的场景”出发来考虑 设计和实现问题。
实际上我认为，如果 开发人员感觉不到 EOS对他带来的方便性，他没有理由去用EOS。

其实建行的项目你还真的需要再去研究研究，那个里面的东西还很多。具体的情况我就不多说了，你既然参与了自然心里有数。
而你觉得你们很务实和追求实际效果，我觉得应该是实情。并且我的接触和得到的信息也一再验证普元里面的人都是在踏踏实实的干事情。但是并不是说你们都实际了，务实了，你们这个企业就自然的踏实了务实了。而实际上就是你们这些的踏实和务实，才叫普元在人们心目中的形象成为了一个只能吹牛，做不了事情的典型。why？因为你们背后的世界观是有问题，启动的时候的想法是有问题的，在人们心目中造成的形象是有问题的。并且你们一再强化你们的粗俗和搏傻的形象，这不能不说是一种悲哀。实际上je上面同你们接触过的人是不少的，他们对你们的看法是一致的。你应该能够通过私下的渠道去了解真实你自己。
而落实到soa上面来说，根本上的问题在于你们内部就对这个概念没啥理解和判断。其实soa所要求的不是首先你们去提客户考虑，而是要首先要客户有一种将业务流程解构为元流程要素和进行再工程重装的思想，是一种客户思维方式的变革。也就是说首先要叫客户改变他们对业务的看法，对流程的看法，而不是叫他们给你们提需求。这也就是为什么soa的重点在业务咨询，而不是技术实现的根本所在。而可以说如果你们能有这样的能力，你们这些做开发的就可有可无了。
而进一步说你们的EOS其实根本就跟soa扯不上啥瓜葛，你们现在生拉硬扯的将他们拉在一起，显得十分的笨拙。不要看IBM、甲骨文他们在宣传所谓的soa产品，你们就觉得自己也能了。他们那么做是因为他们的客户有那么多已经存在的资源需要他们提供一个整合的途径。而你们没有那么多的客户资源，也没有那么多的能力去搞定这些资源。在这个时候贸然宣传soa，说好听点叫附庸风雅，说不听的叫说你可以自己去想。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 29 Apr 2008 15:39:19 +0800 http://ozzzzzz.javaeye.com/blog/188086 http://ozzzzzz.javaeye.com/blog/188086 答复: 忽悠，继续忽悠，组团忽悠... ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/188085  发表时间: 2008年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

hongsoft 写道
ozzzzzz 写道

我说的普元的大改变，首先就是其思想意识必须改变，其次就是产品的定位也需要改变，最后才是形象和宣传的改变。
知名公司会受到很大的争议这点不假，但是要看看他们受到的争议究竟是什么，看看他们的战略思想同他们的战术手段究竟是不是协调合拍。
而就如同你所说，你在内部都觉得普元其实不是一家soa味道很浓的公司，而他给人的感觉和希望给人的感觉却完全相反。这就是典型的战略和战术的不协调的证明（当然有你这个想法的普元人不是一个）。而实际上普元坏就坏在一小撮人身上。
“汇聚一流的人才,努力开发出客户认可的产品”这个说法很好，但是普元究竟是怎么做的呢？而特别是你一小部分人又是如何做的呢？他们除了会喊口号，制定出大而空不切实际的计划，有做了多少实际的事情呢？看看你们的市场定位就知道了，你们已经从开始的雄心勃勃的产品公司转变为以产品促项目的项目公司这个实际情况，就能明白你们这些年究竟做了些什么事情。可以说你们从来就没有真正的理解到这个本究竟意味着什么，就如同你们自己也还不能理解soa究竟意味着什么一样。




战略和战术的不协调吗？ 实际上我个人的看法是这样的：

公司在市场部有市场部的战略和战术，执行得非常好（国内基本没有软件公司有这样的执行力）；
公司在研发和产品有 战略和战术，执行得也很好。（我认为有85分）。

市场部/产品开发 间可能没有 融合好，这个我也有这个感觉，但是 最近变化很大。（最起码 4月的这个会，讲的内容
没有 乱说）


BTW：大家对照产品看PPT，请下载EOS的最新版的产品，用5.x的确是看不出PPT的内容的。
最新版变化非常大。

你们公司的市场部门是国内独一无二的傻瓜构成的，他们的思想和做法给普元在大家心目中的形象造成的危害，只要普元内部的少部分人不知道（当然也可能是不愿意知道）。经过这些年的一再炒作，普元在国内技术社区的负面形象可谓根深蒂固。
这里的问题，并不仅仅在具体的执行层面，高层的战略规划和布局也应该存在严重的问题。可以说这样一个规模的公司，每年的投入这么多，产出这么少在国内是罕见中的罕见。能做到这一点，败家的能力可谓是强而又强。
现在普元内部的一些人不仅不检讨自己的所作所为，还变本加厉的搞假大空，这不能不说是一种病态的做法。可以说几乎行业人所有的人都看到普元的问题所在，就只有普元内部的一些人还是不认账。这里面的是非曲直，大家心理自然有数。
至于说普元的研发能力实在是低下，搞了几年像样的东西一直出不来。难道今天搞个新版本就忽然有了天翻地覆的变化了？其实答案根本不用去想，只要回顾一下方法论大战的经过，看看那些当初的CASE厂家的遭遇，早就该明白了。而你在看看现在那些相关的厂家的盈利模式是什么，就知道当初普元的做法多么愚蠢。而选择这么一个方向，即便普元的技术人员素质再高，能力再强又能有啥用途呢？
而普元的问题还在于，前几年乱讲习惯了。今后即便普元老实了，本分了，他讲话的内容大家一样会觉得水分很大。况且有些人说话吹牛惯了，叫他不吹牛是不太现实的。
而进一步说soa的基础思想在技术上的要求是能够把各种异构的资源，以一种通用的形式展现和协调起来，从而形成一种能够在技术上比较便宜的组织和部署方式。在这个领域只有那些有深厚用户基础的公司，才可能有机会进入。普元这样一个新公司，才那么几个客户就妄图在这个领域施展拳脚简直就是笑话。一个问题是这样做投入的资源会很多，另外异构问题是遇到的知识产权等问题的麻烦也很多。而即便解决了这些难题，soa的根本难点和大部分工作还是没有解决。在这样一个背景下，普元还在那里对soa说三道四，是在给自己做广告，还是在给IBM做广告呢？
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 29 Apr 2008 15:37:22 +0800 http://ozzzzzz.javaeye.com/blog/188085 http://ozzzzzz.javaeye.com/blog/188085 答复: 忽悠，继续忽悠，组团忽悠... ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/188083  发表时间: 2008年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

hongsoft 写道
ozzzzzz 写道

问题的核心并不在此，因为就如同我2004年认识到的，soa的前提条件更多的是商业分析方面的，更多的是对企业资源以及资源信息化测算的能力。而所谓的soa产品即便其真正的是反应了soa的思想的，也不是关键环节，更加不是关键技术。
直白的说普元的宣传和做法都是跟soa没啥关系的，就如同当初他们宣传的构件同组件没有关系一样。现在的普元的做法可以说是前几年吹牛加乱搞的后遗症，我相信随着其逐步走上务实和看重技术的道路，这个问题会得到解决。并且我也看到了一种这个方向的苗头。不过以后什么天涯论剑这样的活动还是少搞，这样的活动只能叫人们更加记住那个只会高呼口号，名不副实的普元。
至少在中国这样的做法只能说是反宣传。


我认同你说的“soa的前提条件更多的是商业分析方面的”观点，但是，你要是完全否认SOA产品对SOA思想的作用，
我不同意。

我希望你这样说是因为你
没有看过EOS的最新版（因为还没有发布，你看到的可能性也比较小，除非你有其他的渠道）。


天涯论剑 你没有去，我也忘记当时有无请你了。我个人认为，效果是很好的。

我个人看法是：会前 去的行业内的人，有100%都是你这个想法；会后，应该有90%的想法发生了很大变化。
这个活动，目标就是这个效果。

可惜我看到的情况是，会前觉得普元在吹牛的人会后觉得这个吹牛的水平在下降。会前不知道普元在吹牛的人，会后觉得普元在吹牛。核心问题在于普元自己对soa就没有啥理解深度，根本和IBM等外企的吹牛不在一个层次上面。而华山论剑我没有去，你们也没请我去，而且请了我也不会去。并且你不知道那些人究竟是怎么说这个事情，你要是知道了，你也就不会再有心情在这里说这个事情了。说实在的，普元的最大问题就是如你所表现的，自我感觉良好。
但是为什么会有这样的情况发生呢？其实原因很简单，soa95%以上的工作是在做业务流程的分析解构和重整，技术层面的支持只占5%不到。这点同ERP类似，也就是你那个产品和开发能力在这个事情上根本就是最最不重要的那个部分，想靠这个打开局面简直就是开玩笑。而你们还一再吹你们普元的soa如何如何，你们是在渲染你们的不足，还在考验听众的能力？
而且你觉得一个声称可以造银弹的企业，他们的产品究竟能够给客户产生多少价值，才能令客户满意呢？这个事情不解决，你觉得人们对普元的看法会从根本上改变吗？
在落实到技术层面，你觉得一个soa产品究竟应该包括些什么内容呢？这些内容又能有多少是能够辅助大家对业务流程进行分析和测试，对业务元素进行重整和再分配？如果你们真的有这个能力，你们觉得是在这里继续开发软件过苦日子，还是去开拓商业咨询呢？
这样的问题用脚后跟思考都能想到答案吧。
说实在的，普元追soa纯粹是浪费钱财，是前几年胡搞的后遗症。至少在soa这个领域，普元联金蝶都差距很远，就别提那些国外大佬了。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 29 Apr 2008 15:35:20 +0800 http://ozzzzzz.javaeye.com/blog/188083 http://ozzzzzz.javaeye.com/blog/188083 答复: 忽悠，继续忽悠，组团忽悠... ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/188082  发表时间: 2008年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

fins 写道
ozzzzzz 写道
现在就看普元是否有这个魄力和能力来个大调头，勇于否定前几年自己的做法和说法了。


没太明白你最后的意思
你是说 普元应该在业务和市场宣传上做出改变
还是指普元的产品定位做出改变?
普元是开发产品的公司
这个产品归根结底就是一个工具 它可以帮助企业"快速的开发出灵活易管控"的项目

我想普元产品的这个定位应该不会变吧?

一个开发产品的公司, 产品定位不变, 那么需要变的是什么呢?


我说的普元的大改变，首先就是其思想意识必须改变，其次就是产品的定位也需要改变，最后才是形象和宣传的改变。
知名公司会受到很大的争议这点不假，但是要看看他们受到的争议究竟是什么，看看他们的战略思想同他们的战术手段究竟是不是协调合拍。
而就如同你所说，你在内部都觉得普元其实不是一家soa味道很浓的公司，而他给人的感觉和希望给人的感觉却完全相反。这就是典型的战略和战术的不协调的证明（当然有你这个想法的普元人不是一个）。而实际上普元坏就坏在一小撮人身上。
“汇聚一流的人才,努力开发出客户认可的产品”这个说法很好，但是普元究竟是怎么做的呢？而特别是你一小部分人又是如何做的呢？他们除了会喊口号，制定出大而空不切实际的计划，有做了多少实际的事情呢？看看你们的市场定位就知道了，你们已经从开始的雄心勃勃的产品公司转变为以产品促项目的项目公司这个实际情况，就能明白你们这些年究竟做了些什么事情。可以说你们从来就没有真正的理解到这个本究竟意味着什么，就如同你们自己也还不能理解soa究竟意味着什么一样。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 29 Apr 2008 15:33:51 +0800 http://ozzzzzz.javaeye.com/blog/188082 http://ozzzzzz.javaeye.com/blog/188082 答复: 忽悠，继续忽悠，组团忽悠... ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/188081  发表时间: 2008年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

fins 写道
其实普元如何看待soa 如何利用soa 这个往往不是客户关注的问题
客户关注的是 普元的产品是否能够开发出帮助企业解决实际问题

目前 普元的产品主要还是在开发和维护方式上带给了客户很大的价值.

正如o6z所说, "soa的前提条件更多的是商业分析方面的，更多的是对企业资源以及资源信息化测算的能力".所以普元的产品到底是不是SOA的,以及用这个产品开发出来的东西到底是不是SOA的, 不取决于普元的技术和产品 而是取决于客户的业务和资源,以及对自身业务和模式的分析.

而普元在帮助客户梳理业务 规划服务这方面 确实还有很长的路要走.
不过庆幸的是普元自身也已经意识到了这个问题.

意识到了，不等于就开始着手解决问题了。
实际上提供企业的业务咨询需要具备一些外在的素质和形象的，这就是为啥成功学的老大只能去给那些小商业上课，而不能去给那些大企业做咨询一个道理。也就是说想进入这个领域，就要表现出足够的务实和追求实际效果的精神，追求价值而不是追求响动的做派。至少目前普元还没有这个能力，也没有这样的给人的感觉。在这个时候搞唱soa，仅仅就是一种蹩脚的宣传罢了。
实际上普元在转向，在务实，在追求实际效果。但是普元中不是所有的人都看到了这一点，也不是所有人都希望这样做。普元是不是能够克服这些内部的阻碍，从而真正的成为一家高科技公司，还需要我们再观察。不过我可以断定，有些人就是不能适合这样的转变，最终的结果不是他们离开，就是普元从新回到原来的老路上去。
其实普元里面的人可以自己反思一下，看看这个所谓的高科技公司最近几年的业绩同普通的制造也比较比较，是不是有脸红的感觉。一个公司如果联给自己创造价值的能力都如此，还说什么给客户提供价值呢？
我是衷心希望普元能够在这条务实求发展的路上好好的发展下去，而不希望还跟那些所谓的国产软件核心企业一样的套取人民的税收过日子了。
归根结底soa就如同erp一样是一种具体而非纯概念，应用广泛而深入，对企业的经营和社会的发展会带来深刻影响的一种潮流。这样的东西，需要的是务实而协作的人去完成，是要靠做具体的事情去完成的。现在就看普元是否有这个魄力和能力来个大调头，勇于否定前几年自己的做法和说法了。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 29 Apr 2008 15:32:32 +0800 http://ozzzzzz.javaeye.com/blog/188081 http://ozzzzzz.javaeye.com/blog/188081 答复: 忽悠，继续忽悠，组团忽悠... ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/188080  发表时间: 2008年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

hongsoft 写道
Readonly 写道
hongsoft 写道
你可以不相信primeton的SOA（这个我估计说服不了你），但是不能不相信SOA这个思想。

您说的真是太正确了，偶来补充几句：
引用

SOA一点也不复杂，只是你们太蠢了

去年，SOA使得土耳其的国民生产总值提高了10倍

SOA是OSA的一个变形词，西班牙语中OSA是母熊的意思，在西班牙语社区有个众所周知的事实：母熊在业务流程建模以及优化可重用IT资源方面做得比其他任何冬眠动物都要好。

更多请看 http://www.soafacts.com/


hongsoft 写道
SOA不SOA没有关系，我们都是想 做出好的软件，能够帮助到用这些软件的人。

留存作证，这意味着：
SOA不SOA没有关系，我们都是想更好地卖出我们的软件，SOA只是用来更方便地忽悠




SOA不SOA没有关系，你也可以为SOA取个其他的名字，但是它的思想，是我们都需要去学习的。

我们做技术的，要是真的对“忽悠”的相信程度 到 70%，其实还不如别做技术了；搞搞 其他的行业，也能赚到钱，或者
你应该去做sales。 不过我认为，靠“忽悠”做sales，也不可能长久。

我依然相信soa的思想是需要很多人学习的，但是在中国学习的一个最重要任务就是将普元最近几年在业界散布种种谬论清楚的揭示出来，将这样的公司的作为清楚的揭示出来，将讲了这些话的人清楚的揭示出来。
就soa来说，不管如何搞，如何做，都是要以业务为主线，以流程为线索，以技术为辅助。像普元这样没有啥业务根基，也习惯于空喊口号的企业，是不可能给企业提高好这样的针对企业的基础经营资源和环境提供好服务的。
可以说普元近些年来的作为已经给大家普遍的建立其一种只会喊口号，而于其实际的能力差距显著的印象。之所以有这样的普遍的看法，归根结底是普元自己仅仅希望通过其背后强大的政府资源，而不想真正的在技术和内部管理上下功夫，并且急于扩大规模，搞炒作的必然结果。
在今天普元的那套所谓构件论已经失去了市场，今天希望再借soa这个概念再次炒作一把，妄想再忽悠点项目。可惜人们也是有学习能力的，不会总是被忽悠。
当然最近普元也在转向，也在务实化发展。不过由于前期的习气和习惯不是那么容易改的，所以依然忘记不了炒作和忽悠。只要这样的习气不改变，这样的习惯不改变，这样的人不离开，普元想成为一个务实而受人尊重的企业就十分困难。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 29 Apr 2008 15:31:39 +0800 http://ozzzzzz.javaeye.com/blog/188080 http://ozzzzzz.javaeye.com/blog/188080 答复: 忽悠，继续忽悠，组团忽悠... ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/188079  发表时间: 2008年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

fins 写道
难道企业真的就想很多人想象的那样, 开发商找个名词一忽悠它,它就上当吗?
要真是那样,IT这行早就不是现在的格局了.

企业选择产品的标准还是要看这个产品是否能够帮助它们解决问题.

一个企业,选择一个SOA产品,绝对不是因为这个产品自称基于SOA思想, 否则这个企业早就垮掉了.

一个企业负责采购IT产品或者是招商的领导,他们难道不想保住自己的官职吗?难道不想立功往上爬吗? 难道花大钱买一套垃圾产品能够帮助他们实现自己的目的吗?

如果IT圈子真那么黑暗, 开发商门把做广告的钱用来贿赂相关的领导岂不是更有效?

那些认为企业的信息化建设就是"钱权的交易,政治的游戏"的人,你们是否可以考虑离开这个肮脏龌龊的IT圈子呢?


当然 不排除确实存在各种黑暗的情况,
但是作为开发人员,最主要的事情还是提高你的技艺,
作为开发商,最主要的事情就是做好你的产品
否则 你连贿赂忽悠的机会都没有




问题的核心并不在此，因为就如同我2004年认识到的，soa的前提条件更多的是商业分析方面的，更多的是对企业资源以及资源信息化测算的能力。而所谓的soa产品即便其真正的是反应了soa的思想的，也不是关键环节，更加不是关键技术。
直白的说普元的宣传和做法都是跟soa没啥关系的，就如同当初他们宣传的构件同组件没有关系一样。现在的普元的做法可以说是前几年吹牛加乱搞的后遗症，我相信随着其逐步走上务实和看重技术的道路，这个问题会得到解决。并且我也看到了一种这个方向的苗头。不过以后什么天涯论剑这样的活动还是少搞，这样的活动只能叫人们更加记住那个只会高呼口号，名不副实的普元。
至少在中国这样的做法只能说是反宣传。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 29 Apr 2008 15:30:18 +0800 http://ozzzzzz.javaeye.com/blog/188079 http://ozzzzzz.javaeye.com/blog/188079 答复: 忽悠，继续忽悠，组团忽悠... ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/188076  发表时间: 2008年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

到今天我依然坚持2004年我的观点——soa更多的是一种商业技术，而不是软件开发技术。
而就如同dlee那erp跟soa做对比，我认为今天的soa实际上是具有悠久历史的mis的一种发展。
而我们现在来分析一下真正推行soa见到成效的企业的例子，其实也就是IBM、甲骨文和SAP这些即有技术背景，同时又有强大的商业咨询能力的公司。而普元之类的公司，只能算作跳梁小丑一样的二角色，在忽悠罢了。
而实际上如果你有时间重读我当初的话，里面就已经阐述清楚了，soa更多的是为了配合商业流程的快速重构和应对多变的商业环境的产物。这个事情企业的流程是柔性的，风格是多样化的，服务的对象也是非格式化的。也就是说昨天的那种大规模生产，大规模铺货，大规模销售的模式，已经让位为——更加强调客户定制，更加有针对性的小区域和小群体铺货，更加针对性的销售，一句话就是更加具有服务的针对性。在这样的情况下，企业即便希望开发一套新系统来满足这样的要求，也会面临许多需要能够更多可以定制，可以快速伸缩性部署，可以更加有效益的信息流转，更加紧密的多流程协调一致的新系统。这样的系统不仅仅需要健壮，也需要数据和部署以及维护和改变的更加灵活快速。
而实施soa的前提条件是必须具有强大的企业业务分析能力和再造能力，已经对支撑此应用对系统要求的测算能力。只有具备了这样的业务分析能力，才能把握住企业运转的真实流程；只有具备这样的再造能力，才能形成一种柔性的企业生态系统；只有具备这样的测算能力，才能把握住企业信息建设的关键环节的约束性指标。
而技术的实现仅仅是在前面这些关键性工作驱动下的一种实现的手段，具体的方式可以多种多样。但是其成本构成和资源的配置必须要能够合乎关键环境的约束性指标。
可以说soa更加看重的是企业对信息系统的规划能力，是企业高层的战略考量的一种在信息系统建设方面的考量。而其针对开发人员的内容相对较少，针对软件公司的技术内容也相对较少。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 29 Apr 2008 15:29:22 +0800 http://ozzzzzz.javaeye.com/blog/188076 http://ozzzzzz.javaeye.com/blog/188076 文档写作个人篇之时限 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/179952  发表时间: 2008年04月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

一个文档需要在什么时间段内完成是个大问题。
其实时限问题是任何工作的一个重要约束指标，这一点估计不会有人不理解。
但是文档的时限又有所不同。一般情况下，文档所要反应的信息应该是其被提交时候最新的。所以尽早完成未必是可取的。
同时由于时限的存在，很可能会要求你的文档要有一定的前瞻性和回顾性。而由于情况的不同，前瞻性和回顾性，需要的程度也有所不同。
同时我们还会发现，如果是提交给组织外，提交的时间也是很有讲究的。比如存在泄密的可能，存在给对方讨价还价的可能，等等如此这般的问题。
而这个方面虽然很重要，但是我观察到的情况是，绝大多数人都没有这个概念。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 07 Apr 2008 01:22:18 +0800 http://ozzzzzz.javaeye.com/blog/179952 http://ozzzzzz.javaeye.com/blog/179952 文档写作个人篇之开始 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/179951  发表时间: 2008年04月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

经常会看到这样的情况——
领导：那个谁，你写个关于这个事情的东西给我
某：啊？啊！。。。。。。好的。
随着心里就琢磨，关于啥东西的啊，又要写啥啊。

其实一个文档要真的写起来并不是那么麻烦，只要你搞清楚很多的背景条件和关于这个文档的确实需求。就如同我们开发软件一样，背景和需求是最先遇到的大问题。我们要写一个文档，应该知道这个文档给谁看，我们又是想给谁看；我们想达到的意图，对方想达到的意图；文档应该被提交的时间。
读者不同，需要的文档也不会相同。比如详细程度，行文风格，内容风格，以至于所用的纸张等等都有讲究。
而你要达到的意图你未必就那么理解，特别是你代表了一个组织情况下。而对方的情况也是如此。
比如一个忙碌的领导很难会看你的厚厚的详细报告，而技术人员往往会关注于某些细节。因此如何定义一个文档的各种约束，是需要你对背景资料有足够的了解。

当然这里我还有说有另外一种情况，那就是要你写的文档的格式和形式等约束已经是明确的。这样的情况一般都是应用于组织内部的文档系统，对外如果也采取这样的方式是不妥当的。即使是有其他的CI要求，在某些情况下，考虑到对方的情况，也需要你做出针对性的定义。

因此写作文档的开始并不是你急于动笔写，而是要先分析和了解情况。

下一节——时限
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 07 Apr 2008 01:13:11 +0800 http://ozzzzzz.javaeye.com/blog/179951 http://ozzzzzz.javaeye.com/blog/179951 文档写作入门 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/179783  发表时间: 2008年04月06日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

文档写作是可以说是一种基础性的能力。基本上大家都会或多或少的接触文档的写作，从小学的时候我们就会面对的各种表格，到我们经常面对的各种软件开发的相关文件。本身代码也是一种文档，只不过为更有针对性，我把文档的范围划定为使用各种自然语言进行表达的工作相关的文件。
文档是一种信息的载体，其内容与格式和形式共同构成一个系统，以表达某种特殊的含义。格式，其实就是表达的规格；而形式则是其被传播的方式以及存在的方式。而内容从某种角度叫，也包括格式和形式，但是我更希望大家在这里仅仅将其理解为文字所表达的信息。要完成一篇文档，所需要的就是对其内容，格式，形式进行规定和构造。所谓格式，也就是你的文档的外观。比如如何分段，如何使用表格，如何显示给读者。而形式实际也包括部分格式的内容，但是还会包括文档如何存在于介质，比如是电子的还是纸张的；是带演示的文字说明，还是使用声音进行说明，又或者是某种动态的类似戏剧的演示；是按照某种规定散在的存放于某系统之中，还是集中的存在于系统；等等。
如果我们不从企业整体应用和维护的角度，关于格式和形式的讨论就不需要过于去探讨。我们可以仅仅以实用的角度，去分析如何在实际中应用它们去完成一个工作中需要完成的文档。但是我们也应该明确知道，文档系统实际上是知识工程的一个最常见的部分。组织中文档的应用，应该追求可使用，可维护，可复用，可跟踪，可积累。
下一节——文档写作个人篇之开始
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sun, 06 Apr 2008 03:42:13 +0800 http://ozzzzzz.javaeye.com/blog/179783 http://ozzzzzz.javaeye.com/blog/179783 栽树也烦躁 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/179775  发表时间: 2008年04月06日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

今天曹雷发现了这么一个帖子，http://www.javaeye.com/topic/176677，给他白活了一通。这里按下不表。
问题是他们是在头脑清醒的情况下问的这个问题吗？那些讨论问题的人头脑是清醒的吗？
其实现在大量充斥着这样的事情，你说丧气不丧气。
今天发了个贴，问问大家想听我讲啥。其实我心理明白，我讲讲这些东西最有市场。但是效果呢？我能叫他们明白这个问题，可是类似的问题呢？讲来讲去，这些事情我唠叨了这么久，又会有啥效果呢？
所以你们别怪我挖坑不栽树，其实是我栽树太多，但是效果我看不到，所以有些灰心丧气了。

貌似这又是一个坑，所以还是要随便栽个树上去。但是心情不好，就不多说，梗概的点一下。该懂的人自然会懂，不懂的人就随他去了。
这个问题，其实不是技术问题，而仅仅就是一个需求问题，是一个对需求根本没有理解的问题。这个功能看起来简单，但是并不像他们想象的那么简单。当然也不是复杂。所谓的朋友最近的动向，其实要分开考虑。一种情况是在客户登陆界面上显示数目有限的几条，一种情况是专门的去检索。两种情况完全不同，各种的解决方法有联系，但是也不一样。其实说白了，就是登陆问题的衍生体。根本就没啥需要考虑的。要考虑，要讨论，本身就说明你的思路有问题，最最客气的说法是你经验不足。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sun, 06 Apr 2008 00:39:56 +0800 http://ozzzzzz.javaeye.com/blog/179775 http://ozzzzzz.javaeye.com/blog/179775 分布式源代码管理程序 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/158870  发表时间: 2008年01月24日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

很多人是从Git那里听说，源代码还有分布式管理的概念的。当然说起来支持分布式的工具也真不少，比如mercurial就很是惹眼（OpenJDK你听说过吧）。咋一下子冒出这么多呢？
开源项目大概对这个潮流有个促进作用，因为很多时候，松散的团队，个人独自开发，采用一个集中式的管理方式显然不适合。
另外个人solo式的开发，逐步开始注重源代码管理，以及集成和测试的支持，也是一个促进的因素。
还有就是移动办公，也刺激了分布式的趋势。显然你坐在火车上用笔记本开发，如果搞一个cvs或者svn，肯定没有用mercurial方便。
而且小的创业团队，在国外很多，特别是学生和自由程序员很多，他们更加没有cvs或者svn的情感约束。
而且很多人习惯使用Email做交流，而众多此类型的工具，对使用Email做具有源代码版本管理功能的提交和发布，都很简便。这也是一个大的背景。
说了这么多，其实我们可以看出这其实当表了一种潮流——组织更加多元化，松散和集中双向支持，更加强调简便直观。而显然一个新手从mercurial入门，会比用cvs和svn更加适合。这也是一个潮流——新人众多，并且地域分布广泛，并且他们更加愿意利用互联网建立团队，从而打破地域的限制。
另外还有一个趋势，那就是配置管理已经从专业团队专用而复杂的昂贵用品，成为一种普遍存在的简便小玩具。当然玩具这个词其实不确切，因为虽然他们功能简单，但是足够用，至少可以满足生产环境的绝大多数场景。
我估计下一步就是会出现很多项目管理的玩具，比如出现一个代替Trac的小东西。可以在随便一个台式机下运行，可以通过Email和邮件列表，或者新闻组互相联系，进行协同。
如果真能如此，好戏就该开始了。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Thu, 24 Jan 2008 00:25:47 +0800 http://ozzzzzz.javaeye.com/blog/158870 http://ozzzzzz.javaeye.com/blog/158870 Python社区的源代码管理工具真多 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/158864  发表时间: 2008年01月24日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

为啥会这样呢？
即使Rails那么牛，但是你看他们依然在用Trac。而且你随便看看，到处都是Trac。更加奇怪的是SVN这个东西，居然也到处都是。更加奇怪的是，那么多分布式的新工具，也是用Python写的。即便是Git，你也会看到很多人在搞SVN——Git。当然另外一个大分支是如gentoo的partage，linux下也一堆包管理的工具是用Python写的。而且你如果多看看还会发现，很多用Python的，他们多喜欢用shell。当然以前我说过，Python是很多管理员的玩具。
而进一步研究你会发现，这些人都不是所谓Python社区的中坚力量。而且他们也不怎么喜欢GUI，大多数都是命令行。大概shell和Python是最简单的语言了，当然据说如果理解了Lisp也很简单。
当然要说猛的也很多，http://www.wikimatrix.org/show/WikiSH，这个就比较猛。某人昨天喝醉了，跟我说他要用shell下个web服务器。虽然可能是醉话，但是我觉得未必不行。当然此公用dos的批处理写了个solo源码管理工具，还写了个项目管理的工具，虽说很简陋，但是能用。而且我看他用的也很欢。
其实很多时候，真的不需要搞一个那么强大正经的东西，随手写个小批处理或者shell，再加几行简单的Python可以搞定很多日常的应用。所以简单而功能简洁，功能也可以很强的。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Thu, 24 Jan 2008 00:01:40 +0800 http://ozzzzzz.javaeye.com/blog/158864 http://ozzzzzz.javaeye.com/blog/158864 敏捷的标准 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/158520  发表时间: 2008年01月23日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

一篇文章

同我最近考虑的东西很类似，只不过我对问题分了类，并且有些内容更加详细。而它之中也有一些是我没有考虑到的，所以很有参考价值。想当初CMM也是来自这样一个类似的问题列表，通过逐步的深化和系统化，从而形成一个大的体系。

无疑标准有好有坏，而标准造成的后果也有好有坏。一个标准化的敏捷是否还是敏捷，这个问题需要我们去研究。而我相信不同的标准化的策略，会造成敏捷的后果不同。关键不在于是否需要标准，而在于这个标准应该如何建立，以及如何划分与组织其内容，同时还要明确指定出应用的范围。

比如在一个成熟的领域，一个成熟的团队更加可能有优势。而在一个快速发展的领域，团队的成熟性是否能够带来能力的优势就不好说了。再例如一个自组织团队，如果在一个已经很流畅的管理系统下是否需要就很值得去测算一下成本。而如果在一个初始的系统下，自组织自然会有更多的成本优势。

也就是说这个标准不仅仅应该考虑开发组织自身的情况，还需要考虑其环境和其目标领域的情况。只有在一个系统考虑整个环境的标准下，才能更加具有具体的针对性。

 

 

 


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 23 Jan 2008 00:47:24 +0800 http://ozzzzzz.javaeye.com/blog/158520 http://ozzzzzz.javaeye.com/blog/158520 好为人师 ozzzzzz 作者: ozzzzzz  链接：http://ozzzzzz.javaeye.com/blog/154955  发表时间: 2008年01月11日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

大概人活着会有一个阶段喜欢处处指点别人，教训别人，所谓好为人师。
这个阶段可早可晚，不过几乎所有人都会有。这种癖好大概来自父性和母性，只不过强烈程度因人不同。这个阶段帮助别人的快乐，比自己去做更多，并且经常会被身后跟着一群晚生后辈所鼓舞。如果这个人刚好是做教育行业，那么这样的热情就会得到最大的发挥。如果是做别的，那么就要看机缘了。
不过还有另外一个阶段，自己对自己开始有了真正的认识，不过表面还装着好为人师，其实骨子里面仅仅是利用传授学问，来验证自己，来拷问自己。继续下去，对自己理解失去兴趣之后，好为人师就成了一个牟利的幌子，只不过这个时候的利可能是钱，也可能是势力，也可能是学术派别，还可能是其他现实的东西。不过最后，如果过了这个阶段，往往就是发现为师这个事情，很有乐趣——一种体验不同人生，不同环境，不同价值观的乐趣。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 11 Jan 2008 03:43:47 +0800 http://ozzzzzz.javaeye.com/blog/154955 http://ozzzzzz.javaeye.com/blog/154955