Я в этой сфере сфере новичок, так что не обессудьте:

Что такое Web Services?
Кокое отношение к этому имеет XML?

Программа, выдающая не HTML-ку, а XML-ку
Webservice может предоставлять какие-нибудь услуги в Inete, напр., доступ к какой-нибудь эксклюзивной БД.

ЗЫ: Чувствую, что скоро Kurt выдаст супер мега статью с примерами

Хех... У меня целых три курсовые по этой теме было написано.

В общем, изначально веб-сервисы задумывались, как средство организации межпрограммного вазимодействия или удаленного вызова процедур (RPC - Remote Procedure Call). Суть идеи RPC заключается в том, что одна запущенная программа может вызывать функции/процедуры другой программы, запущенной на этой же машине или на другой машине в сети. Позже к этой байде приплели объектный подход и получили Object RPC (ORPC).

В основе веб-сервисов лежит протокол SOAP (Simple Object Access Protocol - Простой Протокол Доступа к Объектам). Года четыре назад ао всех статьях по поводу этого протокола, расматривались такие технологии, как CORBA, COM/DCOM, явовский RMI и пр. Все эти технологий так или иначе реализоввывали идею RPC. Но у них были ряд проблем в области глобальных сетей. Потому Мелкософтными с рядом других крупных контор была предложеня идея SOAP.

SOAP является расширением протокола HTTP (хотя и это не факт! SOAP, как
утверждалось, может быть реализован на любом текстовом протоколе. Но в основном используется HTTP, потому его и будем рассматривать). HTTP запрос/ответ делится на 2 части, заголовок и тело. В заголовке передается всякая информация о самом запросе/ответе, в теле непосредственно передаваемые данные (всякие параметры запроса, или возвращаемые данные ответа). Расширение SOAP заключается в том, что немного изменен заголовок, идентифицирующий этот запрос, как SOAP запрос, а в теле передается XML текст, описывающий, что запрашивается или что возвращается. Вот она и связь с XML.

Потом от SOAPа перешли к идее Web-services. Чтобы проще, под веб-сервисом подразумевается предоставление определенных услуг web-узлом. Вот, например, услуга: складывание двух чисел . Суть - клиент передает два числа, сервер их складывает и возвращает клиенту. Причем под клиентом подразумевается любая программа, а не браузер. При создании же этой программы для програмиста все должно выглядить так, как будто он вызывает локальную функцию (метод объекта), например, s = obj.add(a, b). Но это зависит от реализации использования web-сервисов на том или ином языке/платформе.
И так, в веб-сервисах используется XML как формат передаваемых данных и SOAP, как протокол при помощи которого эти данные передаются. Кроме них, еще есть язык WSDL (Web Service Difinition Language), при помощи которого описываются сам сервис, то есть какие методы есть, какие параметры ему передаются, что он возвращает и пр. Есть еще UDDI (не помню, как расшифровывается), эта штука позволяет находить веб-сервисы в сети.
Результатом всего сказаного, можно сказать:
Web Services = XML + SOAP + WSDL + UDDI.

Надо сказать, что мелкософтные в ASP.NET пошли немного дальше, и у них (хотя может быть и не только у них ) возможно работать с веб-сервисам без использования протокола SOAP, а только HTTP, хотя и с рядом ограничений. Вот, примерно и получается то, что сказал stron:

Цитата

Программа, выдающая не HTML-ку, а XML-ку

Однажды, в одной книге по .NET прочитал, что веб-сервис - это объект предоставляемый методы, которые можно вызвать удаленно по сети Интернет. При поверхностном рассмотрении, это так. При создании веб-сервисов на ASP.NET, особенно с Visual Studio, этому утверждению и следуют. Создавать веб-сервисы на ASP.NET действительно очень легко. Примеры я давать не мастер. Тут и правда, Kurt может помочь.

Это сообщение отредактировал(а) Tomcat - 17.11.2004, 11:18

OK, кажется понял что-то. Большое спаибо.

Тогда, такие вопросы:
1. Т.е. если я хочу предоставлять кому-либо услуги по сложению двух чисел , то я должен написать фактически две программы: одну - непосредственно сервис, который будет выполняться на каком-либо компьютере в сети (например, на сервере в Интернете), и вторую, которая будет предоставляться пользователю. Пользователь качает эту прогу, ставит, запускает, подключается и складывает числа до позеленения. Так?

