到现在为止，有5个多月。

我在军区宅了一段时间，到桂林转了一圈，去福州做了一次培训，去EMOS做了一次培训，然后一直给深圳高兴投的项目宅着，到现在。

是该画上一个完美的休止符了，虽然他看上去并不完美，最少从数据上来说，不好看，甚至说，很难看。

先说说KPI考核体系，我也曾经钻过它的空子：

工时率，就是你干活的时间，由项目经理认证。一般这个都还不错，就目前的加班情况来说，那不可能会有问题的。

客户满意度，就是客户给你的打分。一般这个也挺好，我能吃能喝还能侃，所以问题也不大。

销售满意度，也就是销售给的打分。此次的打分十分的出我意料之外，后来问起，是售前的打分，那没招，该是什么鸟样就是什么鸟样。感情我屁颠屁颠加班是我自己找的，不是给任何人干活，是给自己干，我自己犯贱呢，生活可以过的很精彩，也会有很多无奈，我很无奈，关于这点，不过我也就blog骂骂，留作纪念了。关于销售满意度，我比销售对我的失望还要失望的面对销售同学。

知识贡献度，这就是我曾经钻空子的地方，去年基本上一个项目做完了，能闲一个多星期没有很赶紧的项目，所以呢，我闲下来，整理几个知识点，还是能换点钱的。今年就不同啦，基本上培训没什么好总结的，军区做的是重复性工作，好容易到了深圳，赶上了好时候了，天天加班加的和狗一样，项目经理如打鸡血一样，兴奋的一塌糊涂。大部分时候累的连话也不想说，何谈有空整理知识点呢？赶上点背的时候，只是贡献度居然是0，两眼一闭，接受这个事实。希望在回去的一段时间内，把欠pso的东西都补上，交上一份完整的答卷。

主管满意度，这个没什么好说的，我明白我自己，用好了，是一把利剑，用的不好，是一把钝斧子。而这一块有很多F同学的打分，3个多月，总共才5个月，所以呢，分数很低，我也能想象，就像我的预言，今年上半年的良好KPI因为这个项目而废除，这也就算我正式base华南给的100杀威棒了。成，这杀威棒打的不错，彻底杀了一把威，爷我不和你们玩了。

因为是同一个玩法，所以是公平的，所以呢，很好。如果不转部门，我将要被淘汰。

之前总结的三思此处能用上：

思危，思退，思变。

仅以此文，结束base华南的日子。

华南的部分兄弟们，我会想念你们的。

关于此次培训的前因后果，来源于一次失败的PK。在快速开发方面，我们输给了福州的一家本土的公司。不得不承认的一个事实，在快速开发的方面，确实有一部分公司做的比普元要好，但是，对于一家要选平台的软件公司来说，快速开发真的就是王道么？

当然不是，还有很多值得思考的方面和部分。软件公司选择别家公司的平台，本来就存在相当的风险性。如果平台厂商死掉了怎么办？如果上了贼船，不能下怎么办？等等。先撇开如上的风险不说，先谈谈平台对于一家软件公司的重要性。

选择一个好的平台，我认为有以下的一些好处：

1、积累业务经验

做项目的公司，总会能或者努力接到大大小小的项目。如果是行业级别的项目，相信老总的希望是，每个行业级别的项目，都是能复制的，能积累的。然而在贵国，确实不然。就拿电信行业来说，拿下整个电信行业的某个业务系统，并不代表制作的就是同一个业务系统。需要面对的是，需要制作一个业务系统的多个版本，比如浙江版，上海版，安徽版等。每个系统都是由差不多的功能组成的，却又不尽相同。行业的复制，一套行业软件不需要修改，卖到很多个地方，看上去是不可能的。

哈，那么退一步来说，我卖的是一个由在公司的服务仓库抽取的一系列的服务来拼装的软件，不管需求怎么变，理论上来说，大部分的需求都会存在服务仓库中，就算有一些特定的需求没有，也可以团队马上开发并提供服务。这样来说，在业务反应的能力方面，就能完成从一般到优秀的蜕变。

在上一过程中，积累的是一个一个具体的业务完成的服务，可以直接调用。

