在软件世界里组件这个概念真是千差万别，每个系统与工具软件对组件都有各自不同的定义。尤其在Java世界里更是如此，小的从一个页面元素一直到大的一个
业务功能系统，在各自的领域都会给它们定义为组件。按照《计算机百科全书》给组件的定义：是软件系统中具有相对独立功能、接口由契约指定、和语境有明显依
赖关系、可独立部署、可组装的软件实体。由此定义我们来谈一下J-Hi Java快速开发平台对组件的理解与解决方案。
实际上说到底无非是对组件颗粒的划分问题，在不同的条件与环境下组件的作用与功能会有很大差异，其次在定义组件时要保证功能的相对独立并且可组装可部署，
由此J-Hi将组件根据用途与范围的不同划分为如下四类组件类型：技术组件、实体组件、业务组件、系统组件，它们之间的关系是逐级递进，互为基础的。
在我们在深入探讨之前，先来简单的解释一下上图中各种组件类型之间的关系。比如一个OA系统我们就可以把这理解为一个系统组件，而多个系统组件（仓储系
统、人力系统等）可以动态搭建更大的应用系统（ERP）。每个系统组件下会有多个业务组件，例如在OA系统下会有报销单、会议管理等多个业务组件。因为大
部分业务组件之间一般都是松藕合的，所业务组件可以无缝的迁移到其它的系统组件中，即实现业务组件可复用性。而在一个业务组件下会有一个或多个实体组件够
成，我们还以报销单业务组件为例，在报销单最少会有报销单及报销单明细两个实体组件，一个实体您可以理解成与数据库对应的一张表，实体之间可以继承、一个
实体可以有多个子实体。但实体不仅仅是数据库表，它包括从页面到数据库表之间的全部代码实现同时包括CURD所有操作的功能单元。对于实体组件我们会在后
面详细讨论。最后是技术组件，在J-Hi中技术组件可以说是一个抽象的概念，一个技术组件就是一个技术功能单元，它可能是一套生成模版，一个框架的支持，
一套API（比如对短信、全文检索的支持等）
实体组件：J-Hi将一个实体组件定义为一个集合单元，它不仅仅包括数据库表还包括对该数据库表的基础操作
（增、删、查、改）；包括前端的展示面页；包括该实体的权限、菜单、配置信息；还包括它与其它实体的交互操作。当然一个实体组件颗粒度还是太小，还不能完
整的描述一个业务功能。但实体组件相对来说有一定的独立性，可以集成一个集合单元，J-Hi就是以实体组件为基础实现更大粒度的集成，从而实现对一个完整
业务的描述。
业务组件：实际上一个业务组件J-Hi将它对应于一个服务，服务可以认为是一个业务功能模块，用以描述完整的
业务模式，具体相对的业务独立性。在服务内代码间是高聚集的，因为一个服务就是一套完整的业务，在设计服务时应尽最大限度的降低服务与服务之间的藕合度。
因为在这个样一个理论基础上去设计，就可以实现业务组件无缝的在各系统之间的可移植性。因为组件的定义还要可以独立的组装与部署，因此我们开发平台的附属
性产品——Hi平台产品集成工具，它主要是由发布器与部署器组成，以更方便的实现业务组件的迁移。
开发发布器与部署器的目的就是通过可视化的方式，实现跨数据库数据与跨应用系统的业务组件迁移。可以将业务组件看作一个独立的业务单元，可以无缝的集成于
任何以J-Hi平台开发的项目中去。从而真正达到随需组合，动态搭建实际的业务系统，真正的实现业务组件的复用，降低不必要的重复开发。
系统组件：从业务功能上来看系统组件不过是多个业务组件的拼接，更大一级的业务封装。理论上系统组件与系统组
件之间应满足绝对的隔离性，即使是有通信，应该也是通过第三方来进行数据交互（常用的解决方式有两种一种是中间数据库；第二种是webservice）。
但如果是基于平台开发，这种无谓的工作量可以降低很少，甚至可以不需要第三方的交互技术。只要保证两个系统间的通信接口就要以轻松实现。系统组件的迁移也
可以通过发布器与部署器来实现。
技术组件：从技术角度来看，J-Hi与其它的技术组件差别不大。无非是基于平台再开发一些技术组件，比如对
SpringMVC、SpringJDBC、DB2数据库等的支持，页面端也会再集成象DWZ或simpleframework，我们也会再提供更多的页
面端的生成模版，以此类推，平台的技术组件会在技术的不同层面进行扩展。但与其它的技术组件不同之处在于，实现类似于插件一样的可插拔，随需织入。