BlogJava-细心!用心!耐心!-文章分类-项目框架的设想

在线转换工具zamzar，能转换100M以下的到40种格式的文件，包括
图象格式：bmp, gif, jpg, png, tiff;
文档格式：csv, doc, html, odp, ods, odt, cx, pdf, ppt, ps, rtf, txt, xls, xml;
音频格式：aac, ac3, amr, au, flac, m4a, mmf, mp3, ogg, wav, wma;
视频格式：3gp, avi, flv, gvi, ipod, mov, mp4, mpg, ogg
功能相当不错的了，可以说是一个比较全能的工具了，而且页面简洁易用，速度也很不错！！
http://www.zamzar.com/

kaocre是日本的一个专门生成表情图象的网站，提供20种脸形，52种眼睛形状，47种嘴巴形状，而其中呢脸形主要是颜色上的区别。所以根据组合原理，在这个页面上实际上能生成48880种不同的图象来，这么多表情图象已经很充分了，如果你想为自己的博客换一组新表情，不妨考虑下这个在线的工具哦！
http://www.kaocre.com/

在这个网站上有13个有趣的小工具，特别是对图像的特效处理效果很不错，比如点acid选项进入编辑你可以上载一张图片，然后就可以做出很魔幻的效果来，还有eyes，wavey,glitter，Star pen 都可以为照片加上一些有趣的特效，3Dstereogram是做三维立体图的,puzzle是DIY 拼图的工具，其他工具包括，留言，统计，投票，即时涂鸦，拼图，3D涂鸦等，作好之后会自动生成代码以便在网站或blog中引用。
http://www.flash-gear.com/index.php

一个在线的图象修改工具，它主要的方面就是对图片进行恶搞，比如加胡须，加头发，戴帽子等等，非常实用，对所加的各个元素可以自由调整大小，方向等，直到感觉浑然一体为止，然后做的图效果也非常逼真，非常有趣的一个工具！
http://www.pikipimp.com/

输入文字就发音的网站，只支持繁体中文http://www.putonghuaonline.com/

制作在线通辑令http://www.glassgiant.com/wanted/

在你的照片上添加有趣的对话框http://www.bubblesnaps.com/

这个网站提供各种有趣的在线拼图http://www.thebroth.com/

生成自己的卡通头像http://cartoon.msn.com.cn/

在线素描http://flashface.ctapt.de

在线制作徵章http://www.says-it.com/seal/index.php

各种动画图标制作http://ajaxload.info/

字体图片制作http://cooltext.com/

做个图片让别人来拼http://www.flash-gear.com/puzzle

在线媒体转换工具http://media-convert.com/

处用FLASH技术构建，把图片及音乐混合做成、流媒体http://www.photoshow.com/

拼你的博客http://pingoat.com/

在线做个以自己照片做硬币人物的硬币图片，http://onlinewahn.de/generator/m-maker.htm

在线制作FLASH小影片http://www.dfilm.com/index_movie_start.html

在线截屏url后网址的网站http://images.websnapr.com/?url=www.578453175.com

在线国画涂鸦http://jacksonpollock.org/

在线图片处理：http://www1.iephotoshop.com/电信入口http://www.iephotoshop.com/网通入口

DIY网络拼图小工具让你快速将自己的图片DIY成网络拼图，还设有计时器与排行榜。 http://www.webpuzzle.cn

在线剪纸(FLASH版)http://snowflakes.barkleyus.com/

测试你的纯情指数http://www.578453175.com/blog/article.asp?id=173

这个绝对是经典，泡坛人的福音
这个绝对是经典，泡坛人的福音
觉得不错才给大家弄来的！

粉丝身份证：http://id.igogo8.com/
制作印章：http://www.makepic.com/print.php
邮址图片生成：http://www.makepic.com/email.php
条形码生成：http://www.makepic.com/barcode.php
Kiss学堂颁发结业证：http://www.makepic.com/kiss/cert.php
生成头像：http://www.eoool.com/ImageDIY/DIYChooseImg.aspx?ImgSize=96x96x1
邮件：http://www.eoool.com/Sevice.aspx?TypeID=1
聊天图标：http://www.eoool.com/Sevice.aspx?TypeID=2
博客图标：http://www.eoool.com/Sevice.aspx?TypeID=3
网络书签：http://www.eoool.com/Sevice.aspx?TypeID=5
朋友圈：http://www.eoool.com/Sevice.aspx?TypeID=4
按扭：http://www.eoool.com/Sevice.aspx?TypeID=11
生成拼凑图：http://blog.outer-court.com/letters/
一个曰本武士刀劈出你需要的字：http://tools.fodey.com/generators/animated/ninjatext.asp
生成几种卡通人物对话动态图片：http://tools.fodey.com/generators/animated/talking_squirrel.asp
香烟盒生成，可以做警告图片：http://tools.fodey.com/generators/cigarette_packet/generator.cig
支持多种域名的Email图标的生成：http://www.nhacks.com/email/
两个地址支持两种风格任意文本的Email图标的生成：
http://sagittarius.dip.jp/~toshi ... ail/designmail.html
http://sagittarius.dip.jp/~toshi/cgi-bin/catmark/catmark.html
在线favicon生成器：http://www.html-kit.com/e/favicon.cgi
支持各种类型图片的生成，可以选择设置的条件非常灵活：http://www.abi-station.com/tchinese/
支持大量中文字体签名图标生成：http://www.youmade.com/font/
Flickr杂志封面生成器：http://flagrantdisregard.com/flickr/magazine.php
动态生成有趣图片：
爱因斯坦：
http://www.hetemeel.com/einsteinform.php
山姆大叔：
http://www.hetemeel.com/unclesamform.php
辞典：
http://www.hetemeel.com/dictionaryform.php
魔法师：
http://www.imagegenerator.net/create/dumbledore/
Flickr Logo风格图片生成器：http://flickr.nosv.org/
按钮生成网站：
http://kalsey.com/tools/buttonmaker/
http://www.lucazappa.com/brilliantMaker/buttonImage.php
http://www.feedforall.com/public/rss-graphic-tool.htm
http://www.kalsey.com/tools/buttonmaker/
http://www.yugatech.com/make.php
http://www.hkwebs.net/catalog/tools/buttonmaker/index.php
Email图标生成网站：
http://email.playtime.uni.cc/
http://services.nexodyne.com/email/
http://gizmo967.mgs3.org/Gmail/
http://www.hkwebs.net/catalog/tools/gmail/
http://sagittarius.dip.jp/~toshi ... ail/designmail.html
http://www.eoool.com/
Logo生成网站：
http://phorum.com.tw/Generator.aspx
http://www.logoyes.com/lc_leftframe.htm
http://cooltext.com/Default.aspx
Banner图片制作网站：http://www.bannerbreak.com/index.php
在线图片生成网站：
http://www.streetsigngenerator.com/
http://www.letterjames.de/
图片分割器：http://www.html-kit.com/e/is.cgi
立体图片生成器：http://www.chami.com/html-kit/services/imge/
图片生成邮票:：http://photo.stamps.com/PhotoStamps/?source=si00001331
个性拼图：http://www.jigcool.com/jigonline/jigonline1_sc.php
印章制作：http://caishu.sina.com.cn/
韩国身份证的生成以及验证：http://www.udeng.com/images/hanguo.htm
GIF图片的文字LOGO在线生成：http://www.3dtextmaker.com/cgi-bin/3dtext.pl
在线制作logo,bannar的网站：http://www.crazystudy.com<
SAINT.Assess the Security of Computer Networks：http://www.saintcorporation.com/saint/
Abacus.Intrusion Prevention System：http://www.psionic.com/abacus/
Firewall Generator（在线生成简单的防火墙脚本）：http://www.citadec.com/FirewallGenerator.html
身份证号码在线生成器：http://i972.net/~gen/
在线字体图片生成：http://www.youmade.com/font/
中外破解补丁和注册机在线求救：http://hmay.qq.topzj.com/
在线生成条码打印：
http://www.027hc.com/y1.asp
http://www.nlscan.com/soucecentre/demo.asp
http://www.gzbonny.com/asp/barcode.asp
在线图形特效生成：http://www.chami.com/
聊天工具在线状态生成器：http://www.onlinestatus.org/forum/usage.php
个性签名图/闪字在线生成
http://zfwlpt.go1.icpcn.com/qqzone/qqcz.htm
变色贴彩字转换工具
http://zfwlpt.go1.icpcn.com/qqzone/qqcolor.htm
汉字简体/繁体在线转换工具
http://zfwlpt.go1.icpcn.com/qqzone/QQhanzi.htm

张金鹏 2008-11-16 19:15 发表评论

一个完整的接口技术解决方案（八）

张金鹏 — Tue, 29 May 2007 09:33:00 GMT

一个完整的接口技术解决方案（八）

题注：
      发表这篇解决方案，属于非盈利目的。主要是为了让大家了解一种接口技术解决方案文档的编写格式以及让大家评审在我的这个技术解决方案中的不足之处，以便大家指出并加以改进。
      转载，下载或与各种形式使用这篇文章，必须注明文章的作者，出处。
      其他未尽事宜，以国家法律规定的为准！
                     作者：南疯

10 网页地址

u 外协系统Web Service测试地址(ENI内网)：

http://xxx.xxx.xxx.xxx/PECS_CONSTRUCTION_INTERFACE/INTERFACE.ASMX

u WSDL文档地址：

http://xxx.xxx.xxx.xxx/PECS_CONSTRUCTION_INTERFACE/INTERFACE.ASMX?WSDL

u 外协系统正式使用地址：

待定。

u 施工系统Web Service测试地址(ENI内网)：

u 施工系统正式使用地址：

11 Web Service接口

11.1 接口命名规范

对于业务数据，根据前面的表英文名，接口名称全部是大写。如果：

u 前面带有 QUERY_ 的，表示对这个表进行查询并下载记录。

比如：UPDATE_ BEGINWORKREPORT 表示对开工报告进行进行查询并下载记录

u 前面带有 UPDATE_ 的，表示对这个表进行新增或者修改记录。

比如：UPDATE_ BEGINWORKREPORT 表示对开工报告进行新增或修改记录

u 施工系统接受外协系统发送的变更字典信息接口为：UPDATE_DICTIONARY

u 前面带有 DELETE_ 的，表示对这个表进行删除记录。

比如：DELETE _ BEGINWORKREPORT 表示对开工报告进行删除记录

u 其他的外协系统特别提供的接口命名，请见后面的11.4

11.2 输入参数

所有的接口都仅仅接受一个参数，参数变量名为：strXML，文本类型

11.3 输出参数

所有的接口都返回文本数据类型的数据，接受返回值的客户端变量由客户端自行定义。

11.4 外协系统提供的其他接口

外协系统特别提供的Web Service接口名（注意：不全部是大写）（参数遵循前面的规则）：

接口名称	说明
GetFileInfo	获得文档的基本信息
GetFileInfoWithBrother	获得文档的基本信息(带有所有的兄弟记录)
GetFileInfoWithParent	获得文档的基本信息(带有所有的父亲记录)
UploadFile	上传文档
DeleteFile	删除文档
GetDictionary	获得字典信息

12 附录：待定问题

张金鹏 2007-05-29 17:33 发表评论

一个完整的接口技术解决方案（七）

张金鹏 — Tue, 29 May 2007 09:31:00 GMT

一个完整的接口技术解决方案（七）

9 信息数据项

9.1 数据表

英文名	中文名	说明
PROJECT3	三级项目基本信息表	仅接受查询下载
PROJECT1	一级项目基本信息表	仅接受查询下载
RELATIONMAN	项目合作伙伴	仅接受查询下载
DIMENSIONS	项目建设规模	仅接受查询下载
MILEPOST	（三级项目）里程碑	仅接受查询下载
DISASSEMBLE	项目分解	仅接受查询下载
PROJECTDOWN	项目下达、委托、受理	仅接受查询下载
BEGINWORKREPORT	开工报告
ENDWORKREPORT	完工报告
CHECKREPORT	验收报告
ENDWORKREPORT_DIMENS	完工(验收)报告建设规模
CONTRACT_SIGN	施工合同签订过程信息
SERVER_BILL	工程服务采购清单基本信息
SERVER_BILL_ITEMS	工程服务采购单明细
CONST_FILES	施工文件信息
STOP_WORK_APPLY	停工申请
STOPWORK_INFORM	停工通知
RESUME_WORK_APPLY	复工申请信息
DELAY	临时延期申请信息
RESUME_WORK_INFORM	复工通知信息
CONST_SCHEDULE	施工进度
CONST_REPORT	施工报告
SONST_BALAN	施工结算
DESIGNCOMMISSION	设计委托、回复信息	仅接受查询下载
DESIGNCOMMISSIONITEMS	设计委托对应项目列表	仅接受查询下载
DESIGNFILE	设计文件信息	仅接受查询下载
BUDGETSUMTABLEITEMS	预算总表	仅接受查询下载
BUDGET_FIXPRJ2	建筑安装工程费用概算表(表二)	仅接受查询下载
BUDGET_FIXPRJ3A	建筑安装工程量概算表(表三)甲	仅接受查询下载
BUDGET_FIXPRJ3B	建筑安装工程施工机械使用费概算表(表三)乙	仅接受查询下载
BUDGET_EQUIPMENT_A	器材概算表(表四)甲(国内主要材料表)	仅接受查询下载
BUDGET_EQUIPMENT_B	器材概算表(表四)甲(国内需要安装设备表)	仅接受查询下载
BUDGET_EQUIPMENT_C	器材概算表(表四)甲(国内不需要安装设备表)	仅接受查询下载
BUDGET_IMPORT_EQUIPMENT	引进工程器材概算表(表四)乙(引进需要安装设备表)	仅接受查询下载
BUDGET_OTHER_FARE	工程建设其他费用概算表(表五)甲	仅接受查询下载
BUDGET_LITTLE_BULD	小型建筑工程表	仅接受查询下载
SURV_REPORT	监理报告	仅接受查询下载
SURV_INFORM	监理通知单	仅接受查询下载
SURV_RELATE	监理联系单	仅接受查询下载
PROCESS_CHECK	过程检查报告	仅接受查询下载
CHANGE_PRJ	工程变更申请
以下表不属于业务数据表
USER	用户信息
DEPARTMENT	单位信息
DICTIONARY	字典信息
FILES	文档信息表

9.2 字段信息

（参见附件所带的Excel文件）

1.3 字典类型

（未列出.）

字典类型	字典类型ID	说明

张金鹏 2007-05-29 17:31 发表评论

一个完整的接口技术解决方案（六）

张金鹏 — Tue, 29 May 2007 09:31:00 GMT

一个完整的接口技术解决方案（六）

8.2.13 获得字典

施工系统提交字典的分类ID，向外协系统发送请求。外协系统根据字典分类ID，返回对应的字典代码信息。字典代码的信息返回不受最大返回记录100条的限制，一次返回全部的该类字典代码。

请求报文：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <UserInfo>
    <User>ZhangSanUser>
    <PassWord>123456PassWord>
  UserInfo>
  <Description>
  Description>
  <Records>
    <DictionaryID>201DictionaryID>
  Records>
XmlData>

响应报文：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <Description>
    <Result>成功Result>
  Description>
  <Records>
    <Record>
      <Field1>Value1Field1>
      <Field2>Value2Field2>
      <Field3>Value3Field3>
    Record>
    <Record>
      <Field1>Value1Field1>
      <Field2>Value2Field2>
      <Field3>Value3Field3>
    Record>
    <Record>
      <Field1>Value1Field1>
      <Field2>Value2Field2>
      <Field3>Value3Field3>
    Record>
  Records>
XmlData>

报文说明：

标签名	说明
<XmlData>	报文数据主体
<Description>	报文头部信息
<Records>	记录集合
<Record>	一行记录
<UserInfo>	业务认证的用户信息
<User>	业务用户登录名
<PassWord>	业务用户验证口令
<DictionaryID>	字典类型ID。请求下载的字典类型，外协根据字典类型返回对应的字典。
<Field1> <Field2> <Field3> <Field4>	一行字典中的英文字段名称。实际中，这些标签都是字典的英文名。字段的标签全部是大写。具体的字段名称请参见提供的数据模型
<Result>	反馈报文中的下载成功与否信息。如果下载成功，则信息是“成功” 如果下载失败，则信息是“失败：（后面是错误的详细信息）”

8.3 外协系统向施工系统发送请求

外协系统向施工系统发送请求的数据目前有几点需要考虑：

u 如何请求发送一个变更后的业务数据

u 如何请求发送一个变更后的字典数据

u 文档发送请求

外协系统不会主动发送文档的变更信息给施工系统，因为文档的信息（文档的ID）变更是体现在业务的信息当中的，外协系统向施工系统发送业务的变更信息当中就包含了变更了的文档ID，只有在施工系统中进行业务需要获得文档的信息的时候，由施工系统主动发送请求到外协系统获得文档的信息或下载文档。

针对前面这些问题，接口方案的解决方法如下：

8.3.1发送变更后的数据

外协系统在业务数据发生变更（新增、修改、逻辑删除）的时候，会自动发送请求到施工系统要求施工系统进行更新。

注意，外协系统中没有记录上的物理删除，外协系统中所有的删除业务都是逻辑上的删除，仅仅在删除标志位上面标记为“1”。所以，外协系统没有向施工系统发送物理删除的请求。

请求报文：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <UserInfo>
    <User>ZhangSanUser>
    <PassWord>123456PassWord>
  UserInfo>
  <Description>
    <Note>项目经理已经对数据进行了审批Note>
  Description>
  <Records>
    <Record>
      <KeyField>KeyValueKeyField>
      <Field1>Value1Field1>
      <Field2>Value2Field2>
      <Field3>Value3Field3>
      <Field4>Value4Field4>
    Record>
    <Record>
      <KeyField>KeyValueKeyField>
      <Field1>Value1Field1>
      <Field2>Value2Field2>
      <Field3>Value3Field3>
      <Field4>Value4Field4>
    Record>
    <Record>
      <KeyField>KeyValueKeyField>
      <Field1>Value1Field1>
      <Field2>Value2Field2>
      <Field3>Value3Field3>
      <Field4>Value4Field4>
    Record>
  Records>
XmlData>

响应报文：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <Description>
    <Result>成功Result>
  Description>
  <Records>
  Records>
XmlData>

报文说明：

标签名

说明

<XmlData>

报文数据主体

<Description>

报文头部信息

<Records>

记录集合

<Record>

一行记录

<UserInfo>

业务认证的用户信息

<User>

业务用户登录名

<PassWord>

业务用户验证口令

<Note>

业务的简单描述。比如：开工报告审批、施工组织方案审批等

<KeyField>

一行记录中的主键英文字段名称。实际中，这些标签都是字典的英文名。字段的标签全部是大写。

具体的主键字段名称请参见提供的数据模型

<Field1>

<Field2>

<Field3>

<Field4>

一行记录中的英文字段名称。实际中，这些标签都是字典的英文名。字段的标签全部是大写。

具体的字段名称请参见提供的数据模型

<Result>

反馈报文中的保存成功与否信息。

如果保存成功，则信息是“成功”

如果保存失败，则信息是“失败：（后面是错误的详细信息）”

8.3.2发送变更后的字典

外协系统在字典数据发生变更（新增、修改、逻辑删除）的时候，会自动发送请求到施工系统要求施工系统进行更新施工系统的对照字典。

即使是仅仅一个字典条目发生了改变，外协系统向施工系统发送的报文中还是包含了该类字典的所有条目。

