恋风的Blog -技术

Vote weekly for the best MSN Space on “What’s Your Story?” featuring real stories by real people.
SpacesGet your own space | Subscribe to RSS feed | Tell a friend | Search spaces 
Learn
恋风的Blog



Home |ProfileBlogPhotos |Lists |Music

Blog


December 20
redhat linux安装方法.
从硬盘安装:
一、下载iso文件，保存在linux分区或windows分区任一目录中;
md5sum valhalla-i386-disc1.iso
实例：ISO放在E:/redhat目录
二、用winrar工具把第一张盘中DOSUTILS目录COPY出来到WINDOWS分区；
实例：把DOSUTILS放在E：/REDHAT目录下；
三、由纯DOS进入 DOSUTILS 目录，并执行 AUTOBOOT.BAT；
四、安装选择从硬盘安装。
装的时候有个选hard disk的,一般c盘对应hda1,d盘对应hda5,e盘对应hda6..
五、分区,用Disk Druid手工分区.
实例:对F盘重新分区.
引导分区: /boot  ext3    100M
内存交换区:       swap  512M*2
根分区:    /         ext3    5000M
自定义分区: /mnt/linux_c, /mnt/linux_d, /mnt/linux_e....
如果安装完成后，GRUB只能进入LINUX 而不能进入WINDOWS。
然后用WINDOWS启动盘引导，运行FDISK /MBR
重新启动，可以进入WINDOWS。
Add a comment
5:00 PM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!237.entry
December 15
近期学习计划

















Add a comment
3:13 PM  | Permalink |Trackbacks (0) |Blog it
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!236.entry
December 09
集成线&标准线建设计划
三、   集成线标准、规范/规约的建设
1、标准、规范/规约的建设
在IT应用开发的6个核心领域：分析、设计、开发、测试、部署、项目管理6个核心领域中制定相应的标准、规范/规约，标准是强制性的，EB与AI部门必须遵照执行。规范与规约是约束性的，一般输出为标准的模板，贯穿项目6个核心领域的不同阶段，所有的项目人员必须遵照执行。标准、规范/规约的建设主要包括如下内容：
J2EE开发模式标准，JAVA开发规范、Oracle SQL与PL/SQL开发规范，JAVA异常设计与开发标准，Oracle数据库物理设计与逻辑设计规范，UML行为建模规范，UML结构建模规范，UseCase用例规约，通用组件包发布规格说明书，JUNIT单元测试规范，SIT集成测试规范，UAT测试规范，UAT测试用例模板，ECO申请标准模板，ClearCase版本服务器管理规范，LoadRunner压力测试规范，压力测试用例模板，WSAD开发工具配置规范，WAS应用服务器配置与管理规范，CM配置与管理规范，LDAP目录服务器配置与管理规范，standard.huawei.com站点发布与管理规范，页面原型设计规约，struts开发规范，html/jsp/css页面设计规范等。不在上述这些标准、规范/规约中列出的模板，参照CMM中的文档进行。
2、标准、规范/规约建设的计划
序号
需输出的标准、规范/规约
类别
1
J2EE开发模式标准
标准
2
JAVA开发规范
规范
3
Oracle SQL与PL/SQL开发规范
规范
4
JAVA异常设计与开发标准
标准
5
Oracle数据库物理逻辑设计规范
规范
6
UML行为建模规范
规范
7
UML结构建模规范
规范
8
UseCase用例规约
规范
9
通用组件包发布规格说明书
规范
10
JUNIT单元测试规范
规范
11
SIT集成测试规范
规范
12
UAT测试规范
规范
13
UAT测试用例模板
规范
14
ECO申请标准模板
规范
15
ClearCase版本服务器管理规范
规范
16
LoadRunner压力测试规范
规范
17
压力测试用例模板
规范
18
WSAD开发工具配置规范
规范
19
struts开发规范
规范
20
WAS应用服务器配置与管理规范
规范
21
CM配置与管理规范
规范
22
LDAP目录服务器配置与管理规范
规范
23
静态站点发布与管理规范
规范
24
页面原型设计规约
规范
25
html/jsp/css页面设计规范
规范
Add a comment
10:56 AM  | Permalink |Trackbacks (0) |Blog it
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!235.entry
集成线&标准线建设计划
集成线&标准线建设计划
一、   前言
在面向对象的IT应用开发领域，虽然已从面向精细组件（Delicate Component）的开发演化到面向服务（Service Oriented）的开发，但是即使在SOA（Service Oriented Architecture）异军突起、大有一统OOP（Object Oriented Programming）之势的今天，无论是SOA的粗粒度（Coarse grained）还是细粒度（Fine grained）服务，其基础仍然是各种精细对象或组件的开发，例如在RSA（Rational Software Architecture）工具中可通过现有的EJB、Java Bean等创建Web Service服务，因此基础的通用组件积累得越多，不但能够简化设计，而且能够大大提高开发的效率，同时确保代码的质量。
IT应用开发向来是团队性的工作，只有在IT应用开发的6个核心领域：分析、设计、开发、测试、部署、项目管理中参与项目团队的所有成员都遵循一致的标准、规范/规约，才能使团队获得一致或类似的输出，从而保障开发项目的质量。
集成线、标准线的建设是一项复杂的、奠定基业性的工作，其目标与输出的主要内容如下：
（1）         制定集成线通用组件（CBC，Common Base Components）建设的计划。
（2）         标准线涉及IT应用开发6个核心领域中标准、规范/规约制定的计划。
（3）         遵循业界开源组织的惯例，建设一个静态站点专门发布所有的通用组件、标准、规范/规约，发布的所有内容均包涵详细的版本，修订信息，Bug说明，使用范例等。
（4）         凝聚团队的智慧，建立指导性与实战性都极强的知识管理平台，大大提升新老员工的技能。
（5）         若坚持实行上述4点， IT开发与实施的水平将有质的飞跃，会大大缩短IT开发与技术实施类项目的周期，从而在公司高速发展的同时，IT仍然能够保持较快速的响应能力，且能适应业务的频繁变化。
二、   集成线通用组件的建设
1、通用组件建设主要包涵如下几个方面的内容
（1）         基础通用组件：
如Oracle/DB2数据库访问，LDAP目录服务器访问，CM访问，邮件访问，搜索引擎访问，文件上载/下载等。
（2）         应用通用组件：
如树状导航，Cascade层次导航，Rich Editor编辑器，通用用户登陆/注销/忘记口令/口令修改/帐号延期，BPEL工作流定制，CM工作流定制、权限授权/权限撤销，审计日志，异常处理，各种taglib标签库等。
（3）         系统通用组件：
如多线程的定时调度处理，各种中间代理demon等。
（4）         工具通用组件：
如通用的对象置换，比较两个对象是否相等，获取格式化的日期等，一般来讲工具组件提供的都是静态方法，即作用域直接属于类而不是类实例的方法。
2、通用组件建设计划
组件类别
序号
需建设的组件名称
基础组件
1
数据库访问工厂
2
LDAP目录服务器访问EJB
3
CM访问Bean
4
邮件访问Bean
5
搜索引擎访问工厂
6
文件上载
7
文件下载（端点续传）
8
常用对称与非对称加密包
应用组件
1
树状导航
2
Cascade层次导航
3
Rich Editor编辑器
4
通用用户登陆/注销/忘记口令/口令修改/帐号延期
5
BPEL工作流定制
6
CM工作流定制
7
权限授权/权限撤销
8
审计日志
9
异常处理
10
表现层常见的taglib，如Grid (Table)、ComboBox，ListBox，CheckBox，RadioBox、TreeView，翻页，等等
系统通用组件
1
多线程的定时调度
2
中间代理daemon
工具通用组件
1
如通用的对象置换，比较两个对象是否相等，获取格式化的日期等
Add a comment
10:36 AM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!234.entry
September 29
推荐几本书籍
0.设计模式:可复用面向对象软件的基础
1.J2EE核心模式
2.J2EE设计开发编程指南
3.J2EE without EJB(推荐)
4.企业应用架构模式
5.敏捷软件开发：原则、模式与实践
6.解析极限编程:拥抱变化
7.重构:改善既有代码的设计
8.测试驱动开发
9.统一软件开发过程


