Стратегия минимизации зависимостей между внутренними подсистемами в экосистеме RESTful Java

Question

Архитектура нашей системы такова, что существует набор функционально подразделенных подсистем RESTful. Многие из этих подсистем должны отвечать не только на запросы браузеров, но и на другие подсистемы. Межсистемный трафик относительно тяжел и требует масштабирования, поэтому было принято решение использовать сериализованные Java-бины в качестве представления для этого типа связи (из-за скорости сериализации / десериализации). Это, в свою очередь, вводит двоичную зависимость между подсистемами, которые имеют отношения клиент / сервер. Изменение внутренней структуры Java-бинов, предоставляемых через RESTful API, может иметь последствия совместимости версий с клиентскими подсистемами. Конечно, изменение структуры представления любого типа контента будет иметь проблемы с совместимостью, но это явно хуже.

Поскольку один API может обслуживать множество клиентов, координация выпусков каждого набора зависимых подсистем является непривлекательной опцией.

Это должно быть распространенной проблемой, и мне интересно, как другие люди решают / смягчают?

Answer 1

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

Answer 2

Я не уверен, правильно ли я понял ваш вопрос. Я думаю, что это о версии интерфейса, например одна операция и / или объект могут существовать в разных версиях и использоваться разными клиентскими системами, скажем:

ClientA uses InterfaceA
ClientB uses InterfaceA
...

В мире SOA это было решено с помощью пространства имен различных версий (WSDL, XSD), так что вы можете реализовать некоторое управление интерфейсами:

Время t0

ClientA uses InterfaceA.v1
ClientB uses InterfaceA.v1

Время t1 (новая версия InterfaceA)

ClientA uses InterfaceA.v2
ClientB uses InterfaceA.v1

Теперь вы можете реализовать процессы для принудительного перехода ClientB на InterfaceA.v2 в определенный момент времени. В целом, эти концепции были разработаны для мира WS- *, но вы можете применить их и к миру RESTful (я делал это несколько раз). Хорошая статья MSFT: http://msdn.microsoft.com/en-us/library/ms954726.aspx.