前面介绍Mule ESB使用的系列文章中我们使用了自定义的Java Transformer和Java Component，用于接收和处理Mule Message。然而我们使用的Transformer和Component都必须实现AbstractTransformer接口或者org.mule.api.lifecycle.Callable接口，这使得普通的POJO对象无法直接被Mule ESB流程引用，必须填写实现接口的代码。这样不仅增加了代码开发的工作量，而且进行单元测试时无法脱离Mule ESB Container进行，具有很大的局限性。
从Mule ESB 3开始，引入了entry point resolver机制，Mule Flow在引用自定义Component时，同时定义对应的entry point resolver, 使得在Component没有实现接口的前提下，Mule ESB可以准确匹配到Component对应方法，将Mule Message传送给这些方法处理。Mule ESB将这一策略称为entry-point resolution strategy(EPRS),下图显示了Mule ESB如何使用EPRS进行Mule Message传递(Mule in Action 第二版的6.1中原来有配图，不过它基于Mule ESB 3.3版本，已经不适用于当前Mule ESB 3.8版本，因此我重新绘制了流程图)
1)当消息到达Flow中定义的Component时，Mule会检查是否定义了EPRS(可以定义在Flow级别，Component级别，后者定义的entry-point resolver可以覆盖前者定义的entry-point resolver)，如果没有定义，Mule会使用默认的entry-point resolver。
2)Mule根据entry-point resolver寻找匹配的entry point,如果没有找到，会抛出Failed find entry point for component的异常消息。如果找到匹配的entry point,不论有多少个，会执行第一个匹配的entry point。
Mule ESB中定义的entry point resolver有以下几种：
- Callable Entry Point Resolver
- Property Entry Point Resolver
- Method Entry Point Resolver
- Reflection Entry Point Resolver
- Array Entry Point Resolver
- No Arguments Entry Point Resolver
- Custom Entry Point Resolver
下面将对这些Entry Point Resolver进行逐一介绍
来源：oschina
链接：https://my.oschina.net/u/237688/blog/733407