Add a comment
3:15 PM  | Permalink |Trackbacks (0) |Blog it |图书
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!232.entry
September 14
Amowa/AJAX
Ajax（Asynchronous JavaScript + XML）的定义
* XHTML 和 CSS 的标准表示；
* 使用 DOM（Document Object Model）进行动态显示及交互；
* 使用 XML 和 XSLT 进行数据交换及相关操作；
* 使用 XMLHttpRequest 进行异步数据查询、检索；
* 使用 JavaScript 将所有的东西绑定在一起。
Ajax 能够做什么？
如今 Google Suggest 和 Google Maps 使用了 Ajax，通过 Ajax，我们可以使得客户端得到丰富的应用体验及交换操作，而用户不会感觉到有网页提交或刷新的过程，页面也不需要被重新加载，应用的数据交换都被隐藏。
传统的 WEB 应用程序模型是这样工作的：用户的界面操作触发 HTTP 请求，服务器在接收到请求之后进行一些业务逻辑处理，如保存数据等，然后向客户端返回一个 HTML 页面。
但这种方式并没有给予用户很好的应用体验，当服务器在处理数据的时候，用户则处于等待的状态，每一步操作都需要等待，太多的等待会使用户越来越没有耐心。
而 Ajax 则大不相同，它通过 Ajax 引擎，使得应用过程很自然，操作很流畅，因为其只和服务器交换有用的数据，而页面显示等不必要的数据则不再重新加载。Ajax 引擎其实就是 JavaScript、XML、XMLHttpRequest 等等各项技术的综合应用。
传统 WEB 应用模型与 Ajax 应用模型的对比
当服务器在响应用户的请求时，用户在干什么呢？对，在等待。在任务的每一个步骤，用户都在做相同的事。
很明显，如果我们在系统设计时从scratch for applications的角度出发，用户就不会有漫长的等待。每当界面下载完毕，为什么和用户的每一次交互都会被等待所中断？
Ajax有什么不同?
Ajax应用利用了一种中间的媒介（Ajax引擎）消除了用户和服务器交互间的等待。这就像在传统的web模型中间加入了一层，可以降低响应时间。
替代页面下载的是，在Session刚开始时，浏览器下载一个用JavaScript编写的Ajax引擎，通常放在一个隐藏的框架里。这个引擎代替用户和服务器进行通讯。Ajax允许用户交互和服务器响应是异步的。这样用户就不会再看见那个后台操作的沙漏图标了。
传统的发生HTTP请求的模式被js调用Ajax引擎所替代。所有的响应不用再需要服务器返回，Ajax自己就可以操作。如果Ajax引擎需要服务器的响应，它就会异步的向服务器发出响应，通常用XML，不会再出现等待的情况。
当前都有谁在使用 Ajax
当前应用 Ajax 的已有不少网站，如：
*Orkut
*Gmail
*Google Groups
*Google Suggest
*Google Maps
*Flickr 的部分特性
*Amazon 的 A9.com 搜索引擎部分
Ajax 应用前景
Ajax 的最大挑战并不是技术，组成 Ajax 的各项技术已经相当成熟、稳定及易学，主要挑战是如何使用 Ajax 设计应用程序，我们必须抛弃以往对于 WEB 局限性的看法，开始开阔视野、开放思想、不断创新，实现更加丰富的应用体验。
And More From 《Qiantu‘s Weblog》
有人专门开发了一个名为SAJAX（Simple Ajax Toolkit）的工具包，Sajax是一个开源的工具包可以帮助那些网站更加方便的使用Ajax。 Sajax可以在不进行浏览器刷新的情况下，通过使用Javascript来轻松的调用ASP, Cold Fusion, Perl, PHP, Python 等Web应用程序的功能。
两个例子：涂鸦和计算器，将有助于理解什么是Ajax。
Add a comment
11:39 AM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!227.entry
java脚本语言Groovy,Jython,Rhino,JudoScript,Beanshell..
Add a comment
11:26 AM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!226.entry
分布式技术rmi,jini,corba,dcom,soap..
Add a comment
11:25 AM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!225.entry
内容管理系统
Add a comment
11:24 AM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!224.entry
September 08
学习曲线
学习计划：以Appfuse为中心实践。了解AXIS和Compiere,以后再深入研究。
1.学习gof 23中设计模式中的常用模式
结合Jive论坛源码和java与模式书籍（完成）
2.学习J2EE设计模式中的常用模式
结合petstore,ebay和J2EE核心模式书籍（完成）
3.研究support项目公用模块以及其他解决办法 (未完成)
权限管理，用户管理，导航树，搜索，缓存，上传下载等模块。
研究源代码 ACL,Lucene, OsCache etc.
4.学习Tiger新特性和EJB3.0新特性
结合文章资料，重点学习Annotation（完成）
5.温故Ant,Junit,学习xDoclet和Appgen.（完成）
结合书籍Eclipse in action, Junit in Action, xDoclet in Action
温故书籍测试驱动开发，重构，敏捷软件开发。
6.学习JSTL,Velocity,Sitemesh和Web流行框架（基本完成,JSF有待加强）
对照学习webwork,tapestry，JSF和struts。结合书籍JSTL in Action,Tapestry in Action, Struts in Action, JSF in Action.
7.学习Aop和Ioc以及几种流行实现方式（有待深入实践Appfuse）
结合书籍Spring in Action, Spring live, AspectJ in Action.
Aop:Spring Aop, AspectJ, AspectWerkz
Ioc:Spring Ioc,PicoContainer,Avalon
重点是Spring.
8.研究ORM技术（完成）
结合Hibernate in action学习。研究Hibernate和Mr. Persister源码。
自己动手写一个ORM框架(未进行)
9.学习研究Jakarta Commons(其他部分找时间学习)
重点是EL,Validator,BeanUtils,Lucene,Log,Velocity.
重点研究源代码,结合support项目公用模块。
10.学习Appfuse框架（进行中.....）
通过Appfuse一步步实践Struts+Spring+hibernate架构。采用测试驱动TDD开发方式，灵活运用Ant, Junit和Appgen xDoclet。选用Mysql,Tomcat和Eclipse.
11.学习工作流和SOA(后期计划)
学习Shark和Osflow,Compiere.
学习Web Service, SOA, AXIS
了解网格计算。
Add a comment |Read comments (2)
5:34 PM  | Permalink |Trackbacks (0) |Blog it |图书
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!218.entry
Appfuse框架
一、Appfuse简介
Appfuse是Matt Raible 开发的一个指导性的入门级J2EE框架，它对如何集成流行的Spring、Hibernate、iBatis、Struts、xDcolet、Junit等基础框架给出了示范，最新的1.8版本更是提供了对Taperstry和JSF的支持。在持久层，AppFuse采用了Hibernate O/R映射工具；在容器方面，它采用了Spring Framework。用户可以自由选择Struts、Spring/MVC，Webwork，Taperstry、JSF这几个web框架。采用TDD的开发方式，使用JUnit测试各层，甚至测试 jsp 输出的 w/o 错误。为了简化开发，预定义好了一套目录结构、基类、用来创建数据库、配置Tomcat、测试部署应用的 Ant 任务，帮助快速自动生成源程序和自动维护部分配置文件。
参考资料：
在https://appfuse.dev.java.net/可以下载Appfuse，目前的版本是1.8。
Appfuse的参考资料和文档可以在http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse查看。
二、Appfuse框架快速入门
AppFuse项目的主要目的是帮助开发人员减少在开始一个项目时所要做的工作。以下是使用它新建一个项目的基本步骤：
1、下载或从CVS (cvs -d :pserver:guest@cvs.dev.java.net:/cvs co appfuse)检出appfuse最新版本之源码。
2、安装J2SE 1.4+, 正确设置JAVA_HOME环境变量, 安装Ant 1.6.2+, 设置ANT_HOME环境变量。
3、安装MySQL 3.23.x+ (建议使用 4.1.7版本)和Tomcat 4.1.x+ (建议使用 5.0.28版本)，设置CATALINA_HOME环境变量指向你Tomcat安装目录。
4、安装一个本地的SMTP服务器，或者如果你已经有一个可用的SMTP服务器的话，你可以去修改mail.properties (在web/WEB-INF/classes目录下) 和build.properties (在根目录下 -- 为 log4j信息) 以指向你的SMTP服务器 - 默认地它是指向你的本机的SMTP服务器的。
5、将lib/junit3.8.1/junit.jar文件拷贝到$ANT_HOME/lib目录下。
6、执行 ant new -Dapp.name=YOURAPPNAME -Ddb.name=YOURDBNAME 命令。这将创建一个名为“YOURAPPNAME”的目录。
警告: 该命令对于某些app.name值将不执行 - 不要使用 "test"，任何包含 "appfuse" 在其中的名你，或者任何以数字、两个存折号(-) 等等混合出来的名称。
7、转到新的目录，执行ant的setup任务创建数据库，同时将你的应用发布到Tomcat服务器上。只有当你的root用户没有口令建库的任务才会工作。你也可以在需要的时候打开build.properties文件去更改这root用户的口令。如果你想进行测试并且希望了解是否所有方面均可以工作完好，那么你可以执行ant的test-all任务进行全面的测试 -当然前提是当你做测试的时候先将Tomcat服务器停止。
8、执行ant的test-reports任务 - 当这个任务执行完后，会有一条消息告诉你如何查看那些产生的测试报告。
当你确定你通过以上步骤配置好你的AppFuse开发环境后 - 下面你需要做的事就是学习一下指南来了解如何使用 AppFuse 进行你的开发。
可选择的安装
如果你愿意选择用iBATIS做为你的持久层框架，请专门去看一下extras/ibatis目录下的 README.txt 文件。
如果你愿意选择用Spring做为你的WEB层框架，请专门去看一下extras/spring目录下的 README.txt 文件。
如果你愿意选择用WebWork做为你的WEB层框架，请专门去看一下extras/webwork目录下的 README.txt 文件。
如果你愿意选择Tapestry做为你的web层框架，请专门去看一下extras/tapestry目录下的 README.txt 文件。
如果你愿意选择JSF做为你的web层框架，请专门去看一下extras/jsf目录下的 README.txt 文件。
如果你希望你能够通过脚本来自动地完成创建和测试，那么可以参考以下的脚本：
rm -r ../appfuse-spring
ant new -Dapp.name=appfuse-spring -Ddb.name=ibatis
cd ../appfuse-spring
ant install-ibatis install-springmvc
cd extras/ibatis
ant uninstall-hibernate
cd ../..
ant setup
ant test-all test-reports
如果你并不想安装iBATIS, Spring MVC 或者 WebWork，在你将你的项目放入代码控制仓库前你应该删除掉它们在extras目录中的安装内容。
--------------------------------------------------------------------------------
通常当你完成了以上所有步骤并使它们可以工作后，最可能的事是你会希望把“org.appfuse”包名，改为类似“com.company”这样的包名。现在做这件事已经非常简单了，所有你需要做的事就是下载一个改包名的工具，看看它的README文件，以了解它的安装和使用。
注意: 使用这个工具前你最好是将你的项目做一个备份，从而保证能够恢复它。
如果你将org.appfuse.webapp.form包改为如test.web.form这样的包名，你得同时去修改一下src/service包中的ConverterUtil类，getOpposingObject方法是你的朋友，让我们来看一下：
name = StringUtils.replace(name, "model", "webapp.form");
name = StringUtils.replace(name, "webapp.form", "model");
三、AppFuse 开发指南
如果你已经下载了AppFuse并且想在你的机器上安装它，你最好按照快速入门中的步骤进行安装。一旦你已经将所有的内容安装好后，以下的指南是你学习如何使用AppFuse进行开发的最好的教程。
注意: 这个开发指南在AppFuse的发布版本中同样包含一份，如果你想更新在你的工程中的那份拷贝（它在docs目录中），可以通过执行 "ant wiki"来完成。
从 1.6.1 版本开始，你可以产生这个指南所包含的源代码。如果你使用 Struts+Hibernate，你可以产生所有的源代码，如果使用Spring 或者 WebWork，因为写专门的安装程序比较麻烦所以你需要手工配置 Controllers 和 Actions。造成这个局面的主要原因是我没有为这些 web framework 使用 XDoclet 从而使得基于ant的安装程序功能受到了限制。 AppGen 工具可以产生所需要的全部源代码。
还有另外一个AppFuse Generator 项目建立的工具有类似AppGen的功能。
第一部分： 讲述如何创建POJO(对应相应的数据表)和 DAO（管理POJO持久化操作的对象）。
第二部分： 讲述如何创建一个 Business Facades ，它可以跟数据层 (DAOs)和web 层 (Actions 或 Controllers)交互。
第三部分： (Struts)讲述如何创建在你自己的appfuse工程里面创建Actions和JSPs。包括生成JSP并且进行修改定制让它们好看一点。此外，你需要编写WebTest来测试这个JSP的功能。其他可选的web framework如下所示：
Spring, Webwork, Jsf, Tapestry
第四部分: (Struts) 增加一个验证personForm的firstName和lastName为必填项的校验逻辑，并且增加一个列表面显示数据库中所有的person记录。
Add a comment
9:43 AM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!216.entry
Ant
Ant 的安装
Ant安装很简单，只要你从apache网站上下载他的zip包，然后解压到任何本地磁盘上，在环境变量中添加 Path 的值加上 %ANT_HOME%/bin 就可以了，这样在Dos提示符中就可以使用 ant 这个命令了。其他的你需要设置一下 ANT_HOME 这个环境变量为你解压后的目录。还有就是你要检查一下你的JDK安装目录JAVA_HOME是不是加到你的环境变量里面去了。
使用概述
使用ant 也同样是非常简单的事。通常的做法就是在你的项目里面建立一个XML文件，名字通常可以取 build.xml 。当然你可以取任何你喜欢的名字。这个文件就是你需要ant为你项目做的一些辅助性工作的批处理文件。他的格式可能是这样的。我们先不具体说ant 标记，先有一个感性的认识会比较快的上手。
例子：











