Решения BizTalk обычно включают схемы, карты и оркестровки. Решения могут также включать вспомогательные компоненты, бизнес-правила, определения маршрутизации и преобразований на основе портов, торговых партнеров и некоторые другие типы артефактов.
Эффективное управление всеми этими артефактами имеет много преимуществ - гораздо больше преимуществ, чем недостатков.
Преимущества включают в себя:
- Разделение проблем на основе
логическая группировка артефактов (по
функциональность или тип артефакта для
пример). Такой подход уменьшает
возможность модификации аспектов
Ваше решение, не связанное с
проблема, над которой вы работаете в
время.
- Проще проверить - вы можете скомпилировать и
развернуть только компоненты, которые вы
модифицирование. * * +1010
- Проще разделить работу между группами
Разработчики.
- Легче управлять, когда решение
становится больше - это может занять несколько
минуты для загрузки большого BizTalk
решения в Visual Studio.
- Поддерживает более продвинутые подходы
связанные с решениями в стиле ESB (очень
Слабая связь). В зависимости от вашего
Общий подход, вы можете создать
очень модульное решение - для
Дело в том, что модули могут работать
и быть полностью обновленным
независимо друг от друга.
- делает возможным версию
артефакты отдельно.
- Способствует более детальному контролю
за безопасность и использование памяти
путем группировки связанных функций, таких как
что вы развернете их для определенного
например, экземпляр хоста (вы можете
также администрировать мелкозернистый .NET
политики безопасности легче, чем
вы можете с решением, которое развертывает
несколько сборок).
Основной недостаток разделения вашего решения на несколько проектов или поверхностей решений при отладке вашего решения. Отладка решений BizTalk не проста для многих разработчиков, которые являются новичками в BizTalk, и необходимость сузить ошибки в решениях не облегчает работу. Однако вы можете решить эту проблему, более эффективно организуя свое решение и используя стандарты именования, структуры каталогов, расположения пространств имен и связанных с ними методов, чтобы упростить поиск места поиска.
Другие недостатки включают в себя:
- Больше сборок для подписи и развертывания
в GAC
- Взаимозависимости между
проекты могут привести к развертыванию
ошибки, которые могут быть трудно
выследить в плохо организованном
решения.
Вы должны посвятить некоторое время в начале проекта - в идеале во время проектирования - для настройки базовой организации вашего решения. Универсального подхода не существует - вам нужно подумать о том, как вы хотите управлять решением во время разработки, развертывания и обслуживания в контексте функциональности, которую решение предоставляет вашей организации или клиентам.
Хорошее место для начала - разделить ваше решение по типу артефакта или функциональным областям. По мере развития вашего решения вы получите лучшее понимание того, как артефакты связаны друг с другом, как вы хотите управлять надежными именами, безопасностью и физическим развертыванием, и сможете лучше организовать свое решение. Вы должны быть осторожны с этим подходом, поскольку в конечном итоге вам может понадобиться переставить большие части решения, что может привести к разрушительным последствиям, если сроки вашего проекта сжаты.