关键字总汇（OSGI - Google Search）

思考题：
Eclipse Plugin Framework采用的是OSGI的实现，一定程度上我们也能看到OSGI的优点，那么JMX+IoC方式的Plugin Framework与其的比较又是在哪些方面呢？Eclipse Plugin Framework不足的地方又在哪里呢？哪些地方值得改进呢？

或许把OSGi式的结构做成一个类似JXTA那样和语言无关的框架或许更加有意义一点。

越来越多的东西需要去看，需要去学习、理解、掌握。时间却只有那么一点，焦虑的情绪很容易产生。
关注技术走向
新技术追踪，新思想的理解。新方法的学习。blog信息量。

现有的流行技术的学习掌握，

对基础性知识的学习，扩充知识结构，打好基础，提高理解能力和分析能力、把握能力。也有定力。

许多新技术都是从系统论的观点出发（OSGI、SOA、MDA），都是从如何构架一个结构优雅的系统，同时拥有想在目前所期盼或想象得到的对系统的形容词（可扩展、易管理、组件化、微内核、插件化、开发简洁，IDE支持、互操作、高性能、易于测试、重用、提高生产力、降低开发成本、结合业界最佳实践），这一切都仿佛一夜之间要进入新世纪一般（仿佛是1999年年末）。

Plugin的部署

Plugin 的部署，如何更加方便的去部署一个 Plugin ，就象 Osgi 可以通过网络访问等等，考虑中根据配置从相应的目录或网站搜索 Plugin 并注册到系统中

跟着eclipse的潮流走吧，可以把它看作一个技术的风向标（一个以IDE为基础的技术平台正在逐步融会各种技术和需求），当现在迷雾散尽，我们曾经热切探索的技术成为业界的基础设施时，又会有新的喧闹声在耳旁响起。站在巨人的肩膀上，跟着 eclipse 走。

Pattern
对于pattern最重要的是理解，理解为什么要这么设计我觉得那么在自己应用的时候就容易考虑到一些，去S记pattern是没什么意义
对于pattern的理解能让你更加灵活的使用pattern
还是那句话， 设计时要注意考虑的是什么是变化的，而什么是相对不变的

OO
不要把OO等价于JSF, portlet所提供给你的框架实现。 OO 首先是概念上的，然后才是实现上的。

DI和Template模式正是IoC在面向对象领域的表现形式
DI和模板方法模式的区别在于
DI用于解除创建依赖
模板方法用于解除行为依赖

老技术：
ACE、MINA（Netty2）、mudOS


SOA：
web Service-->以Corba为代表的DOC-->基于组件服务器的N-Tier-->基于web服务器的T-Tier-->C/S结构
其根本的通讯方式，几年来未曾变化，只不过是多穿了几件马甲而已，从技术角度讲，如果对网络中间件的架构熟悉的话，从最底层的TCP/IP通讯开始自己构建一个webService的实现也并非什么难事，作为技术人员，我更想关注一些目前可以带来实际好处的技术，如：AOP/脚本语言/IF/微内核的体系结构，甚至更镜花水月的MDA

对项目有用的技术：
MINA（基于网络与并发的高性能软件架构）
OSGi（微内核插件体系结构）

OSGI规范
OSGI规范有广泛的适用性，是因为它是在一个单独的JVM中的一个很小的层，并允许多样的、基于java的、组件的高效合作。它提供一个可扩展的安全机制以便组件可以运行在一个受保护的环境。而且，通过适当的权限，组件可以重用和合作，而不像其他java应用环境。OSGI框架提供一个可扩展排队机制使得这种合作变得可能和安全。
基于OSGI的中间件的存在为OSGI组件提供了广阔的市场。OSGI平台严格的定义似的组件能够运行在各种各样的设备上，从手持设备到大型主机。
采用OSGI规范还可以降低提供新业务的软件开发成本。

 OSGI的主要好处是提供了JAVA的类加载层次，给JAVA提供了类似.NET的Assembly层面的功能。是一个轻量级的微内核容器。如果使用一些增强的bundle还能提供依赖配置管理。 通过OSGI和JMX能够动态插拔

使Eclipse走上了完全动态平台的发展道路.从Eclipse 3.0 M5开始，runtime采用OSGI标准，但仍然兼容现有的Extension机制

最近 OSGi 在軟體業最為人雀躍的發展，莫過於 Eclpise Java IDE 支援 OSGi 標準。這是一個有趣的現象，本來是設計給其他產業的運用，卻在軟體業也有不凡的表現。這也讓我想起 Java 的發展歷史，本來也是為了 embedded 系統而設計，卻意外的在 internet 竄起的年代獲得各方的矚目，更在 enterprise application 中立於不敗之地...

OSGi 採用Micro-Kernel (根据那个台湾人的说法，是从Linux操作系统的微核心衍生过来的)的架構，可以提供無限延伸的功能。OSGi 的 Bundles 線上更新功能、以及應用程式之微量記憶體執行能力，都是開發應用程式的利基。

 JMX是标准的管理API，最终的动态管理应该需要依赖这个来实现