2、锻炼队伍

一个好的产品，是有自己的神髄的。其中有一大批资深的产品相关人员心血。当这么多心血注入一个产品的时候，产品的本身，就是一个活的。你可以说它是一个宠物，也可以说它是一个朋友。

选择产品的时候，慎之又慎，类择友。一个团队能跟着一个优秀的产品来走下去，是团队的幸运。俗话说的好，你能走多远，关键看你和谁同行。

刚开始的时候，学习一个产品的使用，这个时候是陌生的，根本不知道该产品能提供什么功能。慢慢摸索，到熟练使用。最后，会考虑到，这个产品为什么要这样设计，为什么不能那样？能不能这样来提高这个产品？如果能提高这个产品，那么，离能完整的设计这个产品的时间就不远了。

能设计开发底层产品的团队优秀的团队。只要有足够好的协调。

3、拥有自己的核心竞争力

首先申明，核心竞争力包括了核心代码的编写。用任何产品的同时，作为软件公司，没有人会把自己的生杀大权交由另外的公司来处理。如果他出问题了怎么办呢？我基于这个平台做的任何东西，能被其他的地方使用么？……

一家软件公司的核心竞争力可能会包括：业务的熟悉，经验的累计等。

如1所描述，底层业务颗粒度有足够小的时候，其实所谓的业务，就是一些底层业务颗粒的组装。

这些产品足够开源，那项目的成功完全不取决于平台提供商，我们甚至可以向互联网求助。：），而就算平台厂商倒闭了，业务颗粒也能被其他的框架，产品所调用。

如果一个平台能解决以上的问题，那还担心什么呢？

这也就是我能想到的，为什么pk失败后，还存在花钱培训交流的原因。看样子我们的对手对以上三点都没有很明确的答案嘛。

有戏！

------------------------------------------------------------------------

过一段时间再看，自己会有哪些方面的提高。

string        2009-3-21   凌晨

选择一个公司，不是看眼前待遇几何，而是说，个人的发展空间和加薪的可能。似乎每个人力资源的人士都如此说。不过我没听过我们公司的人力资源如此说。可能是自己还不够格的缘故。工作，挣钱，是为了开心的生活。我在普元很开心，这点就足够了。

公正的说，普元的待遇在业内算中上。而最近CEO JOHN的加入，再次调整了薪水。注意：不是往下，是整体往上。还是由于不够格，此次没有调整到鄙人。而比较诱人的是，就像我们的招聘上所说：

普元预计在2010年上市，公司为有志之士提供了令人注目的机遇，包括：高水准的专业培训，完整的薪酬、期权、福利待遇，以及最佳工作环境与自我提升机遇。

关于10年上市，可是CEO john说的，他相当靠谱。所以对此深信不疑！

选择一家外企，可能在进入的时候，挺高。比来普元的薪水多了2k到3k。但是过了几年，再做比较，可能普元的薪水已经比同时进入外企的哥们高了。而10年上市，期权的兑现，也算是你憋闷的比哥们少的那几年的精神补偿了。

可能比你自己的年薪还要高哦，这些可算是额外的收入哦。:)。

而普元的高速发展（关于这个，请查看德勤的报告，或者看公司的主页，普元软件当选德勤高科技、高成长50强，位列软件行业成长速度最快前三甲），给你足够的空间让个人发展。有能耐，这里给足你舞台和灯光光。当然，还有足够的片酬。

怎么样？有些动心了么？要来趁早哦，期权可是论年发的。需要了解普元的，可以添加我的QQ，或者给我邮件。

除了本人现在的待遇，争取知无不言，言无不尽。

EOS工作流符合工作流管理联盟（WfMC）规范，同时，根据中国软件业的具体行情，还整合了国内众多的电信、政府、金融等行业特殊需求在遵循规范的基础之上而进行了扩展。

EOS工作流(Workflow)是具有中国特色的工作流。它溶入了国内电子政务与电信等行业的特征要求。在流程定义中支持包括串行，并行、同步、独占式选择、同步归并、子流程嵌套、自由流、活动回退业务补偿等都多种流程模式；对于流程动态调整，又根据具体的行业需求实现了“特事特办型”、“一刀切型”，“分水岭型”等流程调整方式，从而实现灵活的业务调整。