2. А что, можно реализовывать пользовательскую часть и не отдельной программой, а предоставить возмжность доступа к сервису через браузер? Апплеты что-ли?

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

4. По поводу получаемой информации: получатся, что от сервиса я могу получить информацию только в XML?

Цитата

ЗЫ: Чувствую, что скоро Kurt выдаст супер мега статью с примерами

Опередили, блин. А я тут сижу строчу, хорошо, на форум догадался заглянуть

Цитата

возможно работать с веб-сервисам без использования протокола SOAP, а только HTTP, хотя и с рядом ограничений.

Угу. Через HTTP-POST и HTTP-GET можно передавать лишь:
1) строковые значения;
2) простые массивы (но НЕ пользовательский типов);
3) перечисления.
Все. Остальное - тока через SOAP. Однако, этот протокол поддерживает большинством совеременных сред и языков программирования, как-то .NET-языки, Java, PHP, Perl, Delphi etc.

Цитата

Т.е. если я хочу предоставлять кому-либо услуги по сложению двух чисел  , то я должен написать фактически две программы

Не факт. Не забывай про description service - ты можешь написать лишь сам сервис и опубликовать его в сети, а другие программеры напишут к нему своих клиентов на всевозможных платформах.
Например, ты напишешь сервис, к-й выдает прогноз погоды в данном городе. Другие программеры используют этот ресурс в своих приложениях, к-е могут быть консольными, WinForms, а также с веб-интерфейсом. Короче, какие хочешь.
Ну, конечно, ты можесь сделать и клиента. Однако, не забывай, что твой "клиент" может быть лишь ссылкой на странице (т.е. обращаешься по протоколу HTTP-GET), хотя, ессно, для пользователя очень неудобно получать ответ в XML-формате, нужен клиент, к-й проанализирует этот XML и выдаст результат в приятной т понятной форме.

Цитата

2. А что, можно реализовывать пользовательскую часть и не отдельной программой, а предоставить возмжность доступа к сервису через браузер? Апплеты что-ли?

Клиент все равно нужен (однако, как я уже сказал, вся его реализация может заключаться в формировании ссылки..). Апплеты тут не причем. Я бы сравнил это с программированием на серверных языках типа PHP. Т.е. сервер генерирует XML и отсылает клиенту. Дальше - это личное дело клиента, как он отоьразит эту информацию.

Цитата

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

Да. Я бы назвал это разделением труда. Одни занимаются сервисами, другие - используют их как кирпичики в своих приложениях. Пример - Майкрософтовский .NET-Passport - система аутентификации пользвателей.

Цитата

4. По поводу получаемой информации: получатся, что от сервиса я могу получить информацию только в XML?

Насколько я знаю - да. Это позволяет обойти всякие firewall'ы и прочие трудности.

Цитата

Примеры я давать не мастер. Тут и правда, Kurt может помочь.

Пример.. Пример.. Ладно, пусть будет то самое сложение чисел.
Открываем VS (руководства по написанию сервисов на других ЯП спрашивать в соотв. разделах форума). Создаем новый проект, при этом IIS должен быть запущен. Выбираем "ASP.NET WebService".
Для работы с web-сервисами на .NET-платформе используется пространство имен System.Web.Services, и, создав сервис средствами VS, можно заметить, что наш сервис будет наследником от System.Web.Services.WebService, что, однако, не является необходимым условием - можно создать сервис и на основе System.Object, просто WebService обеспечивает набор очень полезных методов, что позволяет облегчить разработку.
VS создала для нас след. файлы:
1)*.asmx - файл в формате WSDL. Автоматически генерируется VS.
2)*.asmx.cs - собственно, реализация сервиса
3)*.disco - описание web-службы. Перед тем как использовать службу, клиент долен убедиться, что сервис действительно существует по данному адресу.

Итак, добавляем наш метод. В файле Service1.asmx.cs добавляем в класс Service1 строки:

Код

[WebMethod]  public int SuperAdd(int value1, int value2)  {   return value1+value2;  }

