Почему мир активно переходит на данный тип приложений? Что ещё, кроме простого доступа и сопровождения, заставляет людей выбирать именно этот тип архитектуры?
Здравствуйте, Mishka, Вы писали:
M>Почему мир активно переходит на данный тип приложений? Что ещё, кроме простого доступа и сопровождения, заставляет людей выбирать именно этот тип архитектуры?
"-- Шо? Уси?" (c) Анекдот
Что — прям так "мир переходит"? Думаю, надо сперва все же посмотреть, в каких областях переходит. Пока я не видел Web-Word и Web-Quake
Выявив интересующий тебя класс приложений (по предметному делению) уже можно думать. Возможно, для таких приложений простой доступ и суппорт дает очень большие преимущества по сравнению с плюсами standalone приложений.
Так что расскажи нам — о каких приложениях идет речь и мы сообща подумаем...
Здравствуйте, Igor Trofimov, Вы писали:
IT>Так что расскажи нам — о каких приложениях идет речь и мы сообща подумаем...
Так вот в том-то и дело, что приложение в моём случае должно быть доступно только в интранет, deployment кончено проблема, но не сильно большая, но начальство упорно требует web-based application. Потому хотелось бы знать такую вещь — что ещё такого хорошего в web, что его так любят?
Возможно, речь идет о какой-то корпоративной системе. Можешь поподробнее рассказать?
Если компания большая, то работа через web действительно может очень здорово облегчить саппорт и обновления.
Ну, и, наконец, не исключен вариант, что "начальник хочет web"
Я не думаю, что из этого случая уже следует, что "мир активно переходит"
Корпоративные системы — вообще особая вещь.. Там и Java очень здорово прижилась, например.
Здравствуйте, Mishka, Вы писали:
M>Почему мир активно переходит на данный тип приложений? Что ещё, кроме простого доступа и сопровождения, заставляет людей выбирать именно этот тип архитектуры?
А объясните мне популярно что это вообще такое. Про web-based application приходится постоянно слышать, а о чём конкретно идет речь непонятно. Если не трудно, можно парочку типичных задач, решаемых при помощи веб-приложений.
Здравствуйте, Денис Майдыковский, Вы писали:
ДМ>А объясните мне популярно что это вообще такое. Про web-based application приходится постоянно слышать, а о чём конкретно идет речь непонятно. Если не трудно, можно парочку типичных задач, решаемых при помощи веб-приложений.
Здравствуйте, AndrewVK, Вы писали: ДМ>>А объясните мне популярно что это вообще такое. Про web-based application приходится постоянно слышать, а о чём конкретно идет речь непонятно. Если не трудно, можно парочку типичных задач, решаемых при помощи веб-приложений.
AVK>www.rsdn.ru
Большое спасибо за исчерпывающий и информативный ответ.
Здравствуйте, Денис Майдыковский, Вы писали:
ДМ>А объясните мне популярно что это вообще такое. Про web-based application приходится постоянно слышать, а о чём конкретно идет речь непонятно. Если не трудно, можно парочку типичных задач, решаемых при помощи веб-приложений.
Ну это смотря что понимать под веб-приложение, или лучше под понятием web-сервис.
Я читал такое определение, что web-сервис, это некая хреновина (сервис), которая доступна через инет. По этому принципу любую задачу можно переложить на web-сервис.
Здравствуйте, Dima2, Вы писали:
D>Ну это смотря что понимать под веб-приложение, или лучше под понятием web-сервис. D>Я читал такое определение, что web-сервис, это некая хреновина (сервис), которая доступна через инет. По этому принципу любую задачу можно переложить на web-сервис.
Далеко не любую. Насколько я понял из MS-ких проспектов и брошюр веб-сервис в конечном итоге сводится к вызову статической функции через инет. При этом все параметры и результат передаются через инет в текстовом (о ужас!) виде как XML. Но это не самое страшное. Веб-сервисы, как я понимаю, state-less, то есть понятие постоянного объекта (на сервере) отсутствует как таковое.
А вот что сейчас принято понимать под веб-приложением так и осталост в туманных догадках.
Здравствуйте, Денис Майдыковский, Вы писали:
ДМ>Далеко не любую. Насколько я понял из MS-ких проспектов и брошюр веб-сервис в конечном итоге сводится к вызову статической функции через инет. При этом все параметры и результат передаются через инет в текстовом (о ужас!) виде как XML. Но это не самое страшное. Веб-сервисы, как я понимаю, state-less, то есть понятие постоянного объекта (на сервере) отсутствует как таковое.
Я дал более общее определение.
Ты можеш сам написать некий сервис в котором будет все что ты хочеш.
Но вот вопрос что отличает обычный сервис от веб-сервиса, я думаю такие признаки:
— работа через инет (доступность откуда угодно)
— возможность представления и изменения данных через веб-браузер, и соответсвенно возможность работы с таким сервисом с различных платформ. Однако это не исключает других представлений.
Здравствуйте, Dima2, Вы писали:
D>Я дал более общее определение.
Я лишь пытался цитировать по-памяти MS
D>Ты можеш сам написать некий сервис в котором будет все что ты хочеш.
Голыми ручками можно всё что угодно написать, хоть собственный сетевой протокол
А вот если взять готовую реализацию, то "свои" определения могут отличаться.
D>Но вот вопрос что отличает обычный сервис от веб-сервиса, я думаю такие признаки: D>- работа через инет (доступность откуда угодно) D>- возможность представления и изменения данных через веб-браузер, и соответсвенно возможность работы с таким сервисом с различных платформ. Однако это не исключает других представлений.
Так мы про веб-сервисы или про веб-приложения говорим?
Веб приложения — сплошной шайтан и http. Поверьте веб разработчику.
Я проверяю приложения веб оно или не веб так: открываю в фаре исходники и делаю поиск по ключам http и www.
1. Есть оба — продвинутое веб приложение.
2. Есть http, но нет www — кулхацкерное интранет приложение.
3. Есть www, но нет http — исходники мозиллы.
4. Нету ничего — рулезнное станд алоне НЕ веб приложение. Типа нотепада.
Здравствуйте, Денис Майдыковский, Вы писали:
ДМ>Здравствуйте, Mishka, Вы писали:
M>>Почему мир активно переходит на данный тип приложений? Что ещё, кроме простого доступа и сопровождения, заставляет людей выбирать именно этот тип архитектуры?
ДМ>А объясните мне популярно что это вообще такое. Про web-based application приходится постоянно слышать, а о чём конкретно идет речь непонятно. Если не трудно, можно парочку типичных задач, решаемых при помощи веб-приложений.
Вот пример:
Есть некая скандинавская страховая контора. Ей хочется влезть на новый рынок: маленькая но гордая Прибалтика, Россия, ...
Платить за большие оффисы с кучей народа в десятке-другом городов этой конторе не хочется.
Что они делают? Они снимают маленькую комнатушку, сажают туда секретаршу с телефоном и компутером. Секретарша получает заказ (запрос) и вбивает его в компутер (кто, где, когда, зачем, кому...) и нажимает кнопочку ОК. Заказ идет через и-нет на сервер. Страховой агент с ноутбуком и мобильным телефоном (с GPRS, WAP) мотается по всей стране. Сделал одно задание — полез браузером в инет, авторизировался, получил следующее. Я сумбурно излагаю, но надеюсь суть ясна.
Еще пример — заказать билет на смолет SAS можно через WAP.
Еще есть какая-то американская фирма занимающаяся прокатом автомобилей по всей стране. Ситуация аналогична первому примеру...
Здравствуйте, Шура, Вы писали:
Ш> Есть некая скандинавская страховая контора. Ей хочется влезть на новый рынок: маленькая но гордая Прибалтика, Россия, ... Ш> Платить за большие оффисы с кучей народа в десятке-другом городов этой конторе не хочется. Ш> Что они делают? Они снимают маленькую комнатушку, сажают туда секретаршу с телефоном и компутером. Секретарша получает заказ (запрос) и вбивает его в компутер (кто, где, когда, зачем, кому...) и нажимает кнопочку ОК. Заказ идет через и-нет на сервер. Страховой агент с ноутбуком и мобильным телефоном (с GPRS, WAP) мотается по всей стране. Сделал одно задание — полез браузером в инет, авторизировался, получил следующее. Я сумбурно излагаю, но надеюсь суть ясна. Ш>Еще пример — заказать билет на смолет SAS можно через WAP. Ш>Еще есть какая-то американская фирма занимающаяся прокатом автомобилей по всей стране. Ситуация аналогична первому примеру...
Спасибо за разъяснениние. Короче это что-то типа форумов, интернет-магазинов но для "своих".
Я сейчас занимаюсь обработкой мультимедией (обработка изображений, видео) и с ужасом представляю как "мои" мегабайтные потоки данных рано или поздно придётся перекладывать на ресльсы веба. Всё равно кому-то взбредёт в голову удалённо печатать обложки для CD или поздравительные открытки или плакаты/календари. А там и до видео недалеко...
Здравствуйте, Денис Майдыковский, Вы писали:
ДМ>Здравствуйте, Шура, Вы писали:
[]
ДМ>Спасибо за разъяснениние. Короче это что-то типа форумов, интернет-магазинов но для "своих".
Это называется корпоративная система, если не ошибаюсь. А еще есть такой термин как ERP (Enterprise Resourse Planning), почитайте, это интересно.
ДМ>Я сейчас занимаюсь обработкой мультимедией (обработка изображений, видео) и с ужасом представляю как "мои" мегабайтные потоки данных рано или поздно придётся перекладывать на ресльсы веба. Всё равно кому-то взбредёт в голову удалённо печатать обложки для CD или поздравительные открытки или плакаты/календари. А там и до видео недалеко...
Угу. Но пугаться еще рано Такие аббривеатуры как VML, VXML, MML Вам знакомы?
ДМ>Спасибо за разъяснениние. Короче это что-то типа форумов, интернет-магазинов но для ДМ>"своих".
А так же КИС, B2B приложения и вообще любой подобного рода софт. Например, call desk для известной сети супермаркетов, или система взаимодействия вендора с дилерами и дистрибьютерами ну и т.п. Почему Web-приложение? Ну, например потому, что хочется использовать тонкого клиента — например, дилером конторы по продаже шоколадок и собачьего корма (реальный пример) в Мухосранске может быть какая-то баба Дуся, у которой 486-ой ноут с модемом 14400... IE 4.0 на этом вполне работает, и возможностей HTML + JScript вполне хватает для организации фронтенда. При этом бабе Дусе не надо ничего ставить, заморачиваться, администрировать... Вся бизнес-логика работает на сервере, клиент занимается только отображением и, иногда, вводом данных. Далее, разработка Html-гуя довольно дешева, и, зачастую, довольно успешно аутсорсится.
ДМ>Я сейчас занимаюсь обработкой мультимедией (обработка изображений, видео) и с ужасом ДМ>представляю как "мои" мегабайтные потоки данных рано или поздно придётся перекладывать на ДМ>ресльсы веба. Всё равно кому-то взбредёт в голову удалённо печатать обложки для CD или ДМ>поздравительные открытки или плакаты/календари. А там и до видео недалеко...
Почему с ужасом? Хм... каждой технологии место там, где ей есть место... Черт его знает.
Есть тенденция переходить от продажи софта к его аренде, или от продажи продукта к продаже услуг. Тут подобным технологиям, безусловно, место есть.
dmz>А так же КИС, B2B приложения и вообще любой подобного рода софт. Например, call desk для известной сети супермаркетов, или система взаимодействия вендора с дилерами и дистрибьютерами ну и т.п. Почему Web-приложение? Ну, например потому, что хочется использовать тонкого клиента — например, дилером конторы по продаже шоколадок и собачьего корма (реальный пример) в Мухосранске может быть какая-то баба Дуся, у которой 486-ой ноут с модемом 14400... IE 4.0 на этом вполне работает, и возможностей HTML + JScript вполне хватает для организации фронтенда. При этом бабе Дусе не надо ничего ставить, заморачиваться, администрировать... Вся бизнес-логика работает на сервере, клиент занимается только отображением и, иногда, вводом данных. Далее, разработка Html-гуя довольно дешева, и, зачастую, довольно успешно аутсорсится.
Но возможности интерфейса при этом довольно-таки ограничены. Несколько простейших контролов и всё. Для "запросов к базам данных" их может быть и хватает, но в случае простейшей (!) графической обработки происходит полный затык. Например, если пользователь должен выделить интересующую его область на изображении. Приходтся писать самопальный ActiveX, а они, как назло отнюдь не кросплатформены. Тут мы имеем все "прелести" Win32 API. Java-апплеты практически не могут взаимодействовать друг с другом и с клиентским JScript'ом, приходится всё приложение "засовывать" в один большой апплет, что резко ограничивает возможности дизайна. Вот и получается, что ограниченность интерфейса веб-приложений сводит их функциональность к "заполнению анкет".
ДМ>Но возможности интерфейса при этом довольно-таки ограничены. Несколько простейших ДМ>контролов и всё.
Угу. Но, правда, на DHTML можно сделать довольно много. Жаль, потерял URL компании, которая делает DHTML контролы — там было много всего... Полный джентельменский набор. Понятно, что работает не везде, но...
ДМ>Для "запросов к базам данных" их может быть и хватает, но в случае ДМ>простейшей (!) ДМ>графической обработки происходит полный затык. Например, если пользователь ДМ>должен ДМ>выделить интересующую его область на изображении. Приходтся писать самопальный ДМ>ActiveX, а они, как назло отнюдь не кросплатформены. Тут мы имеем все "прелести" Win32 ДМ>API. ...
Угу. Все так.
ДМ>веб-приложений сводит их функциональность к "заполнению анкет".
Не совсем. Довольно много чего можно сделать. Если же нужно больше,
чем возможно добиться на тонком клиенте, то всегда можно достучаться к тем же
сервисам из standalone-приложения.
Здравствуйте, Денис Майдыковский, Вы писали:
ДМ>Здравствуйте, dmz, Вы писали:
ДМ> dmz>>А так же КИС, B2B приложения и вообще любой подобного рода софт. Например, call desk для известной сети супермаркетов, или система взаимодействия вендора с дилерами и дистрибьютерами ну и т.п. Почему Web-приложение? Ну, например потому, что хочется использовать тонкого клиента — например, дилером конторы по продаже шоколадок и собачьего корма (реальный пример) в Мухосранске может быть какая-то баба Дуся, у которой 486-ой ноут с модемом 14400... IE 4.0 на этом вполне работает, и возможностей HTML + JScript вполне хватает для организации фронтенда. При этом бабе Дусе не надо ничего ставить, заморачиваться, администрировать... Вся бизнес-логика работает на сервере, клиент занимается только отображением и, иногда, вводом данных. Далее, разработка Html-гуя довольно дешева, и, зачастую, довольно успешно аутсорсится.
ДМ> ДМ>Но возможности интерфейса при этом довольно-таки ограничены. Несколько простейших контролов и всё. Для "запросов к базам данных" их может быть и хватает, но в случае простейшей (!) графической обработки происходит полный затык. Например, если пользователь должен выделить интересующую его область на изображении. Приходтся писать самопальный ActiveX, а они, как назло отнюдь не кросплатформены. Тут мы имеем все "прелести" Win32 API. Java-апплеты практически не могут взаимодействовать друг с другом и с клиентским JScript'ом, приходится всё приложение "засовывать" в один большой апплет, что резко ограничивает возможности дизайна. Вот и получается, что ограниченность интерфейса веб-приложений сводит их функциональность к "заполнению анкет".
Совсем недавно появился DirectX 9, который, если я не ошибаюсь, можно использавать вкупе с всеми остальными dotNET-овскими наворотами (я не специалист в этой области, так что могу наврать), что дает нам много интересных возможностей.
Насколько я понял из MS-ких проспектов и брошюр веб-сервис в конечном итоге сводится к вызову статической функции через инет. При этом все параметры и результат передаются через инет в текстовом (о ужас!) виде как XML. Но это не самое страшное. Веб-сервисы, как я понимаю, state-less, то есть понятие постоянного объекта (на сервере) отсутствует как таковое.