EOS Workflow由工作流开发环境(Workflow IDE)（与Studio集成）、工作流引擎(Workflow Engine)、客户端、监控与管理工具以及工作流构件库(Workflow Component Library)五个部分组成。通过开发环境快速构建业务流程以及业务处理表单；依托引擎实现流程流转；采用基于Web的缺省客户端和管理监控工具完成对流程的调整、监控与审计。应用丰富的构件库快速定制用户自己的应用，随需应变。

每个用我们工作流的人，就我接触的人来说，在开始的时候，都会怀疑我们的所能提供的效率，包括开发效率和运行效率。

开发方面，一些图元的设置和拖拽，在很大程度上，降低了开发的门槛。就我支持的项目来说，做过关键业务的工作流的人员，不会写JAVA文件，比比皆是。这算不算我们提供了高的开发效率呢？

运行效率。嘿嘿，和原始开发的项目的效率做比较，一定会好。只是有一点，做基础开发，基于代码制作的时候，会在数据库的操作和DB的优化上做很多动作。而用EOS的项目中，少有配备优秀DBA。所以在做服务的过程中，关于数据库方面的调优需要加强。假以时日，应该没人在怀疑我们的运行效率了。

btw：我的普元之路，或许将转入数据库调优方面了。

 “随着各个企业和媒体的呼吁，SOA的概念在中国已经开始普及，由于客户业务上的增多和变化，很多以前基于指针分布式运算的架构已经远远不能满足需要，就算再接上很多软件系统以增强应用也是极其繁琐。” 

“普元作为中国企业参加了SOA标准的制定，但是在其过程中发现，尽管外国的SOA技术发展已经很成熟，但是仍然缺少一个标准，标准的出现就是为了让更多的企业找到统一高效的方法，不管是买到谁的产品，标准是统一的，应用起来也就不会麻烦。因为SOA绝对不只是软件的简单整合。”

 “美国开始推行SOA的时候，企业系统的建设是比较稳定的，有很多应用是SOA重复的，这也与国内外信息化进程的差距有关，在整体系统上加接SOA接口，可能只需要更改原系统的20%就能让整个架构实现SOA的应用。” 

“SOA的架设就像国内外城市的建设一样，国外城市规划很成熟，加盖新楼只是进行修复，而国内的城市一般都会推倒旧楼盖新楼，城市需要重建。”

“SOA是一个开放的标准，虽然大家走的路不一样，但是结果都是对SOA的推广有好处。” 

“很多大的厂商IBM等等，在SOA领域有着极高的声誉，也是SOA标准的大力推动者之一。不过我想微软可能跟我们走的路不一样。” 

“也许微软的选择不是遵循SOA标准，而是在自己已经开发的系统里加上SOA标准接口，毕竟微软在客户端有着巨大的优势，在注重客户体验上微软更有经验，在系统里加上SOA接口或者是别的客户端对微软来说根本不是难题。”

“每个厂商都在市场上扮演自己的角色，虽然大家走的路不一样，最终都在推动SOA市场的发展。” 

基本上，我很佩服他，还好不是崇拜。

转载如下：

春天来了，SOA在哪里？

文/黄柳青

