Генерация XML-документа из объектов Java, структура которых сильно отличается

Ситуация

У меня есть сложный граф объекта модели в Java, который необходимо перевести туда и обратно в XML-документ. Структура графа объектов схемы XML-документа сильно отличается от дерева объектов модели. Они взаимозаменяемы, но для перевода требуется много контекстной -управляемой логики, где используются отношения родитель-потомок -, подобные отношениям.

Проблема

Я работаю с объектами модели, которые хорошо зарекомендовали себя в более старой системе, а схема XML-документа довольно новая. Поскольку большая часть нашего кода зависит от структуры объектов модели, мы не хотим их реструктурировать. Вот упрощенный пример структурных различий, с которыми я имею дело:

Example data model tree

Item

• Description
• cost
• ...

Person

• First Name
• Last Name
• Address
• ...

Address

• Street
• City
• ...

SaleTransaction (*this is the thing being translated)

• Buyer (Person)
• Seller (Person)
• Sold Items[] (List)
• Exchanged Items[] (List)
• Location of Transaction (Address)

Example XML Document Structure

Exchange

• Type
• Parties
  • party_contact_ref
    • type
    • contact_id
• Exchange Details
  • type
  • total_amount_exchanged
• Items
  • Item
    • type
    • owning_party_contact_ref_id
    • exchange_use_type
• Contacts
  • Contact
    • id
    • type

Exchange Type: [ CASH SALE | BARTER | COMBINATION CASH AND BARTER ]

Contact Type: [ PERSON | ADDRESS ]

Exchange Details Type: [ CASH EXCHANGE | BARTER EXCHANGE ]

Сопоставление между SaleTransaction и Exchange возможно, но не 1 -1. В этом примере «покупатель» в модели будет сопоставлен как с контактом, так и с элементом ссылки на контакт в XML-документе. Кроме того, значение атрибута «владелец _сторона _контакт _ссылка _id» элемента «Элемент» будет определяться путем просмотра нескольких различных значений в графе объекта SaleTransaction.

Если объектный граф, с которым я работаю, нуждается в некотором переводе, чтобы его можно было использовать в XML-документе, мой -инструмент -— это XmlAdapter. Однако в данном случае я не считаю использование JAXB XML-адаптеров жизнеспособным решением по трем причинам.

1. Какому XML-элементу соответствует объект в графе модели, также зависит от данных. Я считаю, что все сопоставления XmlAdapter с классом/свойством исправлены.
2. Кажется, невозможно сделать решение «многие к одному» или «один ко многим» с помощью XmlAdapters. MOXy имеет интересное расширение ,но опять же, для этого требуются фиксированные сопоставления со свойствами.
3. Насколько мне известно, XmlAdapters работают с отдельными объектами и не имеют возможности получить доступ к контексту всего маршалируемого/немаршалируемого графа.

Вопрос

Я уверен, что этот тип проблемы довольно распространен, так как вы справляетесь с этим? Есть ли способ справиться с этой проблемой стандартными средствами?

Что я придумал

Если это интересно, вот возможные подходы, которые я придумал:

#1 Отделите проблему перевода графа объектов от проблемы генерации XML. У меня есть самодельный -инструмент, помогающий генерировать графы объектов на основе некоторого объекта контекста. Я мог бы создать классы JAXB из схемы XML, а затем использовать этот инструмент для создания объектов этих классов на основе контекста объекта нашей модели. Это хорошо работает для создания XML-документа из графа объектов модели, но не наоборот. Это также означает использование нестандартных -инструментов, которых я хотел бы по возможности избегать.

#2 Сойдите с ума от XmlAdapter и измените классы модели, чтобы иметь возможность сохранять информацию о состоянии перевода (, например. Этот объект в дереве модели использовался для создания этого элемента в XML-документе ). Это будет держать проблему очень близкой к стандартной модели использования для JAXB, но я думаю, что это будет кошмар для разработки, тестирования и обслуживания.

#3 Разделите проблему графа объектов, как я сделал бы в #1, но используйте JDOM вместо JAXB. Это удалит все необходимые классы и сопоставления JAXB, но потребует создания другого пользовательского инструмента для управления сопоставлением объекта модели с деревом DOM.

Я не в восторге ни от одного из трех решений, но я больше всего неравнодушен к #1.