Прояснение понятий архитектуры Аксапты

[Narayana]

После освоения разработки в Аксапте наступил этап размещения решения на рабочем сервере.
Если раньше тонкости установки не очень занимали внимание, то сейчас хочется сделать все точно и аккуратно.
Стал читать посты про корректную установку и сразу поймал себя на мысли, что не понимаю нескольких основных вещей.
Например, при указании текущего билда речь идет о версии ядра и версии приложения.
Раньше я как-то под приложением считал AOS, а сейчас задумался, так ли это?
И что тогда в таком случае ядро? Это те самые файлы приложения, которые установщик устанавливает между базой данных и AOS-ом?
Они что, лежат на сервере БД и являются слоем между БД и AOS-ами, которые могут лежать на других серверах?

В руководстве по установке написано, что файлы приложения содержат в себе бизнес-логику. А AOS тогда что в себе содержит? Или он просто обеспечивает коннект между клиентом и файлами приложения?

Товарищи, подскажите наивному дилетанту что к чему!

[S.Kuskov]

Цитата:

Сообщение от Narayana

А AOS тогда что в себе содержит? Или он просто обеспечивает коннект между клиентом и файлами приложения?

AOS + клиент - это ядро системы. Т.е это бинарные экзешники, характеризующиеся номером билда.

"Файлы приложения" (файлы с расширением *.aod и др.) содержат бизнес-логику (написанную на x++), которую умеет исполнять ядро системы.

В ранних версиях клиентская часть ядра могла работать с БД напрямую (двухзвенная архитектура: "толстый клиент") в новых версиях вся работа с БД происходит посредством AOS (трёхзвенная архитектура: "тонкий клиент").

[Narayana]

Цитата:

Сообщение от S.Kuskov

AOS + клиент - это ядро системы. Т.е это бинарные экзешники, характеризующиеся номером билда.

"Файлы приложения" (файлы с расширением *.aod и др.) содержат бизнес-логику (написанную на x++), которую умеет исполнять ядро системы.

В ранних версиях клиентская часть ядра могла работать с БД напрямую (двухзвенная архитектура: "толстый клиент") в новых версиях вся работа с БД происходит посредством AOS (трёхзвенная архитектура: "тонкий клиент").

Спасибо за быстрый ответ.
То есть, версия приложения, это версия файлов приложения?
А в AOS и клиент разработчик внести изменения не может?
То есть, в коллекции классов Аксапты классы ядра не присутствуют и написаны на другом языке, доступном только разработчикам ядра?

Стало быть, обновления функционала Аксапты будут работать даже без обновления ядра, получается?

А вот, интересно... в Axapta 6.0 в каталоге Dynamics есть папочка Server, но нет папочки Application. Что бы это могло значить?

[Maximin]

Вы разделИте для себя понятия - ядро Аксапты (среда выполнения) и бизнес-логику и сразу станет всё ясно.
Точно так же как .NET Runtime (бывает 1.0, 1.1, 2.0, 3.0, 3.5, 4.0) и какая-то программа на C#, которая может иметь свои версии (Paint.NET версии xx).
Программа, в принципе, если её написать не используя возможностей, специфичных для конкретной версии .NET, может работать на некоем подмножестве версий .NET Framework.
Рядовой программист не может изменить .NET Framework. Но может изменить приложение.

Точно то же и Аксапта.

А Application нонче в 2012й в БД переехал. Теперь поиск по репозитарию раза в 4 дольше делается и после первого вызова быстрее не становится.

[Narayana]

Цитата:

Сообщение от Maximin

Дык, Application нонче в 2012й в БД переехал. Теперь поиск по репозитарию раза в 4 дольше делается и после первого вызова быстрее не становится.

...ага! Вон оно что... Похоже, эта мода из SharePoint сюда перекочевала.
Чую, закончится это тем, что X++ совсем отменят и Аксапту разберут на запчасти.

[RVS]

Цитата:

Сообщение от Narayana

...при указании текущего билда речь идет о версии ядра и версии приложения.

DAX2009? В трешке был один номер билда, типа 1951 3730/514-193 SP3/OP023-71

Цитата:

Сообщение от Narayana

Раньше я как-то под приложением считал AOS, а сейчас задумался, так ли это?

Не... AOS - отдельно, приложение - отдельно.. Просто, как вам правильно сказали уже, в 2009 приложение без AOS-а работать не может.. В трешке - могло. Вообще, лучше указывать версию системы, о которой спрашиваете.

Цитата:

Сообщение от Narayana

И что тогда в таком случае ядро? Это те самые файлы приложения, которые установщик устанавливает между базой данных и AOS-ом?

Нет

Цитата:

Сообщение от Narayana

Они что, лежат на сервере БД

Не обязательно

Цитата:

Сообщение от Narayana

и являются слоем между БД и AOS-ами, которые могут лежать на других серверах?

Уф.. Вопросы, на которые не могут ответить взрослые, называются детскими..

Цитата:

Сообщение от Narayana

В руководстве по установке написано, что файлы приложения содержат в себе бизнес-логику. А AOS тогда что в себе содержит? Или он просто обеспечивает коннект между клиентом и файлами приложения?