经过冰封雪飘的春节，中国的IT年度才算真正开始。国际国内的IT巨头同仁们把铲雪车掉过头来，准备开挖SOA的金矿。毕竟，SOA这颗种子在中国已经耕耘了很久，在国外已经成为平台软件的主要收入来源！然而，从目前市场的实施热度来看，离市场的宣传热度还是很有差距。电信、银行、电子政务、各行业企业管理，大家都能看到SOA的种种好处，却又无从下手。是什么因数让SOA在中国发展滞后，在中国成功实施SOA的要点又是什么呢？

    第一，公司需要提升企业级的IT规划和掌控能力。看到某国际巨头对SOA的宣传，有了SOA企业应用就能灵活适应业务发展。这让我想起一则眼镜广告的笑话。某眼镜公司的广告说，戴上我们的眼镜，让您读莎士比亚！一个文盲配上了眼镜：我怎么还是不识字呀？实际上，SOA只是应用之间交互的一种工具。在国外，大型企业的IT规划是十年，几十年的稳定架构，部门级的现有系统具有较好的定义和规范。一旦有一种协议帮助企业应用进行交互操作，企业级的应用架构就成立了。而在中国，大部分企业的IT规划一般以应用为中心，IT的规范还在技术规范为主。在有的行业，早早就在总公司的级别开始了如BOSS的企业级规范，但是这些规范主要体现在模型级，而不是规格级，因而总公司的规范在各省实施不一。因为现有系统建设的随意性，即使购买了SOA的相关产品，现有的应用主体上不能包装成SOA的服务在企业级应用间通用。没有可以使用或包装使用的大量的SOA服务，SOA技术就成了文盲的眼镜，没法发挥作用。

如是说来，在大规模开展SOA实施之前，中国的企业必须改变现有的以应用项目为中心的IT规划，学习大型企业的长期IT架构规划能力。我们如果有了企业级的IT规划能力，就能规划和设计出企业的基础服务，然后开发出合适的SOA服务，逐步把现有的应用通过新的SOA体系架构来承载。

    第二，SOA要从面向构件开始。中国的IT规划和建设比国际的同等企业要难十倍，因而照搬国外的技术便不能解决中国IT系统建设的所有问题。大家比较清楚，中国的同等系统的建设,IT投入是国际同类系统的十分之一，系统容量性能的要求是国际同类系统的十倍。电信公司级的数据仓库，国家税务申报系统，证券交易系统，银行柜台系统，等等，其容量和性能都是国际上没有的。

这个十倍的难度，更是体现在业务变化的能力：中国的IT系统的灵活度和变化度要求是国际同等系统的十倍！当我们尝试用SOA服务作为IT规划的基础架构的时候，我们每每发现，我们没有办法设计出固定的SOA服务，因为我们的银行、电信、税务从核心业务的角度来看，还是处于发展和变化的过程中。国际主流的企业模式，是在稳定的社会大环境中发展起来的，业务架构不会有太多不可预见性和变化性。但是中国的电信行业很快将有新的整合，金融业务不断开放有新的业务出现，税收还有很大的税种现在还没有开始征收，我们怎么可能规划出一套完备的SOA服务呢？

如果我们把SOA服务的标准性、开放性应用在构件的层次上，我们发现，就像企业级的业务变化可以通过SOA的组装完成一样，SOA的服务的灵活性可以通过构件的组装来完成。虽然我们不可能为企业现在就设计出一套完备的SOA服务体系，但是我们现在可以为企业设计出一套完备的构件体系。有了这样一组构件，SOA的服务就可以快速的开发，灵活的变化，企业级的业务也因而快速实现。从而我们就实现了中国企业业务变化的加速度！

自从我们普元软件加入OASIS国际标准组织并成为核心会员之后，我们大力参与了SCA、SDO等标准的建设和推广，以及相关的Tuscany开源项目。SCA、SDO用构件的理念让SOA的服务组装在一个图形化的界面完成，变得非常容易和流畅。在普元EOS产品中，我们使用和SCA、SDO完全对称、一致的方法，实现从构件到SOA服务的组装。有了这样的平台，企业级的应用可以从面向构件开始，快速实现业务变化和企业发展。

去年开始，我们也在一些大型企业，比如五大银行之一，开始面向构件的企业级SOA规划，已经取得了诸多成果，并得到客户的认同。只要从国际主流的技术，发展出能够适应中国独特的业务变化加速度的产品，从面向构件开始，SOA即将成为中国企业IT建设的主要手段。

这篇不是软文，而是字字千金的总结。高度，真是决定视野。

google普元的SOA，这或许能成为最标准的答案。

