关于SOA，CTO larry的一些言语：

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

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

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

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

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

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

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

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

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

公司的CTO发给程序员杂志，很清晰的说明了我们的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，这或许能成为最标准的答案。

普元软件（Primeton）是全球领先的面向构件中间件厂商。普元EOS产品家族能帮助客户快速、低成本地构建高质量、灵活、易管控的企业级应用软件及SOA服务，从而大大提升客户在软件上的投入产出比(ROI)，让软件更好服务客户业务，提升竞争力。

普元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

此次使用的版本是53，在52上面发现的。

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是集群的事务不同步，而这次在佛山出现的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的数据源是能满足这个要求的。

，小子无知，大胆猜测。