请求报文：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <UserInfo>
    <User>ZhangSanUser>
    <PassWord>123456PassWord>
  UserInfo>
  <Description>
    <DictionaryID>201DictionaryID>
  Description>
  <Records>
    <Record>
      <Field1>Value1Field1>
      <Field2>Value2Field2>
      <Field3>Value3Field3>
      <Field4>Value4Field4>
    Record>
    <Record>
      <Field1>Value1Field1>
      <Field2>Value2Field2>
      <Field3>Value3Field3>
      <Field4>Value4Field4>
    Record>
    <Record>
      <Field1>Value1Field1>
      <Field2>Value2Field2>
      <Field3>Value3Field3>
      <Field4>Value4Field4>
    Record>
  Records>
XmlData>

响应报文：

张金鹏 2007-05-29 17:31 发表评论

一个完整的接口技术解决方案（五）

张金鹏 — Tue, 29 May 2007 09:29:00 GMT

摘要: 一个完整的接口技术解决方案（五）题注：发表这篇解决方案，属于非盈利目的。主要是为了让大家了解一种接口技术解决方案文档的编写格式以及让大家评审在我的这个技术解决方案中的不足之处，以便大家指出并加以改进。转载，下载或与各种形式使用... 阅读全文

张金鹏 2007-05-29 17:29 发表评论

一个完整的接口技术解决方案（四）

张金鹏 — Tue, 29 May 2007 09:29:00 GMT

一个完整的接口技术解决方案（四）

题注：
发表这篇解决方案，属于非盈利目的。主要是为了让大家了解一种接口技术解决方案文档的编写格式以及让大家评审在我的这个技术解决方案中的不足之处，以便大家指出并加以改进。
转载，下载或与各种形式使用这篇文章，必须注明文章的作者，出处。
其他未尽事宜，以国家法律规定的为准！
作者：南疯

8.2.3 修改一条记录

施工系统在修改了一条记录的时候，上传的报文中与新增的报文类似，只是主键的信息不能为空。外协系统判断主键的信息，如果发现主键的信息不为空，则认为是修改了一条记录。如果施工系统报文中主键不为空，而外协系统在数据库对应的表中又没有发现对应的记录，则自动转换成新增的方式来处理这条记录。

外协系统在反馈中，还是会把主键返回给施工系统。但是，这种情况下，施工系统可能不再需要维护这个主键。

即使是仅仅修改了一个字段，施工单位还得需要上传全部的字段信息（包含被修改的字段）给外协系统。

施工系统不是对记录做物理删除，而仅仅是作了逻辑删除，即仅仅在记录的删除标志位上面做了“1”的标志。这种情况对记录来说，也是修改的范围。只是需要在业务的简单描述中说明“逻辑删除”。即使是逻辑删除记录，施工系统也必须上传全部的字段到外协系统。

请求报文：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <UserInfo>
    <User>ZhangSanUser>
    <PassWord>123456PassWord>
  UserInfo>
  <Description>
    <Note>停工通知确认Note>
  Description>
  <Records>
    <Record>
      <KeyField>KeyValue1KeyField>
      <NormalField1>Value1NormalField1>
      <NormalField2>Value2NormalField2>
      <NormalField3>Value3NormalField3>
      <NormalField4>Value4NormalField4>
    Record>
    <Record>
      <KeyField>KeyValue2KeyField>
      <NormalField1>Value1NormalField1>
      <NormalField2>Value2NormalField2>
      <NormalField3>Value3NormalField3>
      <NormalField4>Value4NormalField4>
    Record>
  Records>
XmlData>

响应报文：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <Description>
    <Result>成功Result>
  Description>
  <Records>
    <Record>
      <KeyField>Value1KeyField>
    Record>
    <Record>
      <KeyField>Value2KeyField>
    Record>
  Records>
XmlData>

报文说明：

标签名

说明

<XmlData>

报文数据主体

<Description>

报文头部信息

<Records>

记录集合

<Record>

一行记录

<UserInfo>

业务认证的用户信息

<User>

业务用户登录名

<PassWord>

业务用户验证口令

<Note>

业务的简单描述。比如：开工报告、施工组织方案等

请求中的<KeyField>

一行记录中的主键字段。在修改的时候，施工系统所给的主键字段内容不能为空。外协系统中根据主键字段内容不为空，认为这是一条修改的记录

响应中的<KeyField>

一行记录中的主键字段。外协系统返回的主键值。这里的主键值和施工系统发送的记录的顺序是一一对应的。

<Result>

反馈报文中的保存成功与否信息。

如果保存成功，则信息是“成功”

如果保存失败，则信息是“失败：（后面是错误的详细信息）”

<NormalField>

一行记录中的英文字段名称。实际中，这些标签都是字典的英文名。字段的标签全部是大写。

具体的字段名称请参见提供的数据模型

8.2.4   删除一条记录

这里的删除指的是物理删除。逻辑删除在记录修改的时候已经说明。

物理删除是彻底的从数据库中删除一条记录，不能恢复。物理删除的时候，施工系统只要在报文中提供主键的信息提交，就能够实现。

同样的，外协系统在反馈的报文中返回成功删除主键的信息，如果其中一条记录不能正常物理删除，则外协自动回滚所有删除的操作。即一条记录不能删除，则所有的记录都不能删除。
请求报文：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <UserInfo>
    <User>ZhangSanUser>
    <PassWord>123456PassWord>
  UserInfo>
  <Description>
    <Note>物理删除Note>
  Description>
  <Records>
    <Record>
      <KeyField>Value1KeyField>
    Record>
    <Record>
      <KeyField>Value2KeyField>
    Record>
  Records>
XmlData>

响应报文：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <Description>
    <Result>成功Result>
  Description>
  <Records>
    <Record>
      <KeyField>Value1KeyField>
    Record>
    <Record>
      <KeyField>Value2KeyField>
    Record>
  Records>
XmlData>

报文说明：（参见数据修改说明）

8.2.5   文档上传

外协系统中，文档的信息是保存在另外的一个表中当中的，所以，许多的业务表，往往存在一个FileID的主键关联到文档表。在业务表中档，可能有一个FileID的字段，也可能会有两个或两个以上的FileID字段关联到文档信息表。

涉及到文档的地方，往往文档的信息会比较大，所以，文档的信息不能包含在基础业务数据的报文当中一起上传。处理的方法是：

先上传文档的实体，从反馈的信息当中得到生成的文档ID（FileID），然后，施工系统在本地记录中的相应字段赋值文档的ID，最后再上传基本业务信息。

如果一条记录中包含有两个或两个以上的文档字段，则施工系统必须依次上传文档获得文档ID之后，赋值，再上传基本业务信息。

一个文档报文当中，只能上传一个文档。

文档报文如下：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <UserInfo>
    <User>ZhangSanUser>
    <PassWord>123456PassWord>
  UserInfo>
  <Description>
  Description>
  <Records>
<Record>
      <ID>ID>
      <FILE_PRJ_ID>123456FILE_PRJ_ID>
      <FILE_TYPE>401FILE_TYPE>
      <FILE_NAME>施工组织方案.DOCFILE_NAME>
      <FILE_UNIT>电信工程公司FILE_UNIT>
          <FILE_MAN>张三FILE_MAN>
<FILE_CREATE_TIME>20061031 153005FILE_CREATE_TIME>
<FILE_AUTHOR>张三FILE_AUTHOR>
<FILE_TITLE>项目XXX施工组织方案FILE_TITLE>
<KeepMutiFile>1KeepMutiFile>
      <FileData>/e5asf@dfgafa#sdgsdg……FileData>
    Record>
  Records>
XmlData>

响应报文：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <Description>
    <Result>成功Result>
  Description>
  <Records>
    <Record>
      <ID>123456ID>
    Record>
  Records>
XmlData>

报文说明：

标签名	说明
<XmlData>	报文数据主体
<Description>	报文头部信息
<Records>	记录集合
<Record>	一行记录
<UserInfo>	业务认证的用户信息
<User>	业务用户登录名
<PassWord>	业务用户验证口令
<ID>	文档的ID，在新增上传一个文档的时候，这个ID永远都是空的。外协系统根据这个文件ID是否为空来判断是否是新的文件。
<FILE_PRJ_ID>	文档所属的项目ID，对于工程协作系统来说，一个文档永远都是会属于某个项目的。这个项目ID可以是一级项目，也可以是三级项目。
<FILE_TYPE>	文件类型。标识文件的归类。比如： D401施工组织设计= 401 D402施工项目计划进度= 402 D403施工日报= 403 <FILE_TYPE>里面的值是代码，文件类型的代码可以从字典接口中获得。
<FILE_NAME>	文档的文件名称，带有扩展名。
<FILE_UNIT>	文件创建单位，中文名
<FILE_MAN>	文档创建人(上传人)
<FILE_CREATE_TIME>	文档创建时间
<FILE_AUTHOR>	文档作者（可为空）
<FILE_TITLE>	文档标题（可为空）
<KeepMutiFile>	是否允许多个文档同时有效。这个标签的值为 1 或 0。当值为1 的时候，则在同样的项目ID、同样的文件类型中，同时可以存在多个的文档同时有效存在。这种情况下，多个文档之间是兄弟之间的关系，当前的文档是弟弟，以前的文档是兄长。当这个值为0的时候，则在同样的项目ID、同样的文件类型中，只有最后上传的文档有效，后面上传的文档会把前面的文档“挤”到历史中，成为当前文档的“父亲”。这种情况下，当前的文档和以前上传的文档之间是父子的关系。更详细的解释请参见后面的“一条记录中一个FileID的字段如何上传多个文件”主题相关内容。
<FileData>	文件实体内容。文件实体内容用二进制读取出来之后，然后转换成base64的格式。
<Result>	反馈报文中的保存成功与否信息。如果保存成功，则信息是“成功” 如果保存失败，则信息是“失败：（后面是错误的详细信息）”

8.2.6 一条记录中一个文档字段上传多个文件

外协系统中，文档是以一种“有关系”的方式来存储的。假设有这样一个业务表Table1，里面有一个文档的外键字段File_ID。当我们往Table1表里面插入一条记录的时候，针对这一条记录，我们希望在File_ID字段中可以带有多个的文档，也即会有多个的File_ID。当然，我们可以把这个表字段的数据模型这个定义：File1_ID，File2_ID,File3_ID……，需要多少个文件，我们就定义几个的File_ID字段。但是这样就会带来问题了，如果你定义了5个的File_ID字段，但是，用户如果想在一条记录中上传6个文档，那么，这样的数据模型就会满足不了用户的要求。还有一种情况，如果用户仅仅上传了2个文档，那么剩下的3个File_ID字段就会白白空着。甚至用户对这条记录没有上传文件，这样定义的数据模型就白白浪费了数据库的资源。

还有一种说法，我可以用记录的形式来表示啊。对的。上传多个文件，是可以在Table1中新增多条记录方式来表示。但是，我们的前提是，Table1是一个业务表，里面的一条记录就是一笔业务。如果你产生了多条记录，那么意味这这样的业务进行了多次。显然违背了业务数据保存的初衷。

外协系统引入了“父子”，“兄弟”的文档保存机制, 即在文档信息表(Files表)中保存文档的基本信息和他们之间的关系。在同样的项目ID、同样的文件类型中，如果可以存在多个的文档同时有效存在，这种情况下，多个文档之间是兄弟之间的关系。后来者文档是弟弟，先到的文档是兄长。在同样的项目ID、同样的文件类型中，只有最后上传的文档有效，后面上传的文档会把前面的文档“挤”到历史中，成为当前文档的“父亲”。这种情况下，后来的文档和以前上传的文档之间是父子的关系。

如果文档之间是兄弟关系的话，则仅仅在业务表Table1中保存最小兄弟的File_ID；如果文档之间是父子关系的话，则仅仅保存最小辈分的文档File_ID。

兄弟和父子的文档保存方式其实都是多个文档串联的一种保存方式，但是，还是会有使用上面的区别的。兄弟关系一般使用在文档之间是平级的情况下。比如施工组织方案，可以有多个文件，但是，这多个文件是互为补充的一部分，互相依赖，又缺一不可。这种情况下，施工系统可以把这类型的文件上传给外协系统，以兄弟的方式保存，施工系统仅仅在业务表当中保存最后上传反馈回来的FileID即可。以后，可以使用这个最小兄弟的File_ID，向外协系统请求以获得他的所有兄长文档。父子的关系一般使用在下面的情景：当仅允许一个文档是最终有效的时候，或者一个文档修改之后再上传到外协系统，我们想把最后上传的文档“覆盖”前面的文档，但是，又想保留文档历史修改痕迹的时候，一般就会用到父子关系。

父子关系中，施工系统仅仅需要保留最小辈分的文档信息，以后，可以使用这个最小辈分的File_ID，向外协系统请求以获得他的所有历史文档。

张金鹏 2007-05-29 17:29 发表评论

一个完整的接口技术解决方案（三）

张金鹏 — Tue, 29 May 2007 09:27:00 GMT

一个完整的接口技术解决方案（三）

8 数据格式

在Web Service的调用过程中，无论是外协系统还是施工系统，都有发送数据和接收数据的要求，也即双方系统同时作为客户端又作为服务端。我们统称这些传递的数据为报文。

客户端发送报文，属于调用；服务端接收报文，属于被调用。

客户端和服务端互相之间通讯的请求报文和结果报文遵循XML格式。客户端发送请求报文，服务器解析调用报文，执行报文中所在接口对应的服务功能。生成结果报文，以xml格式页返回给请求者。请求者拿到结果报文，进行解析，然后再进行相应的处理。

8.1 约定

u 报文中所有的字典信息（比如性别1-男，2-女），都以代码的值（1或者2）来传递。施工单位向外协系统发送的报文中的代码都需要转换成外协的代码，外协系统向施工系统发送的报文中的代码无需转换。

u 报文中的其他数据类型，比如货币、RowID,自定义对象类型等，根据需要转换成文本、数值或二进制（最终转换成Base64字符）的数据类型。

u 报文中数值信息，转换成文本，如：

12368.36

u 报文中数值不支持科学计数的方式。报文中数值的单位使用国标的单位，比如货币使用“元”，长度使用“米”等。无国标的单位以约定为准。

u 报文中的日期信息，转换成YYYYMMDD HHmmss文本格式（24小时制）。如果是空日期，则转换成空文本。

u 报文中的true和false数据类型，转换成 0(表示false)、1（表示true）

u 报文中的二进制数据，转换成Base64字符方式发送。

u 报文中的记录集，放在< Records>标签中；报文中一条记录，放在< Records>标签中。

u 报文中如果存在多条记录，则在标签中就包含多个的标签。如果报文中仅有一条记录，则标签中只包含一个标签.如果没有记录，则仅仅包含一个标签,没有标签。

u 如果返回结果数据集非常多，在性能考虑和数据量冲突的情况下，可以使用分页返回数据集的方式分批返回数据（每次返回最多100条记录）。服务端提供分批结果返回的功能。至于如何使用分页查询的功能，参见下面的XML框架说明。

8.2 施工系统向外协系统发送请求

施工系统向外协系统发送请求的数据目前有几点需要考虑：

u 如何请求查询一个业务数据

u 如何新增一条记录，新增之后如何点到记录的键值

u 如何修改一条记录

u 如何删除一条记录

u 文档如何上传

u 一条记录中一个FileID的字段如何上传多个文件

u 如何在一条记录中补充上传文档

u 如何在一条记录中删除一个文档

u 如何获得文档的基本信息

u 如何获得文档的所有兄弟信息

u 如何获得文档的所有父亲信息

u 如何下载一个文档

针对这些问题，接口方案的解决方法如下：

8.2.1 请求查询一个业务数据

施工系统针对外协系统发送的业务数据查询请求根据业务类型有很多种。为了简化接口，而不是在接口上进行业务操作，所以，外协系统将施工系统发起的数据查询请求看作是数据下载的一种方式，而不为了复杂的业务查询请求提供复杂的条件解析。

外协系统提供的数据查询接口是从数据下载和数据延期性来考虑的。为了满足数据的下载，外协系统提供了按照某一个表的主键来下载数据和按照记录的变更时间范围来下载数据的两种方式查询请求。

请求报文：

xml version="1.0" encoding="utf-8" ?>
<XmlData>
<UserInfo>
    <User>ZhangSanUser>
    <PassWord>123456PassWord>
  UserInfo>
  <Description>
    <RowID>0RowID>
    <KeyValue>123KeyValue>
    <QueryBeginTime>20061018 153000QueryBeginTime>
    <QueryEndTime>20061019 153000QueryEndTime>
  Description>
XmlData>

响应报文：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <Description>
    <RowID>100RowID>
  Description>
  <Records>
    <Record>
      <Field1>Value1Field1>
      <Field2>Value2Field2>
      <Field3>Value3Field3>
      <Field4>Value4Field4>
    Record>
    <Record>
      <Field1>Value1Field1>
      <Field2>Value2Field2>
      <Field3>Value3Field3>
      <Field4>Value4Field4>
    Record>
    <Record>
      <Field1>Value1Field1>
      <Field2>Value2Field2>
      <Field3>Value3Field3>
      <Field4>Value4Field4>
    Record>
  Records>
XmlData>

报文说明：

标签名

说明

<XmlData>

报文数据主体

<Description>

报文头部信息

<Records>

记录集合

<Record>

一行记录

<UserInfo>

业务认证的用户信息

<User>

业务用户登录名

<PassWord>

业务用户验证口令

<RowID>

第一次请求的时候，客户端RowID发送0，表示从第0条记录开发返回。服务端根据条件查询，发现结果超过100条记录，则在返回的结果中，RowID的值为99，表示服务端当前的记录位置处在第100条的位置上，后面还会有剩余的记录。客户端检查返回的结果，如果发现RowID大于0,则继续发送请求进行查询。但是，客户端第二次发送请求继续查询的时候，RowID的值要赋值为第一次返回的值，即RowID=99。服务端第二次收到请求的时候，发现RowID是99,则从第100条返回结果。以此类推循环调用，直到服务端达到记录的末尾，这时候，服务端在返回的结果中RowID=0.客户端发现服务端RowID=0，终止循环调用。

字典、用户信息、单位信息，因为返回的字段比较少，不受100条记录返回的限制。一次调用，就返回全部的结果。

<KeyValue>

查询时主键的值。这个<KeyValue>和下面的<QueryBeginTime><QueryEndTime>是互斥的。如果在请求的时候提供了主键的值，表示客户端要求服务器按照主键的值查询一条记录。如果客户端提供了主键的值，则服务端将忽略<QueryBeginTime><QueryEndTime>中的值。

字典、用户信息、单位信息，因为没有查询时间范围，所以<KeyValue>即表示字典类型。

<QueryBeginTime>

<QueryEndTime>

查询时时间段范围。<QueryBeginTime>是起始时间，<QueryEndTime>是结束时间。表示客户端要求服务端查询在这个时间范围之内所有变更过的记录（包括新增、修改、删除）。

在外协中，一条记录新增的时候，它的创建时间和最后修改时间是一样的，以后修改记录的时候，创建时间不变，改变的仅仅是最后修改时间。同时，外协系统中删除记录仅仅在“记录是否删除”字段中标记“1”，并不是真正的物理删除记录。

这里的时间指的是记录变更的时间，不是记录中的某个业务时间。如果用户需要按照业务时间来查询数据，则施工系统把外协系统的数据获取到本地进行保存，在施工系统中提供按照业务时间查询的功能。

