cloudxman http://cloudxman.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 请大家帮助整理有用的灾区信息 cloudxman 作者: cloudxman  链接：http://cloudxman.javaeye.com/blog/193654  发表时间: 2008年05月16日

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

目前各地都在大力报道灾区救援，但是信息太分散，请大家帮助把有用的信息集中起来，作为我们IT人的一点绵薄力量。

http://www.512ddz.org.cn/

其中，灾区寻人请大家访问 www.521xr.cn网站，帮助失去联系的人尽快联系上。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 16 May 2008 14:14:20 +0800 http://cloudxman.javaeye.com/blog/193654 http://cloudxman.javaeye.com/blog/193654 漫谈金蝶Apusic Studio（二） cloudxman 作者: cloudxman  链接：http://cloudxman.javaeye.com/blog/190476  发表时间: 2008年05月07日

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

金蝶的EAS是未来10-20年的战略高端产品，从运行平台定位就必须支持主流的应用服务器，比如BEA 的Weblogic和IBM 的Websphere，但是从研发角度来讲。Weblogic和Websphere太笨重了，在1G内存的开发人员的机器上工作效率很低。而这个时候，Apusic3.0 已经完全支持J2EE1.4标准，短小精悍，启动速度可媲美Tomcat，但是有支持EJB。对于金蝶来讲，很自然的一个考虑就是把Apusic3.0作为开发期的应用平台选型。当然，这个时候金蝶的战略已经很明确,会借EAS产品线大力发展自己的应用服务器平台了，从而形成国内独一无二的 ERP + 应用平台的持久发展战略。

早期，在金蝶EAS BOS Studio还未发展起来的时候，金蝶EAS的开发团队延用了Eclipse + JVM远程调试的方式来支持Apusic3.0的开发，这种开发对于熟悉Java的人来说，与加了插件的Eclipse + Tomcat 开发基本是一样的。其实，所谓断点调试的功能支持并非IDE环境支持的功劳，而应该归功于Java 在JVM层次就架构好了调试框架 JPDA。

作为大产品研发，任何开发工具的改进都将给提升团队的工作效率带来莫大的价值。金蝶EAS规划的时候，及分离了非常重要的一个团队去专门研发可以支撑未来EAS快速开发和二次开发的一个平台，这个平台当时叫BOS Studio,当然现在有一个很时髦的流行词汇，叫“业务应用基础平台”。

BOS Studio是基于Eclipse上扩展的一个Plugin，不过这个Plugin规模不小，其功能定位是能够支撑 EAS产品的研发和面向最终客户和合作伙伴的二次开发。用当时的术语，称之为 业务驱动的 MDA (Model Driven Architecture)平台。这个产品的立意非常高远，会把企业ERP应用的开发抽象成建模，从应用、开发、部署、维护多个角度解决 ERP产品发展问题。

其实在BOS Studio之前，金蝶在自己的Com/Com+三层架构的K3产品线就根据多年的用户需求积累逐渐抽象出了一个快速配置开发平台，用它来快速定制报表、扩展基础数据等。这套方案直接为EAS产品线的规划提供了原型。只不过EAS的规划站在一个新的起点和高度，拥有了更多想法和创新。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 07 May 2008 09:43:47 +0800 http://cloudxman.javaeye.com/blog/190476 http://cloudxman.javaeye.com/blog/190476 漫谈金蝶Apusic Studio（一） cloudxman 作者: cloudxman  链接：http://cloudxman.javaeye.com/blog/189212  发表时间: 2008年05月04日

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

对于一个软件开发人员来讲，Studio 可比喻为战士驰骋战场的兵器，恰如兵器在现代战争中地位日益重要一样，Studio在现代软件开发中扮演的角色也日益重要。

在集成开发环境(IDE)发展的早期,大家的兵器都很原始。记得我95年刚接触C语言的时候，已经有了Turbo C2.0,在那个还没有太多图形化开发的时代，TC能够很好把.c和.h文件组织起来，并提供编译支持，断点调试和及时帮助。TC使用起来的感觉已经很棒。

随着Window的产生，面向图形化开发的日益重要，集成开发环境就进入快速发展期，各种IDE纷至沓来，从Turbo Vision,Borland C++ ,Microsoft C++ 到Visual Studio, Visual Fox Pro,Delphi,JBuilder,Eclipse等等. 软件工业化生产的各种需求都被日益纳入IDE所要解决的范围，从而不断扩充IDE的能力，以至于最后驱动了Eclipse 这种通用IDE框架的产生。

