Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Java [игнор отключен] [закрыт для гостей] / db service выбор технологии / 18 сообщений из 18, страница 1 из 1
08.01.2014, 23:59
    #38519987
Driverz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
Есть желание поэкспериментировать над SOA архитектурой и появилась задача как реализовать сервис доступа к базе данных, конкретно на какой технологии и протоколе, что бы выжать максимум.
Присматриваюсь к Akka.
Hibernete по умолчанию как ORM.

ИМХО. Студент, учусь. Хочу дельный совет.
...
Рейтинг: 0 / 0
09.01.2014, 00:13
    #38519997
забыл ник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
DriverzЕсть желание поэкспериментировать над SOA архитектурой

что вы под этим понимаете? Не троллинга ради, а ответа для
...
Рейтинг: 0 / 0
09.01.2014, 00:35
    #38520011
Driverz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
забыл никDriverzЕсть желание поэкспериментировать над SOA архитектурой
что вы под этим понимаете? Не троллинга ради, а ответа для
модульную архитектуру, с понятным интерфейсом внутри общей системы.
ИХМО. принципиально она не должна обязательно реализовывать тот же SOAP или RESTful или быть веб службой.( с другой стороны почему бы и нет если все там хорошо с производительностю ).

Я хочу совет от людей которые пощупали это в каком нить продакшене и могут поделиться своим видением
...
Рейтинг: 0 / 0
09.01.2014, 03:44
    #38520097
забыл ник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
DriverzЯ хочу совет от людей которые пощупали это в каком нить продакшене и могут поделиться своим видением

Честно сказать? SOA - полнейшее говно, придуманное маркетологами. Я в недавнем топике описывал с чем сталкиваюсь:)

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

Например мой проект(2000 юзеров в день в продакшене, бывает до 10000) имеет следующую архитектуру. Мы грубо говоря фронтэнд, никакого доступа к базе, чисто аггрегиуруем сервис коллы и дисплеим все в html. Сервисы предоставляются тремя сторонними командами, одна пендосы, две индусы. Это просто ад. Проблемы

1) Производительность - хз че там за этими сервисами спрятано, тупит неимоверно, и возможности что-либо поменять у нас нет
2) Допустим понадобилось дополнительное поле, но облом - в нужной операции его нет, но есть в другой, теперь дилемма - просить чтобы они добавили в первый колл или добавить лишний колл из-за этого чертового поля? Так как сервисы применяются другими приложениями, то каждое такое согласование - это неделя переписки, нервов, и как всегда в итоге сделают не так как надо.
3) Индусы постоянно перед уходом домой ложат свои DEV сервера - локальной разработке капец, у тебя срочный баг а ты ждешь полдня с неизвестным результатом
4) Бывает что ради одного поля мы делаем колл на сервис, который возвращает 100500 объектов, а нам нужна всего одна строка:) Или наш объект - это половина полей из одного колла, половина из другого.
5) Транзакционность, в рамках одного реквеста мне надо заколлать 3 сторонних сервиса(все изменяют данные), разрулить ошибки - это пипец.

и тд и тп, одним словом ад.

ПС реализовано через SOAP, частично REST.

Но если для собственного развития - то можно попытаться потренироваться, хотя пока не столкнешься с жоским продакшеном, такой опыт не такой уж и полезный
...
Рейтинг: 0 / 0
09.01.2014, 17:58
    #38520859
Driverz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
забыл никDriverzЯ хочу совет от людей которые пощупали это в каком нить продакшене и могут поделиться своим видением

Честно сказать? SOA - полнейшее говно, придуманное маркетологами. Я в недавнем топике описывал с чем сталкиваюсь:)

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

Например мой проект(2000 юзеров в день в продакшене, бывает до 10000) имеет следующую архитектуру. Мы грубо говоря фронтэнд, никакого доступа к базе, чисто аггрегиуруем сервис коллы и дисплеим все в html. Сервисы предоставляются тремя сторонними командами, одна пендосы, две индусы. Это просто ад. Проблемы

ПС реализовано через SOAP, частично REST.

Но если для собственного развития - то можно попытаться потренироваться, хотя пока не столкнешься с жоским продакшеном, такой опыт не такой уж и полезный

Как я понимаю проблема тут в "пендосы, индусы", а не в самой технологии.В моем случаи максимальное количество участвующих 2-3 человека, которым не нужно неделя на переписку что бы исправить или добавить какой то метод.Кстати, у вас на сервисе один поток и каждый метод = транзакции ?
...
Рейтинг: 0 / 0
09.01.2014, 18:49
    #38520925
забыл ник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
Driverz
Как я понимаю проблема тут в "пендосы, индусы", а не в самой технологии.В моем случаи максимальное количество участвующих 2-3 человека, которым не нужно неделя на переписку что бы исправить или добавить какой то метод.Кстати, у вас на сервисе один поток и каждый метод = транзакции ?

Правильно понимаете, в целом так и есть. Но если нет пендосов и индусов зачем заморачиваться с соа? С транзакциями все тяжело, не понял ваш вопрос
...
Рейтинг: 0 / 0
09.01.2014, 21:14
    #38521059
Driverz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
забыл никDriverzКак я понимаю проблема тут в "пендосы, индусы", а не в самой технологии.В моем случаи максимальное количество участвующих 2-3 человека, которым не нужно неделя на переписку что бы исправить или добавить какой то метод.Кстати, у вас на сервисе один поток и каждый метод = транзакции ?