普元EOS产品家族目前包括EOS平台，以及基于EOS平台的EOS工作流和EOS报表选件。其中，EOS平台基于SOA国际标准、功能卓越，通过将构件、XML、可视化组装等技术完美结合，以图形化的构件单元快速组装企业应用与SOA服务，具有极佳的灵活性、高质量和易管控优势。EOS工作流选件基于EOS平台运营，可完全满足中国企业各类工作流程，支持业务灵活调整，帮助客户成为“流程型公司”；EOS报表选件则可轻松实现各类中式和西式报表，所见所得，方便管理者全局监控业务。

普元在中国的电信、金融、政务、电力、物流、制造、建筑等多行业拥有超过200家以上的大型客户和众多中小客户，其中包括中国财富100强的大部分公司。普元还与超过100家以上的独立软件开发商（ISV）合作，为客户提供端到端的价值。其中通过与华为的合作，已帮助冰岛、印尼、荷兰、泰国等国家在电信领域实现了多样关键应用。

普元于2001年由多位留美企业家和世界级计算科学家创立，汇聚了来自BEA等世界一流企业的管理精英、技术专家等人才。目前投资超过1.5亿人民币。

普元是SOA国际构件标准组织OSOA和电子商务标准的主要制定者OASIS的核心成员。

普元总部位于上海浦东新区张江高科技园区，在北京、上海、广州、成都、南京、杭州、长沙设有销售和服务分支机构。

普元的成功之处：

－－－－－－－－－－－－－－－－－－－－－－－－－－－

从这篇文章开始，我会在blog上转载4到5篇左右关于我们公司的一些东西，纯属SEO的测试用例，希望能在google的第一页在搜索普元相关的东西的时候看到我的blog。如此。

                                                                                                             －－StringLew

eos提供一种做法，是!=等同于<>  .这个在设置线上条件的时候经常碰到。

但是在查询的时候，这个就不会等同了。

我对EOSORG_T_Employee这个系统自带的表格使用查询生成向导。

<input type="hidden" name="EOSORG_T_Employee/orgID/criteria/operator" value="&lt;&gt;">

<input type="hidden" name="EOSORG_T_Employee/orgID/criteria/operator" value="<>">

出来的效果和使用

<input type="hidden" name="EOSORG_T_Employee/orgID/criteria/operator" value="!=">

完全不同，使用<> or &lt;&gt;，就和没有使用是一个效果。

为什么呢？理论上来说应该是一样的才是。

这是个问题。

在广州的时候，出现的bug是集群的事务不同步，而这次在佛山出现的bug，是多数据源的问题。先说一下整体的情况。

OA系统，用到我们EOS作为整体框架，websphere5＋db2 8.2 + EOS ，eos的版本号为52。用到了多数据源。

理论上来说，一个事务操作一个连接，所以在整个事务中间，如果需要用到另外一个连接，自然会报错。

比如在广州的时候，一个bizlet用到这段代码：

ProcessCaller pc = new ProcessCaller("common", "0", "-1","defaultAppID")

看上去，只是new 一个 ProcessCaller，没什么大不了的。但是实际上，请跟踪他的连接，会发现，他自己会new一个连接。如果这个时候你用调用该bizlet的事务里面的数据，当然，会拿不到里面的数据了。

而这次出现的问题是：

一个prP的事务里面，调用一个biz，bizA的数据源设定是A数据源，而biz里面的biz bizB里面，设定的是B数据源。这样有一个层次的关系。

prP事务>bizA>bizB

当prP事务调起bizA的时候，根据bizA的配置，默认的拿到A数据源，所以这个时候，增个事务是针对A数据源的，而在bizB里面，需要操作是拿到B的数据源，对B数据源对应的表进行操作。由于之前事务已经有一个数据源，这个时候，B数据源在该事务中是拿不到的，所以就会把错误抛出。

很明显，这个错误很正常，如果用到spring的事务，也应该会遇到这个问题。本来逻辑上，这样就是说不过去的。

该怎么解决？

update:

最后的解决方案，在bizB的里面，再次封装一次，封装的biz的属性里面获取另外一个连接的数据源，这样就可以了。对于     如果用到spring的事务，也应该会遇到这个问题。 这句话，可能是有问题的，嘿嘿，chengzhi说，XA的数据源是能满足这个要求的。

，小子无知，大胆猜测。