target="clean" inheritAll="false" />


target="jar" inheritAll="false" />


target="clean" inheritAll="false" />


target="jar" inheritAll="false" />


target="clean" inheritAll="false" />


这个build.xml 文件引自apache的一个项目。里面可以看到有 project 以及target 标签。有些项目的build.xml可能不是以“?xml version="1.0" encoding="UTF-8"?”开头的，不过没关系，以后再说明。每一个build.xml 只能有一个project 标签， 每个project 标签里面包含了几个tartget标签。每一个target可以独立执行或者依赖于其他target执行完毕才能执行。
以下是一个典型的例子。




当中target A 可以独立执行，但是B、C、D 则依赖于其他target才可以执行，也就是说，执行D, ant 就会按照 A- B- C 这样的顺序先执行其他target。
Project 标签里面有一个 default="all" ，这就是说明了在默认情况下 all 这个target 会被执行。
定义变量
在这个文件中没有看到属性定义，其实如果你想使用定义变量的话，可以在project 标签下 定义如这样的标签




这样你在引用的时候就可以使用形如${build}

……

……

这样的变量了，省得自己去修改每一处需要用到变量的地方
添加目录操作





这里的dist.dir 等用${}括起来的，是我们定义的变量。
编译java文件的操作





这里说一下 javac 这个任务标签，其中看到 有 srcdir 、destdir、debug 、encoding 等属性，还有一个 classpath 的子标签。Srcdir就是目标source,需要编译的源文件，destdir就是目的地，编译出来的class的存放地。Debug参数是指明source是不是需要把debug信息编译进去，如果不加这个参数等于在命令行后面加上 -g:none 这个参数。Encoding 这个参数指明以何种编码方式编码你的source文件，对于有中文文字的代码来说这项比较重要。
Classpath 指明了你需要应用的jar包，或者其它class文件的所在地，这也是非常重要的一项选项。使用方式有以下几种。

…….





……

作为classpath 引用预先定义的jar包位置,refid 指明了一个引用变量。一般在real-world情况下会这样使用。简单的使用是这样的：
destdir="${build}"
classpath="xyz.jar"
debug="on"
/>
这就简单了点。
打jar包操作

这个就是把编译好的文件打成jar包的ant 脚本，和上面javac一样，可以放在任意位置。很明显destfile 就是 你想要打成的包，basedir就是你的目标class文件,其它的复杂参数手册上都有，可以对照参考。

excludes="**/Test.class"
/>


上面这段脚本也很容易理解，就是除了Test.class文件以外，把一个source的resource目录，连同编译后的class脚本一起打进app.jar包内。
复制文件操作






上面脚本很容易理解。 Todir 指定了需要拷贝的地点，overwrite 是否需要覆盖，flatten是否忽略目的目录结构，只得是不管什么目录，直接拷贝文件到目的地，丢弃其所在结构。




选定除了j2ee.jar包以外的所有在lib.dir变量所定义的包下面的jar包
其它拷贝样式

单文件拷贝

文件到目录拷贝



目录对拷贝
比较有用的命令






拷贝 sr_dir 目录到 backup/dir目录，并且把所有文件中的 @TITLE@ 替换成 Foo Bar 。还有很多用法，等到要使用的时候可以去查手册。
删除操作