SIP（会话启动协议）了解 SIP
通信提供商及其合作伙伴和用户越来越渴求新一代基于 IP 的服务。现在有了 SIP（会话启动协议），一解燃眉之急。SIP 是不到十年前在计算机科学实验室诞生的一个想法。它是第一个适合各种媒体内容而实现多用户会话的协议
SIP市场竞争愈演愈烈，BEA也加入了
BEA WebLogic SIP Server，这是业界首款基于标准的运营商级J2EE应用服务器，它集成了会话初始化协议（SIP）支持功能。SIP是一种标准协议，为两个或者多个实体之间建立一条通信通道以便传送包括多种媒体（如语音、图像和视频等）的信息。BEA WebLogic SIP Server这款产品是专为在SIP环境开发及部署服务而设计的。

基于OSGI的普及计算系统的改进
本文分析了OSGI框架规范及其应用,指出其局限性,利用SIP来补充OSGI规范使其更符合普及计算的要求,提出了集成SIP方法和OSGI框架的普及计算系统OSA.
关键词：普及计算,SIP,OSGI,OSA

 Thread Pool (SEDA)
把你的服务器的处理过程分解为Stage，给每个Stage配以一个线程池来并发处理Event。Stage之间通过Event来互相转换。
SEDA的秘诀在于总的来说，并发是有好处的。通过把服务器的处理过程分解为Stage，提高了服务器的模块性。同时给每个Stage配置一个自己的线程池来处理它的事件，能够精致调整其池的大小，决定这个Stage的并发性。虽然SEDA的创始者把他写的SandStorm写得n复杂，但是 SEDA本身的思想很简单，利用JDK1.5提供给我们的良好线程支持，百来行代码就能实现一个SEDA的模型出来。

 SEDA基于Staged的事件驱动架构，为可升级的internet服务而设计。主要包括三个目标：
*支持大量并发，每个节点支持上万客户
*通过运行时动态调节，获得稳定的性能
*使复杂的internet服务变得简单。

 Thread Pool (SEDA)
把你的服务器的处理过程分解为Stage，给每个Stage配以一个线程池来并发处理Event。

 NIO
使用JDK1.4中提供的New IO来处理多连接的情况，用以取代旧有的一客户端一线程的IO模型。
NIO能提高服务器性能的关键在于NIO给JAVA提供了非阻塞的IO模型。以前需要用一个线程来等待用户的数据，现在只需要用select“选择”出ready（就绪）的socket，然后在有数据的时候才去读。这样能够用很少的几个线程同时向大量的连接用户提供服务，免去了线程切换带来的开销。

StAX
使用StAX来代替DOM或者SAX。流式的XML解析能够消耗更少的内存，而且速度更快。
DOM很耗费内存，需要性能的地方肯定不能考虑。SAX很庞大肥硕，比起Pull式的流式Parser来，还是慢。StAX是Pull式流式 Parser标准化的产物，04年已经是final了的jsr。现在有一个BEA提供的RI，使用APL协议。服务器实现的一般是协议式的东西，往往是以流为中心，而不是以文档为中心，而且往往需要自己控制着parser去解析，使用StAX最适合不过了。
Javolution
在大量产生临时内存的地方，而且是反复被使用的部分，使用Javolution实时框架来“精致地”管理内存。
In general
好的内存管理与恰当的并发是使得程序性能更好负载能力更强的关键。

JXTA
JXTA的另外一个目的就是找寻一套数量最少、概念最简单的系统构成的“积木”。如果成功，这几块积木就会是今后大家构架信息系统的基本模块，从而帮助人们摆脱像Windows或TCP/IP这样的传统软件带来的包袱。Java、Jini和JXTA像是J的三部曲
XTA不局限于P2P。但JXTA与众不同，它是由一系列网络协议构成的，用任何语言都可以实现，并不只限于Java，只有彻底独立于操作系统、网络传输技术以及程序设计语言，才真正达到了跨平台，而这样的技术，最容易受到业界的认同。

 OSGi和JXTA的渊源
 宫力又接管了JES（Java Embedded Server）部门一年多时间，其中内部制订的规范经过推广应用，后来成为国际标准组织OSGi（open services gateway initiative）的标准， 而宫力本人成为国际标准组织OSGi（Open Services Gateway Initiative）标准协会的董事，并代表Sun公司成为其专家组第一任组长。从1999年起宫力又调往新成立的以研究P2P（对等网络）的JXTA 部门担任技术总监1年多，让他感到欣慰的是，JXTA获得JavaWorld 2001年度的“最佳创新奖”。在此期间，宫力成功主持了JXTA源代码开放社团的建设工作。

 以J2EE/OSGi为基础的RFID中间件

Matrix Java 大讲坛－产品开发过程(Jerry贡献)

在Osgi和JMX+IoC方面我更倾向后者

MINA是个我最欣赏的项目之一

你blog上提到mina与spring、JMX与OSGI的结合计划？？

MINA是一个通讯基础框架。
在java领域中，类似于这种框架还达不到ACE那样的承载度

我就是在想基于OSGI，面向POJO的通讯基础框架

首先JMX能提供更好的plugin的管理，而Osgi在这方面是没法和这种架构来比的，IoC就不用说了，^_^，更好的解决plugin的协作

JMX和Osgi有点类似，不过关注的层面还是不太一样

JMX---JBOSS代码可以参考
OSGI--ECLIPSE可以参考