Правильно понимаете, в целом так и есть. Но если нет пендосов и индусов зачем заморачиваться с соа? С транзакциями все тяжело, не понял ваш вопрос
Хочется так сказать иметь масштабируемую архитектуру, возможно появляться сервиси(модули) на другом языке. Кстати выплыло применения SOA, небольшой гейм сервер, функционал какого разделен на сервисы. Как оказалось много кто использует такой подход.
Вот по поводу транзакций можно по подробней как у вас реализовано и тп.
...
Рейтинг: 0 / 0
09.01.2014, 22:05
    #38521095
забыл ник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
DriverzВот по поводу транзакций можно по подробней как у вас реализовано и тп.

Да через жопу:) В некоторых случаях мы забиваем, внекоторых делаем перепроверки (save-get, или пишем в лог ошибки а потом разруливаем через хелп деск) итп, в остальных крайне просим чтобы нам сделали один колл вместо несколькх и тп. Прикручивать WS-Transactions или распределенных транзакций даже не пытался(ну у нас не финансы не страхование, иначе конечно было бы по-другому)

По поводу вашего видения SOA и гейм-серверов - возможно, тут надо смотреть по ситуации, краткое правило такое -

Если куски вашего приложения могут понадобиться в разных контекстах или для разных клиентов - то можно попробовать, городить такое только ради "изящной" архитектуры - себе дороже, поверьте на слово.
...
Рейтинг: 0 / 0
09.01.2014, 22:28
    #38521111
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
DriverzХочется так сказать иметь масштабируемую архитектуру, возможно появляться сервиси(модули) на другом языке.
ищите масштаб другим методом (не SOA)
...
Рейтинг: 0 / 0
09.01.2014, 22:45
    #38521121
Driverz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
забыл никDriverzВот по поводу транзакций можно по подробней как у вас реализовано и тп.

Да через жопу:) В некоторых случаях мы забиваем, внекоторых делаем перепроверки (save-get, или пишем в лог ошибки а потом разруливаем через хелп деск) итп, в остальных крайне просим чтобы нам сделали один колл вместо несколькх и тп. Прикручивать WS-Transactions или распределенных транзакций даже не пытался(ну у нас не финансы не страхование, иначе конечно было бы по-другому)

По поводу вашего видения SOA и гейм-серверов - возможно, тут надо смотреть по ситуации, краткое правило такое -

Если куски вашего приложения могут понадобиться в разных контекстах или для разных клиентов - то можно попробовать, городить такое только ради "изящной" архитектуры - себе дороже, поверьте на слово.
Так и есть, как у нас любят говорить (из одной бочки, с разными наклейками).
...
Рейтинг: 0 / 0
09.01.2014, 22:45
    #38521123
Driverz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
Petro123DriverzХочется так сказать иметь масштабируемую архитектуру, возможно появляться сервиси(модули) на другом языке.
ищите масштаб другим методом (не SOA)
хм... за и против? альтернатива?
...
Рейтинг: 0 / 0
09.01.2014, 22:54
    #38521129
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
Driverzхм... за и против? альтернатива?
у тебя постановки нет....для альтернативы.
- абстрагироваться от БД можно ОРМ'ом без SOA
- понятие модульность можно делать на классах, инкапсуляции, контрактах и ООПах.

А больше у тебя ничего нет.
Только желание - поизучать.
...
Рейтинг: 0 / 0
09.01.2014, 22:57
    #38521131
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
DriverzКак оказалось много кто использует такой подход.
ждём подробностей
...
Рейтинг: 0 / 0
10.01.2014, 12:17
    #38521683
Driverz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
Хорошо, давайте обсудим вот такой вариант.
...
Рейтинг: 0 / 0
10.01.2014, 12:26
    #38521703
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
очень подходит к твоему
DriverzЕсть желание поэкспериментировать
дерзай.
OFF
Проектировать ИС начинают с документа Концепция и ТЗ
...
Рейтинг: 0 / 0
10.01.2014, 13:13
    #38521811
Driverz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
Petro123очень подходит к твоему
DriverzЕсть желание поэкспериментировать
дерзай.
OFF
Проектировать ИС начинают с документа Концепция и ТЗ
да, большой комментарий.Ну если уже быть так сказать правильным, то проектирования начинают с исследование
...
Рейтинг: 0 / 0
10.01.2014, 13:24
    #38521832
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
Driverzто проектирования начинают с исследование
....предмета автоматизации!
Для выявления Требований к ИС.
А потом - архитектура.
...
А SOA _чаще_ для менеджеров и для договорных отношений между соисполнителями.
...
Рейтинг: 0 / 0
10.01.2014, 13:56
    #38521888
Driverz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
db service выбор технологии
Petro123Driverzто проектирования начинают с исследование
....предмета автоматизации!
Для выявления Требований к ИС.
А потом - архитектура.
...
А SOA _чаще_ для менеджеров и для договорных отношений между соисполнителями.
предмет автоматизации уже был указан выше.
Ладно я понял, вы мне помочь не сможете.
...
Рейтинг: 0 / 0
Форумы / Java [игнор отключен] [закрыт для гостей] / db service выбор технологии / 18 сообщений из 18, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]