<QueryBeginTime><QueryEndTime>和<KeyValue>是互斥的。如果客户端需要按照时间范围来查询，则必须<KeyValue>空。

<Field1>

<Field2>

<Field3>

<Field4>

一行记录中的英文字段名称。实际中，这些标签都是字典的英文名。字段的标签全部是大写。

具体的字段名称请参见提供的数据模型

8.2.1 新增一条记录，得到记录的键值

为了简化数据模型的处理，本方案不考虑主从表的并发处理情况。如果存在主从表的数据需要上传，那么，在一个事务中，施工单位首先先上传主表的记录，从反馈信息中获得主表的主键值。然后，把刚刚获得的主表的主键值赋值给从表的对应外键，再上传从表数据，得到从表的主键值。

如果不是主从表，而是单表，则直接上传数据，从反馈信息中得到主键值。

这种情况的优点是：数据和表相关，施工单位可以灵活的控制表之间的关系；同时，数据包中的报文比较简单，容易解析；接口上面比较清晰，与业务的耦合比较低。

缺点是：一个业务涉及的主从表不能在同一个报文中（这个缺点可以通过施工系统灵活的控制表之间关系来解决）；一个业务中可能会使用到两个或两个以上的接口，造成业务完整性上面的分离（这种缺点可以通过把业务放在一个事务中来解决）；

键值的返回：在调用新增接口之后，外协会按照记录的顺序返回外外协中所生成的键值。施工单位获得键值之后，可以在本地表中更新记录的主键值。

请求报文：

xml version="1.0" encoding="utf-8"?>
<XmlData>
  <UserInfo>
    <User>ZhangSanUser>
    <PassWord>123456PassWord>
  UserInfo>
  <Description>
    <Note>开工报告Note>
Description>
  <Records>
    <Record>
      <KeyField>KeyField>
      <NormalField1>Value1NormalField1>
      <NormalField2>Value2NormalField2>
      <NormalField3>Value3NormalField3>
      <NormalField4>Value4NormalField4>
    Record>
    <Record>
      <KeyField>KeyField>
      <NormalField1>Value1NormalField1>
      <NormalField2>Value2NormalField2>
      <NormalField3>Value3NormalField3>
      <NormalField4>Value4NormalField4>
    Record>
  Records>
XmlData>

响应报文：

张金鹏 2007-05-29 17:27 发表评论

一个完整的接口技术解决方案（二）

张金鹏 — Tue, 29 May 2007 09:26:00 GMT

一个完整的接口技术解决方案（二）

4 接口安全

4.1 接口认证

调用认证：

虽然接口双方都是存在于电信内部网络中，但是，仍不能排除接口服务被攻击、恶意调用以及非法调用等。所以，从接口调用上，必须考虑调用的认证安全问题。

u 本方案中的接口，在客户端调用服务端的时候，必须经过调用身份认证。考虑施工系统的开发平台的多样性，但同时接口服务运行平台都是Windows的情况，本方案采用Windows安全身份认证的方式。即在访问接口所在的服务的时候，都必须进行资格审查（使用Credentials发送认证信息）。

u 另外，接口采用SOAP协议，因此在接口配置上面需要屏蔽HTTP GET 和HTTP POST等其他协议。

u 在接口中审核并进行日志的记录。

u 使用最低权限的进程帐户运行 Web 服务（通过 Machine.config 中的元素来配置）。

u 接口不支持动态生成WSDL,因此作为服务端，应该禁止文档协议。

u 在服务端禁用跟踪，禁用调式编译

业务用户认证：

由于接口涉及电信工程中的各个不同的业务，有获取字典、获得项目信息、发送开工报告等，所以，建立一套业务的用户认证机制是必须的。不同的用户，所具备有的授权不一样，所能执行的业务也不一样。同时，业务用户认证中的用户信息也是记录接口日志中的重要组成部分。

本方案采用的是在接口信息中包含业务认证用户信息的方式来进行认证。服务端在收到请求的时候，应先验证业务的授权用户，如果该业务用户没有执行当前业务的权限，应终止业务的执行，并给出非法用户的警告信息反馈回客户端。

一般情况下，业务认证的用户是系统中的用户。业务认证其实就是应用系统认证的组成部分。

业务认证的用户信息经过加密之后包含在要发送的信息（XML体）中，即在发送的信息中包含业务用户的信息（参见下面的数据格式说明）。

4.2 数据安全

数据的安全表现为如何保证数据在网络传输过程中不会被截获并被解析其中的内容而引起信息泄露与如何保证数据在传输的过程中的数据的完整性两个方面。

Web Service采用XML数据格式来传输信息。所以，无论是发送数据还是返回结果，都要求采用对XML数据加密之后来传输。至于采用何种方式的加密技术，本方案为了保密，只能在开发的时候由开发人员口头告知。涉及到加密技术就要涉及到加密的密钥问题。目前，外协系统和施工系统接口上有很多种类型的业务，到底是每种类型的业务采用不同的密钥，还是按分组来采用同一种密钥的方式，还是所有的业务全部采用同一种的密钥的方式，按照需求各有不同的选择。本方案采用的是最后一种的方式。密钥的发布由作为服务方来发布，由客户端获取。密钥的发布方式待定。

为了保证数据的完整性，首先：方案采用数据签名（SOAP Security Extensions: Digital Signature）。利用XML的数字签名（XML Digital Signature syntax [XML-Signature]）对SOAP进行扩展，在SOAP的头元素中定义签名属性（）来实现。其次：限制并验证 Web 方法输入的类型、长度、格式和范围，验证对 XML 输入数据的验证是基于已协商的架构等。

5 事务处理

事务是一组相关的任务，作为独立于其他任务的独立单元成功（提交）或失败（中止）。分布式事务是影响多个资源的事务。要提交分布式事务，所有参与者都必须保证对数据的任何更改是永久的。不论系统崩溃或是发生其他无法预料的事件，更改都必须是持久的。即使只有一个参与者无法保证这一点，整个事务也将失败，在事务范围内对数据的任何更改均将回滚。

外协系统和施工系统是处于网络之上的两个分布式接口，使用的是分布式事务。要启用分布式事务，可能需要通过网络启用 MS DTC（考虑外协平台和施工平台都是运行在Windows上），以便在使用应用了最新的 Service Pack 的较新操作系统（例如 Windows XP 或 Windows 2003）时使用分布式事务。如果启用了 Windows 防火墙（Windows XP Service Pack 2 的默认设置），必须允许 MS DTC 服务使用网络或打开 MS DTC 端口。

接口中的服务端和客户端的环境事务始终相同，客户端创建的事务上下文并应用对于服务端的当前的事务，以便对于该事务上下文是当前的。这样的事务会造成性能损失，因为可能需要继承原来的上下文，但是，这样的事务确保了在数据库操作的时候信息的完整性。接口中事务的发起总是由客户端发起的，并负责事务的提交和回滚等控制。

6 性能考虑

在接口设计的时候就应该考虑性能上面的问题，不要在事后再加入性能。同时，在项目的开发过程要反复进行测试，可以从机器的吞吐量和响应时间两个基本的指标来衡量接口的性能。接口上面的性能考虑主要从下面几个方面来优化：

u 使用一次连接，多次调用，优化连接资源。

u 对于并行的接口调用使用异步的调用方式。

u 优化线程池减少竞争。

u 考虑使用XML压缩。

u 如果不需要返回，考虑使用单工通讯的方式。

u 适当的设置（如果有代理）代理超时，页面超时，WebService超时。

u 设计"大块头"的接口减少往返。

u 基于消息的编程而不是远程过程调用(RPC) 。

u 使用XML字串作为参数。

u 尽量使用原始数据类型参数。

u 避免在调用之间维护服务器状态。

u 考虑为复杂的WebMethod提供输入校验。

u 考虑对WebMethod的结果使用缓存。

u 选择适用的大数据包传送方式。

u 避免调用本地的WebService。

7 容错处理

客户端向服务端发送数据，服务端解析数据，反馈信息给客户端，这中间的环节只要某一个环节出现问题，都会造成接口的失败。按照失败产生的环节分类，我们可以从三个方面来处理接口的失败。

u 网络连接失败：在调用接口的时候，由于网络不通，造成数据不能正常传输。这样，客户端应该能够记录发送的日志，按照一定的时间间隔重试发送。本方案定为重试发送20次，每次时间间隔2小时。如果一直发生网络不通的情况，该发送日志被保存下来，待后手工发送。所以，客户端系统应该实现手工发送数据的功能。

u 反馈错误信息：服务端在解析数据包，执行数据包业务的时候，可能会发生异常。所以，服务端应当能够捕捉异常信息，比如“非法XML格式”等，然后反馈给客户端。客户端在接受到这类的错误信息之后，应当进行日志记录，能够自动或手工分析异常的信息。

u 网络连接正常，但是无信息反馈：这种情况下，一般是服务端出现了异常，但是又没有捕捉到的情况下发生。这种情况下，客户端把这种错误当作“网络连接失败”来处理。服务端应能够实现相同数据包重新发送过来的处理机制。

张金鹏 2007-05-29 17:26 发表评论

一个完整的接口技术解决方案（一）

张金鹏 — Tue, 29 May 2007 09:24:00 GMT

一个完整的接口技术解决方案（一）

文档编号：	T-JKJS
文档版本：	0.01
项目编号：	XX-DX- PECS

《XX电信工程外部协作系统》

Project Exterior Cooperation System

施工单位接口技术解决方案

编写人：

南疯

日期：

2006-10-30

审核人：

日期：

批准人：

日期：

XXXXXX信息科技股份有限公司

地址：

XXXXXXX

邮编：XXXXXX

电话：

XXXXXXXX

传真：XXXXXX

网站：

XXXXXXXXX

修改记录（Revision Chart）

版本号	批准人	修改人	修改日期	修改记录
0.01		南疯	2006-10-30	第一次创建

0.02详细修改记录：

序号	内容

8.2 施工系统向外协系统发送请求... 13

8.2.1 请求查询一个业务数据... 14

8.2.2 新增一条记录，得到记录的键值... 17

8.2.3 修改一条记录... 19

8.2.4 删除一条记录... 21

8.2.5 文档上传... 23

8.2.6 一条记录中一个文档字段上传多个文件... 25

8.2.7 补充上传文档... 26

8.2.8 在记录中删除一个文档... 27

8.2.9 获得文档的基本信息... 28

8.2.10 获得文档的所有兄弟信息... 31

8.2.11 获得文档的所有父亲信息... 32

8.2.12 下载一个文档... 32

8.2.13 获得字典... 34

8.3 外协系统向施工系统发送请求... 35

8.3.1发送变更后的数据... 36

8.3.2发送变更后的字典... 38

11 Web Service接口.... 44

11.1 接口命名规范... 44

11.2 输入参数... 44

11.3 输出参数... 45

11.4 外协系统提供的其他接口... 45

12 附录：待定问题.... 45

1 引言

1.1 编写目的

本文档为XX电信工程外部协作系统（以下简称外协系统）与电信工程施工单位内部系统（以下简称施工系统）接口技术解决方案，以此作为外协系统与施工系统实施接口的技术方案依据和项目设计标准。

1.2 覆盖范围

XX电信工程外部协作系统项目组

施工系统接口开发技术组

1.3 预期读者与阅读建议

XX电信企业信息化部

XX电信工程建设部

XXXX公司开发人员

施工系统开发人员

1.4 文档约定

粗体正文表示强调内容

红色正文表示未完成或需要今后考虑的内容

蓝色正文表示待讨论内容

1.5 术语与缩略语

术语、缩略语	定义
外协系统	XX电信工程外部协作系统
施工系统	电信工程施工单位内部系统
PECS	XX电信工程外部协作系统英文简称

1.6 参考文献

(XXXX)

2 概述

建设XX电信工程外部协作系统的目标，是在工程项目的管理、建设、使用和实施单位之间搭建起数据交换和协同工作的信息平台，延伸与拓展工程建设管理信息化的应用范围，实现通信工程建设过程的信息化管理，促进工程项目的管理部门、建设部门、实施部门和使用部门之间业务流程协调有序地开展，实现工程项目设计、施工、监理管理功能，将相关的设计、施工、监理单位纳入到工程建设管理中，完善工程项目建设过程管理体系，通过信息化推动管理的规范化，在信息化的应用过程中不断探索市场环境下工程建设管理的新思路和新方法。

根据工程部业务工作的实际情况，项目首先满足工程建设管理中应用最广泛、问题最突出的基本需求。

项目功能需求包括：

Ø 建立工程外部协作系统与MSS等系统的接口；

Ø 建立设计协作服务、监理协作服务、施工协作服务模块，为邮电设计院、电话监理公司和电信工程公司提供工程部所需的协作服务，保证工程建设实施流程的开展；

Ø 在建立工程协作服务模块的基础上，建立工程外部协作系统与邮电设计院、电话监理公司、电信工程公司信息系统的接口，实现工程部与三家实施单位的信息交互与业务协作；

本技术解决方案就是针对实现工程建设部与三家实施单位信息交互与业务协作接口中施工单位接口的技术解决方案的组成部分。

在接口的调用过程中，存在施工系统调用外协系统接口的情况，这时候，施工系统作为客户端，外协系统作为服务端；也存在外协系统调用施工系统的情况，这时候，外协系统作为客户端，施工系统作为服务端。本方案中，除了特殊另外说明外，不考虑外协系统和施工系统角色换位的问题。如果一方发起了调用，那么它就是客户端，另一方就是服务端。反之亦然。

4 接口方式

u 工程外协系统与施工系统之间的接口采用Web Service接口形式来进行业务数据的交互。

u 接口数据传输采用XML数据交换格式，utf-8编码。

u 在外协系统中提供Web Service的API接口。提供由施工系统调用获得信息；并且提供施工系统提交信息的API接口。

u 同样，在施工系统中提供Web Service的API接口。提供由外协系统提交信息的API接口。

u 考虑到工程外协中的数据信息不仅包括了XX电信工程公司的数据而且还包含了其他的施工单位的数据信息。而这些单位也各有其各自工程应用系统。这样，外协系统对各个施工单位系统所提供的接口API及其参数信息、格式均是统一的。同时，也要求各个施工单位所提供的接口API及其参数、格式等也必须要求统一。外协系统与施工系统属于一对多的关系。

u 外协系统要求能够有目的，信息有过滤的把业务信息通过接口正确的发送给相应施工系统接口。非相关的信息不要发送给对应的施工系统。

u 施工系统建立用户映像对照表、字典对照表、单位对照表等数据映像，传递给外协的数据使用的是映像中转换后的外协系统能够识别数据；同时，接收到的数据也根据对照表转换成各自能够解释的数据格式。

u 数据初始化的时候，由施工系统主动调用外协系统的接口，以获得用户信息、字典信息、单位信息、项目信息等基础信息。以后，一旦发生数据的变动，由外协系统主动往施工系统发送信息。

u 外协系统不主动请求施工系统获得数据，但是外协系统会主动请求施工系统发送数据。

u 施工系统主动请求外协系统获得数据，也会主动请求外协系统发送数据。

张金鹏 2007-05-29 17:24 发表评论

乱码问题之终极解决

张金鹏 — Sun, 06 May 2007 04:53:00 GMT

乱码问题之终极解决


这里讨论下新手学习，高手指教一起研究下 (以 tomcat mysql 做例子我推荐所有的编码采用utf-8) 1 工程工程内所有的 .java .jsp .xml .txt 都有默认的编码默认的是系统环境的编码我们中文系统通常是GBK 推荐都采用utf-8 utf-8 的时候你编译生成doc 可能会遇到乱码（特别是采用ant 的时候,生成doc你几乎100%会遇到）解决方法以ant 为例子编译注意 encoding 参数生成doc 注意 encoding 和 charset 这里的encoding 就是指的你 java 文件的编码格式 javac 和javadoc 都有这个参数 charset 指的是生成 doc 后的编码方式 javadoc 的参数 2 数据库 mysql 的编码最复杂从4以后 mysql 号称支持多编码它更灵活了我们也更麻烦了 mysql 有4个级别的编码系统级库级表级 sql语句级请保持采用统一的编码推荐utf-8 其它数据库要简单的多一般都是一种编码 3 web server tomcat 为例 tomcat server.xml 中一个参数 maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" URIncoding="utf-8"/> 经测试这个URIncoding 参数主要是 get 方法中采用编码 4 jsp 显示层第1条中说明了 jsp 文件本身的格式很多朋友采用eclipse +myeclipse 生成jsp 它自动生成一个头<%@ page language="java" import="java.util." pageEncoding="UTF-8"%> 不要误解这句话不能保证你在ie里看到的不是乱码 pageEncoding它的意思是这个页面本身采用的是 utf-8 (似乎只在eclipse 里有效果，我不确定) 为了在ie 里不乱码你还得加一句 <%@ page contentType="text/html; charset=UTF-8"%> 它不能在(myeclispe)自动生成推荐修改 myeclipse的模板在下边的目录里 MyEclipse\eclipse\plugins\com.genuitec.eclipse.wizards_4.0.1\Templates 里边的jsp模版你加上<%@ page contentType="text/html; charset=${encoding}"%> 5 filter 自从tomcat 4 以后网上就流传了一个SetCharacterEncodingFilter 过滤器搜一下有很多很好用 web.xml 中加入  Set Character Encoding  filters.SetCharacterEncodingFilter   encoding  utf-8    Set Character Encoding  /  6 资源文件首先保证文件本身是utf-8 然后部署的时候用 native2ascii 转换这里给出 ant 里的例子

张金鹏 2007-05-06 12:53 发表评论

XML和J2EE的完美结合

张金鹏 — Sun, 06 May 2007 04:50:00 GMT

XML和J2EE的完美结合