我从2003年开始接触Eclipse. 那个时候，作为负责金蝶EAS产品线研发的开发工具和开发流程选型的负责人，我还一直是JBuilder的推崇者，可能不仅我，那个时候金蝶大部分技术人员还在使用的也是JBuilder。但是，我面临的一个任务是为二百多技术人员选择开发工具和开发流程，处于慎重起见，我和我的团队做了一个样板工程来企图验证各种可选工具的最佳搭配，这些工具涉及 VSS、CVS、Starteam、ClearCase、Jbuilder、Together、Rose、Eclipse。经过反复论证和培训推广，最后确定了CVS + Eclipse +Together的开发工具选型格局。

让我欣慰的是Eclipse无疑是正确的选择。事隔几年后，伟大的Borland公司宣布放弃自己了JBuilder框架的独立发展，这让Eclipse成为了事实上Java IDE的工业标准。

金蝶那个时候研发EAS，采用了EJB的持久化框架，所以，除了IDE,还有开发应用服务器的选择。Apusic3.0在这个时候进入研发开始作为开发应用平台使用。

（未完）
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sun, 04 May 2008 10:57:03 +0800 http://cloudxman.javaeye.com/blog/189212 http://cloudxman.javaeye.com/blog/189212 在AOM框架下开发的分工 cloudxman 作者: cloudxman  链接：http://cloudxman.javaeye.com/blog/188303  发表时间: 2008年04月30日

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

在这篇帖子我介绍两个内容
第一：如何转到AOM框架开发？
第二：在AOM框架下开发的分工

最近接触了较多的独立软件开发商，不少技术总监对AOM的演示效果表示非常惊讶，但是由于对JSF框架本身应用还不是很了解，表达了对应用这种技术的一些疑问，其中除了JSF框架本身是否可以满足企业应用开发的各种需求的疑问外，还非常关注采用AOM所带来的对原有工作模式的改变。

我曾经参与过面向电子政务和企业Web开发的项目，接触过采用JSP+JavaBean 和 JSP+Struts/Webwork+Hibernate两种典型开发框架的企业。一般来说，这种开发商存在美工、前端开发工程师、后台开发工程师、DBA几种角色。美工主要根据客户感性需求定制页面视觉效果，一般采用PhotoShop加工成Image,然后 前端开发工程师要把这个Image处理成 Html+CSS+JavaScript，这个纯静态的东西（姑且叫网页代码）是开始Web页面交互设计的基础。从我的感觉，通常的Web开发上面两个处理过程是省不掉的。

从效率上讲，其实在美工采用PhotoShop加工Image的同时，后台工程师就可以开始后台框架代码和DB的设计开发了。等“网页代码”出来后，前端和后端开始结合，这个时期较大的工作量在于把后台的内容放置到网页，以及处理来自页面的内容提交、导航、功能控制等。

Java的长项在于后端，无论从语言使用、框架使用、以及调试都带给人比较愉快的享受。但是前端网页代码、前后台交互，以及处理这两者之间的沟通、变更是整个Web开发的最痛苦的地方。

好，现在我来介绍前面的问题。
1. 对于很多Web首页的开发，由于这个页面在用户要求下，一般“图文并茂、比较花哨”，这种情况下 Web展现依然需要采用 美工+前端工程师来解决。但是从网页代码与后端的交互可以采用AOM提供的很多方便的控件（比如AJAX更新）来帮助解决。

2. 首页外，一般的Web应用就是 布局+菜单+列表+按钮+控件的表达方式了（尤其是后台管理），这个时候AOM可以派上用场，借助Apusic Studio对AOM JSF控件的良好支持，以及无JavaScript的AJAX交互，后台工程师可以完全胜任整个环节。

3. 多个模块可以交由多个后台工程师来并行做，在某些共用控件需要拓展功能的时候，可以分离出“控件设计师”的角色来单独负责控件的完善（也许你的企业，控件设计师与后台工程师是同一人）

4. 通过积累，企业可以形成丰富的自己的控件库，这是提升整个企业后期开发效率的重要积累。（如果采用了JSF+EJB3 或者JSF+Hibernate，从某种程度讲，企业应用的积累更多在于控件了）

