Вот всю последнюю неделю мучает в голове мысль. Пока у меня время терпит — могу думать и выбирать что и как делать. Ситуация такая — есть не очень большая БД. И к ней клиент.
Клиент собственно давно нужно было переписать вот этим и займусь. Но и БД нужно переделывать (и в ней есть огрехи и платформа меня не устраивает). Да и жизнь требует новой реализации.
Ситуация:
1. Работа по локалке.
2. Работа удалённых клиентов (отделения в разных городах), так же подходит вариант периодической репликации.
Тем не менее и потребности новых задач будут. Вот и хочу удобную среду себе. Так или иначе планирую разрабатывать на дотнете. Вот и вопрос... стоит ли использовать веб-сервисы. Т.е. никто из клиентов не будет работать с БД напрямую. Хочется апп-сервер. Или лучше смотреть в сторону толстого клиента?

Здравствуйте, fddima, Вы писали:

F>Ситуация:
F>1. Работа по локалке.
F>2. Работа удалённых клиентов (отделения в разных городах), так же подходит вариант периодической репликации.
F>Тем не менее и потребности новых задач будут. Вот и хочу удобную среду себе. Так или иначе планирую разрабатывать на дотнете. Вот и вопрос... стоит ли использовать веб-сервисы. Т.е. никто из клиентов не будет работать с БД напрямую. Хочется апп-сервер. Или лучше смотреть в сторону толстого клиента?
Думаю, что от AppServer тут не отказаться — реализация на ES. К нему прикручиваем толсого клиента для локалки, а для "дальних родственников" можно прикрутить WS.

Здравствуйте, stasukas, Вы писали:

S>Думаю, что от AppServer тут не отказаться — реализация на ES. К нему прикручиваем толсого клиента для локалки, а для "дальних родственников" можно прикрутить WS.
ES? Это что такое?

Здравствуйте, fddima, Вы писали:

F>Ситуация:
F>1. Работа по локалке.
F>2. Работа удалённых клиентов (отделения в разных городах), так же подходит вариант периодической репликации.
F>Тем не менее и потребности новых задач будут. Вот и хочу удобную среду себе. Так или иначе планирую разрабатывать на дотнете. Вот и вопрос... стоит ли использовать веб-сервисы. Т.е. никто из клиентов не будет работать с БД напрямую. Хочется апп-сервер. Или лучше смотреть в сторону толстого клиента?

Почему нет? Если реализовать нечто вроде кэширования данных на клиентах (на случай проблем со связью у совсем удаленных клиентов ), асинхронное обновление/синхронизация этих данных в бэкграунде используя веб-сервис. Но если сильно большой объем информации, то может быть как нибудь иначе? При количестве записей в DataSet более 500000 возможны тормоза в плане производительности.
В принципе можно посмотреть и на .net remouting.
В любом случае вам лучше поподробней ознакомиться и с тем и с другим (тем более, что в какой то степени это родственные вещи (ремоутинг и веб-сервисы) ) и усиленно проанализировав все и вся определиться окончательно.

Здравствуйте, stasukas, Вы писали:

работать с БД напрямую. Хочется апп-сервер. Или лучше смотреть в сторону толстого клиента?
S>Думаю, что от AppServer тут не отказаться — реализация на ES. К нему прикручиваем толсого клиента для локалки, а для "дальних родственников" можно прикрутить WS.

ES — это EntepriceServices? COM+ уже поддерживает SOAP. Так что к таким компонентам можно обращаться как к Web Services.

Здравствуйте, fddima, Вы писали:

F>Вот всю последнюю неделю мучает в голове мысль. Пока у меня время терпит — могу думать и выбирать что и как делать. Ситуация такая — есть не очень большая БД. И к ней клиент.
F>Клиент собственно давно нужно было переписать вот этим и займусь. Но и БД нужно переделывать (и в ней есть огрехи и платформа меня не устраивает). Да и жизнь требует новой реализации.
F>Ситуация:
F>1. Работа по локалке.
F>2. Работа удалённых клиентов (отделения в разных городах), так же подходит вариант периодической репликации.
F>Тем не менее и потребности новых задач будут. Вот и хочу удобную среду себе. Так или иначе планирую разрабатывать на дотнете. Вот и вопрос... стоит ли использовать веб-сервисы. Т.е. никто из клиентов не будет работать с БД напрямую. Хочется апп-сервер. Или лучше смотреть в сторону толстого клиента?

А платформа, на основе которой вы собираетесь строить архитектуру системы?

С уваженеим,
bw.

Здравствуйте, <Аноним>, Вы писали:

А>А платформа, на основе которой вы собираетесь строить архитектуру системы?
.NET
Сервер однозначно Windows 2003.
Сервер БД — либо на нём же, либо Linux (если это будет не MSSQL).