当前，Java 2平台企业版（J2EE）架构在厂商市场和开发者社区中倍受推崇。作为一种工具，可扩展标记语言（XML）简化了数据交换、进程间消息交换这一类的事情，因而对开发者逐渐变得有吸引力，并开始流行起来。自然，在J2EE架构中访问或集成XML解决方案的想法也很诱人。因为这将是强大系统架构同高度灵活的数据管理方案的结合。 XML的应用似乎是无穷无尽的，但它们大致上可以分为三大类： ●简单数据的表示和交换（针对XML的简单API（SAX）和文档对象模型（DOM）语法解析，不同的文档类型定义（DTDs）和概要（schemas）） ●面向消息的计算（XML-RPC（远程过程调用），SOAP协议，电子化业务XML（ebXML）） ●用户界面相关、表示相关的上下文（可扩展样式表语言（XSL），可扩展样式表语言转换（XSLT））这几类应用在J2EE架构中恰好有天然的对应：数据表示和交换功能是EJB组件模型中持久化服务（persistence services）的一部分，基于消息的通讯由Java消息服务（JMS）API来处理，而界面表示正是Java服务器页面（JSP）和Java Servlets的拿手好戏。在本文中，我们将看到当今基于J2EE的应用里，XML是如何在上述几个方面进行应用的，以及在相关标准的未来版本中这些应用将会如何发展。基础：数据的表示和交换原型化的XML应用（假设有的话）的内容通常是：数据以XML格式存放，为了进行显示、修改甚至写入某个XML文档而经常被读入到某个对象模型中。作为例子，假定我们正处理多种类型的媒体（图品、视频、文本文档等等），并且用下面这个简单的XML DTD来描述这些媒体的元数据：　　以下是一个基于上述媒体DTD的XML文档，描述了与某个课程讲座相关的内容： Media Assets//EN" "http://localhost/Articles/Sun/dtds/media.dtd"> 第14讲与第14讲相关的所有内容讲座的幻灯片 MS PowerPoint application/vnd.ms-powerpoint http://javatraining.org/jaf/E123/lecture- 14/slides.ppt 讲座的视频片断 RealPlayer streaming video video/vnd.rn-realvideo http://javatraining.org/jaf/E123/lecture- 14/lecture.rv http://javatraining.org/jaf/E123/lecture-14/index.jsp 从Web或者企业级应用的角度看，能以这种方式访问数据真是一种福音，因为它体现了高度的可移动性，使我们与元数据的实际资源本身隔离。这些资源可能来自一个关系数据库系统、某种活动媒体服务器或者Web服务器上的一个静态XML文档，等等。如果想把这些数据加载到Java应用中，我们可以从当前众多的Java语言XML解析器中选用一个，通过它将XML数据装入一个DOM文档，最后遍历文档，将所有这些数据转换到我们应用系统的对象模型中。下面是个简单的基于DOM的解析程序，可对上述的媒体DTD进行解析。解析器用的是 Apache Xerces：　　 package jaf.xml; import java.util.; import java.io.IOException; import org.w3c.dom.; import org.xml.sax.; 　　 // XML文档解析程序，使用上述媒体DTD. public class MediaParser implements ErrorHandler { /* 使用Apache Xerces解析器 / org.apache.xerces.parsers.DOMParser mParser = new org.apache.xerces.parsers.DOMParser(); /* 构造函数 / public MediaParser() { // 告诉解析器验证并解析文档 try { mParser.setFeature( "http://xml.org/sax/features/validation", true); } catch (SAXException e) { System.out.println("Error setting validation on parser:"); e.printStackTrace(); } // 设置解析器的错误处理句柄 mParser.setErrorHandler(this); } /* 解析指定的URL，返回找到的XML文档 / public Document parse(String url) throws SAXException, IOException { mParser.parse(url); Document mediaDoc = mParser.getDocument(); return mediaDoc; } /* 解析指定URL的XML文档，将内容转换成 MediaAsset 对象 / public Collection loadAssets(String url) throws SAXException, IOException { Document doc = parse(url); Collection assets = new LinkedList(); NodeList assetNodes = doc.getElementsByTagName("media-asset"); for (int i = 0; i < assetNodes.getLength(); i++) { Node assetNode = assetNodes.item(i); MediaAsset asset = new MediaAsset(assetNode); assets.add(asset); } return assets; } /* * 错误处理代码（为简洁起见省略了） / } MediaParser类的构造函数初始化了一个Xerces DOM解析器。parse()方法告诉解析器到哪个URL去找XML源，然后得到结果文档并返回。loadAssets()方法调用parse()方法从某个XML源加载文档，然后为文档中找到的每个“media-asset”节点创建一个MediaAsset对象。以下是一个使用MediaAsset类的例子： package jaf.xml; import java.util.; public class MediaAsset { // 资源元数据 private String mName = ""; private String mDesc = ""; private Collection mChildren = new LinkedList(); private Vector mTypes = new Vector(); private String mUrn = ""; protected MediaAsset(org.w3c.dom.Node assetNode) { // 为简洁起见省略后面代码 . . . } } 因为篇幅的关系省略了MediaAsset类的详细代码，但应用模式依然是清晰的。MediaAsset类遍历文档的节点，当它碰到不同的子节点时，它用子节点的内容填充自己的成员数据。如果它发现了一个嵌套的子资源节点，它只需要创建一个新的MediaAsset对象，然后将子资源节点的数据填充到新对象的成员数据中。实现上述处理的方法数不胜数。我们还可以使用其他的解析器或解析器架构，如Java API for XML Parsing (JAXP)。除了使用DOM模型外，事件驱动的SAX模型也可用于解析XML。类似的程序也可用来产生XML数据——前提是允许产生新的数据对象（在本例中是MediaAsset），它可将其相应的XML实体插入到DOM中，然后将DOM输出到一个流中（诸如一个文件，一个Socket，或者一个HTTP连接...）。还有其他更高层次的标准，可将XML映射到Java对象的过程进一步自动化（或简化）。例如，使用XML概要（Schema）和XML绑定处理引擎，您可以半自动地将满足某个XML 概要的XML数据转变成Java数据对象。代表性的引擎是Castor，是由ExoLab小组管理的一个开放源代码项目的产物。上述使用Xerces DOM的简单例子仅仅是演示了这一处理过程的底层模型。上述示例表明，在Java环境中解析或产生XML是非常方便的，这与J2EE没有必然关联。格式化为XML的数据可以从应用程序的任何层次流入或输出，这使得与外部系统的集成性无可限量。但我们能否以一种更为直接的方式将XML数据源集成到J2EE架构中去呢？驾驭消息 J2EE架构包含了对JMS（Java消息服务）API的访问，以实现面向消息的通信（J2EE 1.2.1版只需JMS API即可，在J2EE 1.3版中JMS基本定型，此时必须由某个兼容J2EE平台的服务器提供一个JMS API Provider）。这一类的异步交互（与之相对的是：本地或远程方法调用所代表的同步交互）被证明在某些应用环境中是非常有用的。某些时候，交互只需要通过间接的请求或回答来实现，即：在某些情况下，发出消息后不可能立即收到答复，但我们仍希望当消息发出者重新在线时，确保他能收到答复信息。面向消息系统的实际应用之一就是企业之间的松散集成。类似于EDI（电子文档交换）时代的文档交换，两个企业由于业务的需要而交换消息，此时通常不能为了使用RPC或者RMI、CORBA、DCOM之类的远程方法交互而在两者之间进行紧密集成。象JMS API这样的消息系统允许双方交换基于JMS API的消息载荷，前提是双方在会话的时候均能提供兼容的JMS API服务。当前仍然存在的困难是：双方是否能尊从相同的格式或协议。这正是XML大显身手的时候。XML明确地被设计来解决此类数据交换问题——灵丹妙药就是“面向消息的概要表”（Message-Oriented Communication Scheme），实质就是基于一个双方认同的DTD或schema，用XML格式来交换消息载荷。 JMS API支持好几种消息，其中的TextMessage代表文本消息载荷。一个简单而有效的XML消息交换方案是，在一端将我们的XML文档插入TextMessage，然后在另一端用自制的XML解析程序（如前面的MediaParser）解开数据并（可选地）将其转换成Java对象。这使得我们既可以用JMS API支持的公开预订的消息模型，也可以用JMS API支持的点对点的消息模型来发送XML消息。上述方法有一些局限，因为对于JMS运行时处理而言，XML的内容基本上是不透明的。例如，JMS API允许使用基于特定消息头的路由。这很容易理解，尤其当我们希望XML消息根据其内容采取不同走向时。例如在我们的MediaAsset例子中，我们希望公开讲座内容，但只想把特定的内容传送给那些预订了课程的人，或传送给那些表明可以接受某些媒体格式（如视频流）的人。为了发挥JMS API的价值，以便实现上述基于内容的消息路由，我们有必要从XML数据中解析出关键信息，然后在构造标准JMS API消息头时插入这些信息。这是可行的，但要实现XML信息我们就得额外地写很多代码（交换消息的双方均如此）。为了在XML和JMS API之间架起桥梁，一些厂商提供了自定义的JMS扩展，以便直接支持XML消息机制。例如，BEA系统公司基于J2EE的WebLogic应用服务器特别为TextMessage提供了XMLMessage子类，允许用XPath表达式来过滤XML消息。不过这是一种专有的扩展，这要求交换消息的双方必须都能处理这类消息。为此，Sun公司目前正在开发用于XML消息的Java API（JAXM）。其目标是提供一个高级别的标准服务，以实现基于ebXML的消息的合成与传送。一个JAXM服务提供程序可以将这类消息映射到适当的物理消息系统（诸如JMS API）中去。让XML看得见将XML同Web系统的用户界面进行集成显然是一种有益的尝试。绝大多数的界面程序，无论是基于还是不基于Web，都是将数据进行转换，然后用易读的格式展现给用户。用诸如XML这种“易消化”的格式存放数据将简化上述工作，同时它还大大提高了内容的可管理性，接下来我们就可看到这一点。不过首先要大书一笔的是，XML在Web界面层的应用得益于JSP技术的发展。一直以来大家都希望能清晰地区分Web应用程序的表示层与底层对象模型，JSP框架诞生于这些努力之中（包括早期JHTML尝试）。JSP框架允许将Java代码嵌入到HTML内容中，这样既可以实现动态内容，又不必经常修改Java Servlets的代码。在页面中包含Java技术的途径是通过JSP标记（JSP Tags），这些标记以XML风格出现。在JSP中，Java程序以代码片段、服务器端JavaBeans组件、在服务器端触发特定操作的不透明标记（标准的或自定义的）等形式存在。当某个用户通过浏览器请求JSP页面时，一个Java应用服务器解析该JSP页面，将其编译成一个Java Servlet，然后执行该Servlet以产生答复页面。一种直接将XML数据源集成到JSP的界面中去的方法是，将XML加载到JavaBeans组件中（如同我们在MediaAsset例子中所做的），然后在JSP中直接引用这些JavaBeans组件。下面是一个嵌入Java代码片断的例子：第14讲的媒体资源 <%@ page import="jaf.xml." %> Media Assets for Lecture 14: <% MediaParser parser = new MediaParser(); Collection assets = parser.loadAssets("http://javaschool.org /jaf/E162/lecture14-assets.xml"); Iterator iter = assets.iterator(); %> Name Type URN <% while (iter.hasNext()) { asset = (MediaAsset)iter.next(); %> <% } %> 其中粗体部分为JSP代码片断和标记，其余部分是标准的HTML文本。上述程序还有一种更简洁的写法，那就是使用自定义JSP页面标记。这样我们就可以从JSP页面中剔出代码段，只使用JavaBeans组件和自定义的JSP标记即可。比如说，为了去掉创建解析器、加载资源数据到集合中的那段代码，我们可创建一个自己的标记，由它在幕后完成这些工作。以下是例子： . . . <%@ page import="jaf.xml." %> Media Assets for Lecture 14: <%@ taglib uri="http://javaschool.org/taglib" prefix="media" %> http://javaschool.org/jaf/E162/lecture14-assets.xml" collectionName="assets" cursorName="asset" /> . . . 使用自定义标记的最大好处是使我们的程序代码集中在一个地方（对Java技术而言，一般是指在“类”中），易于管理。这样可以将程序中对象层同界面层的集成关系定义得很清晰，修改代码所造成的影响是可以预测和管理的。直接将XML数据转换成Web显示内容的另一种方法是使用XSL和XSLT。在这种方案中，将XML数据映射成HTML（或WML等）的逻辑由XSL样式表（XSL StyleSheet）来定义。样式表描述了每个特定XML数据实体应该怎样转换成界面数据实体（如HTML表格、内联标记等）。在JSP架构中，XSL转换只能应用于特定的XML数据源，最理想的是采用一套自定义的JSP标记并引用某个XSLT处理程序。这方面的典型示例请参考java.sun.com中关于XML同JSP构架集成的白皮书。同前面那个JSP自定义标记加XML解析器组件的方案相比，XSLT方案的伸缩性要好一些，而且具有更好的可管理性。在这种情形下，我们的转换逻辑是编写在一个XSL样式表中，而不是在Java代码中。这意味着当需要修改界面时，大多数情况下只是编辑样式表或者HTML，代码不受影响。不过在决定选用何种方案之前，还是要根据实际状况仔细权衡。如果选用XSLT方案，那么就得有人负责维护这些XSL样式表（要么是负责界面的人，要么是编写程序的人）。XSLT既像内容，又像程序，因此双方都不能把责任推给对方，结果大家可能都被这不伦不类的XSLT弄得矛盾百出。从这点上考虑，采用自定义标记并由界面开发者将其嵌入表示层的方法似乎更有吸引力，因为这样软件工程师只考虑Java代码，而内容工程师也只操心内容标记。 Java servlet过滤器是J2EE 1.3版在其Web层最新发布的一种Web组件。当Sevelet将请求写入某个资源或者从某个资源中读取回答信息时，过滤器可以非常方便地转换其中的头信息和内容信息。这里所说的资源可以是一个Java servlet、一个JSP页面，甚至一个静态Web页。过滤器的确很“酷”，因为它允许开发人员从转换内容的代码中分离出生成内容的那部分代码，并加以重用。当需要通过XSLT方式将XML数据转换到不同的XML应用目标时，Java servlet过滤器尤其有用。在J2EE应用程序中使用Java servlet过滤器转换其输出，以便兼容任何类型客户端的前景呼之欲出。servlet过滤器能够侦测到来自使用WAP协议（无线应用协议）的移动客户端的呼叫，并且将答复内容转换成WML（无线标记语言）格式。servlet过滤器也能检测到来自iMode无线客户的呼叫，并将其转变成cHTML（紧凑HTML）格式。当然，servlet过滤器也能够分辨出传统的HTML浏览器客户的请求，并用正确的格式进行回复。结束语在J2EE 1.2.1规范中，XML“集成”仅指组件或应用程序的XML格式的部署描述。在J2EE 1.3规范中，对XML的支持被扩展为要求具备SAX 2和DOM 2解析器，以及在兼容J2EE的服务器平台上提供XSLT转换处理程序。您可以毋庸置疑地相信，将来在J2EE架构中还会集成进更多的XML特性，因为J2EE规范的定义者们会认真倾听开发者社区中对在企业级应用中使用更多XML的渴求呼声。例如，JSR（Java定义请求）处理小组中与JAXM规范相关的部分（JSR 000067）承诺在J2EE后续规范中集成进JAXM。可以预见，在JSP架构、EJB和JDBC规范中均会有类似的变化。J2EE平台中上述组件的变革，将使Java技术开发者目前用的XML更为规范化（以及标准化），发挥出更大的威力。

张金鹏 2007-05-06 12:50 发表评论

J2EE修炼之四书五经

张金鹏 — Sun, 06 May 2007 04:49:00 GMT

J2EE修炼之四书五经


J2EE其实没有四书五经，因为J2EE一直如汹涌澎湃的大江，推陈出新，不断高速发展，这是一种带领我们走向未来的技术。当然，如何在这种气势如虹的潮流之中不至于迷失方向，需要相关指南性书籍的引导。本文将从线程和模式两个方面推荐J2EE书籍，这两个方面正好是两种不同的方向，线程是从微观、底层机制入手；而模式则是从设计高度来看待J2EE。　　线程（Thread）　　首先，线程是很多J2EE初学者容易忽视的一个基本知识，可以说，无论你是从Java世界的哪一扇门进入J2EE的，线程是必经之道。　　已经不记得在哪里看到过下面一段英文：　　在过去，大概只有勇敢的程序员才勇于使用pthread和Win32线程，现代语言如Java正试图在编写一些令人恐惧的应用如并行计算等方面来挽救我们。　　J2EE的Servlet和EJB确保我们不用担心线程以及同步等问题，我们只要象往常一样编程，容器自动会使用线程池等技术来支持我们的应用。　　由此可见，线程是J2EE最基本的底层机制，每个Servlet/Jsp程序其实是一段线程程序，如果你不懂得线程/多线程的一些原理，如何能娴熟驾驭J2EE的Servlet/Jsp？　　在线程计算方面有很多权威，Dou Lee无疑是这方面的杰出代表，他的并行计算包已经加入了最新的JDK1.5版本中，他的书籍都属于奠基性质，但是，这样书籍可能不是很适合只想对线程进行了解的J2EE初学者。　　《Java线程编程》（Java Thread Programming）　　是我推荐的第一本有关J2EE书籍，在这本书中，作者以简单的例子，形象易懂地从单线程讲解到多线程，线程池（Thread Pool）、并发同时访问对象和变量（Concurrent Access to Objects and Variables），这些都是我们在平时Servlet/Jsp编程中经常会发生疑惑的地方，在这本书的案例中，作者清晰明了地给我们展示这些细节而有重要的技术。同时，也让我们深刻地理解了直接编制多线程应用是一件“令人恐惧”的事情。　　很有意思的是，我在一家网上书店社区里也发现了与我有同样见解的帖子，称这本书是“一本让经典成为过去的书” 　　设计模式　　线程世界就象微生物世界一样，复杂且几乎没有边界，作为信息系统的程序员如果太执著于这样纯技术的微观层面，可能浪费太多宝贵时间和精力，在基本掌握多线程机制后，需要更加关注J2EE的设计应用了。　　J2EE是Java世界中一个独特的框架或标准，所以，我们首先需要掌握基于Java的设计应用，这些设计应用技巧，是先行者经过长期实践总结出来的心得，他们称之为设计模式。在J2EE应用中，只有大量使用设计模式，才能体现出分离和解耦的最高宗旨，才能使得自己的J2EE系统脉络清晰、层次分明，这样的系统才真正具有良好的可伸缩性、稳固的健壮性以及方便的可维护性。　　GoF 23种设计模式已经成为经典，2002年我在我的网站J道发表23种设计模式Java详解时，竟然在中文google里很难发现这方面的资料，这让我万分惊讶，也许国人确实是非常实在，只对算法、数据结构等这样看得见、摸得着的概念感兴趣，其实我一直反复和别人讲：设计模式不是纯抽象概念，它是实践的总结，如同UML一样，是一种交流和编码实现的语言。　　我在2002年帮朋友购买了GoF 23种设计模式的中文版：《设计模式：可复用面向对象软件的基础》，它是2000年12月第2次印刷的版本，这样经典必读书籍，8000册在2年时间内都没有销售完毕，相比那些喧嚣炒作的书籍，在出版几个月内销售过万，越发显得我们这个社会的浮躁和急功近利了。　　当然，这本薄薄的书虽然由四个国人鼎力协助翻译，想必他们也殚思竭虑，尽了最大努力了，可惜书中还是有很多翻译欠妥之处，影响了它的销量。　　由于这本经典的GoF设计模式比较难懂，初学者更多应该是从实例应用中了解和掌握GoF设计模式，相关提供实例应用的书籍有下面几本：　　Mark Grand的Patterns in Java系列；　　美籍华人阎宏的《Java与模式》；　　笔者的《Java实用系统开发指南》；　　EJB 　　EJB是J2EE中一个重要组成部分，J2EE推荐将你的业务功能核心放在EJB中实现，EJB类似肯得基的“全家桶”，将实际中需要的基础功能全都打包在一起了，如果你是个挑剔或个性化的客户，我想你可能不会只满足于“全家桶”。　　不管“全家桶”是否合适你，了解它里面装的是什么是一个必需的过程。掌握EJB需要从两个方面着手：基本原理和如何使用。　　《精通EJB（第二版）》（后注：http://www.javafan.net/softview.jsp?ID=110）　　是对EJB原理讲解得比较透彻，但是书中将EJB一些本质原理推卸给了Corba，而对Corba又没有仔细介绍，我认为初学者应该在这里适可而止，如果你非常对EJB底层实现感兴趣，我推荐阅读JBoss的源码，其实JBoss源码在你孜孜不倦的钻研之劲攻击下很快会土崩瓦解。　　对象池（Object Pool）、RMI和事务机制应该是EJB原理掌握三个方向，这三种技术方向又可以推荐很多书籍供学习研究，这里就不说了。　　EJB主要分EJB容器和EJB应用系统，初学者更多精力应该关注如何构建EJB应用系统，由于EJB提供功能强大且非常有特点，因此，使用他们要非常小心，遵循一定的前提和规则，由此，EJB设计模式是不能不了解的。　　《EJB设计模式》（后注：http://www.javafan.net/softview.jsp?ID=69）是这方面的经典之作，在书中，作者指出了使用CMP注意特点、DAO模式的重要性、DTO模式的变种等。阅读本书的同时，如果参考SUN的PetStore源码学习，将会起到事半功倍的效果，　　看完上面两本书，自己动手实践非常重要，EJB使用中关于EJB reference配置比较麻烦，其原理是这样：调用者---- > EJB Reference ---> 被调用EJB的JNDI名称 ---- >被调用EJB，这些细节使用问题只有实践时才能碰到，也可以从网上寻找一些这方面的电子教程实例。　　只有调试了一两个EJB实例，这时你才可以站出来表达你的想法：喜欢或不喜欢？架构选型时也可以提供参考意见：是轻量型还是重量型？盲目排斥EJB或认为EJB是唯一解决方案等两种极端观点是要不得的，条条大路通罗马，伸缩和性能是关键。　　这里推荐一本从纯设计角度看待EJB/J2EE的书籍：Rod Johnson的《J2EE设计开发编程指南》，英文是Expert One-on-One J2EE Design and Development，Rod Johnson在书中从一个完美的设计角度指出了EJB缺点，这些缺点他是用黑体标识，非常醒目，同时，他将如果不使用EJB所带来的额外工作量使用正常小字体标识了，算是轻描淡写吧。当然，Rod Johnson为了将其理想的设计落实为代码，主持了Spring框架开发，如果J2EE领域有一个既符合完美的设计要求，又能支持成熟应用，同时又是业界标准，那是一个多么令人向往的事情，Spring框架至少在这方面做了有益的探索。　　集群、Web服务和资源整合　　对于中大型软件系统，集群和Web服务是必需掌握的技术，目前相关书籍不多。如何将J2EE新技术和现有资源整合，也属于一个探索性的领域，期待这几个方面有好的书籍问世。