以上操作也是很容易理解的。
执行ant 脚本
在有build.xml 的目录提示符下使用 ant 就可以了。如果是其他的名字，那就使用ant -buildfile 文件名 ，就可以了。
Add a comment
9:34 AM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!215.entry
September 06
Web Service,SOA与AXIS
Add a comment
5:27 PM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!207.entry
Spring Ioc与PicoContainer
Add a comment
5:26 PM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!206.entry
Spring中的AOP简单使用
AOP作为Spring这个轻量级的容器中很重要的一部分，得到越来越多的关注，Spring的Transaction就是用AOP来管理的，今天就通过简单的例子来看看Spring中的AOP的基本使用方法。
首先确定将要Proxy的目标，在Spring中默认采用JDK中的dynamic proxy，它只能够实现接口的代理，如果想对类进行代理的话，需要采用CGLIB的proxy。显然，选择“编程到接口”是更明智的做法。
下面是将要代理的接口：
public interface FooInterface {
public void printFoo();
public void dummyFoo();
}
以及其一个简单的实现：
public class FooImpl implements FooInterface {
public void printFoo() {
System.out.println("In FooImpl.printFoo");
}
public void dummyFoo() {
System.out.println("In FooImpl.dummyFoo");
}
}
接下来创建一个Advice，在Spring中支持Around,Before,After returning和Throws四种Advice，这里就以简单的Before Advice举例：
public class PrintBeforeAdvice implements MethodBeforeAdvice {
public void before(Method arg0, Object[] arg1, Object arg2) throws Throwable {
System.out.println("In PrintBeforeAdvice");
}
}
有了自己的business interface和advice，剩下的就是如何去装配它们了，首先利用ProxyFactory以编程方式实现，如下：
public class AopTestMain {
public static void main(String[] args) {
FooImpl fooImpl = new FooImpl();
PrintBeforeAdvice myAdvice = new PrintBeforeAdvice();
ProxyFactory factory = new ProxyFactory(fooImpl);
factory.addBeforeAdvice(myAdvice);
FooInterface myInterface = (FooInterface)factory.getProxy();
myInterface.printFoo();
myInterface.dummyFoo();
}
}
现在执行程序，神奇的结果就出现了：
In PrintBeforeAdvice
In FooImpl.printFoo
In PrintBeforeAdvice
In FooImpl.dummyFoo
虽然这样能体会到Spring中AOP的用法，但这决不是值得推荐的方法，既然使用了Spring，在ApplicationContext中装配所需要 的bean才是最佳策略，实现上面的功能只需要写个简单的applicationContext就可以了，如下：

"http://www.springframework.org/dtd/spring-beans.dtd">

The aop application context




FooInterface






myAdvice




当然，main中的代码也要进行相应的修改：
public static void main(String[] args) {
ClassPathXmlApplicationContext context = new
ClassPathXmlApplicationContext("applicationContext.xml");
FooInterface foo = (FooInterface)context.getBean("foo");
foo.printFoo();
foo.dummyFoo();
}
现在运行一下，结果将和上面的运行结果完全一样，这样是不是更优雅？当需要更改实现时，只需要修改配置文件就可以了，程序中的代码不需任何改动。
但是，这时候会发现被proxy的object中的所有方法调用时都将运行advice中的before，这显然不能满足绝大多数情况下的需要，此时，只 需借用Advisor就可以了，当然要在Advisor中利用pattern设置好哪些方法需要advice，更改applicationContext 如下：

"http://www.springframework.org/dtd/spring-beans.dtd">

The springeva application context


class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">




.*print.*




FooInterface






myAdvisor




主程序不需进行任何修改，运行结果已经变样了
In PrintBeforeAdvice
In FooImpl.printFoo
In FooImpl.dummyFoo
至此，应该已经理解了Spring中AOP的使用方法，当然Spring中AOP最重要的应用是Transaction Manager，举个这方面的applicationContext例子看看：



class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">

/WEB-INF/jdbc.properties


class="org.springframework.jdbc.datasource.DriverManagerDataSource">

${jdbc.driverClassName}


${jdbc.url}


${jdbc.username}


${jdbc.password}


class="org.springframework.orm.hibernate.LocalSessionFactoryBean">




smartmenu.hbm.xml



${hibernate.dialect}



class="org.springframework.orm.hibernate.HibernateTransactionManager">









class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">








PROPAGATION_REQUIRED,readOnly
PROPAGATION_REQUIRED,readOnly




要想彻底理解Spring的AOP，最好还是多看看源码，开源就是好啊！
Add a comment
4:08 PM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!205.entry
Aspectwerkz动态实现AOP
目前最成熟、功能最丰富的AOP框架当数AspectJ，AspectJ已成为大多数其它框架跟从的标准。但是，AspectJ也走出了非同寻常的一步，它的实现为Java语言增添了新的关键词。虽然新的语法并不难学，但却意味着我们必须换一个编译器，还要重新配制编辑器，只有这样才能适应新的语法。在规模较大的开发组中，这些要求可能难以办到，因为整个开发小组都会受到影响。由于语言本身的变化，开发小组把AOP技术引入到现有项目的学习周期随之延长。
现在我们需要的是这样一个框架，它可以方便地引入，且不会对原来的开发和构造过程产生任何影响。满足这些要求的框架不止一个，例如JBoss AOP、Nanning、Aspectwerkz（AW）。本文选用的是Aspectwerkz，因为它可能是最容易学习的框架，也是最容易集成到现有项目的框架。
Aspectwerkz由Jonas Boner和Alexandre Vasseur创建，它是目前最快速、功能最丰富的框架之一。虽然它还缺乏AspectJ的某些功能，但己足以满足大多数开发者在许多情形下的需要。
Aspectwerkz最令人感兴趣的特性之一是它能够以两种不同的模式运行：联机模式和脱机模式。在联机模式下，AW直接干预属于JVM的底层类装入机制，截取所有的类装入请求，对字节码实施即时转换。AW提供了干预类装入过程的许多选项，另外还有一个替代bin/java命令的封装脚本，这个脚本能够根据Java版本和JVM能力自动生成一组可运行的配制。对于开发者，联机模式有许多优点，它能插入到任何类装入器并在类装入期间生成新的类。也就是说，我们不必手工修改应用程序的类，只要按通常的方式部署即可。不过，联机模式要求对应用服务器进行额外的配制，有时这一要求可能很难满足。
在脱机模式下，生成类需要二个步骤。第一步是用标准的编译器编译，第二步是重点——以脱机模式运行AWcompiler编译器，让它处理新生成的类。编译器将修改这些类的字节码，根据一个XML文件的定义，在适当的point-cut插入advice。脱机模式的优点是AWcompiler生成的类能够在任何JVM 1.3以上的虚拟机运行，本文下面要用的就是这种模式，因为它不需要对Tomcat作任何修改，只要对构造过程稍作修改就可以照搬到大多数现有的项目。
AspectWerkz 主要特性：
1．运行时和加载时字节码修正：你可以在运行时或编译时轻松的改造任何（旧）应用程序或除了rt.jar以外的外部类库
2．支持join point模型
3．支持Annotation：匹配JavaDoc和JSR-175，支持用户自定义Annotation
4．支持部署多个Aspect定义文件到部署的应用程序（WEB-INF/aop.xml、META-INF/aop.xml）
5．Introduction/内类型声明（也称Mixin），也就是具有添加接口和实现到已存在的类中的能力
6．Annotation定义：定义Aspect使用的运行时Annotation（为JSR-175准备）
7．XML定义：定义Aspect使用的XML；XML可以用来精炼、改写和解析Annotation定义
8．插件式Aspect管理器能够和IoC框架（如Spring或PicoContainer）一起工作
9．四种不同的Advice和Introduction部署模型（范围）：perJVM（单模式）、 perClass、perInstance 和perThread
10．Advice和Introduction能够动态部署、反部署或重新部署
11．高性能，使用JIT编译
12．使用Fine-grained模式语言选择join point
13．所有Advice能够和所有的join point和各种混合类型的pointcut
14．脱机变换（可以用作后处理器）
15．Aspect、Advice和Introduction使用POJO编码
16．目标类可以是正规的POJO，也就是不需要接口
17．支持通过定义传递参数给Advice和定义可重用的Advice堆栈
18．元数据被加到类中
19．简单的用法和配置
开始AOP
1）这里我们要在屏幕打印出“Hello AOP!”，看如下代码：
//HelloAOP.java
public class HelloAOP {
public static void main(String args[]) {
HelloAOP ha = new HelloAOP();
ha.test();
}
public void test() {
System.out.println("Hello AOP!");
}
}
编译HelloAOP.java文件：javac HelloAOP.java
2）现在我要在输出“Hello AOP!”前后做一些工作，这些工作在运行时会得到调用机会，如果使用AOP术语，我们可以说我们要编写我们的aspect，这个aspect会在运行时被weave into （织入）HelloAOP class。
//MyAspect.java
import org.codehaus.aspectwerkz.joinpoint.JoinPoint;
public class MyAspect {
public void beforeTesting(JoinPoint joinPoint) {
System.out.println("before testing...");
}
public void afterTesting(JoinPoint joinPoint) {
System.out.println("after testing...");
}
}
javac MyAspect.java
3）织入过程并不简单，我们需要撰写一个描述文件来将aspect和其织入的class中的信息联系起来。
//aop.xml