В том числе и "коннект"... но не только.

Цитата:

Сообщение от S.Kuskov

...(двухзвенная архитектура: "толстый клиент")

Помнится мне, что и "толстый", и "тонкий" - это трехзвенка в 3.0. То есть с использованием AOS. Разница, если мне склероз не изменяет, в коннекте к БД - толстый - ODBC, тонкий - через AOS.

Вот как-то так..

[Maximin]

Цитата:

Сообщение от Narayana

...ага! Вон оно что... Похоже, эта мода из SharePoint сюда перекочевала.
Чую, закончится это тем, что X++ совсем отменят и Аксапту разберут на запчасти.

Эт вряд ли. Дюже долго разбирать придется. Не так давно у МС были планы включить X++ в число языков .NET. Не знаю, как там счас. Но в 2012й чувствуется число "набежавших" бывших .NETчиков с "объектно-озабоченным" подходом.

[Narayana]

Цитата:

Сообщение от RVS

DAX2009? В трешке был один номер билда, типа 1951 3730/514-193 SP3/OP023-71

Не... AOS - отдельно, приложение - отдельно.. Просто, как вам правильно сказали уже, в 2009 приложение без AOS-а работать не может.. В трешке - могло. Вообще, лучше указывать версию системы, о которой спрашиваете.
Нет
Не обязательно Уф.. Вопросы, на которые не могут ответить взрослые, называются детскими..
В том числе и "коннект"... но не только.
Помнится мне, что и "толстый", и "тонкий" - это трехзвенка в 3.0. То есть с использованием AOS. Разница, если мне склероз не изменяет, в коннекте к БД - толстый - ODBC, тонкий - через AOS.

Вот как-то так..

Понял, что вы человек значительный, но предмет обсуждения яснее не стал... )
По вашим словам файлы приложения могут лежать не на сервере БД... А где тогда?
Стало быть, расположение всех частей Аксапты должно указываться в конфигурациях? А конфигурации где должны лежать? Для БД, файлов приложения, бизнес-коннектора и клиента, получается должно быть четыре конфигурации, а их только две...

[Narayana]

Цитата:

Сообщение от Maximin

Эт вряд ли. Дюже долго разбирать придется. Не так давно у МС были планы включить X++ в число языков .NET. Не знаю, как там счас. Но в 2012й чувствуется число "набежавших" бывших .NETчиков с "объектно-озабоченным" подходом.

Это интересно.
Что же получится?
В VS можно будет создать Аксапто-подобный проект с нуля...
Но, сила X++ в богатом функционале, в который можно вставить свои пять копеек.
Хотя, конечно, сами по себе такие типы данных, как валюта имногое другое, уже являются большой ценностью.
Тогда разработка полностью переползет на VS...
К тому времени, наверное, в VS можно будет открывать SharePoint-проекты, а не только контролы и таким образом объединится традиционная и веб-разработка...

[Ivanhoe]

Narayana, не мучайте себя и людей. Вас какая версия интересует?

[Narayana]

Цитата:

Сообщение от Ivanhoe

Narayana, не мучайте себя и людей. Вас какая версия интересует?

О...! Ну, дак, 2009, конечно!
Сорри, диковат-с... ))

[sukhanchik]

АХ2009:
Файлы приложения лежат на одном сервере. Как правило там же, где установлена служба AOS, хотя их и можно разделить.
На том сервере, где установлены службы AOS установлена конфигурационная утилита сервера, с помощью которой для каждой службы AOS прописывается сервер БД и название конкретной БД. Также в ней прописывается путь к файлам приложения.

Вся прописываемая информация по умолчанию хранится в реестре.

Помимо всех настроек - задается специальный порт (число, обычно 4-х значное, по умолчанию - 2712), через который клиент будет подключаться к службе AOS. Настройки для разных служб независимы друг от друга и порты для каждой службы должны отличаться.

На клиенте, в свою очередь, есть своя конфигурационная утилита, в которой прописывается название сервера AOS и номер порта. Эта информация также хранится в реестре, однако часто ее выгружают в *.axc-файл, который и служит ярлыком для подключения к конкретной службе AOS клиента АХ

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

Итого получается:
2 конфигурационных утилиты (сервера и клиента), которые помогают настроить параметры подключения для:
- БД и файлов приложения (утилита сервера)
- бизнес-коннектора (утилита клиента)
- клиента (утилита клиента)

[Ivanhoe]

AX 2009.
AOS (сервер выполнения бизнес-логики) и файлы приложения (сама бизнес-логика) могут быть физически в разных местах. Файлы приложения вряд ли будут на сервере БД, скорее уж на сервере AOS (не рассматриваем установку всего на один сервер).

Конфигурационных утилит две - для сервера и для клиента.

В серверной конфигурации указывается БД и файлы приложения. AOS при запуске подключается к указанной БД и использует указанное приложение.

В клиентской конфигурации указывается AOS, к которому нужно подключаться. Настройка BC - частный случай клиентской конфигурации (в утилите можно указать, что настраиваем - клиента или BC).

