Какая разница между веб-сервисом и веб-приложением? Где применяется одна технология, где другая. Какие инструменты нужно использовать для запуска того и другого?
Желательно популярно, из жизни. Ссылки я и сам почитаю. 
Спасибо.  

Веб-сервис - это обеспечение приложением ответа в "веб-стандартах".

Утрировано, напишу вот плагин под Eclipse IDE, который возвращает список открытых Java файлов, и по конкретному имени - сам файл.
И раздам наружу IP и порт по которому можно достучаться.

Станет ли от этого Eclipse IDE веб приложением?

Т.е. веб-сервис - это тоже веб-приложение?

Редкий дом бывает без каких-либо окон.
Но окно - это еще не есть дом.

Веб-приложение обязано обеспечить передачу view в станадратах веба (то есть HTML) на клиент.
Иначе сложно будет назвать его - веб-приложением.
Но НЕ обязано предоставлять веб-сервисы.

Пример:
Twitter. Зашел браузером - и порядок.
Но он еще и предоставляет НЕ браузерам возможность работы - чтение и изменение данных.
Отсюда и всякие клиенты для него.

Но и не веб приложение, то есть НЕ предоставляющее передачу view клиенту может быть оснащено веб-сервисом.
Например фронт-энд к SQL серверу. 

Если лишить Twitter работы с веб браузером - вряд-ли его можно будет называть веб-приложением.
Но все клиенты типа twhirl будут ведь продолжать работать с ним.

С веб-приложением более менее все понятно. Есть лоигика, базы на стороне сервера, ты обрабатываешь и отправляешь в браузер хтмл, скрипт. Сервер разворачивается на томкате, джетте или на чем то более сложном.
Веб сервис. Я только понимаю, что он отправляет по некоему XML стандарту информацию тому, кто ее запросил. В частности это может быть и браузер, принимающий XML, как я понимаю. В таком случае он мало чем отличается от веб-приложения.  Но получается, что ему не сильно нужен томкат, ему просто нужен инструмент, который будет правильно передавать и принимать хмл... (axis, jax-ws, rest). 
Как работает веб сервис?


Это сообщение отредактировал(а) priam220 - 19.9.2011, 14:42

Стандартов несколько.

Общее у них, они основаны на HTTP протоколе (или его вариантах в виде REST ). Поэтому и названы - веб сервисами.
Внутри же может быть и XML-RPC, и JSON и еще че-нить.



Ты ему:
ДАЙ!
он тебе:
ДЕРЖИ


В таком случае окно мало чем отличается от дома.

N.B.
Не перестаю удивляться - почему у современных программистов так плохо с абстрактным мышлением?
Есть 2 завода.
На них крутятся сервера, предоставляющие веб-сервисы для управления технологическими линиями.
Обмениваются друг с дружкой информацией.

Эти сервера - веб-приложения?

Это сообщение отредактировал(а) Skynin - 19.9.2011, 15:08

Вэб-приложение работает с броузером. Вэб-сервис - с другими приложениями и сервисами. Веб-сервисы используют для взаимодействия RPC-вызовы, базирующиеся на XML. Например SOAP протокол. Еще имеют возможность предоставлять програмный интерфейс WSDL, на базе которого можно генерировать Java-классы (или на любом другом языке) заглушки, для вызова методов сервиса.

Это сообщение отредактировал(а) Sun - 19.9.2011, 15:24

Skynin, спасибо за помощь. С абстракцией вроде все впорядке, ну или почти все.  


Просто я вижу веб-приложение как клиент-серверную реализацию. SOA - как альтернативу к-с реализации. Ты же говоришь, что сервис - это составляющая веб-приложения. 


это как?

Добавлено @ 15:18


а разве нельзя сделать так, что бы сервис работал напрямую с браузером? Или можно, но не нужно.. 

Это сообщение отредактировал(а) priam220 - 19.9.2011, 15:20

Можно. Некоторы веб-сервисы предоставляют HTML-формы ввода, где заполнив определенные поля, можно получить ответ от сервера в виде XML.

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

Это сообщение отредактировал(а) Sun - 19.9.2011, 15:26

Прошу привести цитату где я такое сказал.