张金鹏 2007-05-06 12:49 发表评论

J2EE开发框架发展简史

张金鹏 — Sun, 06 May 2007 04:47:00 GMT

J2EE开发框架发展简史


Java2企业版为中间件领域思想的统一上发挥了很大的作用。比如，J2EE为分布式事务管理、目录服务和消息服务提供了一套标准的编程接口。J2EE的基础??Java2标准版(J2SE) ，成功地为Java提供了一套访问关系数据库的标准。　　但是，就像本文中“J2EE缺乏对编程的支持”提到的一样，J2EE这个平台没有能够提供一个令人满意的应用程序编程模型（application programming model）。Sun公司和一些大的应用服务器供应商都想用开发工具来降低J2EE开发的复杂性，但是这些工具没有其他的JAVA 开发工具优秀，后者有先进的重构工具，和.NET平台相比，J2EE的工具支持显得很逊色。　　很多J2EE开发工具自动产生的代码像这些工具本身同样复杂。在开源社区很多小型J2EE开发者选择了另外一种开发方式?? 一些可以降低J2EE开发难度的开发框架,较为流行的比如： Struts, Hibernate, 和 Spring Framework，他们当今很多J2EE项目种扮演着重要角色。　　为什么要采用框架？　　框架是一由一些类组成，正式这些类为应用程序提供了一个可重用的设计――或者我们经常提到的??应用程序种的一层。应用程序代码访问类库从而执行任务，而框架是调用应用程序代码，从而管理程序的流程。这就是经常说道的好莱坞原则：“不要试图联系我们，我们到时候自会通知你。”开发者写的程序在运行时由框架调用。　　设计一个在各种未知背景下都可以使用的框架是很有挑战性的。框架很适合在复杂的J2EE开发中使用，它可以为开发者提供一个简单易用的模型。采用一个经过良好设计的开源框架有很多好处：　　?在好的框架下，开发者只需要写一些必须的代码；他们不需要直接接触底层的API。这一点很重要。　　?经过良好设计的框架可以为程序提供清晰的结构并且提高程序的内聚性。好清晰的结构使得其他人可以更容易加入项目。　　?一个容易使用的框架可以通过一些例子和文档为用户提供最佳实践。　　?采用成功的框架的代码比自己的代码容易测试　　?框架只有提供了一些值得使用的功能才会变得流行。J2EE工程只有真正需要框架的时候才会用它，而自己的框架并不是这样，后者是处于统治地位的。　　J2EE本身也提供了一些框架。比如， Enterprise Java-Beans (EJB) container或者 Servlet engine，二者都运用了“ 采用了好莱坞原则”这个思想，并采用运行时调用来管理对象。像Struts这些开源web应用框架正式建立在这两个框架的基础上的，本文讨论的重点也是像Struts这样建立在J2EE上的框架，他们为开发者提供了更为简单的模型，和其他的一些好处。　　开源框架的出现　　很多大型的J2EE项目都用自己的内部框架来隐藏平台的复杂性，直到最近人们才逐渐发现一些在很多项目中都存在的共有的难题，这些难题都可以由一个较为统一的解决方案来解决。而有的框架正好可以充当这些问题的解决方案。现在有种很明显的趋势：与从前的内部框架相比，这些框架将成为这些难题的更加“标准化 ”的解决方案。　　J2EE平台的日益成熟是这些框架流行的一个原因。开发者知道有些地方是J2EE的标准API无能为力的，倚他们的经验来看，要弥补这个缺陷是很困难的。于此同时，一些优秀的开源框架可供使用，它们提供了极为丰富的技术文档，在它们背后还有一个专业的团队做支持，并且一切都是免费的。　　Struts，在web应用程序产生时就有的开源框架。在1999－2000年，开发者们意识到JSP“Model1”的缺陷，JSP中充斥着请求处理代码和静态数据模板，这意味着你不得不把业务逻辑和复杂的HTML以及其他的标签混到一起。那个时候还没有标准的框架和J2EE的标准支持，要解决这个问题开发者就得自己实现前端控制器，这样可以把业务逻辑分离到java类中，从而可以减轻对JSP的维护难度。前端控制器模式经常运用在MVC架构中，MVC模式在OO语言的GUI开发中经常使用（这个名字总是让人误解，WEB MVC中的视图是从模型中“拉”数据；而在经典MVC中，模型把事件“推向”视图）。　　最初的前端控制器实现质量参差不齐。2001～2002年间，Apache开源组织发布的Struts改变了这个状况，虽然它并非一个完美的框架，但已经足够使其成为该领域事实上的标准。　　Struts向人们展示了开源框架的一些优点，比如，新手可以很容易地熟悉它的结构。2002年末，它成立很多J2EE项目很自然的选择，每一个认真的J2EE开发者都会对它很熟悉。　　Struts几乎用才每一个J2EE项目中，这使得它成为J2EE架构的一个重要组成部分。甚至很多保守的组织也将其作为软件底层的一部分，并同意接受Apache的开源协议条款。　　Hibernate。下一个倒下的多骨诺米牌就是持久化。J2EE提供了两个持久化的手段：JDBC，它是J2SE中访问关系数据库系统的标准API；另一个是实体Beans ,它是EJB中专门模型化持久化实体的组件。　　JDBC以一种错误的编程模型来强制开发者用Java代码来处理关系思想。而实体beans，先不说Sun和其他主要的J2EE供应商的吹嘘，给人很笨重的感觉：起初这门技术的应用范围很窄，连持久对象间的关系都不能处理。它使得应用程序难于测试，并且使用了一个很糟糕的查询语言。直到2003年，即使EJB2.0和2.0做了很多改进，开发者们却很少用它。　　早期的尝试　　持久化问题的解决方案是由关系-对象映射（ORM）来解决的，它可以透明地持久化普通java对象（POJO）。该思想在注释中有解释。虽然这种方案并不是专属java的。但相对与其他的社区而言比如.NET，ORM在java社区更加流行(.NET开发者总是对之抱有怀疑的态度)。　　早在1990年，一些商业的ORM工具就出现了，比如TopLink。但由于其价格昂贵、结构复杂并且与Sun的实体bean标准相左，所以很少人会用。不管怎样，在持久化POJO方面，这些工具与JDBC和实体Bean相比确实有了很大的进步　　Java Data Object于2001年在Java Community Progress(www.jcp.org)的规范中出现。它为一般的POJO提供了大多数的持久化实现(尽管很多实现都是对关系数据库的)。但Sun公司以及其他的J2EE技术提供商对该技术表现的很冷淡。所以JDO也没有能够流行。　　Hibernate的出现。ORM领域在2002年发生了大变化，原因有两个。首先，实体Beans在实践中失败，开发者们将其从J2EE中忽视掉了。它向开发者们说明了一个规范是如何将开发拉入泥潭的。　　另外的一个原因是Hibernate的发布，它是第一个功能健全的解决关系对象影射解决方案。虽然在功能上，它没有TopLink多样。但在那些最常用的功能上，Hibernate实现的更加健壮，并且有一个非常专业的团队提供全职的开发。Hibernate并不是全新的，它的ORM思想在这个领域很普遍，但它提供的编程模型比其他任何竞争者都容易使用、都来的直接，它为ORM的使用提供了更加易用、廉价的途径。　　于此同时，新一代的商业产品针对关系数据库提供了极其高效的JDO规范的实现。这样开发者的选择就更丰富了；还有，TopLink也朝着开发者友好的方向前进，它的liscense越来越开放了。　　ORM大获全胜　　所的这些因素是的ORM比以往更加规范。虽然很多项目仍然使用自己的持久层框架，但Hibernate，TopLink以及一些高端的JDO实现，使得使用自己持久层框架的难度相对变大、可维护性降低，自然，也没有什么理由去使用自己的框架了。　　虽然这些框架的功能覆盖范围已经很大了，但仍有很多地方不在其中。比如，一个基于struts，hibernate的项目，业务逻辑很难搞定。尽管对于这种问题，J2EE规范提出了解决方案（EJB），但仍旧没有一个合适的编程模型。　　Spring 　　J2EE框架被大规模地运用到项目中，而项目总要负责这些框架以及自己业务代码的连接，使之真正融合到一起。Spring就是专注于这个问题的，它和Hibernate融合的很好。　　本质上讲，Spring是IOC(Inversion of Control)和面向切面编程(AOP)的组合体。它是一个非侵入式的框架，增强了POJO的功能。从服务上讲(With a service abstraction)，它将程序代码从J2EE环境解耦到普通的java对象（自然，这些代码可以脱离J2EE而在多种环境中运行）。它还在很多功能上提供了除EJB之外的选择――比如为所有的POJO提供声明式事务。Spring被广泛运用到很多项目中，从小的web程序到大的企业应用程序。　　在这个领域还有其他的产品，比如HiveMind和NamoContainer。前者和Spring的思想大致相同，只不过在IOC上有较大差异；后者将很多服务融合在PicoContainer的IOC容器中。这些产品的实现方式和J2EE的不同在于，它们都很轻便。　　在有J2EE API下做测试是非常困难的，这些容器将POJO从J2EE API中脱离出来，从而大大降低了测试的难度。测试一个普通的java对象，不用象测试J2EE程序那样，得先将应用程序部署到服务器上，要不就得自己动手模拟J2EE环境。提供日益流行的测试驱动的开发环境（对于开发者来说这是应得的），是这些轻量容器流行的关键因素。　　下一个将会是谁？　　人们日益对开源框架的重视，使得很多项目的成本大大降低，并且投放使用以及维护速度都增加了。现在的开源框架都有很高的质量，都提供了很好的文档＆一些书籍让开发者做参考。即便如此，两大因素是的J2EE领域充满了不确定性：开源领域和J2EE“标准”的冲突和AOP的日益重要。　　开源和标准之间的冲突表现在两个地方。一个是表现层，JSF的身后有Sun公司和其他的一些大公司，而在这个领域有Struts等开源产品与之竞争。在中间层，EJB 3.0采用J2SE5.0的annotations实现了依赖注入(dependency injection)的功能，但这个功能只是Spring的一个子集　　在这两个领域，开源产品都更加革新。JSP借鉴了ASP.NET，而Tapestry则采用了WebObjects的思想。　　同样的，不知道EJB3.0为何要尝试着标准化依赖注入，即使这样会使之不可避免地丧失很多功能。 EJB 3.0好像也要进入程序编写领域，而J2EE规范在这方面还没有涉足。　　于此同时，AOP的重要性在J2EE社区猛增，在使用上，AOP也越来越受到开发者的青睐。像Spring、dynaop等被称作“带着双拐的AOP”实现提升了AOP的知名度。而纯粹的AOP技术比如AspectJ，在将来的几年也会流行起来。　　其次，JBoss通过JCP和EJB3.0保持一致，它极大地推动了AOP技术。但即使如此，JCP 还没有转向AOP迹象。　　下一代的J2EE规范将拥抱更简单的POJO编程模型，就像Spring和Hibernate做的一样。J2EE开发者也注定要从“欺诈客户”转到以自己的编程经验开发上来。这次改变将受到大多数人的欢迎，不像以前那样每一个新规范发布后，最终都没有能很好的实现。

张金鹏 2007-05-06 12:47 发表评论

J2EE体系结构

张金鹏 — Sun, 06 May 2007 04:44:00 GMT

J2EE体系结构


与.NET平台相比，Sun公司的标准定义的J2EE体系结构有很少可以讨论的空间，因为就没有什么可讨论的。如果一个人注意某个具体开发商的产品，如IBM公司的WebSphere，那么就会看到其技术的最大的一部分是WebSphere专用的。比较所有开发商对J2EE的具体改进，已经超出了本文的范围，在我的经验中，大多数对J2EE作为一个平台感兴趣的公司对该标准的可移值性感兴趣。任何对可移值性感兴趣的人都会需要将他们自己局限于Sun公司所定义的标准。 J2EE体系结构可以被分为5部分： Java语言系统客户端程序设计模型中间层基础结构程序员企业级API 非程序员可见API 最后一部分，非程序员可见API，包括定义了如何将其他产品插入到J2EE中的API，如连接器API，以及J2EE模型中被最近的改进有效替代的API，如JTA（Java Transaction API）。由于从比较微软和Sun公司计划的角度来说，非程序员可见API并不重要，因此在笔者的概述中将不涉及这些方面 (就如同笔者在.NET平台概述中并没有涉及功能相当的API一样)。 Java语言系统在高层次上，Java语言系统看起来与.NET Framework类似。在这两种情况中，源代码都是被翻译成一种中间语言。但是，在.NET平台中，这种中间语言是MSIL，而在Java系统中，是Java Byte Code。在这两种情况中，中间语言被带入到运行环境中。在Framework中，运行环境是Common Language Runtime。对于Java，运行环境是Java虚拟机（Java Virtual Machine）。总体而言，Common Language Runtime和Java虚拟机有类似的功能，并且在技术进步方面，都无可置疑地在发展和彼此交互跃进。这两种系统之间最重要的区别与源代码到中间语言的翻译有关。在.NET平台中，中间语言设计用来适应各种语言的需求。在Java中，中间语言设计用来满足Java的需求。虽然从理论上，从除Java外的语言生成Java Byte Code是可能的，但是实际上这还没有在任何一种商业产品中证明。客户端程序设计模型 J2EE客户端程序设计模型重点集中在与浏览器的交互上。客户端程序设计模型有3部分：Java Applets，Java Servlets和Java Server Pages。 Java Applets用来对在浏览器内运行的Java代码进行打包。在.NET平台空间中，这在功能上与ActiveX相当。在笔者的经验中，applets或ActiveX组件使用的相对较少。电子商务体系结构一般都是以向表示层发出请求的浏览器为基础，然后表示层使用HTML页面进行响应。这种系统并没有使用ActiveX或Java Applets，因此笔者在本白皮书中并没有讨论这些技术的任何一种。处理HTTP请求和HTML响应的重要技术是Java Servlets 和Java Server Pages 。这两种技术与微软空间中的ASP.NET（Active Server Pages）类似。 .NET平台与Java表示层中间的主要区别在于处理不同的客户端功能的方式。Java表示层沿用了以前的Microsoft ASP (pre .NET)模型，它使得表示层程序员的责任是决定最终的目的浏览器（或其他瘦客户端系统），瘦客户端系统的功能，以及如何生成HTML来充分发挥瘦客户端系统的优势。中间层基础结构对于J2EE，中间层基础结构是Enterprise Java Beans (EJB)。该规范的当前版本是2.0，可以从网上获得。与J2EE相当的.NET平台是COM+。在EJB和COM+之间，体系结构的差别非常少。这两种体系结构本质上是从MTS（Microsoft Transaction Server）派生出来的，是由微软公司在1996年引入的最初的面向组件的中间层基础结构。由MTS最先引入，然后合并到EJB和COM+中的重要想法包括：通过组件示例的共享所实现的高可伸缩性以中间层为中心的安全性自动事务处理边界管理 EJB加入了一种新的体系结构想法，一项自动管理组件状态的技术。这项技术被称为entity beans（实体豆）。虽然这种想法具有吸引力，但是当前的实施却依赖于独立于数据库缓存的中间层数据缓存。很不幸的是，在这两种缓存之间没有保持一致性的机制。这意味着对实体豆的任何使用都会带来数据库损坏的高风险。在缓存一致性问题解决之前，在最佳试验技术方面，必须得不断考虑实体豆技术。要连接EJB和COM+的深入比较，请参阅笔者最近的著作。程序员企业级API 我们调用Java Enterprise API 时的最重要部分如下： Java Database Connection (JDBC，Java数据库连接) 2.0 ?C 是用于从Java中访问关系型数据库的API 。这与.NET平台空间中的ADO.NET相当。 Java Naming and Directory Interface (JNDI，Java命名与目录接口) ?C 是用于从Java中访问企业名称与目录服务的信息的API 。这与.NET平台空间中的Active Directory Services Interface (ADSI，活动目录服务接口)有点类似。 Java Message Service (JMS，Java消息服务) 1.0 ?C 是用于异步工作流的Java API 。这在功能上与Microsoft Message Queue API相当，这个API已经被排队组件所替代。

张金鹏 2007-05-06 12:44 发表评论

J2EE层次设计架构实例分析详解

张金鹏 — Sun, 06 May 2007 04:43:00 GMT

J2EE层次设计架构实例分析详解