5. 对于哪些还没有采用JSF的企业，建议可以找一个规模不大的项目，来应用JSF和AOM，一旦熟悉了JSF，即可快熟推广到其他新的项目。

6. 只要企业认同了JSF这一Java官方框架，AOM本身不会给你带来更多麻烦。因为AOM是可以选择的，想要的时候要，不想要的时候也可以不要。

7. 根据我的经验，对于有过JavaWeb后台开发的工程师，JSF框架的适应应该在1-2周左右。至于AOM 和Apusic Studio的适应，应该在2-3天。Apusic Studio是Eclipse的plugin,并且把Application Server无缝集成，相信每个Eclipse的爱好者会非常熟悉。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 30 Apr 2008 10:34:03 +0800 http://cloudxman.javaeye.com/blog/188303 http://cloudxman.javaeye.com/blog/188303 Ext和金蝶AOM的应用场景比较 cloudxman 作者: cloudxman  链接：http://cloudxman.javaeye.com/blog/187729  发表时间: 2008年04月28日

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

http://aom.group.javaeye.com/group/topic/5040
金蝶AOM与Ext的关系


熟悉Ext的，都知道Ext是非常优秀的纯JS客户端展现解决方案，作为纯JS方案，其优点是与服务端无关，所以，对于高手来讲，会获得一种“深入骨髓”的DIY能力，不仅可以在客户端尽情玩弄JS，还可以通过Ext提供的各种AJAX与服务端自如交互。

而AOM呢，更多捆绑了J2EE5.0(JSF)，AOM是在JSF的基础上通过引擎级别的RenderKit把Ext悄无声息地带入了基于Java的B/S开发。

纯Ext 的应用虽然灵活，但是对于较大的项目开发而言，却存在“效率较低”，“维护困难”的烦恼。这种烦恼尽管在JS对象包装，Firefox增强Debug能力等的支持下有了一定的改进，但是相对于传统C/S软件开发的效率和维护来讲，还是远远不够JavaEE5.0 之所以引入JSF，其目标应该是看到了B/S架构的业务系统的发展远景，从而希望对B/S应用的开发引入工业化的生产模式。尽管纯Ext的出现，已经让人非常惊喜，但是还是无法改变 广大B/S 应用开发工程师 苦于“前端开发和维护”的境况。

AOM 借助JSF+Ext，带来了前后台一体化的良好组件支持，并且把客户与服务端的交互 在内部机制上做了一个“透明化”；另外，AOM通过对Studio的不懈改进，较好实现了Ext 组件的属性化定制。不能说这样的实现是最好的实现，但是，至少这是在B/S开发上，更倾向于工业化生产的一种探索。

我个人觉得AOM的推广限制其实在于大家目前对于JSF的陌生。一旦JSF走出摇篮，成为大众的框架选择，这样AOM对于 Browser+ Javascript +Java来讲，目前提供的开发模式是非常顺乎自然的。这种模式不仅是金蝶，我想其他厂商也必然会推出类试的来。只不过，目前金蝶由于在Application Server和Studio上的广泛积累，反而成为较早的创新者和布道者。

当然，我觉得JSF的模式并不适合所有的B/S应用，所以，从这个角度来讲，金蝶AOM只适合那些适合JSF框架的应用。对于已经证明可以采用JSF框架的应用，应用金蝶AOM 我想会在学习成本、开发效率、维护代价、应用易用性和界面美观性上都获得相当的价值。

国内很多基于B/S的应用，其实是面向局域网的，并且并发用户也不大，对于这样的应用，我比较推荐使用金蝶AOM,比如OA(办公自动化)，比如内部流程审批 等等。

相反，对于那些面向互联网的应用，并发用户很大或者交互界面非常复杂，或者后台不倾向于选择Java，可能使用Ext更具有架构上的灵活性和适应性。

以上是我的个人看法，欢迎大家交流。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 28 Apr 2008 18:41:32 +0800 http://cloudxman.javaeye.com/blog/187729 http://cloudxman.javaeye.com/blog/187729 AOM2.0正式发布（二） cloudxman 作者: cloudxman  链接：http://cloudxman.javaeye.com/blog/165444  发表时间: 2008年02月27日

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

