1） 首先请求消息会流到 Database Lookup 元素，该元素根据请求消息中所带的航班号和航班原定起飞日期，从数据库中查询出已订了该航班的所有乘客的信息（名称和电话号码），然后把所有的乘客信息填充到请求消息中的预设字段。经过了这一步，消息流中已经包含了乘客的信息。

　　2） 消息经过 MessageLogger 元素，该元素进行一些消息日志的记录

　　3） 当消息流到 MessageFilter 元素的时候进行分流，分离出到底是应该是调用延误航班的服务还是取消航班的服务。我们在请求信息中包含了一个字段flag，默认情况下我们规定都流向调用取消航班服务。如果这个字段的值是 delay 的话，流向延误航班。MessageFilter 的配置如图6所示：

　　图6 MessageFilter 的端子
 
　　输出有两个，default 默认流向取消航班服务，notifyDelay 流向延误航班服务。我们使用 XPath 对消息内容中 flag 的值进行判断：

　　/body/notifyFlightInfo2Users/notifyCondition/flag [self: node ()=’delay’]
 
　　如图7所示。

　　图7 定义 MessageFilter 的 pattern
 
　　4） 经过过滤后，延误航班消息和取消航班消息分别流向各自的服务，由于我们的请求消息的格式和航班服务本身所要求的格式不一致，所以我们必须要对消息的格式进行匹配，使之符合航班服务要求的格式，这个时候 XSLTransformation 可以起作用了，我们以取消航班服务为例，如图8：

　　
　　图8 取消航班的格式匹配视图
 
　　Target 一栏是航班服务的消息格式，它需要用户名称（userId）和提示信息（notifyInfo）两个信息，而 Source 一栏是请求消息的格式。通过把请求消息中的信息和目标消息中的信息进行匹配，我们能够得到被航班服务接受的消息格式。

　　5） 最后当航班服务处理完之后，我们也需要使用 XSLTransformation 把服务返回的结果信息转化成 FlightNotifyUserMediation 能够接受的信息格式。如图9：