Part 1 层　　　　层（layer）这个概念在计算机领域是非常了不得的一个概念。计算机本身就体现了一种层的概念：系统调用层、设备驱动层、操作系统层、CPU指令集。每个层都负责自己的职责。网络同样也是层的概念，最著名的OSI的七层协议。　　　　层到了软件领域也一样好用。为什么呢？我们看看使用层技术有什么好处：　　　　● 你使用层，但是不需要去了解层的实现细节。　　● 可以使用另一种技术来改变基础的层，而不会影响上面的层的应用。　　● 可以减少不同层之间的依赖。　　● 容易制定出层标准。　　● 底下的层可以用来建立顶上的层的多项服务。当然，层也有弱点：　　● 层不可能封装所有的功能，一旦有功能变动，势必要波及所有的层。　　● 效率降低。　　　　当然，层最难的一个问题还是各个层都有些什么，以及要承担何种责任。　　　　典型的三层结构　　　　三层结构估计大家都很熟悉了。就是表示（presentation）层, 领域（domain）层, 以及基础架构（infrastructure）层。　　　　表示层逻辑主要处理用户和软件的交互。现在最流行的莫过于视窗图形界面（wimp）和基于html的界面了。表示层的主要职责就是为用户提供信息，以及把用户的指令翻译。传送给业务层和基础架构层。基础架构层逻辑包括处理和其他系统的通信，代表系统执行任务。例如数据库系统交互，和其他应用系统的交互等。大多数的信息系统，这个层的最大的逻辑就是存储持久数据。　　　　还有一个就是领域层逻辑，有时也被叫做业务逻辑。它包括输入和存储数据的计算。验证表示层来的数据，根据表示层的指令指派一个基础架构层逻辑。　　　　领域逻辑中，人们总是搞不清楚什么事领域逻辑，什么是其它逻辑。例如，一个销售系统中有这样一个逻辑：如果本月销售量比上个月增长10％，就要用红色标记。要实现这个功能，你可能会把逻辑放在表示层中，比较两个月的数字，如果超出10％，就标记为红色。　　　　这样做，你就把领域逻辑放到了表示层中了。要分离这两个层，你应该现在领域层中提供一个方法，用来比较销售数字的增长。这个方法比较两个月的数字，并返回boolean类型。表示层则简单的调用该方法，如果返回true，则标记为红色。　　　　例子　　　　层技术不存在说永恒的技巧。如何使用都要看具体的情况才能够决定，下面我就列出了三个例子：　　　　例子1：一个电子商务系统。要求能够同时处理大量用户的请求，用户的范围遍及全球，而且数字还在不断增长。但是领域逻辑很简单，无非是订单的处理，以及和库存系统的连接部分。这就要求我们1、表示层要友好，能够适应最广泛的用户，因此采用html技术；2、支持分布式的处理，以胜任同时几千的访问； 3、考虑未来的升级。　　　　例子2：一个租借系统。系统的用户少的多，但是领域逻辑很复杂。这就要求我们制作一个领域逻辑非常复杂的系统，另外，还要给他们的用户提供一个方便的输入界面。这样，wimp是一个不错的选择。　　　　例子3：简单的系统。非常简单，用户少、逻辑少。但是也不是没有问题，简单意味着要快速交付，并且还要充分考虑日后的升级。因为需求在不断的增加之中。　　　　何时分层　　　　这样的三个例子，就要求我们不能够一概而论的解决问题，而是应该针对问题的具体情况制定具体的解决方法。这三个例子比较典型。　　　　第二个例子中，可能需要严格的分成三个层次，而且可能还要加上另外的中介（mediating）层。例3则不需要，如果你要做的仅是查看数据，那仅需要几个server页面来放置所有的逻辑就可以了。　　　　我一般会把表示层和领域层/基础架构层分开。除非领域层/基础架构层非常的简单，而我又可以使用工具来轻易的绑定这些层。这种两层架构的最好的例子就是在VB、PB的环境中，很容易就可以构建出一个基于SQL数据库的windows界面的系统。这样的表示层和基础架构层非常的一致，但是一旦验证和计算变得复杂起来，这种方式就存在先天缺陷了。　　　　很多时候，领域层和基础架构层看起来非常类似，这时候，其实是可以把它们放在一起的。可是，当领域层的业务逻辑和基础架构层的组织方式开始不同的时候，你就需要分开二者。　　　　更多的层模式　　　　三层的架构是最为通用的，尤其是对IS系统。其它的架构也有，但是并不适用于任何情况。　　　　第一种是Brown model [Brown et al]。它有五个层：表示层（Presentation），控制/中介层（Controller/Mediator），领域层（Domain）, 数据映射层（Data Mapping）, 和数据源层（Data Source）。它其实就是在三层架构种增加了两个中间层。控制/中介层位于表示层和领域层之间，数据映射层位于领域层和基础架构层之间。　　　　表示层和领域层的中介层，我们通常称之为表示-领域中介层，是一个常用的分层方法，通常针对一些非可视的控件。例如为特定的表示层组织信息格式，在不同的窗口间导航，处理交易边界，提供Server的facade接口（具体实现原理见设计模式）。最大的危险就是，一些领域逻辑被放到这个层里，影响到其它的表示层。　　　　我常常发现把行为分配给表示层是有好处的。这可以简化问题。但表示层模型会比较复杂，所以，把这些行为放到非可视化的对象中，并提取出一个表示-领域中介层还是值得的。　　　　Brown ISA 　　表示层表示层　　控制/中介层表示-领域中介层　　领域层领域层　　数据映射层数据库交互模式中的Database Mapper 　　数据源层基础架构层　　　　领域层和基础架构层之间的中介层属于本书中提到的Database Mapper模式，是三种领域层到数据连接的办法之一。和表示-领域中介层一眼，有时候有用，但不是所有时候都有用。　　　　还有一个好的分层架构是J2EE的架构，这方面的讨论可以见『J2EE核心模式』一书。他的分层是客户层（Client），表示层（Presentation），业务层（Business ），整合层（Integration），资源层（Resource）。差别如下图：　　　　J2EE核心 ISA 　　客户层运行在客户机上的表示层　　表示层运行在服务器上的表示层　　业务层领域层　　整合层基础架构层　　资源层基础架构层通信的外部数据　　　　微软的DNA架构定义了三个层：表示层（presentation），业务层（business），和数据存储层（data access），这和我的架构相似，但是在数据的传递方式上还有很大的不同。在微软的DNA中，各层的操作都基于数据存储层传出的SQL查询结果集。这样的话，实际上是增加了表示层和业务层同数据存储层之间的耦合度。 DNA的记录集在层之间的动作类似于Data Transfer Object。转贴于 265考试网 Part 2 组织领域逻辑　　　　要组织基于层的系统，首要的是如何组织领域逻辑。领域逻辑的组织有好几种模式。但其中最重要的莫过于两种方法：Transation Script和Domain Model。选定了其中的一种，其它的都容易决定。不过，这两者之间并没有一条明显的分界线。所以如何选取也是门大学问。一般来说，我们认为领域逻辑比较复杂的系统可以采用Domain Model。　　　　Transation Script就是对表示层用户输入的处理程序。包括验证和计算，存储，调用其它系统的操作，把数据回传给表示层。用户的一个动作表示一个程序，这个程序可以是script，也可以是transation，也可以是几个子程序。在例子1中，检验，在购物车中增加一本书，显示递送状态，都可以是一个 Transation Script。　　　　Domain Model是要建立对应领域名词的模型，例如例1中的书、购物车等。检验、计算等处理都放到领域模型中。　　　　Transation Script属于结构性思维，Domain Model属于OO思维。Domain Model比较难使用，一旦习惯，你能够组织更复杂的逻辑，你的思想会更OO。到时候，即使是小的系统，你也会自然的使用Domain Model了。　　　　但如何抉择呢？如果逻辑复杂，那肯定用Domain Model：如果只需要存取数据库，那Transation Script会好一些。但是需求是在不断进化的，你很难保证以后的需求还会如此简单。如果你的团队不善于使用Domain Model，那你需要权衡一下投入产出比。另外，即使是Transation Script，也可以做到把逻辑和基础架构分开，你可以使用Gateway。　　　　对例2，毫无疑问要使用Domain Model。对例1就需要权衡了。而对于例3，你很难说它将来会不会像例2那样，你现在可以使用Transation Script，但未来你可能要使用Domain Model。所以说，架构的决策是至关紧要的。　　　　除了这两种模式，还有其它中庸的模式。Use Case Controller就是处于两者之间。只有和单个的用例相关的业务逻辑才放到对象中。所以大致上他们还是在使用Transation Script，而Domain Model只是Database Gateway的一组集合而已。我不太用这种模式。　　　　Table Module是另一个中庸模式。很多的GUI环境依托于SQL查询的返回结果。你可以建立内存中的对象，来把GUI和数据库分开来。为每个表写一个模块，因此每一行都需要关键字变量来识别每一个实例。　　　　Table Module适用于很多的组件构建于一个通用关系型数据库之上，而且领域逻辑不太复杂的情况。Microsoft COM 环境，以及它的带ADO.NET的.NET环境都适合使用这种模式。而对于Java，就不太适用了。　　　　领域逻辑的一个问题是领域对象非常的臃肿。因为对象的行为太多了，类也就太大了。它必须是一个超集。这就要考虑哪些行为是通用的，哪些不是，可以由其它的类来处理，可能是Use Case Controller，也可能是表示层。　　　　还有一个问题，复制。他会导致复杂和不一致。这比臃肿的危害更大。所以，宁可臃肿，也不要复制。等到臃肿为害时再处理它吧。　　　　选择一个地方运行领域逻辑　　　　我们的精力集中在逻辑层上。领域逻辑要么运行在Client上，要么运行在Server上。　　　　比较简单的做法是全部集中在Server上。这样你需要使用html的前端以及web server。这样做的好处是升级和维护都非常的简单，你也不用考虑桌面平台和Server的同步问题，也不用考虑桌面平台的其它软件的兼容问题。　　　　运行在Client适合于要求快速反应和没有联网的情况。在Server端的逻辑，用户的一个再小的请求，也需要信息从Client到Server绕一圈。反应的速度必然慢。再说，网络的覆盖程度也不是说达到了100％。　　　　对于各个层来说，又是怎么样的呢？　　　　基础架构层：一般都是在Server啦，不过有时候也会把数据复制到合适的高性能桌面机，但这是就要考虑同步的问题了。　　　　表示层在何处运行取决于用户界面的设计。一个Windows界面只能在Client运行。而一个Web界面就是在Server运行。也有特别的例子，在桌面机上运行web server的，例如X Server。但这种情况少的多。　　　　在例1中，没有更多的选择了，只能选在Server端。因此你的每一个bit都会绕一个大圈子。为了提高效率，尽量使用一些纯html脚本。　　　　人们选用Windows界面的原因主要就是需要执行一些非常复杂的任务，需要一个合适的应用程序，而web GUI则无法胜任。这就是例2的做法。不过，人们应该会渐渐适应web GUI，而web GUI的功能也会越来越强大。　　　　剩下的是领域逻辑。你可以全部放在Server，也可以全部放在Client，或是两边都放。　　　　如果是在Client端，你可以考虑全部逻辑都放在Client端，这样至少保证所有的逻辑都在一个地方。而把web server移至Client，是可以解决没有联网的问题，但对反应时间不会有多大的帮助。你还是可以把逻辑和表示层分离开来。当然，你需要额外的升级和维护的工作。　　　　在Client和Server端都具有逻辑并不是一个好的处理办法。但是对于那些仅有一些领域逻辑的情况是适用的。有一个小窍门，把那些和系统的其它部分没有联系的逻辑封装起来。领域逻辑的接口　　　　你的Server上有一些领域逻辑，要和Client通信，你应该有什么样的接口呢？要么是一个http接口，要么是一个OO接口。　　　　http接口适用于web browser，就是说你要选择一个html的表示层。最近的新技术就是web service，通过基于http、特别是XML进行通信。XML有几个好处：通信量大，结构好，仅需一次的回路。这样远程调用的的开销就小了。同时，XML还是一个标准，支持平台异构。XML又是基于文本的，能够通过防火墙。　　　　虽然XML有那么多的好处，不过一个OO的接口还是有它的价值的。hhtp的接口不明显，不容易看清楚数据是如何处理的。而OO的接口的方法带有变量和名字，容易看出处理的过程。当然，它无法通过防火墙，但可以提供安全和事务之类的控制。　　　　最好的还是取二者所长。OO接口在下，http接口在上。但这样做就会使得实现机制非常的复杂。　　　　Part 3 组织web Server 　　　　很多使用html方式的人，并不能真正理解这种方式的优点。我们有各种各样好用的工具，但是却搞到让程序难以维护。　　　　在web server上组织程序的方式大致可以分为两种：脚本和server page。　　　　脚本方式就是一个程序，用函数和方法来处理http调用。例如CGI脚本和java servlet。它和普通的程序并没有什么两样。它从web页面上获得html string形态的数据，有时候还要做一些表达式匹配，这正是perl能够成为CGI脚本的常用语言的原因。而java servelet则是把这种分析留给程序员，但它允许程序员通过关键字接口来访问信息，这样就会少一些表达式的判断。这种格式的web server输出是另一种html string，称为response，可以通过流数据来操作。　　　　糟糕的是流数据是非常麻烦的，因此就导致了server page的产生，例如PHP，ASP，JSP。　　　　server page的方式适合回应（response）的处理比较简单的情况。例如“显示歌曲的明细”，但是你的决策取决于输入的时候，就会比较杂乱。例如“通俗和摇滚的显示格式不同”。　　　　脚步擅长于处理用户交互，server page擅长于处理格式化回应信息。所以很自然的就会采用脚本处理请求的交互，使用server page处理回应的格式化。这其实就是著名的MVC（Model View Controller）模式中的view/controller的处理。　　　　应用Model View Controller模式首要的一点就是模型要和web服务完全分离开来。使用Transaction Script或Domain Model模式来封装处理流程。　　　　接下来，我们就把剩余的模式归入两类模式中：属于Controller的模式，以及属于View的模式。　　　　View模式　　　　View这边有三种模式：Transform View，Template View和Two Step View。Transform View和Template View的处理只有一步，将领域数据转换为html。Two Step View要经过两步的处理，第一步把领域数据转换为逻辑表示形式，第二步把逻辑表示转换为html。　　　　两步处理的好处是可以将逻辑集中于一处，如果只有一步，变化发生时，你就需要修改每一个屏幕。但这需要你有一个很好的逻辑屏幕结构。如果一个web应用有很多的前端用户时，两步处理就特别的好用。例如航空订票系统。使用不同的第二步处理，就可以获得不同的逻辑屏幕。　　　　使用单步方法有两个可选的模式：Template View，Transform View。Template View其时就是把代码嵌入到html页面中，就像现在的server page技术，如ASP，PHP，JSP。这种模式灵活，强大，但显得杂乱无章。如果你能够把逻辑程序逻辑在页面结构之外进行很好的组织，这种模式还是有它的优点的。　　　　Transform View使用翻译方式。例如XSLT。如果你的领域数据是用XML处理的，那这种模式就特别的好用。　　　　Controller模式　　　　Controller有两种模式。一般我们会根据动作来决定一项控制。动作可能是一个按钮或链接。所这种模式就是Action Controller模式。　　　　Front Controller更进一步，它把http请求的处理和处理逻辑分离开来。一般是只有一个web handle来处理所有的请求。你的所有的http请求的处理都由一个对象来负责。你改变动作结构的影响就会降到最小。

张金鹏 2007-05-06 12:43 发表评论

当前流行的J2EE WEB应用架构分析

张金鹏 — Sun, 06 May 2007 04:42:00 GMT

当前流行的J2EE WEB应用架构分析


