When should you choose custom OMDataSource-backed elements over standard parsing?

Choose a custom OMDataSource implementation when the data an element needs to represent doesn't start out as XML at all - a Java object graph, rows from a database query, an in-memory JSON structure - and converting it to XML is a cost you want to defer or potentially avoid entirely, rather than pay unconditionally on every message.

This is the mechanism underneath Axis2 databinding integrations like ADB: a service's return value, still a plain Java object at that point, gets wrapped in a data-source-backed OMSourcedElement so the actual XML generation only happens if and when the response body is genuinely serialized onto the wire - if a downstream interceptor or pivot logic never actually reads the body as XML, that conversion simply never happens.

By contrast, when the source is already XML - bytes received over a socket, a file on disk, a string already in that format - there's no conversion to defer, so standard StAX-based parsing into a normal element tree via OMXMLBuilderFactory is the appropriate and simpler tool; wrapping already-XML content in a data source adds complexity without buying anything, since the "deferred conversion" benefit doesn't apply when there was never really a conversion step to defer.

A secondary case for a custom data source is representing genuinely large or expensive-to-materialize content that you want to stream or generate on demand piece by piece, rather than holding the entire representation, XML or otherwise, in memory at once - though this is a less common motivation than the databinding pass-through scenario.