4)run it
aspectwerkz -Daspectwerkz.definition.file=aop.xml HelloAOP
//output:
before testing...
Hello AOP!
after testing...
Everything is fine!
Add a comment
3:37 PM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!204.entry
AOP的几种Java实现方式
据统计，目前与AOP相关的项目已达近百种，而基于Java的AOP实现机制也有二十多种，以下所列举的是商业上得到成熟应用的几种基于Java的AOP的实现机制。
AspectJ
AspectJ是目前最完善的AOP语言，由AOP的首倡者Gregor Kiczales领导的一个小组提出并得到发展。AspectJ是对Java编程语言的扩展，通过增加了一些新的构造块支持对横切关注点的模块化封装，通过对源代码级别的代码混合实现织入，是一种典型的使用静态织入的AOP实现机制。AspectJ提供了两种横切实现机制，一种称为动态横切（Dynamic Crosscutting），另一种称为静态横切（Static Crosscutting）。
动态横切是指在程序执行的某一个明确的点上运行额外的，预先定义好的实现，是一种静态实现机制，并非是动态的。为了实现动态横切，AspectJ中引入了四个新的概念：连接点（Join Point），切入点（Pointcut），参考（Advice）和方面（Aspect）。连接点是明确定义的程序执行过程中的一个点，切入点则是指一组相关的连接点，参考定义了在连接点执行的额外实现，方面则是指对横切关注点的模块化封装实现的单元，类似于AOP中的类，由切入点，参考与普通的Java成员声明组成。如前所述，连接点是程序执行中明确定义的点，比如，类接受到方法调用时，方法调用时，属性访问时都是连接点的例子，在连接点处可以执行预定义的额外实现。而要指明在哪些连接点上执行，则需要定义切入点，切入点可以在程序运行时匹配特定的连接点，AspectJ中预定义了一系列标准切入点，包括方法与构造器的调用，接受调用，执行，域的get，set访问，异常处理，实例类型匹配，处于类或方法体中，控制流中，调用者调用方法，类型的初始化与静态初始化，通过这些预定义切入点的组合可以实现自定义的、复杂的切入点。在编译时，方面中的参考将被转化为标准的方法，类代码中匹配切入点的连接点将被转化为一个静态的标记点，然后，这些静态的点将被对参考所转化成的方法的调用所取代，由此完成两种代码的织入，最后对织入完成的代码编译为字节码，即完成了整个编译过程。目前，AspectJ即支持编译前的预处理方式实现代码的织入，也支持编译后的字节码操作。
静态横切是指对已存在的类型定义引入新的方法，属性等，与动态横切不同，静态横切不改变类型的动态行为，而是改变其静态结构，也即导入（Introduction）。通过在方面代码中声明方法，属性，需要继承的超类，接口等，在代码织入时，可以改变应用此方面的类的定义。
AspectWerkz
AspectWerkz是一个动态的AOP框架，利用对字节码的修改实现方面的织入，并使用Java虚拟机的动态替换字节码的能力实现动态AOP的要求。AspectWerkz没有扩展Java语言，方面、参考、切入点等均使用标准的Java构造块，即类以及方法来实现，并使用XML文件定义这些构造块，此外AspectWerkz还支持使用JavaDoc标记实现的运行期属性定义。AspectWerkz采用了与AspectJ相似的连接点模型，只是支持的连接点种类少于AspectJ，参考的类型一致。
AspectWerkz通过引入一个间接层，方面容器（Aspect Container）以及对字节码的转化，即代码织入实现动态AOP的要求，方面容器管理部署好的类、方面代码，并根据XML文件或JavaDoc注释中定义的方面，参考，切入点等得到连接点处相关的方面信息，并在程序的执行中控制执行流程，在匹配的连接点处执行适当的参考。
AspectWerkz通过类载入层次的适当位置拦截类载入从而实现字节码的修饰。AspectWerkz提供了两种织入模式实现AOP：静态织入以及动态织入。静态织入只在类载入时对字节码作一次性的转化，通过将类的方法实现移入AspectWerkz命名的方法中，将原方法中的代码改写，由方面容器调用适当的参考，并调用前述AspectWerkz添加的方法从而完成代码的织入。导入则由混合类型（Mixin）实现，用于为类增加新的方法，混合类型是一种使用接口与实现类的方式模拟多重继承的机制。AspectWerkz通过修改字节码使被导入的类实现混合类型的接口，并在接口定义的方法中，将控制交给容器管理器，由它来完成对实现的调用。静态织入可以在运行时动态的为切入点增加，删除参考，可以引入新的参考，但是无法定义新的切入点，这需要动态织入。动态织入由两阶段织入完成，分别为类载入阶段与激活阶段。首先，在类载入时，按照静态织入的方法，为需要实现动态织入的类的每个方法添加一个相应的空的方法，匹配连接点的方法除外。然后，在激活阶段，原方法体中的代码将被交换到类载入时新产生的方法中，原方法将实现静态织入时相同的处理，从而方面容器控制流程。前述代码交换是由热交换（HotSwap）实现的，这是JVM提供的API。通过方面容器与织入模型，AspectWerkz提供了动态AOP的实现。
SpringFramework
SpringFramework是一个采用了反转控制（Inversion of Control, IoC）策略的基于J2EE的轻量级应用框架。SpringFramework的核心是IoC容器，对于其它应用，如数据库访问，日志等，SpringFramework多使用现有的、成熟的框架。SpringFramework采用了模块化的方式，各模块可以共同使用，也可以单独使用其中的一个模块， SpringFramework的一个模块提供了对动态AOP的支持，SpringFramework中提供的声明式事务管理就是基于动态AOP的。
SpringFramework中AOP的实现基于动态代理（Dynamic Proxy）， 动态代理源于代理模式，即通过接口实现对业务对象的访问，但动态代理无需为每一个需代理的业务对象静态的生成代理对象，只需提供需要代理的接口与代理实现，就可以在运行时动态的生成代理对象，代理对上述接口的访问，同样的机制也使用于对类的代理，使用类似于修饰者的模式，通过子类化实现。SpringFramework默认使用JDK提供的动态代理机制，此时，业务对象通过接口编程，若需要代理对类的访问，则需要使用CGLIB，这是一个开源的动态代理实现。
SpringFramework的AOP实现不同于AspectJ与AspectWerkz，它不是完全的AOP实现，而是设计用于在应用服务器环境下实现AOP，与SpringFramework的IoC容器配合使用。SpringFramework中参考，切入点与方面均由普通Java对象实现，其中连接点模型与AspectJ相同，只是远不如AspectJ丰富，目前只提供对方法调用的拦截。有4种类型的参考，分别为方法调用时，之前，返回时与抛出异常时，通过实现SpringFramework的参考接口可以自定义参考类型。在SpringFramework中，方面称为Advisor，是一个包含参考与切入点的Java类。像其它由IoC容器管理的组件一样，参考，切入点与方面也由IoC容器管理 ，由XML配置文件定义。配置的内容包括业务对象的接口与实现，自定义的或由SpringFramework提供的切入点与参考类，或使用Adviser类取代单独的切入点与参考类。在运行时，通过IoC容器进行名称查找，就可以由容器使用代理机制自动产生代理对象，并在符合切入点定义的连接点处执行参考。SpringFramework除自身实现的AOP框架外，还在寻求与其它AOP实现机制的整合，目前已经实现了与AspectJ的整合，以利用AspectJ丰富的切入点语法，并利用AspectJ的方面实现。
JBoss
JBoss是一个开源的符合J2EE规范的应用服务器，作为J2EE规范的补充，Jboss中引入了AOP框架，为普通Java类提供了J2EE服务，而无需遵循EJB规范。Jboss通过类载入时，使用Javassist对字节码操作实现动态AOP框架，Javassist是一个开源的编辑字节码的类库。
Jboss中参考，切入点与方面也由普通Java对象实现，并使用XML文件配置。Jboss的连接点模型与AspectJ略有不同，提供了一系列预定义的切入点，包括类匹配，方法调用，构造器调用，域访问，特定的调用与被调用关系。通过这些切入点的逻辑运算，可以实现更为复杂的切入点。方面为Java类，参考是其中的一个方法，方面中不含切入点，方面主要为各种拦截器（Interceptor），拦截器即为只含一个参考的方面，单一连接点上可由多个拦截器形成拦截器链，拦截器执行额外的操作。对方法的拦截由Advisor类管理，在连接点依次调用拦截器，并最终调用被逻辑的方法。而关于切入点，参考已及方面的信息由AspectManager管理。此外，Jboss提供对元数据的支持，用于为类，方法，构造器以及域添加额外的属性，并可在运行期访问。
为实现拦截，Jboss需要修改类的字节码，大致过程如下。XML配置文件中关于切入点，拦截器，元数据以及混合类的信息在应用程序部署时被读入、解析，并生成相应的对象，这些信息与实例化的对象由AspectManager管理。在需要混入方面代码的类载入时，AspectManager将创建Advisor类，将方面相关信息传递给它，并对类的字节码进行修改，之后将修改过的字节码交给类载入器完成类的装载。字节码的修改主要是对被载入的类添加一系列方法用于代理那些匹配连接点的方法调用，构造器调用，域访问以及方法导入，转为对Advisor类相应方法的调用。类中各方法将重命名，保留原方法体，并添加一个与原方法同名的方法，在这个方法中调用那些代理方法，用来将调用代理给Advisor类，或调用重命名的原方法。对于域访问，分别添加两个方法，对应于读与写操作，将域访问代理至Advisor类，在访问这个域的类中，则需将对域的访问转换为对上述方法的调用。对于构造器调用，则添加一个方法，将调用代理至Advisor类，并对构造对象的类的构造代码作相应转换。对于导入，被导入的类中将添加一个混合类实现的引用，并添加混合类接口中的方法，将对混合类方法的调用代理至Advisor类，并最终调用混合类的实现。相关类载入后，初始化Advisor类，填入拦截器链，以完成整个处理过程。
Add a comment
3:04 PM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!203.entry
September 05
AspectJ如何实现AOP
使用AspectJ,我们不用对原有的代码做任何修改,就可以为代码提供不同的Aspect(方面)--比如,认证,事务等。我们只需要提供两个不同的Aspect--认证Aspect和事务Aspect。
比如，我们有一个Bank（银行）类。Bank有两个方法，deposit（存钱）和withdraw（取钱）。
class Bank {
public float deposit(AccountInfo account, float money){
// 增加account账户的钱数，返回账户里当前的钱数
}
public float withdraw(AccountInfo account, float money){
// 减少account账户的钱数，返回取出的钱数
}
}
这两个方法涉及到用户的账户资金等重要信息，必须要非常小心，所以编写完上面的商业逻辑之后，项目负责人又提出了新的要求--给Bank类的每个重要方法加上安全认证特性。
于是，我们不得不分别在上面的两个方法中加入安全认证的代码。
class Bank {
public float deposit(AccountInfo account, float money){
// 验证account是否为合法用户
// 增加account账户的钱数，返回账户里当前的钱数
}
public float withdraw(AccountInfo account, float money){
// 验证account是否为合法用户
// 减少account账户的钱数，返回取出的钱数
}
}
这两个方法都需要操作数据库，为了保持数据完整性，项目负责人又提出了新的要求--给Bank类的每个操作数据库的方法加上事务控制。
于是，我们不得不分别在上面的两个方法中加入安全认证的代码。
class Bank {
public float deposit(AccountInfo account, float money){
// 验证account是否为合法用户
// Begin Transaction
// 增加account账户的钱数，返回账户里当前的钱数
// End Transaction
}
public float withdraw(AccountInfo account, float money){
// 验证account是否为合法用户
// Begin Transaction
// 减少account账户的钱数，返回取出的钱数
// End Transaction
}
}
我们看到，这些与商业逻辑无关的重复代码遍布在整个程序中。实际的工程项目中涉及到的类和函数，远远不止两个。如何解决这种问题？
我们首先来看看OOP能否解决这个问题。
我们利用Design Pattern的Template Pattern，可以抽出一个框架，改变上面的例子的整个设计结构。
abstract class Base {
public float importantMethod(AccountInfo account, float money){
// 验证account是否为合法用户
// Begin Transaction
float result = yourBusiness(account, money)
// End Transaction
return result;
}
protected abstract float yourBusiness(AccountInfo account, float money);
}
class BankDeposit extends Base{
protected float yourBusiness(AccountInfo account, float money){
// 增加account账户的钱数，返回账户里当前的钱数
}
};
class BankWithdraw extends Base{
protected float yourBusiness(AccountInfo account, float money){
// 减少account账户的钱数，返回取出的钱数
}
};
这里我们用一种很勉强的方法实现了认证和事务代码的重用。而且，有心的读者可能会注意到，这种方法的前提是，强制所有的方法都遵守同样的signature。
如果有一个转账方法transfer(AccountInfo giver, AccountInfo receiver, float money)，由于transfer方法的signature不同于yourBusiness的signature，这个方法无法使用上面的框架。
这个例子中提到的认证，事务等方面，就是AOP所关心的Aspect。
AOP就是为了解决这种问题而出现的。AOP的目的就是-- Separation of Concerns.
下面介绍AspectJ工具如何解决Separation of Aspects的问题。
我们只需要提供两个不同的Aspect--认证Aspect和事务Aspect。
aspect AuthAspect {
pointcut bankMethods() : execution (* Bank.deposit(…)) || execution (* Bank. withdraw (…));
Object around(): bankMethods(){
// 验证account是否为合法用户
return proceed();
}
}
aspect TransactionAspect {
pointcut bankMethods() : execution(* Bank.deposit(…)) || execution (* Bank. withdraw (…));
Object around(): bankMethods(){
// Begin Transaction
Object result = proceed();
// End Transaction
return result;
}
}
我们用AspectJ编译器编译Bank文件和含有aspect的这个文件，出来的结果就是带有安全认证和事务处理的Bank类。编译出来的这个Bank类调用了AspectJ Runtime Lib，所以，如果你要运行这个Bank类，你需要把AspectJ Runtime Lib设置在你的classpath里面。
我们来看看，AspectJ编译器为我们做了什么事情。
1.       首先，AspectJ从文件列表里取出所有的文件名，然后读取这些文件，进行分析。
2.       AspectJ发现一些文件含有aspect的定义，在这个例子里，就是AuthAspect和TransactionAspect的定义；这些aspect就是代码生成规则。
3.       AspectJ根据这些aspect代码生成规则，修改添加你的源代码。在这个例子里，就是修改添加Bank文件。
4.       AspectJ读取AuthAspect的定义，发现了一个pointcut--bankMethods()；这个pointcut的定义是execution(* Bank.deposit(…)) || execution(* Bank. withdraw (…))，表示所有对Bank类的deposit和withdraw方法的执行点。
5.       AspectJ继续读取AuthAspect的定义，发现了一个around()，这在AspectJ中叫做Advice， Advice允许你在某个类的方法的调用之前或调用之后，加入另外的代码。所示代码中的around()的" // 验证account是否为合法用户"部分，就是要加入的代码。这段代码要加在哪里呢？around()后面跟了一个pointcut--bankMethods()。根据这个pointcut，AspectJ会把这段代码加入到Bank.deposit和Bank.withdraw两个方法的执行之前。
6.       AspectJ读取TransactionAspect的定义，象第（4）步一样，发现了发现了一个pointcut--bankMethods()。
AspectJ继续读取AuthAspect的定义，发现了一个around()。这次AspectJ把"Begin Transaction"和"End Transaction"两段代码加在Bank.deposit和Bank. withdraw两个方法的执行前后。
Add a comment
11:30 AM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!202.entry
August 30
流程驱动面向服务的架构
分离关注，松散耦合是软件系统开发的一个目标，Aop & Ioc是这种思想很好的诠释。下面要介绍的SOA和Workflow是这种思想更高层次的应用。
传统的软件系统中，业务逻辑没有被分离。直到Workflow引擎的不断开发，业务逻辑才逐渐从整个系统中被单独分离。加上SOA这一概念，让业务逻辑采用松耦合的调用机制，粗粒度的服务也让系统的使用者更易操作。本人将两个概念结合起来，谈如何用Workflow来驱动SOA。
引言
传统的三层架构(表示层，业务逻辑层，数据访问层)应用由于业务流程逻辑被硬编码于程序代码中，并且采用了紧耦合的功能调用机制，使得应用系统缺乏敏捷性和互操作性。本文提出了一个流程驱动面向服务的架构，它采用了松耦合的web服务调用机制。它使得系统设计不再是以对象，接口和组件等技术术语为中心，而是以流程和服务为中心。它将流程提升到架构的中心地位，形成独立的流程层，采用业务流程管理系统实现流程的独立管理和控制，提升了流程动态调整的能力，从而大大提升了系统的敏捷性。
传统的业务流程处理问题
传统的两层或者多层应用架构存在以下问题:
1.业务流程硬编码于程序中，无法可视化，不利于分析和设计
2.无法方便地修改和调整代码以适应流程变化。
3.流程设计到流程实现需要大量人工转换，效率低，代码可能脱离需求
4.多种应用标准(COM, J2EE)导致互操作和集成困难
5.系统集成采用转有技术，成本高，维护困难
新技术的解决之道
本文为解决长期以来困扰企业系统建设中存在的系统隔离，缺乏灵活性等问题，提出了一种不同于传统应用架构的新的应用架构，称之为”流程驱动面向服务的架构”——PdSoA。该架构充分采用了XML, WebService和BPM(Business Process Management)等新的技术，为构造敏捷的，互操作的应用打下了坚实的基础。
首先，XML为数据描述提供了一种通用的，开放的，平台无关的表示方案，它已成为系统间数据交换的标准格式。
其次，WebService技术的出现极大的简化了程序功能的调用，特别是跨组织(异构)的远程调用，这对跨组织的应用集成具有重要意义。
但是，离散的，孤立的Web服务尚不足以发挥最大的价值，而将各种相关的Web服务组合连结起来，形成完整的业务流程将会给企业带来突破性的效益。此时BPM可以发挥它的威力了。它使得应用开发范式由传统的面向对象的范式转变到以流程为中心的范式，开发人员直接使用与现实世界相符的流程概念进行设计，设计结果可以在BPMS中立即执行，无需复杂的人工转换。
PdSoA架构组成
由于WebSerive技术的成功，许多厂商提出了SOA的概念，SOA强调了服务(通常由WebService实现)在应用架构中的重要地位。但仅有服务尚不够，所以本文提出了一种新的应用架构PdSoA。
表示层                                                 用户接口
业务流程层                        业务流程，业务规则           |
|      （服务注册库）
业务服务接口层                                  业务服务                    |
业务服务实现层                 远程调用，业务组件，Web服务
数据访问层                          数据访问组件或服务
数据源层                                 DB, XML, File
整个PdSoA架构的运行过程大概是这样的:
1.用户通过用户接口启动相应的业务流程(也可以由其他流程或组件启动)
2.业务流程编排调用相应的业务服务(通常实现为Web服务)
3.业务服务代表系统内部功能对外的业务接口，它调用下一层的业务组件
4.业务组件调用数据访问组件访问数据库
5.不同的数据源可以通过数据转换服务形成全局性的联邦数据虚拟视图，供上层调用
PdSoA架构不同于传统架构之处在于:
1.        首先，它多了一层业务服务接口层(以WebService实现)。服务设计面向业务而非技术。该层通常以粗粒度的WebService暴露系统的业务功能，而非传统的细粒度的组件和对象。这样，即使业务人员也可以编排业务服务。
2.        其次，它将业务流程抽象出来，形成一种独立，可视化的业务流程层。
a)          流程可以由业务人员（而非技术人员）可视化设计。例如可以用BPMN可视化建模。
b)          设计好的流程几乎可以直接部署执行，解决了传统上从设计到实现的转换问题。建好的模型可以由BPMS自动转化为一种非可视的模型(如BPEL4WS)来表达的，然后BPMS可以解释相应的BPEL4WS并执行之。
c)          极大地提高了流程动态调整的能力。由于流程可以以可视化方式表达(BPMN)，不再固化于程序代码中，业务人员可以方便的以可视化方式修改流程并由BPMS执行，整个过程在最好的情况下甚至无需编码。这就为业务人员调整流程打开了新的途径，动态调整流程以适应业务变化已不再是业务人员和技术人员的梦魇。
d)          更好地控制业务流程。使用流程服务可以提供一个中心服务，该中心服务控制器它服务的交互，从而可以查询运作信息和管理信息，这将进一步改善系统的管理和维护。
e)          减少依赖项的数量。当许多服务直接交互时，这些服务必须辨别出彼此的服务接口。这样，在合并更多服务时，依赖项数量将按服务数的指数增长。而利用流程服务提供的中心管理点，则可以形成星形拓扑，其在系统中保留的依赖项总数与涉及的服务呈线性比例关系。
f)           简化外部通信。仅向外部公开一个入口点，即流程服务入口点。
g)          简化异常处理。
在PdSoA中，以BPEL4WS表达的业务流程本身也可以作为一个Web服务对外展示自己，供其它系统以一致的方式调用，这种基于业务流程的服务称为流程服务。不管是业务服务还是流程服务都可以将自己注册到服务注册库，供其它系统查找。业务流程层的业务规则是流程执行时所遵循的规则，由BPMS维护。
BPMS
如上所述，PdSoA架构将业务流程提升到架构的中心地位，专门增加了一个流程抽象层来表达和管理流程，但这需要一类特定的软件系统来管理和控制业务流程，这就是业务流程管理系统BPMS。在BPMS中，业务流程成为新的数据类型，它不仅可以被IT人员理解和操纵，而且可以直接被业务人员理解和操纵，在BPMS中创建的流程模型几乎不需任何编码就可以立即执行。BPMS应该具有的基本功能包括：定义业务流程，运行业务流程，监控业务流程，集成人，流程和应用，仿真业务流程，实现业务流程规则引擎。
应用开发范式的转变
随着企业开发的业务服务越来越多，业务服务将成为企业最重要的基础设施和资产。
传统开发范式
建立业务模型 -à 系统设计(业务模型转化为设计模型) -à 系统实现（编码）-à 系统部署与执行。
基于PdSoA架构的开发范式
建立业务模型(主要是业务流程模型) -à 直接部署与执行。
对比上面两种开发范式，可以看出，基于PdSoA架构的应用开发范式由于采用了BPM技术，其业务模型在设计好后可以通过BPMS直接部署和执行，而无需象传统范式那样经过繁琐的业务模型到设计模型的转换以及后续地编码，这就极大的简化了开发过程，提高了开发效率。
PdSoA架构支持标准
PdSoA架构相对于传统三层架构实际上增加了两个技术层次，一是业务服务接口层，二是业务流程层。目前，业界已开发了比较成熟的技术标准支持这两个层次，从而使PdSoA架构具有了广泛应用的可能性，支持这两层的技术标准栈如图所示
流程符号         BPMN
流程实施         BPML        (BPML4WS)
流程接口         BPQL,UDDI,WSCI,WS-Security,WS-Transaction,WS-Coordination
服务描述         WSDL
服务传输         SOAP
结语
传统的三层架构应用由于流程逻辑硬编码与程序代码中，使得程序难以动态调整以适应业务流程的变化，缺乏敏捷性；又因为采用了紧耦合的技术，使得程序互操作性差，难以有效集成。而流程驱动的面向服务地架构采用了松耦合的Web服务技术，大大提高了系统的互操作性，同时，由于采用了现代BPM技术，将流程独立出来，实现了对流程的独立管理和控制，使得流程的动态调整得以实现，系统敏捷性得到巨大提升。
Add a comment
4:40 PM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!170.entry
企业应用架构选型
本文将首先考察企业应用的一般概念和需求；然后讨论两种目前最流行的企业级Java应用架构，分析它们满足企业应用的需求的方式，最后清算一下两种选型的代价和使用范围。
企业应用的概念和需求
笼统地说，一个“企业级应用系统”肯定是一个“服务于商业目的，处理企业业务信息，数据的软件系统”。大概可以总结出以下五方面特征:
1．有复杂的业务逻辑
2．有大量持久化数据
3．与多种外部系统相关联
4．有较高的性能要求
5．在运行时需要随时监控，管理；应该能够实时记录，观察系统运行情况，修改系统配置。
当然，开发人员要设计，实现的并不是整个系统的所有部分。开发人员只负责实现与业务相关的核心应用内容，其余的底层结构部分则是在架构选定之后，由相关的系统软件提供(可能是AppServer或者是专门的框架产品)。开发人员关心的是最终完成的“业务构件”，这些“构件”填入“架构”，形成了整个企业系统。
我们之所以把系统中这些有待开发的关键部分称为“构件”，而不是“组件”或“对象”，是因为后面这两种称呼，恰恰与两种具体的架构选型有关。众所周知，如果我们开发的是一个EJB架构的企业应用系统，那么我们的实际工作是在编写EJB组件；另一方面，如果我们使用Spring框架开发应用，那么我们写出的则主要是些POJO。
但无论采用哪种架构，由于前面提到的企业应用的基本特征，我们编写的“构件”都需要从架构系统软件获得一些关键支持或称为“基础服务”。
1．   事务处理：确保关联操作正常，完整的执行。
2．   持久性：实现数据的存储，关系性数据与业务对象之间的映射。
3．   安全性：保证资源只被授权的客户端访问。
4．   构件的生命周期管理和资源管理：负责构件的创建，销毁，构件之间关系的维护，构件的装池(pooling)和重用，并负责构件要用到的Socket，线程，数据库连接等资源的分配，释放和装池。
5．   并发访问管理：处理多个客户端对特定业务构件的并发访问。
6．   寻址服务：当业务构件需要调用其他对象/组件时，架构系统软件应该提供相应的寻址机制，对调用者隐藏被调用者的实现细节。
以上列出的基础服务，对于绝大多数企业应用都是不可或缺的。另外，考虑到企业级应用扩展，集成，升级的可能性，还有一些需求也应该属于这里：
7．   远程机制：如有业务构件和web构件不在同一物理层中，则往往有必要通过某种远程机制（RMI或web service）暴露业务接口。
8．   集群机制：当企业应用的规模扩展，负载增加时，肯定会考虑添加备份服务器以提高处理效率。
9．   管理机制：可以是一个console界面或其他类型的管理接口，供系统管理员实时掌握运行状态，更改系统配置。
10. 日志机制：记录系统运行信息和异常信息。
在理想情况下，业务构件应该能够“透明的”享受以上大多数的基础服务。一个常见的例子是日志机制，系统所采取的日志记录格式，记录媒质，都应该独立于核心的业务逻辑，业务逻辑只是隐式地使用了日志服务。
EJB架构
EJB架构是一种基于组件模型的系统架构，EJB容器提供了对事务处理，持久性，安全性，组件生命周期管理和资源管理，并发访问管理，寻址服务，远程机制以及集群机制的内置支持。换句话说，这是一座一上来就标榜“全功能”的豪华公寓。
事务处理：EJB容器负责实现底层事务服务，并通过JTA提供访问。
持久性：通常由Entity Bean实现。有BMP(通常DAO模式封装)和CMP两种。
安全性：EJB容器提供了声明式安全性机制，可以通过配置实现基于role的访问限制。
组件的生命周期和资源管理：AppServer负责这些核心机制(pooling/callback)。
寻址服务：JNDI。
远程机制：RMI/IIOP(EJB2.0技术规范)。SOAP(web service形式EJB2.1技术规范)。
集群机制：EJB架构同时支持纵向扩展和横向扩展。
通过以上介绍我们发现，EJB架构提供了企业级应用的所有基础服务(EJB开发范式诞生的初衷)，但其中一些服务的实现存在缺陷，在应对特定业务场景的时候往往捉襟见肘；另一方面，所有这些服务都必须一篮子提供，即使只使用到了其中的少数几个服务，我们也必须付出运行所有服务的代价。
另外，EJB采取的组件模型具有很强的“侵略性”，为了享用上述服务，业务构件必须具有EJB的接口声明。
轻量级容器架构
很长一段时间以来，EJB架构一直被认为是完整的J2EE方案中不可或缺的核心成分。但随着AOP，Ioc等技术的逐渐发展成熟，一些开发者干脆放弃了EJB容器，转而采取了一种全新的J2EE方案。
在EJB容器之外提供各种企业级基础服务——轻量级容器架构不仅做到了这一点，而且让开发者感到了可贵的自由。针对EJB架构的两大弊病a.一揽子提供所有服务 b.组件接口的强侵略性，轻量级容器架构做出了彻底的变革：a.实现透明的“照单点菜”服务提供，使用者可以按需配置当前运行的服务；b.放弃组件开发范式，采用POJO，基本上消除了EJB架构强加给业务构件的侵略性接口。
以下考察轻量级容器框架怎样通过AOP，Ioc技术实现各项企业级服务的。
事务处理：
底层服务由专门的事务处理框架完成，业务对象可以采用编程方式实现事务(如事务模版)；但更好的方案是通过声明实现(xml配置或者在源代码中给出meta data注释)。Spring框架在底层通过interception，为POJO业务对象添加事务功能。
持久性
Spring框架通过DAO模式实现对象持久性，并针对各种常见数据访问机制(如JDBC，JDO，Hibernate，iBatis，SQL Map)设计了专门的处理模版。
安全性
可以通过AOP拦截，实现基于声明的安全机制，这通常比EJB安全机制更符合复杂的业务需求。
对象的生命周期管理和资源管理
生命周期管理由容器实现。对象无需具有特定接口，回调方法在配置声明，以供容器到时自动完成回调。资源寻址由容器完成，资源管理由容器调用底层服务实现。
并发访问管理
容器负责自动处理并发请求；开发者可以把业务对象视为单线程模型。
寻址服务
借助IoC架构，寻址服务由容器透明地实现，无需进行显示代码，只需在配置文件中声明对象之间的依赖关系即可。
远程机制
Spring内置了对RMI, web services(JAX-RPC)的支持，另外还支持两种轻量级的远程机制：Hessian(一种二进制协议)/Burlap(一种XML协议)。
集群机制
通常采用横向集群方案，也就是添加整个应用系统的备份。
评价：与EJB容器相比，轻量级容器在事务处理，持久性，寻址以及构件生命周期管理/
资源管理机制方面具有较大优势。在安全性，并发访问，远程机制方面与EJB容器相差无几，也许在集群机制（本文没有详述消息处理机制，因为缺乏MDB的代替方案）方面与EJB容器有明显差距。
选择与代价
我们首先从系统开发的角度，通过三个方面考虑两种架构的差异。
1．   组件编程 vs. 对象编程
首先，组件的粒度大于对象，一个组件可以由多个对象构成。其次，组件不能脱离相关框架独立存在，组件的生命周期完全由框架管理，并且在接口和实现中都显示地依赖于框架中基础设施，而在理想情况下，对象则可以单独使用。最后，组件往往要求接口和实现之间的分离，用户在使用组件时，只要知道接口定义即可；而一个对象则不一定具有这样严格定义的接口特征。
EJB开发体现了组件编程范式的典型特征，EJB不能须臾离开容器存在。用EJB实现的业务组件无法摆脱对专门的接口和异常的依赖——这正暴露了EJB的“侵略性”。
基于轻量级容器的开发则是传统Component编程和POJO编程的一种混合体。由于它广范采用了IoC地注入，回调机制，所以业务对象代码中几乎不存在对容器和相关服务的依赖；业务对象不需要容器特有的接口声明，所以这些对象完全可以独立于容器使用，测试。另一方面，业务对象一旦进入容器，也仍然区别于传统，单纯的Java对象，它在整个生命周期中受到容器的全程管理，事实上，用户对它的调用也会经过容器多次拦截/代理。最后，即使是在轻量级容器架构中，通常也会鼓励接口与实现之间的分离。
总上所叙，轻量级容器架构的自由隐含着巨大的收益。另外从面向对象原则，测试调试，开发效率等等角度来说，对于大多数企业应用系统，轻量级架构都优于EJB架构。
2．   正交性
EJB架构和轻量级容器架构，从“正交性”视角出发，它们的部分初衷都是区分，隔离与业务逻辑“正交”的各项系统功能，并改由容器提供相关服务，而不是手动编码实现。
如前文所述，EJB架构已经抽象出了各种关键的企业服务，并且提供了声明性的配置策略；而且在EJB容器本身的底层实现中，我们也已经能看到对interception的大量应用。
但只有在明确地引入了AOP技术的轻量级架构中，我们才能看到更为彻底的功能正交划分；interception能让开发者能够以更灵活，更符合业务需求的形式定制基础服务。
但应当注意的是，AOP也并非解决正交问题的万应药：“基础服务”的很多细节，不可避免的要与“业务逻辑”混杂在一起——事实上，在很多时候它们就是“业务逻辑”的一部分。在一些特别繁复的应用场景中，与其为正交而正交，勉强隔离各项功能，不如考虑怎样让它们体面地共存。
因此，从正交性角度考虑，对于业务需求极为简单或极为复杂的场景，采用EJB架构也许还有优势，对于较复杂的场景，轻量级架构则可能更为适用。
3．“设计”vs.“补丁”
轻量级容器架构易于配置，易于即插即用地添加新功能，与EJB架构相比，这显然隐含着一种更灵活，更能随机应变的开发范式。
通过AOP增强业务对象，加入原先的设计中不包含的功能，这固然能够一时应付全新的需求，但是采用了这种范式，开发者确实倾向于“懒得”从一开头就把事情想清楚，倾向于怀疑理性预测未来的能力。如果啊AOP的兴起只是助长了这种编码风格，那么我们面临的就不仅是两种容器架构的分歧，而且还是“设计”与“补丁”这样两种精神取向的区别。
从这个角度考虑，也许应该首先预估系统业务需求变更地可能性，当需求相对固定时，EJB架构不乏可取之处；如果需求变化频繁，那么也许应该考虑轻量级架构——但即使如此也应牢记，AOP的本意并不是“打补丁”。
Add a comment
4:37 PM  | Permalink |Trackbacks (0) |Blog it |计算机与 Internet
PermalinkClose
http://spaces.msn.com/juicydanielchan/blog/cns!C97D69BD51CBEFFA!169.entry



Help
x

Tips
31 ways to use your blogMust-know blogging tipsTips for formatting your blogWays to change how your blog entries are displayed
FAQs
How do I add a photo to a blog entry?How do I delete a category?How do I delete a comment or trackback?What‘s a trackback?
Did you know?
You can create your own Space in three easy steps. With your own Space you can tell your own story, stay connected with friends and have fun. Clickhere to get started. You can explore someone‘s friends network by clicking on the explore friends link on their friends list. Discover new people and maybe even connect with old friends. You can leave comments on photos and make them come to life. Who‘s hot. What‘s cool. Where‘s fun. Tell them about it. You can find the most popular interests categories on Spaces. See what everyone else is into by clickinghere.
Search Help

  
©2006 Microsoft.   Legal   MSN Privacy   Advertise   Feedback  Code of Conduct  Report Abuse  Help