WebMethod указывает на то, что это метод сервиса. Там можно еще кучу свойств указывать типа описания метода и т.п., но сейчас это не важно.
Итак, у нас есть сервис, к-й складывает два целых числа.
Откомпилим этот проект. Теперь или просто запустим (откроется броузер) или откроем вручную броузер (я предпочитаю этот вариант) и в строке адреса укажем:

Цитата

http://localhost/serviceTest0/service1.asmx

(я свой проект назвал serviceTest0)
Появится описание сервиса (WSDL-описание можно посмотреть по ссылке "Service Description" справа вверху. Именно его будут использвать клиенты в своих приложениях), а также описание публикуемых методов, где ма не без удивления обнаружим наш SuperAdd.
Кликнув по ссылке, получим описание метода, как к нему обращаться через HTTP-POST и SOAP, а также прилашение опробовать метод в действии - а именно, два текстовых поля, куда можно ввести целые (!) числа.
Введем, например, 2 и 3 и жмем Invoke. Откроется новое окно броузера с таким текстом:

Цитата

<?xml version="1.0" encoding="utf-8" ?>   <int xmlns="http://tempuri.org/">5</int>

Это и есть ответ сервера. Именно этот текст будут анализировать клиенты.
Теперь добавим в наш проект возможность складывать вещественные числа:

Код

[WebMethod]  public float SuperAdd(float value1, float value2)  {   return value1+value2;  }

Все хорошо, все компилится, но при запуске получаем ошибку:

Цитата

Both Single SuperAdd(Single, Single) and Int32 SuperAdd(Int32, Int32) use the message name 'SuperAdd'

Произошла ошибка на уровне SOAP. Методы имеют одинаковые имена! Для устранения этой беды используем, как и предлагается, аттрибут MessageName. Заодно опробуем и аттрибут Description, весьма полезный при практическом использовании:

Код

[WebMethod(Description="My super ADD!!!", MessageName="Add our floats")]  public float SuperAdd(float value1, float value2)  {   return value1+value2;  }

Теперь все будет ОК.
...
Два слова о клиентах.
При разработке клиента нужно уметь передавать данные по протоколу SOAP, как сказано при описании Вашего сервиса. Формировать SOAP-запрос довольно тяжело, поэтому при разработке .NET-клиента испольуется понятие прокси-сборки. Т.е. генерируется сборка, к-я преобразует вызовы клиента в SOAP и отсылает на сервер. Клиент же работает с "удаленной" сборкой так, как будто она расоложена на его же машине.
Такая прокси-сборка формируется с помощью утилиты wsdl.exe, однако, при использовании VS, такая сборка генерируется автоматически с одним НО: при VS генерирует прокси-сборку, к-я может общаться лишь по SOAP-протоколу (в отличие от wsdl.exe, где протокол можно указать вручную). Хотя, надо признать, такое решение оправданно - в большинстве случаев SOAP - оптимальный вариант.
Итак, создадим консольного клиента.
Первым делом создаем прокси-сборку:
Project->Add WebReference.
Там вписываем наш URL (http://localhost/serviceTest0/service1.asmx) и жмем "Add Reference". В итоге получаем сборку с именем, соответсвующим имени сервера, где расположен сервис. В нашем случае - localhost.
Теперь пример использования этой сборки. Это очень простой код, на деталях я останавливаться не буду. Зочу лишь заметить, что реально сложение обрабатывается сервером, а не клиентом:

Код

localhost.Service1 myservice= new localhost.Service1();   Console.WriteLine(myservice.SuperAdd(5,6));

Т.е. мы сначала создаем обеъкт, а потом используем его методы.
Ну, и на последок о пользовательский типах.
Чтобы сервис мог работать с пользвательскими типами, их следует определить в том же namespace'е, что и сервис, только перед определением указать:

Код

.. using System.Xml.Serislization; .. [XmlInclude(typeof(MyType))] public class MyType { .. }

За сим все.
Мне кажется, для начала хватит.
Замечу лишь, что к нашему сервису отлично пишется клиент на Delphi и др. ЯП.

Да, а как же искать веб-сервисы? Правильно ли я понимаю что должны существовать сайты-каталоги с описаниями публичных сервисов? И как используется UDDI ?