HTTP (сокр. от англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом. 
HTTP

Что ты обернешь в HTTP, твое дело.


Бразуер ожидает - HTML (или код который его будет генерить)
Понимает конечно и простой текст, и XML

Поэтому конечно можно.
Например веб сервис предоставляющий список какие-то текстовые данные.
Ты ему ссылкой в браузере
дай список
Он тебе текст
ID=234fsdT43T543T54T;"Ляляляля"
ID=fghgfhftyu756674w;"Люлюлю"

Ты пишешь чуток другую ссылку, добавлешь к ней fghgfhftyu756674w, жмешь энтер, и получаешь на экран свой текстовый файл
Люлюлю
Место ID32535353
Качество IDdsgdfgd

Опять пишешь чуток другую ссылку, добавляешь ID32535353
И получаешь:
Урюпинск

Нравится так работать?

Но обычно делают на стороне сервера проверку, а кто клиент.
1. Ежели браузер, то держи HTML
2. Если иной, возможно специально оговеренный, держи ID=234fsdT43T543T54T;"Ляляляля"

Второй функционал для веб-приложения - необязателен.
Первый необязателен для сервера чего либо, приложений, данных, датчиков, ...

И необязательны одинаковые ссылки для доступа. То есть проверки "кто клиент" может и не быть.
Зашел по одной ссылке, например начинающейся с www - получил HTML
Зашел начинающейся с - data, получи ID....

P.S.
Кстати, самым известным и частым веб-сервисом является RSS
Человеку конечно понятно, что он возвращает.
Но гораздо удобней когда сама программа из этих данных делает удобочитаемое.
Это может быть программой внутри браузера, как в Opera, может быть выполнена в виде веб-страниц, как Google reader, может быть внешней как RSSOwl

Но суть - RSS сервис возвращает НЕ html. А нечто специализированное и стандартизированное.
Но завернутое в HTTP стандарт обмена.

Трудно представить себе, зачем может понадобиться сервер с RSS но без WWW (отдачи HTML), но ничто не мешает сотворить и такой.
Будет ли такой сервер, без возможности получения html считаться веб-приложением?

Это сообщение отредактировал(а) Skynin - 19.9.2011, 15:42

не, ну про окна и дом... Я понял, что окно - сервис, это составляющая дома, - веб-приложения.  

Skynin,  но ведь xml не обязательно передавать по http! 

1. Получается так, что вебсервису вовсе не нужен томкат. Сервлет получает запрос от клиента, создает хмл, передает сервису, который находится локально сгенеренный хмл, получает ответ от сервиса, обрабатывает его возможно при помощи другого сервиса и отправляет на браузер... так?

2. В чем разница между Axis (я так понял уже не используется), axis2 и jax-ws?

Перечитайте что я написал гипотетически про Twitter.

И ответьте на вопрос - без отдачи HTML контента - считается веб приложением, или нет?


Не обязательно.

Но тогда этот сервис не будет называться - веб-сервисом.


Нужто только соблюдение HTTP стандартов.
Хотите сами реализуйте. Хотите Томкат или Jetty ставьте.


В оформлении xml завернутых в http протокол.

Apache Axis is an implementation of the SOAP ("Simple Object Access Protocol") submission to W3C.
The Java API for XML Web Services (JAX-WS) is a Java programming language API for creating web services.

A Web service is a method of communication between two electronic devices over a network.
Web_service
Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

Дело в том, что куча сетевого оборудования понимает http стандарты.
Особенно усякие файрволы, NATы и прочая.

А если будете конектится напрямую по TCP, да на особые порты, то как бы не пришлось пострадать немножко.


Это сообщение отредактировал(а) Skynin - 19.9.2011, 16:03

Мм... "Обычное" веб приложение является  сервисом с точки зрения REST. ^_^

Вебсервисы ориентированы на работу с "роботами" (программами), потому имеют определённый формальный протокол.
А обычное веб приложение ориентировано на работу с людями. Там тоже протокол, только неформальный. Как хочешь, так и проводи черту.)

Спасибо, дальше попробую сам.

Именно так. 
Глянуть только на содержимое SOAP от Microsft - так Brainfuck покажется детским лепетом 

Но, вручную кто ж пишет веб-сервисы, библиотек и фреймворков тьмы.