最近中心要选一个业务架构平台，要我们考察。

但看了许多产品，感觉现在这类产品差别太大了，无论是EOS还是LiveBOS，还是起步，完全无法真正放在一起比较：eos更像一套软件开发的方法加上统一的技术架构，要学习的细节很多，有点费劲。livebos很特别，连数据库的设计都不要了，感觉是把C++的类思想，直接在业务层面实现了，与原来的开发思路差别有点大了，用起来得改换思路。起步的东西呢，感觉更接近应用，但技术上有点怪，既不是JAVA，也不是.net,完全是自己搞了一套，未来方向看不出。。。。

所以感觉这东西不是那个也不是最好的选择了，甚至该不该用，都是问题。

请教一下各位大侠的看法？

哦，期待高人出现

一、业务架构中间件与辅助开发平台的系统实现方法的差异
在整个软件开发项目的过程中，都要经历在软件需求分析、系统设计、系统实现的过程，即使我们采用了组件化的开发、面向对象的设计，还是会发现，分析设计人员、程序员和用户之间，仍然无法沟通的很好，应用系统在交付用户使用时，仍然离用户的真实意图比较远。这是因为，提出需求的用户和系统设计的技术人员看问题的角度不同。
用户是从业务的角度，提出应用软件是哪个职能范围的、有哪些应用模块、每个模块又有哪些子模块，这是一种基于“业务对象”的描述方法。而开发人员则是从技术的角度，架构是什么？数据库的结构是什么样的？表间关系是什么？业务逻辑如何编写？页面展现如何设计？这是传统的“组件”或“构件”思路。所以，用户和开发人员之间沟通起来仍然很难，业务实现及业务调整都依然为软件开发项目带来很大的难度和不可控因素。
而对应与应用系统实现，软件开发平台为了解决这些问题，经历了语言级开发到辅助开发平台的升级，直到我们所提供的面向业务架构的中间件平台。
而辅助开发平台源自与语言级软件开发环境，是从软件项目框架和程序开发过程各环节的开发效率上增加了许多特色的工具，从而为开发团队、开发者提供了更为高效的开发工具和项目控制与组织管理的手段，最终为整个项目降低了开发成本，提高了开发效率，但这并未真正意义上解决上面的问题。
例如：基于软件辅助开发平台，我们依然遵循需求分析，数据库建模，业务逻辑建模，页面设计，调试跟踪，测试，发布等过程，但是在每个节点上辅助开发工具都会提供相应厂商所特有的“可视化工具”以减低过程的操作难度，提升开发效率。
我们从软件系统开发实现的过程来看，开发人员会按照调研的需求分析报告，按照数据库建模，业务逻辑建模，页面设计的过程对业务需求进行分层的计算机语言转化，然后再将业务逻辑与物理数据库、展现页面与业务逻辑之间建立映射关系，之后在开始跟踪调试，最终发布应用程序。在这整个过程中程序员会利用辅助开发平台的“可视化工具”进行配置和关联，去自动生成系统的70%-80%的代码，复杂业务逻辑仍需手工代码编写实现。这对开发人员来说确实减低了很大的开发工作量，具体体现在开发过程中的普遍性及通用性的工作量，细节性的复杂业务逻辑处理难度和工作量并没有得到改善，这大概会占20%-30%的代码量。
但是软件系统的并不是一成不变的，随着业务需求的升级，软件系统功能及业务处理必须进行同步的更新，例如数据结构上需要增加一个字段，这时就会涉及物理数据库的调整，也会涉及业务逻辑的调整和页面展现的调整等等，当然也包括各层面的映射关系的调整。这时不管是哪个方面的调整都会影响其他层面的设计，而且既可能是通过“可视化工具”自动生成的代码部分，也可能是自定义的代码部分，而这种虽然只是系统从1.0到1.01的升级，都需要我们调整这0.1的升级部分所涉及的三层调整，以此看来并不是20%和80%的关系了，而是100%的调整。
而面向业务结构的中间件平台又是如何解决上述问题的呢？
业务架构平台是以业务对象建模为核心的业务中间件及其集成开发工具。在它的支持下，应用软件彻底实现“业务驱动导向”的软件开发模式，并实现“应您所需，随时而变”的应用系统。基于业务中间件平台，开发者只需要基于业务和管理的层面，而非技术的层面来理解、设计、构架和集成企业的信息系统（基于业务层面是指开发人员只需描述企业的组织机构、业务流程、业务信息、业务资源、业务逻辑、业务事件等业务内容，而不考虑技术层面的东西），就可以实现各类基于WEB的高层次的信息化应用。而且，用户可以随时在运行中重新定义或调整业务模型，从而达到使自己的信息系统完全贴近不断变化的业务需求，这也是“灵动”的价值体现。
在这样的平台里，开发者所关注的就是“业务模型”，在集成开发环境中通过对“业务对象（BO）”的分析来设计描述模型，而“业务模型”的处理流程通过“业务流程（BP）”来描述业务对象的逻辑关系，业务模型提交至中间件服务器后自动会生成标准应用系统的三层架构，自动建立关联映射关系。当业务对象调整时，只需要修正业务模型重新提交至服务器，服务器又自动修正应用系统中的每个层面，关联映射关系会自动关联。
通过以上我们可以看出，随着两大主流语言开发工具的发展，辅助开发平台的生存空间将会不断缩小，这主要源自各种辅助开发平台的初衷只是语言级开发工具的补充，事实上这是一厢情愿的做法，从计算机语言的发展趋势来看，它将是主流的语言开发工具的过度品，这种现象在微软.net架构的VS上已经有了较大的体现。而且我们通过对各种辅助开发平台的对比可以看出，其核心的差异主要体现为：一方面业务逻辑分解上的颗粒度粗细不同，组件、构件、服务……；另一方面所提供的工具的便捷性不同，可视化、图形化、向导模式、拖拽模式……；而这些“差异特色”都将会在主流语言的开发工具的逐步体现。
而业务架构平台则是在开发工具之上的业务模型描述工具，它与开发工具之间是分工关系，可以基于.net也可以基于J2EE，而且他会随着开发语言的发展而越来越强大，毕竟业务模型的建立永远是在系统开发设计实现之前。
二、业务架构中间件平台的特性
1、业务模型的重用：通过业务架构中间件开发的各种业务系统都是以对象模型的形式存在，每个对象模型都是依据“业务对象”而建立，对与程序的二次使用者来说，这样的模型较三层结构设计的系统更易解读，同时当系统需要进行重用时，只需要复制所需的模型文件即可，因为模型文件包含了整个业务对象的所有信息，复制后，重新提交至服务器即可再次生成系统的各个层面。由此看来这种意义上的重用与组件、构件、类的重用完全不同，这是基于业务层面的，是包含着三层体系的业务模型。
2、团队的协同开发与版本控制：由于平台系统协同开发者都在针对不同的业务对象进行建模，开发环境与服务器交互的是xml文件，所以平台不但提供的CVS控制，还提供了基于http协议的SVN控制，这使得协同开发人员之间在地理空间的局限。可以通过互联网直接连接服务器提交业务模型或者修改业务模型。
3、业务模型的反向工程：平台的对象模型特性还使得我们能够实现对象模型与业务系统之间的相互转换。
4、平台的应用难度：平台的对象模型建立均以参数化或者图形化的方式实现，使得平台对开发人员的技术要求降至最低，而只注重于开发人员对系统需求的理解和对对象模型工具的使用熟练程度。
5、系统的技术架构与技术路线：平台完全基于J2EE架构设计，标准的多层分布式应用程序，符合业界的技术发展趋势。同时平台的系统设计实现方法已申请商业方法专利（Business Method Patent,BMP）。
6、系统的开发性与扩展性：
WebService支持：平台是一个面向服务的的架构体系(SOA),通过系统服务或自定义方法很方便的调用第三方的Webservice,同时也可以将对象与操作以webservice方式供第三方调用。
HTML扩展支持：利用平台的建模工具可以不用任何代码生成美观的操作界面,但为了满足用户的不同需求，平台同样支持以HTML代码为基础的自定义页面,用户可以利用页面编辑器生成各种格式的操作界面.同时平台提供了一个“JSP资源”类型的系统对象来方便挂接应用开发人员定制的JSP或者是html文件，当加入JSP资源，平台可以统一对其进行权限控制。可以将这些JSP挂入系统菜单，也可与其他对象进行整合。
流程扩展支持：平台流程引擎中流程有活动，动作及转向等元素，并对这些元素提供了事件支持，可以在进入某个活动，触发某个动作，或具体到转向上进行事件处理。在事件处理上，用户可以调用消息服务，执行表单操作或直接的数据库SQL操作。此外，平台还提供了流程的相应编程接口，可支持在流程外启动或办理任务。
数据访问接口：平台具有有很强的集成能力，有多种数据访问能力来获取第三方软件的数据，支持异构数据库访问，支持直接tcp/ip数据访问，支持FIX通讯协议，支持基于webservice的数据源。同时平台也能输出excle,csv,xml等多种格式的数据。
深度开发支持：系统整个体系有很好的可扩展性。提供了丰富的Java接口。如界面模式接口，操作验证接口，操作接口，操作拦截器。用户可以自行实现这些Java接口并加入相应配置中，系统即可按这些接口进行界面或操作处理。平台在系统每个层面、用户方法、计算列公式、流程条件及事件处理中都提供了SQL语句与脚本语言支持。在表达式脚本中，平台也提供了直接加载JavaBean的函数。JavaBean加载后，用户即可在脚本中设置javabean属性及调用javabean方法。

不错。支持！