在传统的编程模型下，页面美工通过网页设计工具“画”出来的页面，程序员看不懂；而如果程序员对页面进行修改，则页面美工又无法理解；并且，如果要更改业务逻辑，程序员需要不断的维护页面内容，最终造成页面美工与程序员无法协同工作。而在IoVC的编程思想下，页面美工只需要给每个组件设置一个ID，程序员在后台的业务逻辑中，便拥有对页面UI元素的完全控制力。Web页面在美工完成之后，程序员再也无需因为需求的变更或者逻辑的变化，而再重新维护Web页面内容。
简而言之，IoVC是一种更好的MVC，是对MVC的一种高层次抽象。

3. 无状态支持
ViewState是很多时候必须维护的状态，采用IoVC模式后，由于状态维护在服务端，使得UI端的界面状态维护不在需要。另外基于facelets的xhtml文件本身就是组件树。

4. 增强调试辅助
AOM通过RenderKit生成了很多交互式的JS代码，虽然这些代码都是经过很多检验可靠的代码，但是不排除遇到极端情况的辅助调试需求，AOM2.0 充分考虑到了当“AJAX无需写JS代码”后所存在的调试需要，提供了诸多调试辅助措施。

5. Lite Bean
Lite Bean，脱胎于JSF中的Managed Bean（托管Bean），却又远超过Managed Bean的功能范围，它是展现层与业务层的粘接器。
在AOM中，一个Lite Bean就是一个普通的POJO对象，它可以继承任何基类，也可以实现任何接口。而Lite Bean的声明与配置，也遵循“Convention Over Configuration”的原则，只需一个简单的Annotation声明，使您从繁重的xml文件中解脱出来。在Lite Bean中，您可以编写、调用、组合任何后台的业务逻辑，同时，遵循IoVC的编程思想，也使您拥有对UI的完全控制力。在Lite　Bean中，还可以注入任何其它资源，也可以再注入其它的Lite Bean。Lite Bean同时还是Apusic OperaMasks与Spring、EJB3等其它已有编程模型的粘接器，一个Spring对象或EJB 3对象，同时也可以成为一个Lite Bean，而一个Lite Bean同时也能够轻松的被Spring对象或EJB 3对象所调用，这是一种神奇的魔力，通过LiteBean，能够使您通过IoVC思想拥有对UI的完全控制力，又使您任意的调用、组装任何的后台逻辑，从而使您的工作轻松之极，并完全享受Web开发的乐趣。

6. Elite，the Ruby of J2EE
Java，曾经被称之为史上最优雅的语言，吸引了诸多程序员的目光，目前已经成为世界上使用率最高的语言。但在Web 2.0浪潮的冲击下，在“简单、轻量、敏捷”压倒一切的态势下，Java也略显疲态，日益臃肿与复杂起来。人们即希望拥有Java语言自身的强大、健壮与稳定，又期望拥有类似于Ruby等动态语言的敏捷、高效与灵活。一种新的动态语言，elite，能够使您鱼与熊掌二者兼得。
ELite是一个集命令式和函数式风格为一身的面向对象的程序设计语言，既有高阶函数（first-class functions）、列表推导（list-comprehension）、模式匹配（pattern-matching）、延时求值（lazy-evaluation）等函数式语言所具有的语言特征，又具有和Java相近的语法结构。
与Java相比，Elite语法简单、高效，并且更加的面向对象
Elite同时也是一种DSL（Domain Specific Language），并且，它向领域扩展的能力是简单且强大的1[km/h] * [1.hour + 45.minute]
与其它动态语言相比（譬如说Ruby），Elite能够与Java很好的集成
有人说，在Web 2.0的冲击下，RoR（Ruby on Rails）正在侵占J2EE的领地，但Elite将成为J2EE中的Ruby，并且，与Ruby相比，Elite对Java程序员更自然，更亲切，也更强大。Elite是为Web而生，将会成为Java程序员最有力的武器！
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 27 Feb 2008 13:23:47 +0800 http://cloudxman.javaeye.com/blog/165444 http://cloudxman.javaeye.com/blog/165444 AOM2.0正式发布（一） cloudxman 作者: cloudxman  链接：http://cloudxman.javaeye.com/blog/164856  发表时间: 2008年02月25日

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