[Narayana]

Сейчас наконец вчитался в руководство по установке. Пишут про экземпляр файлов приложения. То есть, может быть несколько не только AOS-ов, но и экземпляров файлов приложения?
Ну, AOS-ы, понятно, для разгрузки сети и поднятия производительности. А экземпляров файлов приложения зачем несколько? Вроде бы, язык выбирается в клиенте... Они что, все эти несколько экземпляров файлов приложения с одной базой будут работать?
А я ж могу, вапще, экземпляры файлов приложения для разных стран поставить... И че тогда получится??

[sukhanchik]

Цитата:

Сообщение от Narayana

А экземпляров файлов приложения зачем несколько? Вроде бы, язык выбирается в клиенте... Они что, все эти несколько экземпляров файлов приложения с одной базой будут работать?

Это равносильно количеству копий программ. Для работы нужен один экземпляр (обычно, хотя бывают варианты конечно).
Но они могут "клонироваться", как разработческая копия, тестовая, обучающая и т.д.
Два разных приложения на одной БД работать естественно не смогут

Цитата:

Сообщение от Narayana

А я ж могу, вапще, экземпляры файлов приложения для разных стран поставить... И че тогда получится??

В 2012 уже все "слили" воедино все страны . В 2009 - это просто будут разные программы, имеющие похожий интерфейс и функционал

[Narayana]

Цитата:

Сообщение от sukhanchik

Это равносильно количеству копий программ. Для работы нужен один экземпляр (обычно, хотя бывают варианты конечно).
Но они могут "клонироваться", как разработческая копия, тестовая, обучающая и т.д.
Два разных приложения на одной БД работать естественно не смогут



В 2012 уже все "слили" воедино все страны . В 2009 - это просто будут разные программы, имеющие похожий интерфейс и функционал

Ага...! Значит экземпляр файлов приложения может быть только один и все экземпляры AOS-ов должны работать именно с ним?
Конечно, слово "ядро" как-то смутило очень сильно поначалу.
Ну, так бы и писали, - база, приложение, сервер приложения, клиент.
Стало быть, "ядро" обновлять нужно по отдельности. Отдельно AOS, отдельно клиента. А если я, например, AOS обновил, а клиент нет, или наоборот. Что тогда в версии будет показано для ядра и, вообще, система-то будет при этом работать?

То есть, в 2012 страну можно выбирать так же, как раньше компанию?!
Круто.

[sukhanchik]

Цитата:

Сообщение от Narayana

Стало быть, "ядро" обновлять нужно по отдельности. Отдельно AOS, отдельно клиента. А если я, например, AOS обновил, а клиент нет, или наоборот. Что тогда в версии будет показано для ядра и, вообще, система-то будет при этом работать?

Приложение (=программный код) тестируется на соответствующих версиях клиента и АОСа.
Т.е. они могут разойтись в версиях - но никто не гарантирует при этом работоспособность.
Однако, практика показывает, что обновлять ядро (бинарники клиента и АОСа) более поздними версиями чаще полезно, чем вредно, хотя всегда надо читать перечень изменений в новой версии, в любом случае понимая, что тестирование старого приложения с новыми бинарниками не было.

Версии клиента и АОСа опять-таки могут и отличаться, но лучше чтобы совпадали. Ключевая фраза "такие варианты не тестировались = отсутствует гарантия работы без глюков"

[Narayana]

Цитата:

Сообщение от sukhanchik

Приложение (=программный код) тестируется на соответствующих версиях клиента и АОСа.
Т.е. они могут разойтись в версиях - но никто не гарантирует при этом работоспособность.
Однако, практика показывает, что обновлять ядро (бинарники клиента и АОСа) более поздними версиями чаще полезно, чем вредно, хотя всегда надо читать перечень изменений в новой версии, в любом случае понимая, что тестирование старого приложения с новыми бинарниками не было.

Версии клиента и АОСа опять-таки могут и отличаться, но лучше чтобы совпадали. Ключевая фраза "такие варианты не тестировались = отсутствует гарантия работы без глюков"

Угу, стало намного понятнее.
Более позднее ядро, вроде, не должно ломать юзерский наработанный функционал и трогать новые таблицы.
А если мы обновляем приложение?
При каждом обновлении необходимо доработки сохранять в отдельном проекте и после обновления заново устанавливать?
А при этом индексы и связи в таблицахне ломаются?

[lvan]

я уверен, что у вас сломаются. почему вы спрашиваете элементарные вещи на форуме, вместо того, чтобы прочесть документацию?

[sukhanchik]

Цитата:

Сообщение от Narayana

А если мы обновляем приложение?
При каждом обновлении необходимо доработки сохранять в отдельном проекте и после обновления заново устанавливать?
А при этом индексы и связи в таблицахне ломаются?

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

Связи в таблицах на уровне БД отсутствуют, поэтому они не ломаются
А вот индексы, таблицы и поля система строит самостоятельно. Этот процесс называется синхронизация.

Конечно, нужно заботиться об обновлении и сохранении своих данных.