Здравствуйте, fddima, Вы писали:

F>Здравствуйте, stasukas, Вы писали:

S>>Думаю, что от AppServer тут не отказаться — реализация на ES. К нему прикручиваем толсого клиента для локалки, а для "дальних родственников" можно прикрутить WS.
F> ES? Это что такое?
EntepriceServices

Здравствуйте, stasukas, Вы писали:

S>>>Думаю, что от AppServer тут не отказаться — реализация на ES. К нему прикручиваем толсого клиента для локалки, а для "дальних родственников" можно прикрутить WS.
F>> ES? Это что такое?
S>EntepriceServices
Уже понял. Ладно, видимо нужно курить план и пробовать реализовать прототип.

А>>А платформа, на основе которой вы собираетесь строить архитектуру системы?
F> .NET
F> Сервер однозначно Windows 2003.
F> Сервер БД — либо на нём же, либо Linux (если это будет не MSSQL).
Если будут использоваться веб-сервисы под ASP.NET, тогда не обойтись без промежуточного слоя в силу специфики ASP.NET

С уважением,
bw.

Здравствуйте, <Аноним>, Вы писали:

F>> .NET
F>> Сервер однозначно Windows 2003.
F>> Сервер БД — либо на нём же, либо Linux (если это будет не MSSQL).
А>Если будут использоваться веб-сервисы под ASP.NET, тогда не обойтись без промежуточного слоя в силу специфики ASP.NET
А если по-подробнее?!

Веб сервисы — рулез Особенно когда надо разговаривать с SUN, TIBCO и прочими гиморами.
Enterprise Services — не сильно хорошо. В основном дает декларативный язык описания трансакций — гимор и Queued Components.

Для разделенных/удаленных систем лучше трансакции прописывать самому, т.к. тут основной геморрой в том, что ms sql любит короткие трансакции, а в случае разделенной системы короткие трансакции не сильно получаются — будет например висеть lock на целую таблицу пока с удаленного клиента будет скачиватся метровый xml файл по 56k — не кошерно.

Оракл, с другой стороны, любит длинные трансакции, но не дружит с дот нетом. В частности сильно не дружит с DTC, на котором все эти трансакции и базируются. Плюс, все эти автоматические трансакции базируются на .NET Connection Pooling над которым в 1.1 нет никакого контроля. В 2.0 вроде бы обещают, но когда он появится этот 2.0? и когда его можно начинать использовать в production?

Вывод в общем такой: веб сервисы использовать стоит Это действительно легко и удобно. Но без трансакций

Здравствуйте, B0rG, Вы писали:

BG>Веб сервисы — рулез Особенно когда надо разговаривать с SUN, TIBCO и прочими гиморами.
Пожалуй разговаривать с богами солнец я не буду. А что такое TIBCO так и не знаю... Так что тут проще. А насчёт рулез — дааааааа! Чем больше ковыряю, тем больше нравится, но пока прототип еще не сделал — немогу никаких выводов сделать.

BG>Для разделенных/удаленных систем лучше трансакции прописывать самому, т.к. тут основной геморрой в том, что ms sql любит короткие трансакции, а в случае разделенной системы короткие трансакции не сильно получаются — будет например висеть lock на целую таблицу пока с удаленного клиента будет скачиватся метровый xml файл по 56k — не кошерно.
Ну может можно сначала залить xml файл, а потом уже его обрабатывать?!

BG>Оракл, с другой стороны, любит длинные трансакции, но не дружит с дот нетом. В частности сильно не дружит с DTC, на котором все эти трансакции и базируются. Плюс, все эти автоматические трансакции базируются на .NET Connection Pooling над которым в 1.1 нет никакого контроля. В 2.0 вроде бы обещают, но когда он появится этот 2.0? и когда его можно начинать использовать в production?
Насчёт 2.0 — то я думаю в этом году уже можно будет

BG>Вывод в общем такой: веб сервисы использовать стоит Это действительно легко и удобно. Но без трансакций
Вопрос — ну где, ну где такое слово? Где? Вроде оно практически у всех — транзакция...

Здравствуйте, B0rG, Вы писали:

BG> будет например висеть lock на целую таблицу пока с удаленного клиента будет скачиватся метровый xml файл по 56k — не кошерно.
А кому нужна транзакция на скачивание xml-файла? Транзакция нужна когда идет обработка логики по полученным данным, а здесь уже можно сделать ее достаточно короткой практически всегда.

Здравствуйте, Merle, Вы писали:
BG>> будет например висеть lock на целую таблицу пока с удаленного клиента будет скачиватся метровый xml файл по 56k — не кошерно.
M>А кому нужна транзакция на скачивание xml-файла? Транзакция нужна когда идет обработка логики по полученным данным, а здесь уже можно сделать ее достаточно короткой практически всегда.