Apusic OperaMasks 2.0 M1 于2月22日正式在 http://www.operamasks.org 发布，欢迎大家去下载试用。

这里我简单介绍一下AOM 2.0的 技术特性。AOM2.0相对于AOM1.2版本做了很多重大的改变，主要是以下几个方面：

1. 升级到Ext2.0
2. IoVC编程模型支持
3. 无状态支持
4. 增强调试辅助
5. 完善的布局组件
6. 组件快速开发支持

1. 升级到Ext 2.0
使用过AOM的朋友都知道，AOM是借助ExtJs来提供客户端组件的。Ext1.x虽然取得了巨大影响，但是由于其性能较差，以及布局不方便等原因逐渐为Ext2.0所取代。AOM2.0 这个版本终于破费周折把JS 组件统一升级到了Ext 2.0，并将在后续逐渐依托2.0的模型 构建更加强大\稳定的 RICH　Component。

2. IoVC编程模型支持
IoVC——“Inversion of View-Control”，即“视图控制反转”，换言之：它能够把对“View（即UI视图）的控制力”注入到你的后台业务逻辑中。这样一来，你在编写业务逻辑的过程中，对View拥有足够的控制力，从而能够将展现层与业务逻辑完全的解耦。
我举一个例子来说明。

使用传统的EL表达式： 
页面：
<w:textField  value="#{myBean.value}" 
tooltip="#{myBean.tooltip}"/>
后台：
public class MyBean {
	private String value;
	private String tooltip;
     public String getter/setter()...
}


使用IoVC模型： 
页面：
<w:textField id="txt"/>
后台：
public class MyBean {
	@Bind(id="txt")
private String value;
	@Bind(id="txt" att="tooltip")
private String tooltip;
}

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


JavaEye推荐



]]> Mon, 25 Feb 2008 18:26:34 +0800 http://cloudxman.javaeye.com/blog/164856 http://cloudxman.javaeye.com/blog/164856 好的技术也需要营销 cloudxman 作者: cloudxman  链接：http://cloudxman.javaeye.com/blog/164818  发表时间: 2008年02月25日

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

最近在国内知名技术社区javaeye创建了关于AOM(Apusic OperaMasks)讨论的一个圈子。说实在的，创建的初衷是为了营销，但是我想说的是营销不是广告，同时技术更需要营销。

国内技术型产品的公司历来不注重营销，所以很多很优秀的技术都夭折在幼儿时期。而那些可能一开始并非最优秀的技术或者产品，懂得充分借助了新旧广告以及口碑传播来营销，最终获得了行业关注和应用推广，从而度过了冬天走向春天，一步步完善而成为主流技术品牌。作为国内关注Java技术、关注技术性产品的金蝶中间件，说实在的，在技术营销上做的并不好，至少不如普元好，所以我们来看金蝶的技术社区和普元的技术社区，就会发现很多差距，这个差距的本质不是设计而是意识和习惯。不过我还是要庆幸，国内公司正在积极成长。也许当中国创业板诞生，当更多的高科技公司从谋求生存的状态中解脱出来后，会更积极关注自己产品和技术的营销。

回到技术型产品营销的话题，我们如何来做好技术性产品的营销呢？我有一些小的体会，欢迎大家也谈谈自己的想法。

1. 呈现清楚你的产品

技术型产品的目标人群是技术人员，这是一个非常务实、朴实的人群。对技术的关心一方面来自自己的强烈兴趣、另一方面来自“你的产品是否真正有效解决我工作中的问题”。所以，营销的本质是做好宣传，把这个产品好与不好、适合与不适合需要呈现清楚，不要浪费你产品用户的时间，这样你的产品才能真正卖出去。

2. 保持积极改进的心态

产品的完善是个持续的过程，用户反馈的问题其实就是最好的需求点，捕捉到这些需求点就应该立即努力去满足它，这样不仅用户从你的改进中看到希望，你也始终能够确保你的产品一直在提供有价值而不是空洞的功能。

3. 努力减少学习成本

产品功能的复杂并不是产品不易学、不易用的借口。技术以“用”为本、所以降低产品的学习成本会帮助更多的人理解到产品功能的价值，从而产生进一步了解、深沉次使用机会。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 25 Feb 2008 18:13:02 +0800 http://cloudxman.javaeye.com/blog/164818 http://cloudxman.javaeye.com/blog/164818