Комментарии 10
Респект.
Тоже пишу про SOA, но не на хабре, а в личном блоге.
На мой взгляд, осталась нераскрытой тема межсервисной коммуникации.
А это очень важно, например вопрос — синхронная она или нет. Должен ли отправляющий сервис ждать, пока получатель получит и обработает вызов. Может ли один бизнес-процесс распараллелиться на несколько одновременных межсервисных взаимодействий, а потом собраться в единый результат.
Мы на этом достаточно голову поломали в своё время.
Тоже пишу про SOA, но не на хабре, а в личном блоге.
На мой взгляд, осталась нераскрытой тема межсервисной коммуникации.
А это очень важно, например вопрос — синхронная она или нет. Должен ли отправляющий сервис ждать, пока получатель получит и обработает вызов. Может ли один бизнес-процесс распараллелиться на несколько одновременных межсервисных взаимодействий, а потом собраться в единый результат.
Мы на этом достаточно голову поломали в своё время.
Спасибо, об этом напишу в одной из следующих частей ;) Ну и конечно обменяться опытом можно всегда и вне поста.
В общем сложно ответить на этот вопрос априори, для разных систем подходят разные модели, тут нужно смотреть по конкретной ситуации.
В общем сложно ответить на этот вопрос априори, для разных систем подходят разные модели, тут нужно смотреть по конкретной ситуации.
у нас на проекте используется самопальный фреймворк для общения сервисов между машинами на базе 0mq. Обычные зпросы типа user_service.online_users() делается синхронно и передаются данные в бинарном формате. Для случаев когда сервис должен знать о создании или изменении определенного объекта, мы использует слушатели. Например руби код при создании юзера вызывает broadcast(user, :create), слушатели в сервисах перехватывают данный вызов и записывают айди и нужные данные этого пользователя в локальную базу.
Хорошая статья, для вравления мозгов
Несколько вопросов
1. Вы в статье используете различные термины, например Technology First, Architecture First, это ваши или есть источник?
2. SOA замечательно звучит и проектируется в теории, но SOА сам по себе это абстрактный подход к проектированию, реализацией которого как раз и является SOAP (ака WS) из вашей статьи я так и не понял выбранную Вами альтернативу, что вы нашли лучше SOAP для SOA?
Несколько вопросов
1. Вы в статье используете различные термины, например Technology First, Architecture First, это ваши или есть источник?
2. SOA замечательно звучит и проектируется в теории, но SOА сам по себе это абстрактный подход к проектированию, реализацией которого как раз и является SOAP (ака WS) из вашей статьи я так и не понял выбранную Вами альтернативу, что вы нашли лучше SOAP для SOA?
SOAP — это не совсем реализация SOA. SOAP — это одна из технологий, которую можно (а можно и не) применять в SOA.
Я думаю, что если погуглить то можно найти использования этих терминов и другими авторами, так не буду себе приписывать авторство. На мой взгляд это сочетание настолько банально, что не стоит его возводить в ранг 'аксиомы' или 'термина'. Примерно как «сначала главное» (first things first).
Мы как раз сейчас экспериментируем с архитектурой, сделали Spring-приложение, в котором пошли как раз от сервисов. БД у нас хоть и одна, но поскольку сервисы независимы, ничто не мешает сделать так как вы говорите — свою персистентность для каждого сервиса.
Мы не используем Hibernate, взяли реализацию DataMapper — MyBatis. Таким образом, наши модели — чистые POJO, без жестко заданных связей через какой-нибудь JPA.
Вопрос: что бы вы посоветовали в данном случае сделать, чтобы изолировать сервисы друг от друга по данным? Если нужно, текущее состояние кода можно посмотреть здесь: github.com/7bits/jade-fff (проект учебный, но по мотивам реального).
Мы не используем Hibernate, взяли реализацию DataMapper — MyBatis. Таким образом, наши модели — чистые POJO, без жестко заданных связей через какой-нибудь JPA.
Вопрос: что бы вы посоветовали в данном случае сделать, чтобы изолировать сервисы друг от друга по данным? Если нужно, текущее состояние кода можно посмотреть здесь: github.com/7bits/jade-fff (проект учебный, но по мотивам реального).
Добрый день Анна,
для начала позвольте заметить что у Вас очень симпатичный сайт. Единственное — при разрешении 1280х800 claim не виден. Это мне возразил один из специалистов по usability, когда я послал ему Ваш сайт как пример для хорошего IT-Сайта.
К делу:
1) Вы уверены что у Вас есть сервисы? Employer- и Recruiter- сервисы я бы такими не назвал, так как все проблемы там решаются при помощи SQL (ну или вызова к repository что в итоге тоже самое). Ваши сервисы при этом используют одни и те же repository, так что ни о каком разделении сервисов говорить не приходится: оба используют DealRepository, ApplicantRepository, UserRepository. Что ещё страшнее: RecruiterService использует EmployerRepository.
В Вашу защиту: то что spring называет сервисом и то что является сервисом с точки зрения СОА — две большие разницы.
2) Ваше разделение на пакеты! Ваше разделение на пакеты!
Разделение на пакеты должно быть по… затрудняюсь найти русское слово, на английском это Domain, а на немецком: Fachlichkeit. С таким разделением как у Вас построить СОА будет невозможно (ну или очень сложно), ведь практически невозможно проследить от каких пакетов зависит какой сервис и какой ещё зависит от тех же пакетов. Раз персистентность сервиса EmployerService его и только его, почему бы ей не находиться в под-пакете employer? Тоже касается и его данных. У вас всё в одной куче.
Если вы посмотрите на Схему 3: начинать надо с сервисов. Если бы Вы начали так, то у вас были бы совсем другие сервисы (попробуйте если не верите).
3) Ваше разделение сущностей emoployer и recruiter и последующая интеграция их при помощи общего объекта user… Это как-то ни то не сё. Либо у Вас таки есть employer и recruiter, либо их нет. Если уж собирать их в одну таблицу, то назовите это User и дайте ему какой-то enum type.
Ещё два маленьких замечания
1) javax.servlet-api надо декларировать provided. Я Ваш проект дальше compile не собирал, он пытался создать какие-то таблицы и т.д. и мне попросту было лень создавать специально базу, но теоретически томкат должен ругаться при старте.
2) Копирование разной конфигурации через мавен профайл: посмотрите на этот проект: www.configureme.org он позволяет хранить все конфиги в одном файле (stackable/cascading), и переключать нужные через параметр в рантайм. Плюс в том что Вы деплоите на все системы один и тот же, тестированный артефакт.
П.С. Я уже упоминал Ваше разделение на пакеты?
для начала позвольте заметить что у Вас очень симпатичный сайт. Единственное — при разрешении 1280х800 claim не виден. Это мне возразил один из специалистов по usability, когда я послал ему Ваш сайт как пример для хорошего IT-Сайта.
К делу:
1) Вы уверены что у Вас есть сервисы? Employer- и Recruiter- сервисы я бы такими не назвал, так как все проблемы там решаются при помощи SQL (ну или вызова к repository что в итоге тоже самое). Ваши сервисы при этом используют одни и те же repository, так что ни о каком разделении сервисов говорить не приходится: оба используют DealRepository, ApplicantRepository, UserRepository. Что ещё страшнее: RecruiterService использует EmployerRepository.
В Вашу защиту: то что spring называет сервисом и то что является сервисом с точки зрения СОА — две большие разницы.
2) Ваше разделение на пакеты! Ваше разделение на пакеты!
Разделение на пакеты должно быть по… затрудняюсь найти русское слово, на английском это Domain, а на немецком: Fachlichkeit. С таким разделением как у Вас построить СОА будет невозможно (ну или очень сложно), ведь практически невозможно проследить от каких пакетов зависит какой сервис и какой ещё зависит от тех же пакетов. Раз персистентность сервиса EmployerService его и только его, почему бы ей не находиться в под-пакете employer? Тоже касается и его данных. У вас всё в одной куче.
Если вы посмотрите на Схему 3: начинать надо с сервисов. Если бы Вы начали так, то у вас были бы совсем другие сервисы (попробуйте если не верите).
3) Ваше разделение сущностей emoployer и recruiter и последующая интеграция их при помощи общего объекта user… Это как-то ни то не сё. Либо у Вас таки есть employer и recruiter, либо их нет. Если уж собирать их в одну таблицу, то назовите это User и дайте ему какой-то enum type.
Ещё два маленьких замечания
1) javax.servlet-api надо декларировать provided. Я Ваш проект дальше compile не собирал, он пытался создать какие-то таблицы и т.д. и мне попросту было лень создавать специально базу, но теоретически томкат должен ругаться при старте.
2) Копирование разной конфигурации через мавен профайл: посмотрите на этот проект: www.configureme.org он позволяет хранить все конфиги в одном файле (stackable/cascading), и переключать нужные через параметр в рантайм. Плюс в том что Вы деплоите на все системы один и тот же, тестированный артефакт.
П.С. Я уже упоминал Ваше разделение на пакеты?
Спасибо за слова про сайт, но он в жесткой разработке, это далеко не окончательный вариант. Там и картинок под ретину нет, например :-)
1. В-общем, мы изначально не ставили себе целью сделать SOA. Наша цель была сделать максимально независимыми Use cases. Сейчас каждый Use case реализуется методом какого-то *Service и поэтому их можно менять независимо. По сути — это сервисы с точки зрения DDD, но не SOA, конечно. Прошу прощение, за то, что ввела в заблуждение.
2) Нет, разделения персистентности у нас пока нет и не будет. Поскольку все текущие модели сейчас относятся к одному Bounded context (это опять DDD), то их и не нужно разделять. А вот если появится mailer или еще какой-то технический сервис, то вполне можно будет для него использовать другое хранилище.
Если посмотреть на пакеты и остальное под углом DDD, не пытаясь разделить Employer и Recruiter на сервисы с точки зрения SOA (а мы и не планируем этого), то описанных вами проблем просто нет.
3) Это разные роли. Они являются агрегатами сущностей (опять DDD) и поэтому методы собраны именно так. Здесь разделение только логическое, а не физическое.
Про servvlet-api и maven посмотрю, спасибо!
1. В-общем, мы изначально не ставили себе целью сделать SOA. Наша цель была сделать максимально независимыми Use cases. Сейчас каждый Use case реализуется методом какого-то *Service и поэтому их можно менять независимо. По сути — это сервисы с точки зрения DDD, но не SOA, конечно. Прошу прощение, за то, что ввела в заблуждение.
2) Нет, разделения персистентности у нас пока нет и не будет. Поскольку все текущие модели сейчас относятся к одному Bounded context (это опять DDD), то их и не нужно разделять. А вот если появится mailer или еще какой-то технический сервис, то вполне можно будет для него использовать другое хранилище.
Если посмотреть на пакеты и остальное под углом DDD, не пытаясь разделить Employer и Recruiter на сервисы с точки зрения SOA (а мы и не планируем этого), то описанных вами проблем просто нет.
3) Это разные роли. Они являются агрегатами сущностей (опять DDD) и поэтому методы собраны именно так. Здесь разделение только логическое, а не физическое.
Про servvlet-api и maven посмотрю, спасибо!
Отличная статья. Что вы посоветуете почитать из литературы, блогов по архитектуре java приложений. Очень интересуют реальные примеры. Может быть какой-то OpenSource проект на java, чтобы детально почитать исходники.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Масштабировать просто