Сервис-ориентированная архитектура и развивающиеся объекты, совместно используемые между приложениями

Question

Я собираюсь начать набор услуг WCF для различных бизнес-приложений. Эта SOA будет очень незрелой для начала и в конечном итоге превратиться в сильный слой среднего уровня.

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

Например: если у вас есть SOA, предоставляющая сервис, который возвращает объект obj1. Эта услуга потребляется app1, app2, app3. Представьте, что объект был изменен для app1, я не хочу обновлять app2 и app3 для изменений, сделанных для app1. Если изменение является добавочным свойством, оно будет работать нормально, оно просто не будет отображаться, но что произойдет, когда вы удалите свойство? Или изменить свойство из строки в int? Как вы управляете изменениями?

Заранее вам за помощь?

PS: я сделал небольшую картину, но, видимо, мне нужна репутация 10, так что вы должны будете использовать ваше воображение ...

Answer 1

Цель состоит в том, чтобы ограничить изменения заставляют своих клиентов, чтобы сделать немедленно. В конечном итоге им придется внести некоторые изменения, но, надеюсь, это происходит только при неизбежных обстоятельствах, таких как несколько версий, и вы постепенно сворачиваете их.

Неразрывные изменения могут быть:

1. Добавление дополнительных свойства
2. Добавление новых операций

Критические изменения включают в себя:

1. Добавление требуемого СВОЙСТВ s
2. Удаление свойства
3. Изменение типов данных свойств
4. Изменение названия свойств
5. Удаление операции
6. Переименование операции
7. Изменение порядка свойств, если явно указано
8. Изменение привязок
9. Изменение пространства имен служб
10. Изменение м приведение в действие операции. Например, я имею в виду, что операция всегда возвращала все записи, но она была изменена только для возврата определенных записей. Это нарушит ожидаемый ответ клиентов.

Варианты:

1. Добавить новую операцию для обработки обновленных свойств и логики. Измените код за оригинальной операцией, чтобы установить новые свойства и логику обслуживания рефакторинга, если сможете. Не забудьте не изменять значение операции.
2. Если вы хотите удалить операцию, которую больше не хотите поддерживать. Вы вынуждаете клиента в какой-то момент меняться. Вы можете добавить документацию в wsdl, чтобы клиент знал, что он устарел. Если вы разрешаете клиенту использовать вашу dll-контракт, вы можете использовать атрибут [Obsolete] (он не генерируется в окончательном wsdl, поэтому вы не можете просто использовать его для всех)
3. Если это большое изменение вообще, новая версия сервиса и/или интерфейса и конечной точки может быть легко создана. Т.е. v2, v3 и т.д. Тогда вы можете иметь клиентов перейти на новую версию, когда настало время

Здесь также хороший блок-схема из «Apress - Pro WCF4: Практика Microsoft SOA», которые могут помочь ,