学过软件工程的都知道，软件产品的生产周期是一个经历若干阶段的漫长过程，包括需求获取 - 设计 - 开发 - 维护等等。

需求阶段 - 总想考虑到所有的问题，或是一切按合同办事。但在现实中根本不得能，因此很多公司开始提倡“随需而变”的能力，希望快速的响应用户的需求变化
维护阶段 - 总希望自己开发出来的东西一劳永逸，永远不要再产生任何麻烦，产生了麻烦也不要找到我。甚至有些项目组的人员开发出来一大堆不成熟的产品、项目后撒手不管，走人了事，毫无职业操守，亦是对自身行业声誉（至少是国内IT服务提供商声誉）的一个打击。真正的项目开发不应该这样，一定是非常易于维护的，能够快速地找出问题的所在，或是新需求切入点的所在，然后解决

很明显，前面提到的两个问题都要也只能通过设计和开发来解决。问题来了，怎样开发出的软件才能快速地响应需求，易于维护？可以有很多不相冲突的说法，比如解耦，比如通过POJO封装数据等等。这些东西流行开来以后，很多人有疑问，为什么我的项目中一定要用这些框架？我不用这些框架也可以快速的开发出我要的功能，而且更加简单，等等。如果孤立地从设计和开发的角度看这些问题，这种说法并没有错误，但是如果从整个软件开发的生命周期来看，则不是这样。当然，这里还有一个是否“过度设计”的trade-off在里面，不过那又是另一个话题了。

再说说各种各样的平台吧，它们和框架不同，软件体系结构中有一种架构模型即层次模型，我们现在的TCP/IP协议栈即属于这种模型，我们的软件对于平台产品的依赖是一种朝向稳定的依赖，就好像我们在调试代码时往往不会去调试操作系统API的bug一样，因此在开发这种平台层次级别的产品时就没有必要再去采用那些为了保障“企业应用”Web软件生命周期中所采用的方法了，完全可以用最基础，最底层的手段。只要能够做到高效、稳定即可。因此，平台中间件产品的开发必须和应用软件产品分开来看，虽然它们可能都在用Java这种编程语言。

还记得小时候常看的电影《神鞭》吧！

联合国是国家间的标准化组织，可惜一超多强们只把它当作是一个道具，需要时拿来用一下，不需要时完全可以踢到一边。
历史上，每个朝代都认识到失败的教训，却最终都迎来了相似的结局。

有人说，软件行业是一个天生的垄断行业，其特质是，产品研发的过程异常的复杂，但产品一旦出炉，就可以疯狂而不计成本地生产。只有NRE Cost，眼下的软件行业也出现了群雄逐鹿的场面，上游产业被几家大公司所瓜分，这些大公司如果能互相牵制，则会坐在一起，成立一个组织。如果一家独大，则我行我素，称王称霸。

看看他们的一路成长：

初始：

他们想占有你，最初都会很乖。就像女孩在成为家庭主妇之前总能收到男孩的礼物。

成长：

大公司们也渐渐从规范的参与者，变成规范+的树立者，比如IE，Office，再比如Oracle的特性等等。

称霸：

市场占有的差不多了，可以不顾客户的意志做自己喜欢的事情，反正你已经离不开我。

消亡：

客户们怨声载道，新的“符合规范”或简洁明了的产品出现市场。

希望这些大软件厂商们能够吸取教训，也希望小软件厂商们将来不要走入历史的怪圈。

下面一一展开讨论

（一）保障安全性

安全性的主要解决方案是利用Java提供的keytool生成一个keystore，并利用这个keystore对jar包进行signjar的操作。
整个对Java文件的编译，打包和signjar过程可以利用Ant来完成，比如下面的Ant脚本片段就是用来处理signjar的，大家也可以通过相应的Java命令直接处理：

< target  name ="signjar"  depends ="jar" >
  < signjar  jar ="example.jar"
  keystore ="${basedir}/yangyi.keystore"  storepass ="mypassword"  alias ="mykey" ></ signjar >
</ target >

