其主要特性（features）包括：
- 基于Apache ActiveMQ的可靠消息
- 基于Apache Camel的消息、路由和EIP（Enterprise Integration Patterns）
- 基于Apache CXF的WS-*和RESTful web服务
- 由Apache Karaf技术支持的基于OSGI的服务运行环境。
通过另外可安装的特性（features），ServiceMix也支持：
- Activiti的BPM引擎
- Apache OpenJPA的完整的JPA支持
- Apache Aries的XA事务管理
- 仍旧支持JBI标准（在ServiceMix 3.x系列之后已废弃），通过Apache ServiceMix NMR来支持，Apache ServiceMix NMR包含了丰富的Event、Messaging和Audit API。
构建ServiceMix应用方式主要有OSGI Blueprint，OSGI声明式服务和Spring DM（legacy）。可以看到对于一些常见的基础标准常见，直接使用Bludeprint配置文件即可以完成配置。
ServiceMix的官方网站地址为：http://servicemix.apache.org/ 。 其下载和安装部署也相对简单，在下载完成后，可以直接通过QuickStart里面的例子对ServiceMix的基础功能进行熟悉，以最简单的两个文件目录文件集成传输为例来进行说明如下：
首先是需要编写BluePrint.xml的配置文件，具体如下：
由于ServiceMix本身是基于OSGI和Karaf的组件化热部署框架，因此在配置文件开发完成后，只需要将该配置文件拷贝到Deploy目录下即可以完成该文件路由服务的部署。在部署完成后的服务运行后，我们将文件拷贝到camel/input目录下，可以看到文件会被传输和包括到output目录下。
对于具体部署的日志和状态可以通过 log:display 命令进行显示。
对于ServiceMix本身也提供另一个简单WebConsole端，可以通过：
>>features:install webconsole
进行Console管理端的安装，安装完成后通过 http://localhost:8181/system/console 地址访问，以smx/smx进行登录，登录后可以看到当前安装的组件本身的状态，可以查询总线运行相关的服务日志信息。
当前ServiceMix的版本为6.1版本，虽然仍然有对JBI规范的支持，但是也可以看到其核心已经转换为Camel，ActiveMQ和CXF三个核心开源组件的集成。同时基于Karaf实现的OSGI运行环境和容器。Karaf作为一款成熟而且优秀的OSGi运行环境以及容器已经被诸多Apache项目作为基础容器。
对于ServiceMix本身由于重点是在ESB服务运行引擎和开源组件的集成，因此可以看到在SOA治理管控，可视化的服务设计和开发方面都相对欠缺。而且当前ServiceMix相关的文档资料极少，实际在企业应用的场景也不多，如果要学习ServiceMix其核心需要学习的内容还是基于Camel的集成，消息中间件和CXF服务化框架，这三者本身是ServiceMix的基础。
对于服务开发中存在的个性化规则和逻辑的处理，ServiceMix提供了足够的开放性和灵活性，可以通过Eclipse环境进行plugin插件开发，开发完成的插件可以直接部署到deploy目录中。
在JBOSS Fuse ESB被红帽收购了做了较大的整合和商用化，即推出了JBOSS FUSE ESB引擎和基于JBOSS Developer Editon的服务可视化设计和开发。该ESB引擎本身仍然是基于Camel底层的可视化设计和实现，通过设计器的协助可以更加快速和高效的配置和开发ESB服务。
ESB在JAVA领域主要有两种标准，一种是Sun提供的JBI业务集成规范，一个则是由BEA和IBM提出的SCA/SDO标准。可以看到对IBM和Oracle的ESB平台基本采用的是SCA/SDO的标准。而对于开源的ESB如ServiceMix，JBOSS ESB等更多则是基于JBI规范进行实现。
最后在简单说明下OSGI和JBI规范
OSGi(Open Services Gateway Initiative,开放服务网关协议)提供了一个面向服务组件的编程模型，基于 OSGi 编程，具有模块化，标准化，面向服务，动态性，易复用，易扩展，易部署等诸多优点。
OSGi 带来了规范化的模块划分，低耦合的模块间关系，统一的模块开发方式，可动态插拔的模块管理环境。开发 OSGi 应用程序的第一步是在需求分析的基础上进行精心的模块划分，模块划分的原则是尽量保持单个模块的独立性，使模块与模块之间的耦合降到最小，每一个模块暴露给其它模块的信息最少，尽量让模块之间使用 OSGi 框架提供的服务***制来通信。一般可采用一个模块一个 Bundle 的方式，并为每一个 Bundle 在 Eclipse 环境中建立一个 Project 来进行开发，由于模块与模块之间的耦合很小，各个 Bundle 之间并不会象传统的开发方式中的各模块之间那样存在纠缠不清的包和类的引用关系，因此大部分Bundle的开发工作可以并行进行而不会互相影响。
JBI的本质是一种服务总线思想。JBI的目标是创建一个用于各种Java组件服务集成的运行环境。JBI容器以一种可插拔的方式集成不同类型的服务，而不是通过编写客户端代码来实现服务的集成。目前流行的服务容器有Servlet容器、EJB容器、JMS容器。
1. Servlet容器只能处理以HTTP/SOAP协议传输的消息（接收与响应）；
2. EJB容器只能处理RMI协议传输的消息；
3. JMS容器则处理的是JMS协议传输的消息；
它们之间无法进行通讯，如果想集成上面不同类型的容器服务，则必须有一种能融合以上不同容器的 新容器出现。JBI就是基于解决这种问题的思路出现的，JBI提供了各种各样的容器绑定组件（Binding Component,称BC）,BC专门负责接收各种各样的传输协议的消息与发送请收消息给外部容器。当然JBI还提供其它的功能，要不这纯属一种代理 了，就没什么意义；
JBI提供处理各种业务的组件（即Service Engines组件，称SE）的消息，比如接收到HTTP的消息后需要转发给外部组件EJB，则需要SE组件来进行转换（更准确的说是Transform SE组件）。其实BC与SE之间是无法直接通信的，所有的消息都是通过传输通道（Deliver Channel）传送到NMR（Normalized Message Router），再由NMR通过DC将信息转到SE或BC的。