如果您正在将最初使用预先解析方式开发的应用程序配置为使用延迟解析方式，或者您打算将应用程序在延迟解析方式与预先解析方式之间进行切换，那么您一定要知道这两种方式之间的差别，以及在这两种方式之间进行切换时的注意事项。
因为预先 XML 解析方式与延迟 XML 解析方式具有不同的底层实现，所以虽然业务对象变成接口和服务抛出的堆栈跟踪具有相同的异常类名，但是它们可能不包含相同的异常消息或者封装的一组特定于实现的异常类。
采用延迟 XML 解析方式时可优化性能；进行序列化时，它会尝试将入站字节流中未修改的 XML 复制到出站字节流中。这样会提高性能，但是，如果整个业务对象是以延迟 XML 解析方式进行更新的，或者它先前是采用预先 XML 解析方式运行的，那么出站 XML 字节流的序列化格式可能会不同。
尽管 XML 序列化格式可能在语法上不完全等同，但是，无论采用哪种解析方式，业务对象所提供的语义值都是等同的；在采用不同解析方式运行、但语义等同的应用程序之间可以安全地传递 XML。
延迟 XML 解析业务对象方式实例验证器对业务对象提供了更高精确度的验证，尤其是对属性值进行构面验证。正是由于进行了这些改进，因此延迟解析方式实例验证器将捕获到采用预先解析方式时未捕获到的其他问题，并且提供更详细的错误消息。
最初在 WebSphere Integration Developer V6.1 之前开发的调解流可能包含一些 Mapping 原语，这些 Mapping 原语使用无法直接在延迟 XML 解析方式下运行的映射或样式表。当已将应用程序迁移为用于延迟 XML 解析方式时，迁移向导可以将与“映射”原语相关联的映射文件自动更新为采用新的解析方式运行。但是，如果 Mapping 原语直接引用一个已手动编辑的样式表，那么此样式表不会被迁移并且不能以延迟 XML 解析方式运行。
如果应用程序正在利用未发布且特定于实现的专用业务对象编程接口，那么在切换解析方式时，编译此应用程序可能会失败。在预先解析方式下，这些专用接口通常是由 Eclipse 建模框架 (EMF) 定义的业务对象实现类。
在所有情况下，强烈建议您除去应用程序中的专用 API。
IBM Integration Designer 中的调解组件能够使用 com.ibm.websphere.sibx.smobo 包中提供的 Java™ 类和接口来处理消息内容。在延迟 XML 解析方式下，仍然可以使用 com.ibm.websphere.sibx.smobo 包中的 Java 接口，但是，直接引用 Eclipse 建模框架 (EMF) 类和接口的方法或者从 EMF 接口继承的方法可能会失败。
在延迟 XML 解析方式下，ServiceMessageObject 及其内容无法强制类型转换为 EMF 对象。
BOMode 服务用来确定当前正在执行的 XML 解析方式是预先解析方式还是延迟解析方式。
V7.0.0.0 之前的所有应用程序都采用预先 XML 解析方式运行。在运行时使用 BPM 运行时迁移工具对它们进行迁移时，它们将继续采用预先 XML 解析方式运行。
为了能够将版本低于 V7.0.0.0 的应用程序配置为采用延迟 XML 解析方式，请首先使用 Integration Designer 来迁移该应用程序的工件。迁移之后，再将该应用程序配置为采用延迟 XML 解析。
请参阅迁移源工件以了解有关在 Integration Designer 中迁移工件的信息；另请参阅配置模块和库的业务对象解析方式以了解有关设置解析方式的信息。