Судя по оценкам мнения разделились.
В случае распределенных трансакций — нужна.
Например тот же самый веб шоп. У Вас трех-звенка:
1. Front-End
2. Middleware
3. your Database

4. Credit Card Webservice.

Удобнее всего гнать транзакцию с номера 2. Т.к. 4. часто бывает сильно удаленным, трансакция получается распределенной. Вот Вам и закачка большого xml файла между участками 2/3 и 4. Домыслить остальное предоставляется читателю в качестве самостоятельно упражнения.

Здравствуйте, fddima, Вы писали:

BG>>Веб сервисы — рулез Особенно когда надо разговаривать с SUN, TIBCO и прочими гиморами.
F> Пожалуй разговаривать с богами солнец я не буду. А что такое TIBCO так и не знаю... Так что тут проще. А насчёт рулез — дааааааа! Чем больше ковыряю, тем больше нравится, но пока прототип еще не сделал — немогу никаких выводов сделать.

Лучше Вам и не знать. Мне тоже лучше не знать. Хотя с точки зрения job security можно и подучить

F> Ну может можно сначала залить xml файл, а потом уже его обрабатывать?!

Распределенная трансакция — читайте предыдущий мессаг.

F> Насчёт 2.0 — то я думаю в этом году уже можно будет

Если Вы любите играться с новыми технологиями — это очень полезно и хорошо. Я же люблю получать деньги за то, что делаю работающие продукты в срок и качественно. На проверенных технологиях.

F> Вопрос — ну где, ну где такое слово? Где? Вроде оно практически у всех — транзакция...

Не занудствуйте — для здоровья, говорят, плохо. Сам то я не проверял, конечно.

Здравствуйте, B0rG, Вы писали:

BG>Если Вы любите играться с новыми технологиями — это очень полезно и хорошо. Я же люблю получать деньги за то, что делаю работающие продукты в срок и качественно. На проверенных технологиях.
Я предпочитаю работать с новыми технологиями. А насчёт проверенных — так разработку можно начинать уже, а ввод системы в рабочий стан в ближайшие пол года не планируется. Хм. Мне было бы даже привычно взять дотнет 1.1, но уж хочется вкусности.

F>> Вопрос — ну где, ну где такое слово? Где? Вроде оно практически у всех — транзакция...
BG>Не занудствуйте — для здоровья, говорят, плохо. Сам то я не проверял, конечно.
Я просто поинтересовался почему так.

Здравствуйте, B0rG, Вы писали:

BG>Судя по оценкам мнения разделились.
Да не разделились, тот минус был скорее политический, иначе Мика рискнул бы изложить свои соображения...

BG>В случае распределенных трансакций — нужна.
Распределенные транзакции — это отдельная пестня, ну допустим нам приспичило делать их с помощю Web-сервисов...

BG>Например тот же самый веб шоп. У Вас трех-звенка:
BG>1. Front-End
BG>2. Middleware
BG>3. your Database

BG>4. Credit Card Webservice.

BG>Удобнее всего гнать транзакцию с номера 2. Т.к. 4. часто бывает сильно удаленным, трансакция получается распределенной.
Да не факт, удобнее разделить это на несколько транзакций.
1. заказ переводится в сосояние "ожидание оплаты" (2-3)
2. запрос на авторизацию кредитки через Web-сервис (2-4)
3. в случае успеха перевод заказа в состояние "ожидание отгрузки" и сообщения об этом радостном известии юзеру (3-2)
3а. в случае неуспеха заказ остается в состоянии "ожидание оплаты" и сообщается об этом печальном событии юзеру с просьбой повторить ввод.

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

BG>Вот Вам и закачка большого xml файла между участками 2/3 и 4.
Только 2-4 DB, таким образом, остается не затронутым и спокойно работает в привычном режиме.

BG> Домыслить остальное предоставляется читателю в качестве самостоятельно упражнения.
Еще примеры необходимости XML траффика в транзакции есть?

Здравствуйте, Merle, Вы писали:

M>Никакой необходимости делать все в одной большой транзакции нет, однако с точки зрения юзера все выглядит так, как буд-то транзакция одна и большая.

Это я все к тому, что, как правило, нет необходимости вовлекать БД в пользовательские транзакции (кроме как посредством пользовательских блокировок, которые аккурат для этого и предназначены), особенно если оные транзакции шибко длинные и распределенные.

Здравствуйте, fddima, Вы писали:

F>>> Вопрос — ну где, ну где такое слово? Где? Вроде оно практически у всех — транзакция...
BG>>Не занудствуйте — для здоровья, говорят, плохо. Сам то я не проверял, конечно.
F> Я просто поинтересовался почему так.

В силу своего геогрфического положения, говорю, думаю и пишу по английски. Переводить хорошо не всегда получается Это как раз один из тех случаев.