1. 架构概述 J2EE体系包括java server pages(JSP) ,java SERVLET, enterprise bean，WEB service等技术。这些技术的出现给电子商务时代的WEB应用程序的开发提供了一个非常有竞争力的选择。怎样把这些技术组合起来形成一个适应项目需要的稳定架构是项目开发过程中一个非常重要的步骤。完成这个步骤可以形成一个主要里程碑基线。形成这个基线有很多好处：各种因数初步确定为了形成架构基线，架构设计师要对平台（体系）中的技术进行筛选，各种利弊的权衡。往往架构设计师在这个过程中要阅读大量的技术资料，听取项目组成员的建议，考虑领域专家的需求，考虑赞助商成本（包括开发成本和运行维护成本）限额。一旦架构设计经过评审，这些因数初步地就有了在整个项目过程中的对项目起多大作用的定位。定向技术培训一旦架构师设计的架构得到了批准形成了基线，项目开发和运行所采用的技术基本确定下来了。众多的项目经理都会对预备项目组成员的技术功底感到担心；他们需要培训部门提供培训，但就架构师面对的技术海洋，项目经理根本就提不出明确的技术培训需求。怎不能够对体系中所有技术都进行培训吧！有了架构里程碑基线，项目经理能确定这个项目开发会采用什么技术，这是提出培训需求应该是最精确的。不过在实际项目开发中，技术培训可以在基线确定之前与架构设计并发进行。角色分工有了一个好的架构蓝图，我们就能准确划分工作。如网页设计，JSP 标签处理类设计，SERVLET 设计，session bean设计，还有各种实现。这些任务在架构蓝图上都可以清晰地标出位置，使得项目组成员能很好地定位自己的任务。一个好的架构蓝图同时也能规范化任务，能很好地把任务划分为几类，在同一类中的任务的工作量和性质相同或相似。这样工作量估计起来有一个非常好的基础。运行维护前面说过各个任务在架构图上都有比较好的定位。任何人能借助它很快地熟悉整个项目的运行情况，错误出现时能比较快速地定位错误点。另外，有了清晰的架构图，项目版本管理也有很好的版本树躯干。扩展性架构犹如一颗参天大树的躯干，只要躯干根系牢，树干粗，长一些旁支，加一些树叶轻而易举无疑。同样，有一个稳定的经得起考验的架构，增加一两个业务组件是非常快速和容易的。大家都知道这些好处，一心想形成一个这样的J2EE应用程序架构（就像在windows平台中的MFC）。在这个路程中经历了两个大的阶段： 1.1. 模型1 模型1其实不是一个什么稳定架构，甚至谈不上形成了架构。模型1的基础是JSP文件。它从HTTP的请求中提取参数，调用相应的业务逻辑，处理HTTP会话，最后生成HTTP文档。一系列这样的JSP文件形成一个完整的模型1应用，当然可能会有其他辅助类或文件。早期的ASP 和 PHP 技术就属于这个情况。总的看来，这个模型的好处是简单，但是它把业务逻辑和表现混在一块，对大应用来说，这个缺点是令人容忍不了的。 1.2. 模型2 在经过一番实践，并广泛借鉴和总结经验教训之后，J2EE应用程序终于迎来了MVC（模型-视图-控制）模式。MVC模式并不是J2EE行业人士标新立异的，所以前面我谈到广发借鉴。MVC的核心就是做到三层甚至多层的松散耦合。这对基于组件的，所覆盖的技术不断膨胀的J2EE体系来说真是福音和救星。它在浏览器（本文对客户代理都称浏览器）和JSP或SERVLET之间插入一个控制组件。这个控制组件集中了处理浏览器发过来的HTTP请求的分发逻辑，也就是说，它会根据HTTP请求的URL,输入参数，和目前应用的内部状态，把请求分发给相应的WEB 层的JSP 或SERVLET。另外它也负责选择下一个视图（在J2EE中，JSP,SERVLET会生成回给浏览器的html从而形成视图）。集中的控制组件也有利于安全验证，日志纪录，有时也封装请求数据给下面的WEB tier层。这一套逻辑的实现形成了一个像MFC的应用框架， 1.3. 多层应用 Client tier客户层一般为浏览器或其他应用。客户层普遍地支持HTTP协议，也称客户代理。 WEB tier WEB应用层在J2EE中，这一层由WEB 容器运行，它包括JSP, SERVLET等WEB部件。 EJB tier 企业组件层企业组件层由EJB容器运行，支持EJB, JMS, JTA 等服务和技术。 EIS tier 企业信息系统层企业信息系统包含企业内传统信息系统如财务，CRM等，特点是有数据库系统的支持。应用框架目前主要集中在WEB层，旨在规范这一层软件的开发。其实企业组件层也可以实现这个模型，但目前主要以设计模式的形式存在。而且有些框架可以扩充，有了企业组件层组件的参与，框架会显得更紧凑，更自然，效率会更高 2. 候选方案目前，实现模型2的框架也在不断的涌现，下面列出比较有名的框架。 2.1. Apache Struts Struts是一个免费的开源的WEB层的应用框架，apache软件基金致力于struts的开发。Struts具是高可配置的性，和有一个不断增长的特性列表。一个前端控制组件，一系列动作类，动作映射，处理XML的实用工具类，服务器端java bean 的自动填充，支持验证的WEB 表单，国际化支持，生成HTML，实现表现逻辑和模版组成了struts的灵魂。 2.1.1. Struts和MVC 模型2的目的和MVC的目的是一样的，所以模型2基本可以和MVC等同起来。下图体现了Struts的运作机理： 2.1.1.1. 控制如图所示，它的主要部件是一个通用的控制组件。这个控制组件提供了处理所有发送到Struts 的HTTP请求的入口点。它截取和分发这些请求到相应的动作类（这些动作类都是Action类的子类）。另外控制组件也负责用相应的请求参数填充 From bean,并传给动作类。动作类实现核心商业逻辑，它可以通过访问java bean 或调用EJB。最后动作类把控制权传给后续的JSP 文件，后者生成视图。所有这些控制逻辑利用一个叫struts-config.xml文件来配置。 2.1.1.2. 模型模型以一个或几个java bean的形式存在。这些bean分为三种： Form beans(表单Beans) 它保存了HTTP post请求传来的数据，在Struts里，所有的Form beans都是 ActionFrom 类的子类。业务逻辑beans 专门用来处理业务逻辑。系统状态beans 它保存了跨越多个HTTP 请求的单个客户的会话信息，还有系统状态。 2.1.1.3. 视图控制组件续传HTTP请求给实现了视图的JSP文件。JSP能访问beans 并生成结果文档反馈到客户。Struts提供JSP 标签库： Html，Bean，Logic，Template等来达到这个目的，并有利于分开表现逻辑和程序逻辑。 2.1.2. Struts的细节分析 2.1.2.1. 视图-控制-模型用户发出一个.do的HTTP请求，控制组件接收到这个请求后，查找针对这个请求的动作映射，再检查是否曾创建过相应的动作对象（action实例），如果没有则调用actionmapping生成一个动作对象，控制组件会保存这个动作对象供以后使用。接着调用actionmapping的方法得到actionForm对象。之后把actionForm作为参数传给动作对象的perform方法，这个方法结束之后会返回给控制组件一个 actionforward对象。控制组件接着从这个对象中获取下一个视图的路径和重定向属性。如果为重定向则调用HTTPSERVLETREPONSE的方法来显示下一个视图，否则相继调用requestdispatcher, SERVLETcontext的方法续传HTTP请求到下一个视图。当动作对象运行perform方法时，可能出现错误信息。动作对象可以保存这些错误信息到一个error对象中，接着调用自身的saveerrors方法把这个错误保存到request对象的属性中。接着动作对象调用actionmapping对象的getInput方法从动作映射中获取input参数，也就是产生输入的视图，并以这个input为参数生成一个actionforward对象返回。这个input参数的JSP中一般有HTTP:errors定制标签读取这些错误信息并显示在页面上。 2.1.2.2. 模型到视图模型到视图指视图在显示之前装载系统数据到视图的过程。系统数据一般为模型内java bean的信息。示意图表现了由控制组件forward过来的有html:form定制标签的JSP 的处理逻辑。 html:form定制标签处理对象从application scope（通过查询SERVLETCONTEXT对象的属性来实现）获取先前由控制组件actionSERVLET放在那里的动作映射等对象，由html:form 的action属性查得actionform名字、类型和范围等信息，在相应的范围内查找actionform，如果有则利用它的信息填充html form表单[实际填充动作在嵌套的html:text等定制标签的处理对象中]。否则在相应范围内创建一个actionform 对象。 2.1.3. 优缺点优点一些开发商开始采用并推广这个框架作为开源项目，有很多先进的实现思想对大型的应用支持的较好有集中的网页导航定义缺点不是业届标准对开发工具的支持不够复杂的taglib，需要比较长的时间来掌握 html form 和 actionform的搭配比较封闭，但这也是它的精华所在。修改建议把actionform属性的设置器和访问器修改成读取或生成xml文档的方法，然后 html form和actionform之间用xml文档进行数据交换，使之松散耦合，适应数据结构易变化的应用。 2.2. JATO JATO应用程序框架是iPlanet 应用程序框架的旧名。它是一个成熟的、强大的，基于J2EE标准的面向于开发WEB应用程序的应用框架。结合了显示字段、应用程序事件、组件层次和以页面为中心的开发方法、以及MVC和服务到工作者service-to-workers的设计模式等概念。JATO可适用于中、大、超大规模的WEB应用。但是它也不是一个企业层的应用框架，也就是说它不会直接提供创建EJB, WEB services等企业层组件的方法，但用它可以构造出访问企业层组件的客户应用。这个框架功能主要有三部分组成： iPlanet应用框架核心； iPlanet应用框架组件； iPlanet应用框架扩展。应用框架核心定义了基本接口、对象协议、简单组件，以及iPlanet应用框架程序的最小核心。包括视图简单组件、模型简单组件、请求分发组件和可重用命令对象。iPlanet应用框架组件利用框架核心定义的基本接口、协议和组件向开发者提供高层的重用组件，这些组件既有与特定视觉效果无关的水平组件，同时也有适应特定实用环境、提高可用性而特意提供的垂直型组件。框架扩展实现了用框架相容的方法访问非J2EE环境的方法。通常情况下，扩展被框架应用程序用来无缝访问J2EE容器特定功能。JATO平台栈图很清楚地表达了这个情况 JATO最大的威力在：对于快速开发用户，你能利用框架组件和扩展提高生产率，对于要求更大灵活性的用户，你能实现框架核心提供的接口来保持应用的框架兼容性。此图表示实现一个JATO应用程序，可以简单地实现控制组件module1Servlet，视图组件ListCustomersViewBean和模型组件CustomersModuleImpl，以及一个给客户代理显示界面的ListCustomers.jsp文件。并清楚地表明这些组件与JATO框架组件的继承关系。 JATO标签库提供了VIEW对象与JSP文件的接口。库中标签处理程序负责实现VIEW对象和JSP产生地客户端文档的信息同步和交换。这个图清楚地表达了这种对应关系 2.2.1. MVC分析前端控制组件接收用户发来的任何请求，这个可在WEB.xml中指定请求分发组件负责视图管理和导航，和前端控制组件封装在ApplicationSERVLETBase一起实现。应用程序开发者需要为每一个子系统（人力资源，财务，CRM等）实现一个此类的继承。请求分发组件分发请求给工作者，工作者实现了command接口。应用开发者可以实现这个接口。JATO提供了一个缺省实现：DefaultRequestHandingCommand，这个实现会把请求传给视图组件的特定事件。组合视图是指视图组件在显示给用户时的层次关系：根视图是一个ViewBean类的对象字段是一个DisplayField类的对象，容器视图是一个ContainerView类的对象。 2.2.2. 优缺点分析优点：这种框架的适应范围大，即提供了底层接口，也有立即可用的组件具有与客户端RAD开发工具相似的开发概念如页为中心（等同于VB的FORM），事件处理等. 对大型的应用支持较好缺点：不是业届标准目前还没有开发工具的支持（然JATO已经为工具支持做好了准备）没有定义网页导航，开发者在视图中自己指定具体的导航URL 修改建议把众多的VIEW/MODEL对应修改成xml文档传递数据，加上集中的网页导航定义 2.3. JSF(JavaServer Faces) JSF是一个包括SUN在内的专家组正在定义的开发WEB应用用户界面的框架，JSF 技术包括：一组API，它实现UI了组件，管理组件的状态，处理事件，输入校验，定义页面导航，支持国际化和访问；一个JSP定制标签库实现与JSP的接口。 JSF非常简单，是一个定义良好的编程模型。利用这个技术，开发者通过在页面内组合可重用的UI组件，在把这些组件和应用的数据源相连，路由客户产生的事件到服务器端的事件处理器进行编程。JSP处理了所有幕后的复杂工作，使得开发者把关注重点放在应用代码上。 2.3.1. STRUTS、JATO和JSF比较它们之间有部分重叠，但重点不一样。 STRUTS和JATO都提供了一个MVC式的应用模型，而JSF只在用户界面上提供编程接口。这意味着前两者涉及的范围比后者广。JSF可以成为前两者在UI开发的部分。 JSF的规范的发布版将在 2002年底发布，实现可能要比这个时间晚些。另外将会有工具支持这个框架的应用开发。 2.4. WAF WAF是WEB APPLICATION FRAMWORK的简称，是SUN蓝皮书例子程序中提出的应用框架。它实现了 MVC和其他良好的设计模式。 2.4.1. 细节分析 2.4.2. 视图-控制-模型如图所示，开发人员编写的两个xml配置文件定义了WAF的运作参数。Screendefinition.xml定义了一系列的屏幕(screen)。Mapping.xml则定义了某个动作之后应该显示的屏幕，但没有指定屏幕到哪里拿数据。用户发出一个HTTP请求（.screen），由TemplateSERVLET屏幕前端控制组件接收，它提取请求信息，设置request对象CurrentScreen属性，再把请求发到模版JSP。模版JSP收到请求后，JSP中的Template标签察看这个当前屏幕，并从屏幕定义文件（Screendefinition.xml）中获取这个屏幕的具体参数，再生成html返回给客户。假设返回给客户的html中包括了html表单，用户在输入一定数据之后提交，发出一个HTTP请求（*.do）。这个请求被MainSERVLET接收，它提取请求信息，察看动作映射文件（mapping.xml），设置处理这个请求的动作对象(HTTPAction对象)，交给requestprosessor对象处理。Requestprosessor对象调用动作对象完成任务，如果需要进一步处理，requestprosessor对象会调用WEBclientcontroler对象的事件处理机制。MainSERVLET在处理完请求之后，从屏幕流管理对象那里得到下一个屏幕，并把请求传给这个屏幕的JSP文件。值得一提的是WEBclientcontroler事件处理机制最终把HTTP请求的数据传到了EJBAction对象那里处理。这样HTTPAction对象和EJBAction对象形成了两级处理机制，前一级与request对象紧密相关，把数据封装起来形成一个Event对象，再传给了EJBAction对象，后者与Request对象无关。这个方式可以形成一个session级别的数据处理机制。下图显示了这个方法。HTTPAction1对象处理一个请求，并把数据放到一个状态SessionBean内，HTTPAction2也如此，当HTTPAction3接收到HTTP请求之后，把控制传给EJBAction, 后者获取状态SessionBean数据，处理请求，成功后清控状态SessionBean的内容。这个机制非常适应多个输入页面才能满足一个业务的输入数据的情况（比如购物车）。 2.4.3. 优缺点分析优点屏幕导航定义明确为框架的扩展提供了一个空间缺点源码比较乱，稳定性和可靠性没人验证。只是一个框架躯干，没有正式的model层，视图的概念不强没有模型到视图的定义修改意见只有一个框架躯干，正为实现自己的应用框架提供了灵活性。没有僵化的视图概念，提供了在网页输入到模型的扩充接口，比如插入XML数据交换。

张金鹏 2007-05-06 12:42 发表评论

J2EE中软件基础结构的瓶颈

张金鹏 — Sun, 06 May 2007 04:41:00 GMT

J2EE中软件基础结构的瓶颈


可扩展性是系统中的一个非常重要的非功能性需求。但系统中可能有多个瓶颈会阻碍系统的扩展性。在这篇文章中，我们尝试分析软件基础结构成为瓶颈的案例，而不考虑硬件资源上的限制（如CPU、磁盘空间、网络速度等）。下面我们将探讨一下这个问题。下面是一些整篇文章中用到的一些术语： ·吞吐量：系统支持的每秒能够处理的事务个数。 ·服务请求：每个事务中特定硬件的使用率，等于硬件使用率除以吞吐量。 ·硬件资源：指处理器、内存、磁盘和网络。 ·软件资源：指WEB线程、执行线程、BEAN池及数据库连接池等。 ·预计时间：用户预计两次并发提交请求之间的时间。 ·短时间法则：一个验证测试及确信测试环境不是瓶颈的法则。 ·响应时间：用户等待他提交的请求返回响应的时间。理论基础任何J2EE应用通常都有下面几个层次，如图1： 1、硬件基础结构资源（处理器、内存、磁盘和网络） 2、软件基础结构资源（JVM,WEB服务器、应用服务器、数据库服务器） 3、软件应用（J2EE应用） Figure 1. Snapshot of a J2EE system 这儿有两个可能性导致瓶颈：硬件成为主要瓶颈或者软件成为主要瓶颈。在第一种情况，硬件资源不足够而软件资源很充分，如图2。随着负载的增加，硬件资源成为瓶颈，而软件可以继续扩展。减轻这个瓶颈的方案通常是扩大或者增加硬件。 Figure 2. The hardware pipe becomes a bottleneck 在第二种情况，硬件资源是足够的而软件资源相对有限。随着负载的增加，软件资源成为瓶颈，如图3。减轻这种瓶颈的方案通常是使用软件群集或优化软件。 Figure 3. Software pipe becomes a bottleneck 应用服务器如何工作？来考虑一下应用服务器的内部机制。应用服务器的基本功能包括事务管理、数据持久、对象池、SOCKET处理和请求处理。这些功能的流程如图4。有各种组件来处理这些功能。这些组件需要同步应用服务器中的线程来维护数据的一致性并操作数据。虽然这种同步对应用服务器的功能正确性是必须而且有用的，但是也成为高负载的限制，即使有足够的硬件资源。 Figure 4. Internals of an application server 实验为了理解瓶颈的状况，我们在基于Windows/Intel平台用流行的J2EE应用服务器来测试一下JAVA PETSTORE应用。一些测试用例如PetStore应用的浏览和购买周期来测试扩展性。我们确信整个测试环境（包括操作系统、JVM、应用服务器和应用自身）已经尽可能优化了，而且J2EE应用没有任何瓶颈或同步问题。我们使用了多用户负载测试并观察了响应时间、吞吐量、资源利用率等指标。环境如下： 1、 J2EE PetStore应用 2、 J2EE应用服务器 3、 Sun JVM 1.3 4、 Windows 2000高级服务器 5、 Intel Dell PowerEdge 8450 (8Intel至强800MHz处理器, 4GB RAM) 6、 100Mbps Cisco dedicated network 7、负载测试工具WebLoad 在这个测试中我们看到即使有足够的硬件资源，应用服务器的实例个数限制了扩展的能力。在这里软件资源（如执行线程、BEAN池大小、数据库池和其他应用服务器参数）优化后即使这些资源不足也不会影响系统的扩展。下面我们来研究一下减轻这种问题的方案。注：Sun J2EE PetStore可以被更多地优化来改善性能和可扩展性。解决方案同一机器上的群集当吞吐量满载了应用服务器的一个实例时，需要增加一个实例来减轻这种问题。这个方案如图5。 Figure 5. Instance clusters on the same hardware box 当前机器的CPU使用率只有40%因而有足够空间来增加一个实例。我们可以发现在增加了实例后，吞吐量也增加了50%，如表2 在不同机器的群集当吞吐量满载了应用服务器的一个实例时，机器的CPU使用率只有40%。因为8CPU的机器未完全利用，所以我们测试一下更低配置的机器。现在我们使用两个4CPU的机器，如图6。 Figure 6. Instance clusters on different hardware boxes 我们发现4CPU机器的CPU使用率已达到80%，再增加实例也没有什么用处了。因此我们又增加一台4CPU的机器来运行应用的实例。在增加机器后，吞吐量几乎翻了一倍。在这里我们确信数据库服务器不会成为瓶颈。注：在上面的两台机器的测试中，负载平衡是通过一种不增加应用服务器实例功能负载的方式来处理的。但是在实际的生产环境中很难做到。因为我们观察到8CPU的机器被没有被完全利用，所以我们使用4CPU的机器重新测试了一遍。测试的结果可以在下表中看到，分别对应配置1和2。4CPU的配置几乎被完全利用了，这意味着使用4CPU的配置比8CPU的配置更实际，因为前者花费更少。小结这些实验指出了软件基础结构如应用服务器实例可能成为瓶颈，并给出了一些解决方案来减轻这种问题（包括在相同或不同机器上的群集）。这个问题需要在J2EE应用的负载计划或大小确定时优先考虑，因为这直接影响到应用的扩展性。这种想法很重要，下面我通过一个情景对话来表达。项目经理：你的意思是应用服务器（代表软件基础结构）会成为系统的瓶颈。性能架构师：是的项目经理：那为什么这种情况不是经常发生。性能架构师：是的，因为有时候瓶颈首先发生在硬件或应用本身。这时候应用服务器还没有使用到所有的扩展性。项目经理：这是事实。那么解决这种瓶颈的方法就是使用群集。如果有足够的硬件资源就在同一台机器上跑群集否则在多台机器中配置。性能架构师：是的。这也是在这篇文章中所得到的。

张金鹏 2007-05-06 12:41 发表评论

基于RBAC模型的权限管理系统的设计和实现2

张金鹏 — Fri, 27 Apr 2007 02:07:00 GMT

基于RBAC模型的权限管理系统的设计和实现

裴辉东梁云风

（1. 山东省烟台海颐软件股份有限公司；2山东省烟台东方电子信息产业股份有限公司）

摘要：提出了基于RBAC模型的权限管理系统的设计和实现方案。介绍了采用的J2EE架构的多层体系结构设计，阐述了基于角色的访问控制RBAC模型的设计思想，并讨论了权限管理系统的核心面向对象设计模型，以及权限访问、权限控制和权限存储机制等关键技术。

关键词：权限管理系统；角色；访问控制；RBAC模型；J2EE；LDAP

0 引言

管理信息系统是一个复杂的人机交互系统，其中每个具体环节都可能受到安全威胁。构建强健的权限管理系统，保证管理信息系统的安全性是十分重要的。权限管理系统是管理信息系统中可代码重用性最高的模块之一。任何多用户的系统都不可避免的涉及到相同的权限需求，都需要解决实体鉴别、数据保密性、数据完整性、防抵赖和访问控制等安全服务(据ISO7498-2)。例如，访问控制服务要求系统根据操作者已经设定的操作权限，控制操作者可以访问哪些资源，以及确定对资源如何进行操作。

目前，权限管理系统也是重复开发率最高的模块之一。在企业中，不同的应用系统都拥有一套独立的权限管理系统。每套权限管理系统只满足自身系统的权限管理需要，无论在数据存储、权限访问和权限控制机制等方面都可能不一样，这种不一致性存在如下弊端：

a.系统管理员需要维护多套权限管理系统，重复劳动。

b.用户管理、组织机构等数据重复维护，数据一致性、完整性得不到保证。

c.由于权限管理系统的设计不同，概念解释不同，采用的技术有差异，权限管理系统之间的集成存在问题，实现单点登录难度十分大，也给企业构建企业门户带来困难。

采用统一的安全管理设计思想，规范化设计和先进的技术架构体系，构建一个通用的、完善的、安全的、易于管理的、有良好的可移植性和扩展性的权限管理系统，使得权限管理系统真正成为权限控制的核心，在维护系统安全方面发挥重要的作用，是十分必要的。

本文介绍一种基于角色的访问控制RBAC（Role-Based policies Access Control）模型的权限管理系统的设计和实现，系统采用基于J2EE架构技术实现。并以讨论了应用系统如何进行权限的访问和控制。

1 采用J2EE架构设计

