Следует отметить, что устойчивостью к обрыву связи в любом случае обладают тонкий и Web-клиент, а в случае толстого клиента «воскрешение» пользовательского сеанса зависит главным образом от того, какая именно операция выполнялась клиентским приложением в момент обрыва связи. Некоторые операции (например, работа с транзакциями), к сожалению, требуют непрерывной связи между клиентом и сервером и не могут быть временно прерваны.
В-четвертых, динамическая балансировка нагрузки между рабочими процессами кластера. Кластер постоянно отслеживает загруженность своих рабочих процессов и вычисляет интегральную доступную производительность каждого процесса. Если доступная производительность разных процессов существенно различается, происходит переключение части пользовательских сеансов с более нагруженных процессов на менее нагруженные.
В предыдущих версиях «1С: Предприятия 8» анализ загруженности рабочих процессов тоже выполнялся, но только в момент возникновения нового клиентского соединения – кластер принимал решение, какому из рабочих процессов передать это соединение для обслуживания. Но на практике разные пользователи создают непропорциональную нагрузку на кластер – например, одни просто листают список документов, а другие формируют «тяжелые» отчеты. И при неблагоприятном стечении обстоятельств (несколько «тяжелых» пользователей попали в один рабочий процесс) возникали проблемы производительности информационной системы. Конечный пользователь вовсе не обязан знать о существовании рабочих процессов и тонкостях распределения нагрузки между ними, но на ситуацию «вдруг все стало тормозить» он обязательно отреагирует, причем реакция будет строго негативной.
Механизм динамической балансировки нагрузки на рабочие процессы, появившийся в версии «1С: Предприятие 8.2», позволяет насколько это возможно равномерно распределять активность пользователей по рабочим процессам кластера и использовать аппаратные ресурсы наиболее эффективно.
В предыдущих версиях «1С: Предприятия 8» пользовательский интерфейс целиком и полностью создавался разработчиком прикладного решения. Платформа практически никогда не принимала самостоятельных решений о выводе того или иного элемента на какую-либо форму, а изменения в структуре метаданных конфигурации никоим образом не влияли на интерфейсную часть. Разработчик должен был в явной форме создать командный интерфейс (главное меню и панели инструментов) и в буквальном смысле «нарисовать» все необходимые формы. При этом разработчик получал полную свободу действий – можно было поместить любой элемент в любое место любой формы, придать любой размер, раскрасить в любые цвета и т. д. К сожалению, у полной свободы действий есть и своя оборотная сторона – при работе через Интернет или по медленным каналам связи передача информации о такой форме между клиентом и сервером стала бы очень затратным мероприятием. Более эффективный способ – передача не собственно формы, а правил ее формирования.
В «1С: Предприятии 8.2» реализована принципиально новая интерфейсная модель, называемая управляемым приложением. Управляемое приложение базируется на следующих концепциях.
• Оконная система. Каждое окно «1С: Предприятия 8» в режиме управляемого приложения – независимо и представлено отдельном элементе на панели задач ОС (или же отдельное окно браузера при работе с Web-клиентом). Основное окно предназначено для навигации по функциям конфигурации и данным информационной базы, а вспомогательные окна используются для доступа к данным (например, через формирование отчетов) и модификации объектов информационной базы.
• Декларативное описание интерфейса. Управляемое приложение позволяет разработчику перейти от конструирования интерфейса к декларированию, т. е. к явному или неявному указанию платформе, какой элемент и в какой ситуации выводить или не выводить в пользовательский интерфейс. Наиболее простой пример такого декларирования – настройка прав доступа к объектам конфигурации. Платформа автоматически исключит из интерфейса функции, выполнять которые текущий пользователь не имеет права. Могут применяться и более сложные способы – например, механизм функциональных опций, при помощи которого разработчик может описать зависимость между элементами интерфейса и данными информационной базы.