Comments 40
И понимаешь, что все-таки 1С свернула не туда!
Тонкий клиент 1С целиком и полностью копирует основную идею ultima or nexus резалтсет запроса хранить на сервере. Правда при этом программирование усложняется на порядок так как необходимо обеспечивать разделение программного текста на серверный и клиентский. Кстати через nexus можно совершенно спокойно рассматривать метаданные 1с или любых других mssql систем. У меня был опыт сопровождения биллинговой системы BillOnLine, в которую я внедрил nexus скрипт и тем самым обеспечил альтернативный интерфейс над таблицами системы. В силу того, что зачастую в современных системах база рассматривается как набор таблиц, хранящих данные и не более, а nexus работает с хранимыми процедурами, то на сегодняшний момент nexus — это единственная технология внедрения в любую учетную систему на базе mssql. Это я проделывал с базами DocsVision and 1C. возврат к Nexus обязательно произойдет., имхо.
Существовал (и вроде даже как-то дышит до сих пор) концептуальный аналог нашей Ультимы — это "БОСС-Компания" (не путать с «БОСС-Корпорацией»)
С тех пор я не видел потенциально более гибких систем.
Сделать гибкую систему, внезапно, не так сложно, как сделать поддерживаемую и масштабируемую.
Гибкость обычно приводит в восторг технических специалистов, поскольку позволяет менять систему под пожелания бизнеса, без переписывания кода. Однако у гибкости есть обратная сторона: часто, когда сделать можно «как угодно» до конечного пользователя доходит продукт, где не сделано никак. Т.е. типа с посылом «делайте, как вам больше нравится». А вот для конечного пользователя часто больше одного варианта (желательно строго прописанного в соответствующей должностной инструкции) — ни разу не плюс! Пользователь на предложение ему свободы действий впадает в ступор… Не каждый, но большинство. Просто потому, что в современную систему часто уже на уровне интерфейса заложены некие best practices, без которых человек сам не знает что ему нужно и как правильно…
Да, по хорошему должна быть прокладка из внедренцев в костюмах между техногиками в джинсах и клиентом. И никогда гиков, каким был я, к клиенту не пускать)
Ну, я надеюсь, мы с вами правильно друг-друга поняли. ;)
Потому, что мне-то как раз ваша разработка, в силу ряда можно сказать «личных» причин, очень понравилась! ;) Но имея опыт внедрения как раз максимально гибких самописных решений как раз столкнулся с выше описанными сложностями. Оказалось, что пользователям не надо гибко — им надо «напишите инструкцию куда нажимать». А внедренцев в костюмах у меня тоже не было....
Есть небольшое отличие точки зрения автора от моей. Автор рассматривает nexus, как нечто прошлое. Я же рассматриваю его, как будущее. Может быть далекое, но будущее. Потому что вижу дорогу, по которой надо идти. Например, если привязать @@spid к схеме, то получится отличное разделение индивидуального от общественного. Каждый пользователь работает в своей схеме и со своими таблицами detailed etc. Процесс обобществления, конечно, есть. Но, это отдельная тема. Работа выполняется через слой view, которые несут в себе нагрузку метаданных для разных языков "человеков". Я уже не говорю про поисковые возможности класса иерархий без перемещения инфы в таблицах. Конечно, непривычно и на первых порах сложно, но это путь не к учетной системе, а прототипу искусственного интеллекта, который не есть чтото центральное и всеобъемлющее, а компактное. То есть nexus клиент + локальная база, к которой, если надо может подключиться другой клиент. Это путь к автоклассификации объектов с последовательным усложнением их свойств и поведенческих процедур.
Это основной плюс nexus — он масштабируем. Поддерживать его действительно трудно поскольку в исходном варианте требуется вручную писать sql скрипты и полностью отсутствует работа с метаданными. Первое, что я сделал — это написал класс по генерации простого класса, потом класса посложнее, потом класса по выполнению динамического sql запроса. На самом деле надо писать полноценный конфигуратор, как в 1С. Поддержка — это всегда программист. Например, я — 1С программист. И чем я занимаюсь? По большому счету пишу код, который в конечном счете превращается в sql запрос. И чем мощее этот запрос, тем эффективнее код. Nexus работает с sql кодом только, и других программистов, кроме sql не надо. Вот в чем основная фишка. Все программисты и их технологии тоже, работающие на сервер приложений, в принципе не нужны.
Это основной плюс nexus — он масштабируем.
Что вы понимаете под масштабируемостью? Для меня это способность обслуживать растущее число запросов ценой разумного (в идеале — не более чем линейного) роста ресурсов.
Ну и заодно (и это коррелирует с поддерживаемостью) — способность обслуживать растущую фукнциональность ценой сублинейного роста числа разработчиков.
Nexus работает с sql кодом только, и других программистов, кроме sql не надо. Вот в чем основная фишка.
Ну, для вас это, видимо, "фишка", а для меня — жирный крест.
То есть Вы не используете SQL?
Не всегда.
Сервер приложений — это большой ресурс. Вы его приобрели дополнительно, а теперь начали линейно экономить?
Сервер БД я тоже экономлю, как ни странно.
Впрочем, у меня есть более занятный вопрос: а как, собственно, сделать из nexus веб-приложение?
Впрочем, у меня есть более занятный вопрос: а как, собственно, сделать из nexus веб-приложение?
да, если делать это сейчас (с нуля, разумеется), то система должна была бы поддерживать как WinForms клиента так и Web. Некоторые фичи (pessimistive locks) не очень совместимы с web, ну и бог с ними
А вот как архитектурно — очень интересный вопрос.
В чем же экономия, если запросы верные и оптимизированы?
Экономию сюда принесли вы. А я спросил про масштабируемость. Во сколько раз надо увеличить серверные ресурсы, если число пользователей увеличилось в 1000 раз (при этом нагрузка, производимая одним пользователем, осталась неизменной)?
Ни во сколько.
Если ни во сколько, значит изначально ваш сервер был в 1000 раз более мощным, чем нужно для решения задачи, и это неэкономно.
Нет, мы исходим из того, что изначально сервер подобран так, чтобы выполнять прогнозируемую нагрузку с приблизительно 80% загрузкой ресурсов.
Процессоры сервера всегда не дорабатывают или просто простаивают.
Это значит, что ваша система изначально неэффективна.
Я както такими вопросами не парюсь.
Значит и масштабируемость вас не волнует.
Если не нахожу, то эскалирую проблему выше на закупку новой техники. Где тут масштабирование?
Масштабирование именно там, где когда вам не хватает ресурсов на обслуживание увеличившейся нагрузки, вы закупаете новую технику.
Когда строишь дом, неважно какого размера, фундамент должен быть. Он, конечно, зависит от веса дома, почвы и пр. Но все это лишь параметры фундамента, а не какая-то фундаментальная характеристика «масштабируемость». Собственно, как и время, которую возвели в ранг чуть ли не измерения, а на самом деле, это всего лишь характеристика движения.
К примеру, я имею удовольствие (точнее неудовольствие) работать с одной корпоративной системой ITSM, где каждый клик тупит секунд по пять — и ничего, не жужжат.
Ну обычно ERP системы все таки не фейсбук — даже WEB интерфейс будет выставлен, скорее всего, только в Intranet.
Это когда как. Я знаю как минимум две ERP-системы, для которых облако — это основной способ развертывания, и это было очень важно в прошедшем году.
Так что вряд ли тут нужна какая то эластичность и фермы.
"Эластичность и фермы" нужны не только тогда, когда у вас растут пользователи на одну компанию, но и когда у вас растет число обрабатываемых запросов (проходило через компанию 100 заказов в день, а теперь — десять тысяч), и когда вы хотите, предоставляя облачные услуги, экономить на размещении компаний на серверах.
Впрочем, у меня есть более занятный вопрос: а как, собственно, сделать из nexus веб-приложение?
Технически это несложно: вместо тонкого rich-клиента пишется аналог на JS + web server. Вместо прямого использования SPID в протоколе поддерживается сессия и делается проброс контекста в слой бизнес логики (session id -> SPID), метод описан в книжке "СУБД для программиста"
P.S. к «минусованию» ваших комментариев никакого отношения не имею
Кажется несложным, но немедленно вызывает следующие вопросы.
Начнем с того, что надо сделать авторизацию. Раньше все было, как я понимаю, очень просто, и пользователь напрямую авторизовался в СУБД, а теперь так уже не выйдет.
А во-вторых, теперь нужен веб-сервер, а веб-сервер — это тоже ресурс, и в этот момент распределение ресурсов и логики между СУБД и этим сервером становится занятным рассуждением.
Вопрос был «как сделать веб-клиент?», вроде бы я ответил. Как сделать веб-клиент без веб-сервера не совсем понимаю. Сюжет о разделении нагрузки — другой вопрос, опять-таки, не вижу, что там нужно дополнительно разделять по сравнению с исходной архитектурой. Бонусы появляются, да.
Почему же не выйдет? Авторизацию можно по-прежнему продолжать использовать СУБД-шную, логин/пароль пробрасываются напрямую
Во-первых, это весьма небезопасно, потому что вам придется гонять пароль в плейнтексте. Во-вторых, это будет работать только для авторизации с паролем, но не будет работать для windows accounts.
(ну и заодно у авторизации-по-пользователю есть та проблема, что при определенном числе пользователей MS SQL просто говорит "больше нет", но это уже совсем отдельный разговор)
Вопрос был «как сделать веб-клиент?», вроде бы я ответил.
Понимаете ли, в чем дело, сам по себе ответ на этот вопрос весьма очевиден. Неочевидны следствия (часть из которых я описал выше), и которые и начинают потихоньку тыкать в те же самые места архитектуры, которые были озвучены как проблемные выше по треду. В частности, разделение нагрузки — это как повтор вопроса про разделение нагрузки между СУБД и прикладным сервером, про который уже выше написали, что плюс в том, что прикладной сервер вообще не нужен.
Рассматривайте архитектуру, не как отсутствие сервера приложений (СП), а как реализацию сервера приложений средствами СУБД, тогда большинство вопросов отпадает. Вопрос про распределение нагрузки решается аналогичным образом, как и в случае выделенного СП.
Зачем же гонять пароли открытым текстом? Веб-приложения давно умеют HTTPS.
Затем, что HTTPS где-то заканчивается, пусть даже и на самом веб-сервере.
Аналогично настраивается и SSO в Windows-сети.
Не настраивается. Я пробовал, double-hop ломается приблизительно через раз.
Рассматривайте архитектуру, не как отсутствие сервера приложений (СП), а как реализацию сервера приложений средствами СУБД, тогда большинство вопросов отпадает.
Неа, не отпадает. Вопрос "почему SQL — самый подходящий язык для написания бизнес-логики", например, никуда не девается.
Вопрос про распределение нагрузки решается аналогичным образом, как и в случае выделенного СП.
Понимаете, в случае выделенного СП я могу масштбировать СП отдельно, а БД — отдельно. И в моем личном опыте сделать нормальный кластер серверов приложений (или веб-серверов) намного проще, чем кластер СУБД. Проще говоря, в моем опыте СП можно (и выгодно) масштабировать горизонтально, а СУБД приходится вертикально.
Полностью с вами согласен, что масштабирование пары СУБД+СП имеет больше степеней свободы, чем СУБД со встроенным СП. Но как выше уже заметили, клиенту нужны не степени, а «чтобы работало по надежному сценарию, пусть даже одному».
Разумеется, процедурное расширение SQL может показаться менее подходящим языком реализации бизнес-логики, тут есть и плюсы (встроенный интегрированный SQL, высокая производительность связанного с СУБД кода, отсутствие перегонки данных между процессами), так и минусы (как правило слабая организация модульности, СУБД vendor lock, отсутствие ООП, более сложное тестирование). Это все понятно, остается выбрать баланс соответствия конкретному случаю.
Замечание про дырки в цепочках TLS правильное, но, к сожалению, не специфичное для данной архитектуры.
Для данной архитектуры специфично то, что ей нужен именно пароль. Не хэш, не токен — только и исключительно пароль, причем пароль от пользователя в БД.
Вопрос неустойчивости SSO несколько субъективный, у меня был позитивный опыт (крупная supply chain система).
Ваш опыт — он именно с "давайте залогиним пользователя в СУБД под той конкретной windows-учеткой, под которой он сейчас залогинен в браузере", или просто SSO?
Но как выше уже заметили, клиенту нужны не степени, а «чтобы работало по надежному сценарию, пусть даже одному».
Клиенты — они разные. Я как-то работал с клиентом, у которого изначальная система имела общие черты с описанной в посте. MS SQL, бизнес-логика в хранимых процедурах, сквозная авторизация windows-пользователя из толстого клиента в MS SQL. Все было неплохо, пока им не понадобилось дать доступ к этой же системе на два порядка большему числу пользователей снаружи организации (и, естественно, через web).
Это все понятно, остается выбрать баланс соответствия конкретному случаю.
Я был бы рад, если бы это действительно было "все понятно". Но опыт показывает, что не понятно.
Для данной архитектуры специфично то, что ей нужен именно пароль. Не хэш, не токен — только и исключительно пароль, причем пароль от пользователя в БД.
Хмм… Представим себе типовое хранение хешей паролей в БД, проверкой которых занимается соответствующий сервис, напрямую соединяющийся с БД. Пусть длина цепочки передачи пароля до сервиса равна N. Теперь совместим сервис с СУБД. Длина цепочки остается N.
Не забываем учесть необходимую дополнительную авторизацию самого сервиса в СУБД, получаем две цепочки уязвимости вместо одной.
Ваш опыт сомнению не подлежит, но я бы не хотел переходить от обсуждений концептов к их реализациям.
Теперь совместим сервис с СУБД. Длина цепочки остается N.
Эээ. Вы предлагаете совместить веб-сервер с СУБД?
Ваш опыт сомнению не подлежит, но я бы не хотел переходить от обсуждений концептов к их реализациям.
А как вы разделяете концепт и реализацию? Где вы проводите грань?
Я вот не вижу смысла обсуждать концепт, если при тыкании палочкой становится понятно, что он нереализуем.
Обсуждаемый концепт реализован во множестве проектов «двухзвенок» с толстым клиентом, причем как концепт он обсуждался лет 20 назад.
Удивительная однозвенка на MS SQL