Есть смысл. Так как при использовании асинхронности мы самостоятельно переключаем контекст и поток исполнения. А при многопоточности этим занимается операционная система.
Эта статья не про взаимодействие с веб-сервисами, использующих SOAP, а лишь о некоторых способах работы с XML-документами 🙂 Именно поэтому ничего не сказано о WSDL и XSD. SOAP рассмотрен как пример частного случая. К тому же необходимость получения данных из XML бывает при различных задачах.
Отметим, что эта статья рассказывает о возможных способах работы с XML-документами в целом, а не о взаимодействии с веб-сервисами, использующих SOAP. XML-документ — это не всегда SOAP, а значит, схем может и не быть. Кроме того, мы не ставили целью проведение полноценного сравнительного анализа JAXB и DOM, а лишь показали выполнение одних и тех же преобразований с использованием каждого из них, и в заключении отмечаем только некоторые плюсы и минусы JAXB и DOM.
Вы правы, эта библиотека была удалена с версии Java 11. Мы внесли исправления, спасибо! 🙂 К слову о создании классов и расстановке аннотаций, XML-документ — это не всегда SOAP, а значит, схем может и не быть. Задачи при работе с подобными документами бывают абсолютно разными. Здесь описаны лишь некоторые способы, с помощью которых возможно получить доступ к требуемым данным из XML.
Добрый день! Спасибо за уточнение. Действительно, на момент написания статьи в 2020 году версия 2.0 была только анонсирована. Поэтому мы упоминаем о скором добавлении параллельного запуска, но не учитываем его при сравнительном анализе с другими фреймворками.
Спасибо! Чтобы обмениваться, multithreading и асихнронка уже используют общую память. Для обмена между процессами можно использовать очереди (Queue) или каналы данных (pipe).
Решить проблему с Deadlock могут помочь 2 правила:
Так как Deadlock — это взаимная блокировка, т.е. захват в прямом и обратном направлении в разных потоках, отсюда вытекает правило. Если в процессах нужно захватывать Lock, то делаем это всегда в одном порядке (направлении).
И второе правило — освобождаем блокировки в обратном порядке их захвата, подобно стеку. Первым захватили — последним отпустили.
По мнению автора: Заниматься поддержкой версий при независимом деплое идеологически неверно. Должна быть обратная совместимость, раз мы пошли этой дорогой. И это не то же самое, что проверка типа. Версия может поменяться, но типы остаться прежними. Как разработчикам AppShell узнать сигнатуры методов, чтоб локально все компилилось, если объединяемся в рантайме? Только чтение документации к МФ-ам, а тут могут быть и человеческие ошибки. Допустим мы компилим под флаг strictNullChecks, передаем null в метод, который оказывается не умеет работать с null. Без тайпингов компиляция не отловит ошибки. Поэтому и предложен "замороченный" вариант с одновременной сборкой МФ-а и сборкой тайпингов под пакет
В рантайме мы можем типизировать с помощью утиной типизации. Не очень удобно, громоздко, для декларативного подхода нужно json валидаторы писать или использовать либы. Но по сути все кастомные тайп гарды так и работают. Опять же ошибки всплывут в рантайме, просто мы сможем их качественней обработать
Можно попробовать составить d.ts файлы на основе сборки МФ-ов. Файлы эти нпм пакетами доставлять в основное приложение. Именно этот вариант вы и описали, как я понял. Но тогда надо будет при каждом деплое МФ-а пересобрать основное приложение с учетом потенциально изменившихся типов. При этом версии этих пакетов надо менять, ведь они зафиксированы в package-lock. Апать пакет и комить новый резолв зависимостей через ci, чтоб разработчики могли потом подтянуть изменения и узнать, что да как там в новой версии. Способ компромиссный, но по-своему хлопотный
Автоматизированный подход может помочь взять лучшее от этих двух подходов: простоту типизации и независимость команд, но надо учесть массу нюансов.
Разберем npm пакеты. В package.json можно указать диапазон версий, что даст возможность апать пакет и триггерить сборку главного приложения. Но в package-lock.json зафиксирована конкретная версия пакета, которая работала на момент ручной интеграции или обновления пакета разработчиком. Опасно удалять этот файл и ставить зависимости заново, так как могут быть зарезолвлены иные версии сторонних зависимостей. Можно точечно обновить пакет и сделать комит через CI, чтобы разработчики могли отребейзиться и увидеть изменения в зависимостях, но в этом случае большая ответственность возлагается на DevOPS-инженеров.
С сабмодулями Git проще, поэтому это решение выглядит рабочим. Можно сделать git submodule foreach "git checkout master", а затем дергать сборку, но здесь может быть появиться блок со стороны разработки. Не всем нравится разработка через сабмодули, так как она приводит к сильной связности кода и проект ощущается монолитом. Когда проект достаточно большой, то хочется большей изоляции фич друг от друга.
Обнаружили баг, далее разработчик анализирует код, к обсуждению подключается аналитик и другие члены команды (по возможности). Если есть возможность оптимизации - оптимизирует, нет - эскалирует проблему тимлиду. Затем уже тимлид анализирует и оптимизирует, если есть возможность, если нет - эскалирует продакту, детально описывая проблемы и указывая возможные риски. Далее продакт обсуждает проблемный пункт НФТ с бизнесом. Обычно находим нужные доводы и приходим к компромиссу.
Но, по нашему мнению, нефункциональные требования не нужно менять из-за того, что система им не соответствует. Наоборот, это систему надо менять. Если вы видите, например, в kibana или в Sentry, что она не справляется - зовите девопсов. А еще лучше в коде заранее предусмотреть контрольные точки, на которых могут возникать проблемы, и при их возникновении получать соответствующие алерты. Но тут опять же мы говорим не об изменении НФТ под систему, а о внесении изменений в систему под НФТ.
Добрый день. В данном случае bpm предназначена для одного из российских банков. По нашим наблюдениям, Camunda бывает удобны как для бизнеса, так и для разработчиков, поскольку позволяет привязывать к схеме делегатный джава-код и сильно ускоряет процесс разработки. Как мы отмечали в прошлой статье, в чистом коде реализация займет гораздо больше времени, а поддерживать может быть нелегко из-за запутанной паутины вызовов и управления доступом. Хотя где-то действительно можно и проще работать без bpm – каждый решает сам.
Добрый день. Всё зависит от задачи, условий и уровня владения тем или иным инструментом. В общем случае сеньор-разработчику зачастую проще написать все чистым кодом, тогда как бизнесу бывает удобнее Camunda – чтобы наглядно видеть блок-схему процесса и легко подключать к проекту разработчиков любого уровня, не требуя от них погружения в чужой код.
Что касается вопросов, мы сделали несколько предположений, исходя из опыта нашего проекта – и в других проектах, безусловно, могут быть свои особенности.
1. Как версионировать БП, как мигрировать со старой версии на новую?
Можно указать в пулах version tag, кроме того, при деплое активные процессы закончат свой жизненный цикл по старой версии схемы.
2. А если при этом состав процессов или модели данных несовместимы?
Основы SOLID говорят, что проект должен быть открыт для расширения, но закрыт от изменений. Модель данных нужно менять в рамках разумного.
3. Где хранить актуальное состояние модели: только в инстансе процесса или во внешнем хранилище? Если во внешнем хранилище как решать проблему конкурентного доступа?
Можно хранить в контексте или во внешней БД (что даже лучше). Проблему конкурентного доступа нужно решать по мере ее возникновения, иначе сориентироваться трудно, если вообще возможно. Острее будет стоять вопрос версионирования и миграций БД. Также стоит присмотреться к документоориентированным БД.
4. Как вообще рефакторить это все это добро?
Рефакторить как раз-таки просто: схема оказывается отвязана от кода и можно с большой степенью свободы менять реализацию как схемы, так и кода.
5. И самое главное: а какой вообще bpm дает профит? По своей сути bpmn - это описание конечного автомата, так почему не использовать, например, акторную модель?
Дело в скорости разработки: в чистом коде реализация займет гораздо больше времени, а поддерживать может быть нелегко из-за запутанной паутины вызовов и управления доступом. Хотя, где-то действительно можно и проще работать без bpm – каждый решает сам.
Спасибо за оценку и дополнение! Добавили его в материал
Спасибо за внимательность! Да, аутентификация. Поправили
Добрый день! Подключить фильтр можно в ConfigureServices следующим образом:
services.AddSwaggerGen(options =>{options.OperationFilter<SourceHeaders>();});Добрый день! Мы добавили в статью новый раздел «Версионность», где рассказали, как настроить Swagger для работы с разными версиями API
Есть смысл. Так как при использовании асинхронности мы самостоятельно переключаем контекст и поток исполнения. А при многопоточности этим занимается операционная система.
Эта статья не про взаимодействие с веб-сервисами, использующих SOAP, а лишь о некоторых способах работы с XML-документами 🙂 Именно поэтому ничего не сказано о WSDL и XSD. SOAP рассмотрен как пример частного случая. К тому же необходимость получения данных из XML бывает при различных задачах.
Отметим, что эта статья рассказывает о возможных способах работы с XML-документами в целом, а не о взаимодействии с веб-сервисами, использующих SOAP. XML-документ — это не всегда SOAP, а значит, схем может и не быть. Кроме того, мы не ставили целью проведение полноценного сравнительного анализа JAXB и DOM, а лишь показали выполнение одних и тех же преобразований с использованием каждого из них, и в заключении отмечаем только некоторые плюсы и минусы JAXB и DOM.
Вы правы, эта библиотека была удалена с версии Java 11. Мы внесли исправления, спасибо! 🙂
К слову о создании классов и расстановке аннотаций, XML-документ — это не всегда SOAP, а значит, схем может и не быть. Задачи при работе с подобными документами бывают абсолютно разными. Здесь описаны лишь некоторые способы, с помощью которых возможно получить доступ к требуемым данным из XML.
Добрый день! Спасибо за уточнение. Действительно, на момент написания статьи в 2020 году версия 2.0 была только анонсирована. Поэтому мы упоминаем о скором добавлении параллельного запуска, но не учитываем его при сравнительном анализе с другими фреймворками.
Параллельный запуск был добавлен после публикации материала в версии 2.0-M4 (2020-11-01). До сих пор это версия 2.3, в документации указана с пометкой WARNING как experimental feature: https://spockframework.org/spock/docs/2.3/release_notes.html#_2_0_m4_2020_11_01
Спасибо!
Чтобы обмениваться, multithreading и асихнронка уже используют общую память.
Для обмена между процессами можно использовать очереди (Queue) или каналы данных (pipe).
Решить проблему с Deadlock могут помочь 2 правила:
Так как Deadlock — это взаимная блокировка, т.е. захват в прямом и обратном направлении в разных потоках, отсюда вытекает правило. Если в процессах нужно захватывать Lock, то делаем это всегда в одном порядке (направлении).
И второе правило — освобождаем блокировки в обратном порядке их захвата, подобно стеку. Первым захватили — последним отпустили.
По мнению автора:
Заниматься поддержкой версий при независимом деплое идеологически неверно. Должна быть обратная совместимость, раз мы пошли этой дорогой. И это не то же самое, что проверка типа. Версия может поменяться, но типы остаться прежними. Как разработчикам AppShell узнать сигнатуры методов, чтоб локально все компилилось, если объединяемся в рантайме? Только чтение документации к МФ-ам, а тут могут быть и человеческие ошибки. Допустим мы компилим под флаг strictNullChecks, передаем null в метод, который оказывается не умеет работать с null. Без тайпингов компиляция не отловит ошибки. Поэтому и предложен "замороченный" вариант с одновременной сборкой МФ-а и сборкой тайпингов под пакет
Уточните, что имелось в виду:
В рантайме мы можем типизировать с помощью утиной типизации. Не очень удобно, громоздко, для декларативного подхода нужно json валидаторы писать или использовать либы. Но по сути все кастомные тайп гарды так и работают. Опять же ошибки всплывут в рантайме, просто мы сможем их качественней обработать
Можно попробовать составить d.ts файлы на основе сборки МФ-ов. Файлы эти нпм пакетами доставлять в основное приложение. Именно этот вариант вы и описали, как я понял. Но тогда надо будет при каждом деплое МФ-а пересобрать основное приложение с учетом потенциально изменившихся типов. При этом версии этих пакетов надо менять, ведь они зафиксированы в package-lock. Апать пакет и комить новый резолв зависимостей через ci, чтоб разработчики могли потом подтянуть изменения и узнать, что да как там в новой версии. Способ компромиссный, но по-своему хлопотный
Автоматизированный подход может помочь взять лучшее от этих двух подходов: простоту типизации и независимость команд, но надо учесть массу нюансов.
Разберем npm пакеты. В package.json можно указать диапазон версий, что даст возможность апать пакет и триггерить сборку главного приложения. Но в package-lock.json зафиксирована конкретная версия пакета, которая работала на момент ручной интеграции или обновления пакета разработчиком. Опасно удалять этот файл и ставить зависимости заново, так как могут быть зарезолвлены иные версии сторонних зависимостей. Можно точечно обновить пакет и сделать комит через CI, чтобы разработчики могли отребейзиться и увидеть изменения в зависимостях, но в этом случае большая ответственность возлагается на DevOPS-инженеров.
С сабмодулями Git проще, поэтому это решение выглядит рабочим. Можно сделать git submodule foreach "git checkout master", а затем дергать сборку, но здесь может быть появиться блок со стороны разработки. Не всем нравится разработка через сабмодули, так как она приводит к сильной связности кода и проект ощущается монолитом. Когда проект достаточно большой, то хочется большей изоляции фич друг от друга.
Спасибо за подробные дополнения!
Спасибо) передадим автору)
Обнаружили баг, далее разработчик анализирует код, к обсуждению подключается аналитик и другие члены команды (по возможности). Если есть возможность оптимизации - оптимизирует, нет - эскалирует проблему тимлиду. Затем уже тимлид анализирует и оптимизирует, если есть возможность, если нет - эскалирует продакту, детально описывая проблемы и указывая возможные риски. Далее продакт обсуждает проблемный пункт НФТ с бизнесом. Обычно находим нужные доводы и приходим к компромиссу.
Но, по нашему мнению, нефункциональные требования не нужно менять из-за того, что система им не соответствует. Наоборот, это систему надо менять. Если вы видите, например, в kibana или в Sentry, что она не справляется - зовите девопсов. А еще лучше в коде заранее предусмотреть контрольные точки, на которых могут возникать проблемы, и при их возникновении получать соответствующие алерты. Но тут опять же мы говорим не об изменении НФТ под систему, а о внесении изменений в систему под НФТ.
Добрый день.
В данном случае bpm предназначена для одного из российских банков. По нашим наблюдениям, Camunda бывает удобны как для бизнеса, так и для разработчиков, поскольку позволяет привязывать к схеме делегатный джава-код и сильно ускоряет процесс разработки.
Как мы отмечали в прошлой статье, в чистом коде реализация займет гораздо больше времени, а поддерживать может быть нелегко из-за запутанной паутины вызовов и управления доступом. Хотя где-то действительно можно и проще работать без bpm – каждый решает сам.
Всем привет! Вышло продолжение статьи - на этот раз рассмотрим особенности тестирования моделей процессов.
Добрый день. Всё зависит от задачи, условий и уровня владения тем или иным инструментом. В общем случае сеньор-разработчику зачастую проще написать все чистым кодом, тогда как бизнесу бывает удобнее Camunda – чтобы наглядно видеть блок-схему процесса и легко подключать к проекту разработчиков любого уровня, не требуя от них погружения в чужой код.
Что касается вопросов, мы сделали несколько предположений, исходя из опыта нашего проекта – и в других проектах, безусловно, могут быть свои особенности.
1. Как версионировать БП, как мигрировать со старой версии на новую?
Можно указать в пулах version tag, кроме того, при деплое активные процессы закончат свой жизненный цикл по старой версии схемы.
2. А если при этом состав процессов или модели данных несовместимы?
Основы SOLID говорят, что проект должен быть открыт для расширения, но закрыт от изменений. Модель данных нужно менять в рамках разумного.
3. Где хранить актуальное состояние модели: только в инстансе процесса или во внешнем хранилище? Если во внешнем хранилище как решать проблему конкурентного доступа?
Можно хранить в контексте или во внешней БД (что даже лучше). Проблему конкурентного доступа нужно решать по мере ее возникновения, иначе сориентироваться трудно, если вообще возможно. Острее будет стоять вопрос версионирования и миграций БД. Также стоит присмотреться к документоориентированным БД.
4. Как вообще рефакторить это все это добро?
Рефакторить как раз-таки просто: схема оказывается отвязана от кода и можно с большой степенью свободы менять реализацию как схемы, так и кода.
5. И самое главное: а какой вообще bpm дает профит? По своей сути bpmn - это описание конечного автомата, так почему не использовать, например, акторную модель?
Дело в скорости разработки: в чистом коде реализация займет гораздо больше времени, а поддерживать может быть нелегко из-за запутанной паутины вызовов и управления доступом. Хотя, где-то действительно можно и проще работать без bpm – каждый решает сам.