如果直接用命令，则其形式为：
jarsigner [ options ] jar-file alias
具体的操作方法可以参考下面的链接：
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/jarsigner.html
通过这个signjar的操作，我们就给这个包中的类进行了一次数字签名，这样，当Applet进行默认许可之外的操作时，窗口将弹出这个数字签名要求本地用户进行确认，只有在确认后，用户才可以继续进行操作。

这样我们可以在第一次用户运行Applet程序时，在用户的许可下动态地在用户的$user.home/.java.policy下生成一个授权文件，以后就可以执行需要的操作了，为保证客户端的安全性，仅赋予用户执行特定文件夹权限的权利，如（仅作为例子,可以根据需要自己配置文件和Socket访问权限）：
grant codeBase "file:/home/yiyang/test/×" {
 java.security.AllPermission;
};

（二）下载并管理库支持

这个过程可以通过Java的URL类提供的openConnection方法来获取一个InputStream从而获取到远程的资源（包括支持库和配置文件两部分）
1）对于配置文件，因为其内容都比较少，而且比较简单，可以直接通过输入流来获取，这是没有异议的；
2）对于库文件，在下载之前先到我们管理的库的目录下找到版本索引文件（我们设定一个版本索引文件来管理升级），这个版本索引文件如下所示：

time={资源获取的时间戳}
lib1.jar=1.0
lib2.jar=1.1

其中，服务器端也保留有一份这样的版本文件，当下载库文件时，首先对客户端和服务端的库的总时间戳进行比较，如果客户端大于或等于服务端，则不需下载，否则，如果客户端对应项目为空或者其总的时间戳小于服务端，则进一步比较内部库文件的版本，发现版本低的库或在客户端不存在的库后，自动到服务器上进行下载，在下载成功后，更新客户端的索引文件。

（三）通信

这个问题小弟曾在以往的blog中有过详细的讨论，可以到http://yangyi.blogjava.net中的相应随笔中找到答案。总的来说，在类型协议并不复杂，且客户端，服务端均为Java开发的情况下，应用Hessian是一个好的解决方案，需要指出的是Hessian中的代码对客户端来说并不是全部必须的，大家可以根据客户端的使用情况对这个库进行瘦身。只保留作为客户端必要的类即可。

（四）动态的实例化及插件结构

我们要实现用户界面的集成，从根本上说要解决下面的几个问题：
1）菜单集成
2）支持库集成
3）集成点
4）输出变量
对于客户端为Applet开发的插件，我们把上面的四项配置统一在XML文件中进行描述定义。
这里需要注意的是菜单要提供名称，支持库要提供下载路径或者本地路径，集成点我们希望是一个JPanel。
在定义好XML后，可以到网址：http://www.flame-ware.com/xml2xsd/去获得一个对应的schema，利用这个schema和JAXB提供的xjc工具，我们就可以生成对应的XML操作类，来对配置进行处理。
对于菜单的集成可以动态地在JMenu中添加MenuItem（表示插件的功能）
根据配置的支持库的位置，我们可以通过Java的URLClassLoader对库进行动态的加载，然后根据相应的集成点，获取实例，这个过程的示例代码如下所示：

File f  =   new  File( " a.jar " );  // a.jar是我们从配置文件中读取的支持库
URL url  =   null ;
Class lib  =   null ;
try   {
 url  =  f.toURI().toURL();
 lib  =  Class.forName( " Lib " ,  true ,  new  URLClassLoader(
    new  URL[]  { url } ));  // Lib是我们从配置文件中读取的集成点
 JPanel plugin_panel  =  (JPanel)lib.newInstance();
  return  plugin_panel;
}   catch  (Exception e)  {
 e.printStackTrace();
}

对于输出变量，其主要作用是用户各个插件之间的信息交互，我们可以通过一个总的HashMap来实现，为避免变量值出现冲突，在变量名前自动加上插件名的前缀。
如plug_in1的变量var1，其系统名称为：plug_in1__var1.

解决了上面的四个障碍，我们就可以把精力投入到具体的功能实现上了。