2013-10-03 4 views
0

Мне скоро нужно реализовать интерфейс. Интерфейс должен будет предоставить контракт между веб-сервисом и «n» другими веб-службами для управления трафиком. Компания планирует сначала исследовать/протестировать с помощью одного сервиса управления трафиком и добавить его позже, когда они станут доступными. Я могу определить интерфейс, который является «общим» для этого единственного варианта использования, но проблема в том, что в любой момент в будущем нам может понадобиться связываться с другой веб-службой, которая может или не может быть совместима с интерфейсом, который у нас есть при этом время.Java и «общие» интерфейсы

I может изменить интерфейс Java по мере того, Это также означало бы обновление всех исполнителей интерфейса.

Я хотел бы знать, есть ли какие-либо шаблоны, которые были бы подходящими для этого. Почти как «динамическое расширение интерфейса» во время выполнения. Или любое умное использование Java-дженериков, которое позволило бы нам реализовать один интерфейс Java, который можно было бы использовать с любыми/всеми системами управления трафиком.

Подводя итог: Когда мы приходим к общению с любыми другими услугами третьих лиц, я хочу, чтобы на нашей стороне были минимальные усилия для их интеграции.

Любые мысли?

+0

Это довольно неопределенный вопрос. Это не похоже на то, что у вас есть определенная проблема с вашим интерфейсом. Вы не даете нам намека на то, как это могло бы выглядеть. Вы спрашиваете о потенциальных новых провайдерах, которые еще не существуют. Вы не объяснили, что вы подразумеваете под интерфейсом (объекты, представляющие сообщение, клиент Java и т. Д.). Наконец, вы не указываете тип услуг, которые вы планируете использовать. Большие веб-сервисы? Веб-службы RESTful? – toniedzwiedz

+0

Я понимаю, что это расплывчато, но это те требования, которые у меня есть. Наше веб-приложение предложит фабрике получить имплантацию интерфейса. Эта реализация будет использовать неизвестные службы. Мне интересно, есть ли какая-либо магия Java/интерфейса, которую мы можем использовать, чтобы облегчить задачу интеграции неизвестных служб позже по линии. Например, служба третьей стороны может потребовать 1 ... * запрос/ответы, прежде чем мы получим нужные нам данные. Каждый запрос может иметь 1 .. * параметры. Я знаю, что это расплывчато, и я подозреваю, что ответ отрицательный, но хотелось хотя бы спросить. – protectedmember

+0

Вы не можете решить неопределенные, неопределенные требования с дополнительными уровнями косвенности. –

ответ

1

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

Если вы ожидаете столкнуться с «устройствами» (службами управления трафиком) с диверсифицированной семантикой, вам придется иметь несколько типов драйверов ... опять же, в той же ситуации, что и различие между блочными устройствами и символьными устройствами.

Ваша ситуация - еще один пример очень хорошо известного и решенного шаблона :-)

+0

Отложить на себя слишком широко? Очевидно, не так, как у меня теперь есть преимущество в чем-то ... Драйверы устройств. Благодарю за то, что так быстро ответил, Джим! – protectedmember

+0

Я занимаюсь программным обеспечением с тех пор, как мейнфреймы (1975), и удивляюсь тому, как много раз повторяется несколько десятков концептуальных проблем. Большинство «новых» парадигм уже давно существуют (например, в 1960-х годах были созданы виртуальные машины). –

+0

Точка, путь принят. Еще раз спасибо, Джим – protectedmember

Смежные вопросы