星期四, 03月 5th, 2009
SOA模式短文推荐
强烈推荐SOA爱好者下载收藏《SOA Pattern》一文，又有精品全文《SOA Design Pattern》推荐下载
作者将模式分为三类：（1）基本服务模式，是最小粒度的服务模式，已经无法再次拆分，可以认为是模式原语，多用在服务层面使用。（2）架构模式，通用的SOA系统设计要素，多用在系统设计时，做为架构风格的一个元素。（3）复合模式，基本服务模式的组合，用来定义系统的衔接特征，多用在应用系统整合场景。下面按照自己的理解和使用经验，简单说明一下，具体的介绍还请研究原文。
基本模式说明：
- Aggregator：将多个独立的消息体通过该计算组件组合为一个消息体。
- Service Bus：将多个独立的系统（已有系统、新系统）通过统一机制整合起来。
- Dynamic Routing：与规则库配合，实现一个消息体的路由，实现上常采用基于消息头路由、基于内容路由2中情况。
- Event-Driven Consumer：常用在资源有限的场景，解决资源竞争的问题，例如，网络接入时，系统所能接收到socket有受限的，此时即可通过该模式解决。
- Filter：消息内容的过滤，例如，关键字过滤，也可用在信息补全场景。
- Router：将消息发送到不同的应用，与Dynamic Routing的区别在于，此时规则是固定的，常常有2中使用方式，单播、多播。
- Translator or Transformer：用在消息格式的转换场景。
架构模式说明：
- Asynchronous Processing：异步事件风格解决服务之间的交互，例如，ATM到银行账务系统，多用该模式。在实践中，也鼓励使用这种风格，实现SOA，以弱化一致性、事务性，缓解资源受限等场景，该模式需要业务配合才能完全发挥。
- Bridge：常用在2中体系之间的交互，把一种协议转换为另一种协议。它与Translator的区别在，Translator是针对消息的，它针对链路。
- Cross-Service Operation：把多个服务封装为一个服务来使用，以确保一致性、事务性，可以把该风格弱化为分布式事务风格。
- Event-Driven Dispatching：基于事件的派发，常用在pub/sub场景。
- Process Aggregation：把多个过程聚合在一起，按照一定顺序进行消息处理，此时不要求一致性，每个过程都是独立的，用BPM技术更容易理解该场景。
- Routing and Filtering：实现一个消息的多种渠道应用，例如，一个业务通知，通过Mail，IM、SMS、语言、甚至特殊应用传达给用户的场景，一个产品为多个渠道提到内容的场景。
- Replicator：实现一份消息，服务处理的时候，同时往数据库复制一份，例如，数据备份容灾、数据采集、数据审计等。
复合模式说明：
- Centralized Schema：解决跨应用边界的数据共享问题。
- Concurrent Contracts：解决一个服务多个消费者时，每个消费者接口不同的问题。
- Decomponse Capability：？？
- Enterprise Service Bus：通过一个消息总线，解决应用整合的问题，化解复杂的网状链接。
- Fault-Tolerant Service Provider：通过负责均衡解决服务高可靠性的问题。
- Wrapper：解决传统应用服务化的问题。
星期三, 03月 4th, 2009
StarMx,Jopr,Galaxy介绍
StarMx是一款利用Jmx实现资源自我管理的框架（下图是一张自动系统的架构），业务目的是：自我配置、自我优化、自我恢复、自我保护。
- 自我配置：系统能够自己动态完成组件的安装和卸载；自己实现条件的改变和校正。
- 自我优化：系统能够监控自己的容量和状态，通过优化一些行为来改善性能。
- 自我恢复：系统能够自己发现、诊断、恢复问题；也能够从故障中自我恢复。
- 自我保护：系统能够自我低于风险。
Galaxy是一款SOA治理平台，主要提供了服务的注册和仓储，业务目的：服务描述和组织、服务静态生命周期管理、依赖管理、服务搜索、网络部署（依赖Netboot）。
Jopr 是一款可插入的框架，提供管理、监控、报警、操作控制、配置的能力。
三款产品，选择的核心业务目标有所不同，但业务域还是一致的，就是服务与IT治理。下图展示了把3款产品的核心概念整合起来使用的一个示意图：
要实现SOA治理，关键的一点还是为每个服务注入一个探测器，从而实现服务数据采集、治理中心指令传达的目的；对于这三款产品，由于其架构的差异，整合起来还是有点挑战的。
星期二, 03月 3rd, 2009
ManicTime时间跟踪的利器
常常为记录每日时间的消耗情况和每日周报而痛苦吗？常常为时间管理无法跟踪而痛苦？ManicTime，绝对的利器（安装的时候，要下载.Net Framework3.5，因而有些慢，请耐心）。
星期四, 02月 26th, 2009
11种开源的Twitter客户端（转）
Twitter的用户群越来越多，如何与已有应用集成(例如，该文《Social mashups with Groovy》)，也逐步为大家所关心，该文《10 Open Source Twitter Clients - And Counting》提供了现存的一些开源方案。
名称
语言平台
运行平台
地址
Spaz
JavaScript
跨平台
Gwibber
Python and GTK
GNOME
Mitter
Linux, Windows and MacOS X
Witty
Windows
Twoot
jQuery and Fluid
Linux 、Windows
gTwitter
GTK+/C#
Linux 、Mac
Pwytter
Python/tkInter
跨平台
JibJib
Java Mobile Edition
跨平台
NatsuLiphone
iPhone
MoTwitAir
Flex
支持Flash的平台
Twitter4J
Java
跨平台
星期三, 02月 25th, 2009
真的需要 Distributed OSGi?
读完《Why Do We Need Distributed OSGi?》一文，就想“真的需要分布式OSGI吗？”。
瞧瞧OSGI的用户:工具开发者，平台开发者，应用开发者（文中提及的进入企业）。A:对于工具开发者来说，对这个需求不是很强烈，例如要访问SVN、BUG等服务器，都是专有通信协议，直接分布进来还不如自己用个代理模式搞定之；如果对方也是基于OSGI平台，似乎有可能，可这样的应用不是很好找，而且对方也未必相同的分布机制呀。B:平台开发者，稳定的平台，一定要高内聚，低依赖，例如开发一个应用服务器，其中的某个关键组件是依赖外部的一个服务组件，这稳定性保证起来就比较麻烦，何苦哪。C:应用开发者，直接把OSGI作为应用开发容器（下面支一个JBOSS之类的应用服务器），这样的用户到也有，对于规模较大的系统，分布式计算的需求也是存在的，这种情况下，这个容器的作用与EJB是类似的，与CORBA在业务目标上不是很相似；如果想基于RMI之类的重分布式技术，那么还不如直接用EJB哪，如果想用SOAP之类的轻分布式技术，那么只需要把服务通过一个渠道发布出去即可（现在很多人也是这么搞的），例如JBOSS（假如基于JBOSS搭建环境）提供的HTTP通道，稳定又可靠。
看看如何分布？简单的用个CXF，好像不行唉。分布的需求千奇百怪，看看SCA规范中关于分布绑定一节，再看看JBI规范中关于分布绑定的内容，在OSGI规范中加上老长老长的一段相似的东西；如果再考虑安全体系，请求模式，注册/寻址模式，服务质量等，这可好玩了，刚好和IBM的websphere匹配上了（还以为是给IBM定制的规范哪？），全线支持SOA，看起来很美很妙呀。
瞅瞅一个变态而常用的需求，如果想在分布的服务请求之间，增加些规则或逻辑，例如：数据格式转换，多路发送等，不知道这规范还支持不？如果不支持，还是得把ESB搞进来，既然把ESB搞进来了，还要OSGI的分布做啥？从模式角度来说，组合只是一种基本的分布模式，上面讲的这些需求就属于其它分布模式的范畴，可以参考这篇文章《SOA模式》，所实在的，不搞SOA，闲着没事搞啥分布呀。
每种技术都有其作用域，垮了域就不再是强项了，很容易成鸡肋。OSGI常常用组件动态能力，扩展能力说事，我看就扩展能力最具有使用价值，再就是组件之间的隔离能力，真正复杂大型应用中，动态能力反而加强了系统复杂性，目前好似还没有人搞过成本/收益的测试。从职责分离的角度，把分布的复杂需求（应用层的分布需求，比系统层要复杂）封装在独立的组件里（例如：ESB产品，JBI产品等），比OSGI框架层来实现效果会更好一些。从实践经验来看，OSGI + Spring + ESB搭建的应用平台(实在不行，就用SpirngDM)，能够更好的把三种技术的强项聚焦起来，满足企业应用的需要。妄图一个规范打遍天下，还不如加强自有优势，强强联合，用成熟、低廉、可靠的技术来满足企业级市场的需要。
真的不是很需要Distributed OSGi!!!!!!!!
SOA模式短文推荐
强烈推荐SOA爱好者下载收藏《SOA Pattern》一文，又有精品全文《SOA Design Pattern》推荐下载
作者将模式分为三类：（1）基本服务模式，是最小粒度的服务模式，已经无法再次拆分，可以认为是模式原语，多用在服务层面使用。（2）架构模式，通用的SOA系统设计要素，多用在系统设计时，做为架构风格的一个元素。（3）复合模式，基本服务模式的组合，用来定义系统的衔接特征，多用在应用系统整合场景。下面按照自己的理解和使用经验，简单说明一下，具体的介绍还请研究原文。
基本模式说明：
- Aggregator：将多个独立的消息体通过该计算组件组合为一个消息体。
- Service Bus：将多个独立的系统（已有系统、新系统）通过统一机制整合起来。
- Dynamic Routing：与规则库配合，实现一个消息体的路由，实现上常采用基于消息头路由、基于内容路由2中情况。
- Event-Driven Consumer：常用在资源有限的场景，解决资源竞争的问题，例如，网络接入时，系统所能接收到socket有受限的，此时即可通过该模式解决。
- Filter：消息内容的过滤，例如，关键字过滤，也可用在信息补全场景。
- Router：将消息发送到不同的应用，与Dynamic Routing的区别在于，此时规则是固定的，常常有2中使用方式，单播、多播。
- Translator or Transformer：用在消息格式的转换场景。
架构模式说明：
- Asynchronous Processing：异步事件风格解决服务之间的交互，例如，ATM到银行账务系统，多用该模式。在实践中，也鼓励使用这种风格，实现SOA，以弱化一致性、事务性，缓解资源受限等场景，该模式需要业务配合才能完全发挥。
- Bridge：常用在2中体系之间的交互，把一种协议转换为另一种协议。它与Translator的区别在，Translator是针对消息的，它针对链路。
- Cross-Service Operation：把多个服务封装为一个服务来使用，以确保一致性、事务性，可以把该风格弱化为分布式事务风格。
- Event-Driven Dispatching：基于事件的派发，常用在pub/sub场景。
- Process Aggregation：把多个过程聚合在一起，按照一定顺序进行消息处理，此时不要求一致性，每个过程都是独立的，用BPM技术更容易理解该场景。
- Routing and Filtering：实现一个消息的多种渠道应用，例如，一个业务通知，通过Mail，IM、SMS、语言、甚至特殊应用传达给用户的场景，一个产品为多个渠道提到内容的场景。
- Replicator：实现一份消息，服务处理的时候，同时往数据库复制一份，例如，数据备份容灾、数据采集、数据审计等。
复合模式说明：
- Centralized Schema：解决跨应用边界的数据共享问题。
- Concurrent Contracts：解决一个服务多个消费者时，每个消费者接口不同的问题。
- Decomponse Capability：？？
- Enterprise Service Bus：通过一个消息总线，解决应用整合的问题，化解复杂的网状链接。
- Fault-Tolerant Service Provider：通过负责均衡解决服务高可靠性的问题。
- Wrapper：解决传统应用服务化的问题。
StarMx,Jopr,Galaxy介绍
StarMx是一款利用Jmx实现资源自我管理的框架（下图是一张自动系统的架构），业务目的是：自我配置、自我优化、自我恢复、自我保护。
- 自我配置：系统能够自己动态完成组件的安装和卸载；自己实现条件的改变和校正。
- 自我优化：系统能够监控自己的容量和状态，通过优化一些行为来改善性能。
- 自我恢复：系统能够自己发现、诊断、恢复问题；也能够从故障中自我恢复。
- 自我保护：系统能够自我低于风险。
Galaxy是一款SOA治理平台，主要提供了服务的注册和仓储，业务目的：服务描述和组织、服务静态生命周期管理、依赖管理、服务搜索、网络部署（依赖Netboot）。
Jopr 是一款可插入的框架，提供管理、监控、报警、操作控制、配置的能力。
三款产品，选择的核心业务目标有所不同，但业务域还是一致的，就是服务与IT治理。下图展示了把3款产品的核心概念整合起来使用的一个示意图：
要实现SOA治理，关键的一点还是为每个服务注入一个探测器，从而实现服务数据采集、治理中心指令传达的目的；对于这三款产品，由于其架构的差异，整合起来还是有点挑战的。
ManicTime时间跟踪的利器
常常为记录每日时间的消耗情况和每日周报而痛苦吗？常常为时间管理无法跟踪而痛苦？ManicTime，绝对的利器（安装的时候，要下载.Net Framework3.5，因而有些慢，请耐心）。
11种开源的Twitter客户端（转）
Twitter的用户群越来越多，如何与已有应用集成(例如，该文《Social mashups with Groovy》)，也逐步为大家所关心，该文《10 Open Source Twitter Clients - And Counting》提供了现存的一些开源方案。
|
名称
|
语言平台
|
运行平台
|
地址
|
|---|---|---|---|
Spaz |
JavaScript
|
跨平台
|
|
Gwibber |
Python and GTK
|
GNOME
|
|
Mitter |
Linux, Windows and MacOS X
|
||
Witty |
Windows
|
||
Twoot |
jQuery and Fluid
|
Linux 、Windows
|
|
gTwitter |
GTK+/C#
|
Linux 、Mac
|
|
Pwytter |
Python/tkInter
|
跨平台
|
|
JibJib |
Java Mobile Edition
|
跨平台
|
|
NatsuLiphone |
iPhone
|
||
MoTwitAir |
Flex
|
支持Flash的平台
|
|
Twitter4J |
Java
|
跨平台
|
真的需要 Distributed OSGi?
读完《Why Do We Need Distributed OSGi?》一文，就想“真的需要分布式OSGI吗？”。
瞧瞧OSGI的用户:工具开发者，平台开发者，应用开发者（文中提及的进入企业）。A:对于工具开发者来说，对这个需求不是很强烈，例如要访问SVN、BUG等服务器，都是专有通信协议，直接分布进来还不如自己用个代理模式搞定之；如果对方也是基于OSGI平台，似乎有可能，可这样的应用不是很好找，而且对方也未必相同的分布机制呀。B:平台开发者，稳定的平台，一定要高内聚，低依赖，例如开发一个应用服务器，其中的某个关键组件是依赖外部的一个服务组件，这稳定性保证起来就比较麻烦，何苦哪。C:应用开发者，直接把OSGI作为应用开发容器（下面支一个JBOSS之类的应用服务器），这样的用户到也有，对于规模较大的系统，分布式计算的需求也是存在的，这种情况下，这个容器的作用与EJB是类似的，与CORBA在业务目标上不是很相似；如果想基于RMI之类的重分布式技术，那么还不如直接用EJB哪，如果想用SOAP之类的轻分布式技术，那么只需要把服务通过一个渠道发布出去即可（现在很多人也是这么搞的），例如JBOSS（假如基于JBOSS搭建环境）提供的HTTP通道，稳定又可靠。
看看如何分布？简单的用个CXF，好像不行唉。分布的需求千奇百怪，看看SCA规范中关于分布绑定一节，再看看JBI规范中关于分布绑定的内容，在OSGI规范中加上老长老长的一段相似的东西；如果再考虑安全体系，请求模式，注册/寻址模式，服务质量等，这可好玩了，刚好和IBM的websphere匹配上了（还以为是给IBM定制的规范哪？），全线支持SOA，看起来很美很妙呀。
瞅瞅一个变态而常用的需求，如果想在分布的服务请求之间，增加些规则或逻辑，例如：数据格式转换，多路发送等，不知道这规范还支持不？如果不支持，还是得把ESB搞进来，既然把ESB搞进来了，还要OSGI的分布做啥？从模式角度来说，组合只是一种基本的分布模式，上面讲的这些需求就属于其它分布模式的范畴，可以参考这篇文章《SOA模式》，所实在的，不搞SOA，闲着没事搞啥分布呀。
每种技术都有其作用域，垮了域就不再是强项了，很容易成鸡肋。OSGI常常用组件动态能力，扩展能力说事，我看就扩展能力最具有使用价值，再就是组件之间的隔离能力，真正复杂大型应用中，动态能力反而加强了系统复杂性，目前好似还没有人搞过成本/收益的测试。从职责分离的角度，把分布的复杂需求（应用层的分布需求，比系统层要复杂）封装在独立的组件里（例如：ESB产品，JBI产品等），比OSGI框架层来实现效果会更好一些。从实践经验来看，OSGI + Spring + ESB搭建的应用平台(实在不行，就用SpirngDM)，能够更好的把三种技术的强项聚焦起来，满足企业应用的需要。妄图一个规范打遍天下，还不如加强自有优势，强强联合，用成熟、低廉、可靠的技术来满足企业级市场的需要。