采用J2EE企业平台架构构建权限管理系统。J2EE架构集成了先进的软件体系架构思想，具有采用多层分布式应用模型、基于组件并能重用组件、统一完全模型和灵活的事务处理控制等特点。

系统逻辑上分为四层：客户层、Web层、业务层和资源层。

a. 客户层主要负责人机交互。可以使系统管理员通过Web浏览器访问，也可以提供不同业务系统的API、Web Service调用。

b. Web层封装了用来提供通过Web访问本系统的客户端的表示层逻辑的服务。

c. 业务层提供业务服务，包括业务数据和业务逻辑，集中了系统业务处理。主要的业务管理模块包括组织机构管理、用户管理、资源管理、权限管理和访问控制几个部分。

d. 资源层主要负责数据的存储、组织和管理等。资源层提供了两种实现方式：大型关系型数据库（如ORACLE）和LDAP（Light Directory Access Protocol，轻量级目录访问协议）目录服务器（如微软的活动目录）。

2 RBAC模型

访问控制是针对越权使用资源的防御措施。基本目标是为了限制访问主体（用户、进程、服务等）对访问客体（文件、系统等）的访问权限，从而使计算机系统在合法范围内使用；决定用户能做什么，也决定代表一定用户利益的程序能做什么^[1]。

企业环境中的访问控制策略一般有三种：自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法（RBAC）。其中，自主式太弱，强制式太强，二者工作量大，不便于管理^[1]。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销；2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

NIST（The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）^[1]。RBAC0模型如图1所示。

a. RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。

b. RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。

c. RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。

d. RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。

3核心对象模型设计

根据RBAC模型的权限设计思想，建立权限管理系统的核心对象模型。如图2所示。

对象模型中包含的基本元素主要有：用户（Users）、用户组（Group）、角色（Role）、目标（Objects）、访问模式（Access Mode）、操作（Operator）。主要的关系有：分配角色权限PA（Permission Assignment）、分配用户角色UA（Users Assignmen描述如下：

a .控制对象：是系统所要保护的资源（Resource），可以被访问的对象。资源的定义需要注意以下两个问题：

1.资源具有层次关系和包含关系。例如，网页是资源，网页上的按钮、文本框等对象也是资源，是网页节点的子节点，如可以访问按钮，则必须能够访问页面。

2.这里提及的资源概念是指资源的类别（Resource Class），不是某个特定资源的实例（Resource Instance）。资源的类别和资源的实例的区分，以及资源的粒度的细分，有利于确定权限管理系统和应用系统之间的管理边界，权限管理系统需要对于资源的类别进行权限管理，而应用系统需要对特定资源的实例进行权限管理。两者的区分主要是基于以下两点考虑：

一方面，资源实例的权限常具有资源的相关性。即根据资源实例和访问资源的主体之间的关联关系，才可能进行资源的实例权限判断。

例如，在管理信息系统中，需要按照营业区域划分不同部门的客户，A区和B区都具有修改客户资料这一受控的资源，这里“客户档案资料”是属于资源的类别的范畴。如果规定A区只能修改A区管理的客户资料，就必须要区分出资料的归属，这里的资源是属于资源实例的范畴。客户档案（资源）本身应该有其使用者的信息（客户资料可能就含有营业区域这一属性），才能区分特定资源的实例操作，可以修改属于自己管辖的信息内容。

另一方面，资源的实例权限常具有相当大的业务逻辑相关性。对不同的业务逻辑，常常意味着完全不同的权限判定原则和策略。

b.权限：对受保护的资源操作的访问许可(Access Permission)，是绑定在特定的资源实例上的。对应地，访问策略（Access Strategy）和资源类别相关，不同的资源类别可能采用不同的访问模式（Access Mode）。例如，页面具有能打开、不能打开的访问模式，按钮具有可用、不可用的访问模式，文本编辑框具有可编辑、不可编辑的访问模式。同一资源的访问策略可能存在排斥和包含关系。例如，某个数据集的可修改访问模式就包含了可查询访问模式。

c.用户：是权限的拥有者或主体。用户和权限实现分离，通过授权管理进行绑定。

d.用户组：一组用户的集合。在业务逻辑的判断中，可以实现基于个人身份或组的身份进行判断。系统弱化了用户组的概念，主要实现用户（个人的身份）的方式。

e.角色：权限分配的单位与载体。角色通过继承关系支持分级的权限实现。例如，科长角色同时具有科长角色、科内不同业务人员角色。

f.操作：完成资源的类别和访问策略之间的绑定。

g.分配角色权限PA：实现操作和角色之间的关联关系映射。

h.分配用户角色UA：实现用户和角色之间的关联关系映射。

该对象模型最终将访问控制模型转化为访问矩阵形式。访问矩阵中的行对应于用户，列对应于操作，每个矩阵元素规定了相应的角色，对应于相应的目标被准予的访问许可、实施行为。按访问矩阵中的行看，是访问能力表CL(Access Capabilities)的内容；按访问矩阵中的列看，是访问控制表ACL（Access Control Lists）的内容。

4 权限访问机制

权限管理系统端：提供集中管理权限的服务，负责提供用户的鉴别、用户信息、组织结构信息,以及权限关系表的计算。如图3所示。

图3 权限的访问示意图

Fig.3 Privilege invoke

系统根据用户，角色、操作、访问策略和控制对象之间的关联关系，同时考虑权限的正负向授予，计算出用户的最小权限。在业务逻辑层采用Session Bean实现此服务，也可以发布成Web Service。采用代理Proxy模式，集中控制来自应用系统的所要访问的权限计算服务，并返回权限关系表，即二元组{ObjectId，OperatorId}。

应用系统端：可以通过访问能力表CL和访问控制表ACL两种可选的访问方式访问权限管理系统。以基于J2EE框架的应用系统为例，说明访问过程：

a.首先采用基于表单的验证，利用Servlet方式集中处理登录请求^[2]。考虑到需要鉴别的实体是用户，采用基于ACL访问方式。用户登录时调用权限管理系统的用户鉴别服务，如果验证成功，调用权限计算服务，并返回权限关系表，以HashMap的方式存放到登录用户的全局Session中；如果没有全局的Session或者过期，则被导向到登录页面，重新获取权限。

b.直接URL资源采用基于CL访问方式进行的访问控制。如果用户直接输入URL地址访问页面，有两种方法控制访问：1.通过权限标签读取CL进行控制；2.采取Filter模式，进行权限控制，如果没有权限，则重定向到登录页面。

5 权限控制机制

权限所要控制的资源类别是根据应用系统的需要而定义的，具有的语义和控制规则也是应用系统提供的，对于权限管理系统来说是透明的，权限将不同应用系统的资源和操作统一对待。应用系统调用权限管理系统所获得的权限关系表，也是需要应用系统来解释的。按此设计，权限管理系统的通用性较强，权限的控制机制则由应用系统负责处理。

由于应用系统的权限控制与特定的技术环境有关，以基于J2EE架构的应用系统为例来说明，系统主要的展示组件是JSP页面，采用标记库和权限控制组件共同来实现。

a. 权限标识：利用标签来标识不同级别资源，页面权限标签将标识页面对象。

b. 权限注册：遍历JSP页面上的权限控制标签，读取JSP的控制权限。通过权限注册组件将JSP页面上的权限控制对象以及规则注册到权限管理信息系统中。

c. 权限控制：应用系统用户登录系统时，从权限管理系统获得权限关系表之后，一方面，权限标签控制页面展示；另一方面，利用权限控制组件在业务逻辑中进行相应的权限控制，尤其是和业务逻辑紧密联系的控制对象实例的权限控制。

6 权限存储机制

权限管理系统采用了两种可选的存储机制：LDAP（Lightweight Directory Access Protocol）目录服务数据库和关系型数据库。存储用户信息、组织结构、角色、操作、访问模式等信息。

其中，目录服务系统基于LDAP标准，具有广泛的数据整合和共享能力。元目录（Meta-Directory）功能允许快速、简洁的与企业现存基础结构进行集成，解决基于传统RDBMS等用户数据库与LDAP用户数据库的同步问题。

7 结语

本文论述了一种基于RBAC模型的权限管理系统的实现技术方案。该权限管理系统已成功应用于系统的设计和开发实践，与应用系统具有很好的集成。实践表明，采用基于RBAC模型的权限具有以下优势：权限分配直观、容易理解，便于使用；扩展性好，支持岗位、权限多变的需求；分级权限适合分层的组织结构形式；重用性强。

张金鹏 2007-04-27 10:07 发表评论

基于RBAC模型的权限管理系统的设计和实现

张金鹏 — Fri, 27 Apr 2007 02:06:00 GMT

0 引言
管理信息系统是一个复杂的人机交互系统，其中每个具体环节都可能受到安全威胁。构建强健的权限管理系统，保证管理信息系统的安全性是十分重要的。权限管理系统是管理信息系统中可代码重用性最高的模块之一。任何多用户的系统都不可避免的涉及到相同的权限需求，都需要解决实体鉴别、数据保密性、数据完整性、防抵赖和访问控制等安全服务(据ISO7498-2)。例如，访问控制服务要求系统根据操作者已经设定的操作权限，控制操作者可以访问哪些资源，以及确定对资源如何进行操作。
目前，权限管理系统也是重复开发率最高的模块之一。在企业中，不同的应用系统都拥有一套独立的权限管理系统。每套权限管理系统只满足自身系统的权限管理需要，无论在数据存储、权限访问和权限控制机制等方面都可能不一样，这种不一致性存在如下弊端：
a.系统管理员需要维护多套权限管理系统，重复劳动。
b.用户管理、组织机构等数据重复维护，数据一致性、完整性得不到保证。
c.由于权限管理系统的设计不同，概念解释不同，采用的技术有差异，权限管理系统之间的集成存在问题，实现单点登录难度十分大，也给企业构建企业门户带来困难。
采用统一的安全管理设计思想，规范化设计和先进的技术架构体系，构建一个通用的、完善的、安全的、易于管理的、有良好的可移植性和扩展性的权限管理系统，使得权限管理系统真正成为权限控制的核心，在维护系统安全方面发挥重要的作用，是十分必要的。
本文介绍一种基于角色的访问控制RBAC（Role-Based policies Access Control）模型的权限管理系统的设计和实现，系统采用基于J2EE架构技术实现。并以讨论了应用系统如何进行权限的访问和控制。

1 采用J2EE架构设计
采用J2EE企业平台架构构建权限管理系统。J2EE架构集成了先进的软件体系架构思想，具有采用多层分布式应用模型、基于组件并能重用组件、统一完全模型和灵活的事务处理控制等特点。
系统逻辑上分为四层：客户层、Web层、业务层和资源层。
a. 客户层主要负责人机交互。可以使系统管理员通过Web浏览器访问，也可以提供不同业务系统的API、Web Service调用。
b. Web层封装了用来提供通过Web访问本系统的客户端的表示层逻辑的服务。
c. 业务层提供业务服务，包括业务数据和业务逻辑，集中了系统业务处理。主要的业务管理模块包括组织机构管理、用户管理、资源管理、权限管理和访问控制几个部分。
d. 资源层主要负责数据的存储、组织和管理等。资源层提供了两种实现方式：大型关系型数据库（如ORACLE）和LDAP（Light Directory Access Protocol，轻量级目录访问协议）目录服务器（如微软的活动目录）。
2 RBAC模型
访问控制是针对越权使用资源的防御措施。基本目标是为了限制访问主体（用户、进程、服务等）对访问客体（文件、系统等）的访问权限，从而使计算机系统在合法范围内使用；决定用户能做什么，也决定代表一定用户利益的程序能做什么^[1]。
企业环境中的访问控制策略一般有三种：自主型访问控制方法、强制型访问控制方法和基于角色的访问控制方法（RBAC）。其中，自主式太弱，强制式太强，二者工作量大，不便于管理^[1]。基于角色的访问控制方法是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销；2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
NIST（The National Institute of Standards and Technology，美国国家标准与技术研究院）标准RBAC模型由4个部件模型组成，这4个部件模型分别是基本模型RBAC0（Core RBAC）、角色分级模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和统一模型RBAC3（Combines RBAC）^[1]。RBAC0模型如图1所示。

图1 RBAC0模型

a. RBAC0定义了能构成一个RBAC控制系统的最小的元素集合。在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标 objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。RBAC0与传统访问控制的差别在于增加一层间接性带来了灵活性，RBAC1、RBAC2、RBAC3都是先后在RBAC0上的扩展。
b. RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。
c. RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。
d. RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。
3核心对象模型设计
根据RBAC模型的权限设计思想，建立权限管理系统的核心对象模型。如图2所示。

对象模型中包含的基本元素主要有：用户（Users）、用户组（Group）、角色（Role）、目标（Objects）、访问模式（Access Mode）、操作（Operator）。主要的关系有：分配角色权限PA（Permission Assignment）、分配用户角色UA（Users Assignmen描述如下：

图2 权限管理系统核心类图

张金鹏 2007-04-27 10:06 发表评论

xinag 学习java的30个目标

张金鹏 — Wed, 25 Apr 2007 06:21:00 GMT

1.你需要精通面向对象分析与设计(OOA/OOD)、涉及模式(GOF，J2EEDP)以及综合模式。你应该十分了解UML，尤其是class，object，interaction以及statediagrams。

　　2.你需要学习JAVA语言的基础知识以及它的核心类库(collections，serialization，streams，networking， multithreading，reflection，event，handling，NIO，localization，以及其他)。

　　3.你应该了解JVM，classloaders，classreflect，以及垃圾回收的基本工作机制等。你应该有能力反编译一个类文件并且明白一些基本的汇编指令。

　　4.如果你将要写客户端程序，你需要学习WEB的小应用程序(applet)，必需掌握GUI设计的思想和方法，以及桌面程序的SWING，AWT， SWT。你还应该对UI部件的JAVABEAN组件模式有所了解。JAVABEANS也被应用在JSP中以把业务逻辑从表现层中分离出来。

　　5.你需要学习java数据库技术，如JDBCAPI并且会使用至少一种persistence/ORM构架，例如Hibernate，JDO， CocoBase，TopLink，InsideLiberator(国产JDO红工厂软件)或者iBatis。

　　6.你还应该了解对象关系的阻抗失配的含义，以及它是如何影响业务对象的与关系型数据库的交互，和它的运行结果，还需要掌握不同的数据库产品运用，比如:oracle，mysql，mssqlserver。

　　7.你需要学习JAVA的沙盒安全模式(classloaders，bytecodeverification，managers，policyandpermissions，
codesigning， digitalsignatures，cryptography，certification，Kerberos，以及其他)还有不同的安全/认证 API，例如JAAS(JavaAuthenticationandAuthorizationService)，JCE (JavaCryptographyExtension)，JSSE(JavaSecureSocketExtension)，以及JGSS (JavaGeneralSecurityService)。

　　8.你需要学习Servlets，JSP，以及JSTL(StandardTagLibraries)和可以选择的第三方TagLibraries。

　　9.你需要熟悉主流的网页框架，例如JSF，Struts，Tapestry，Cocoon，WebWork，以及他们下面的涉及模式，如MVC/MODEL2。

　　10.你需要学习如何使用及管理WEB服务器，例如tomcat，resin，Jrun，并且知道如何在其基础上扩展和维护WEB程序。

　11.你需要学习分布式对象以及远程API，例如RMI和RMI/IIOP。
　　12.你需要掌握各种流行中间件技术标准和与java结合实现，比如Tuxedo、CROBA，当然也包括javaEE本身。

　　13.你需要学习最少一种的XMLAPI，例如JAXP(JavaAPIforXMLProcessing)，JDOM(JavaforXMLDocumentObjectModel)，DOM4J，或JAXR(JavaAPIforXMLRegistries)。

　　14.你应该学习如何利用JAVAAPI和工具来构建WebService。例如JAX-RPC(JavaAPIforXML/RPC)，SAAJ (SOAPwithAttachmentsAPIforJava)，JAXB(JavaArchitectureforXMLBinding)，JAXM(JavaAPIforXMLMessaging)， JAXR(JavaAPIforXMLRegistries)，或者JWSDP(JavaWebServicesDeveloperPack)。

　　15.你需要学习一门轻量级应用程序框架，例如Spring，PicoContainer，Avalon，以及它们的IoC/DI风格(setter，constructor，interfaceinjection)。

　　16.你需要熟悉不同的J2EE技术，例如JNDI(JavaNamingandDirectoryInterface)，JMS (JavaMessageService)，JTA/JTS(JavaTransactionAPI/JavaTransactionService)，JMX (JavaManagementeXtensions)，以及JavaMail。

　　17.你需要学习企业级JavaBeans(EJB)以及它们的不同组件模式：Stateless/StatefulSessionBeans，EntityBeans(包含Bean- ManagedPersistence[BMP]或者Container-ManagedPersistence[CMP]和它的EJB-QL)，或者 Message-DrivenBeans(MDB)。

　　18.你需要学习如何管理与配置一个J2EE应用程序服务器，如WebLogic，JBoss等，并且利用它的附加服务，例如簇类，连接池以及分布式处理支援。你还需要了解如何在它上面封装和配置应用程序并且能够监控、调整它的性能。

　　19.你需要熟悉面向方面的程序设计以及面向属性的程序设计(这两个都被很容易混淆的缩写为AOP)，以及他们的主流JAVA规格和执行。例如AspectJ和AspectWerkz。

　　20.你需要熟悉对不同有用的API和frame work等来为你服务。例如Log4J(logging/tracing)，Quartz (scheduling)，JGroups(networkgroupcommunication)，JCache(distributedcaching)， Lucene(full-textsearch)，JakartaCommons等等。

21.如果你将要对接或者正和旧的系统或者本地平台，你需要学习JNI (JavaNativeInterface) and JCA (JavaConnectorArchitecture)。

　　22.你需要熟悉JINI技术以及与它相关的分布式系统，比如掌握CROBA。

　　23.你需要JavaCommunityProcess(JCP)以及他的不同JavaSpecificationRequests(JSRs)，例如Portlets(168)，JOLAP(69)，DataMiningAPI(73)，等等。

　　24.你应该熟练掌握一种JAVAIDE例如sunOne，netBeans，IntelliJIDEA或者Eclipse。(有些人更喜欢VI或EMACS来编写文件。随便你用什么了：)

　　25.JAVA(精确的说是有些配置)是冗长的，它需要很多的人工代码(例如EJB)，所以你需要熟悉代码生成工具，例如XDoclet。

　　26.你需要熟悉一种单元测试体系(JNunit)，并且学习不同的生成、部署工具(Ant，Maven)。

　　27.你需要熟悉一些在JAVA开发中经常用到的软件工程过程。例如RUP(RationalUnifiedProcess)andAgilemethodologies。

　　28.你需要能够深入了解加熟练操作和配置不同的操作系统，比如GNU/linux，sunsolaris，macOS等，做为跨平台软件的开发者。

　　29.你还需要紧跟java发展的步伐，比如现在可以深入的学习javaME，以及各种java新规范，技术的运用，如新起的web富客户端技术。

　　30.你必需要对opensource有所了解，因为至少java的很多技术直接是靠开源来驱动发展的，如java3D技术。

张金鹏 2007-04-25 14:21 发表评论

编写人：	南疯	日期：	2006-10-30
审核人：		日期：
批准人：		日期：

地址：	XXXXXXX	邮编：XXXXXX
电话：	XXXXXXXX	传真：XXXXXX
网站：	XXXXXXXXX