Основные понятия Web-службы
Основы web-служб
Концепция, лежащая в основе функционирования web-служб, не нова. Существует множество и других сред программирования, которые базируются на принципе разделения приложений и функций между компьютерами по сети, позволяющем сделать работу их пользователей более эффективной и гибкой. Однако до сих пор ни одна из таких сред не приобрела широкой популярности, поскольку с их применением связаны две проблемы: внутренняя сложность системы и гетерогенная природа Интернета, связывающего компьютеры с разными операционными системами, сетями и платформами разработки.
История развития web-служб
История программирования в значительной степени представляет собой процесс перехода от небольших изолированных сред (таких как мэйнфреймы и автономные приложения) к более широкомасштабным и многокомпонентным системам, начиная от сетевого и клиент-серверного программного обеспечения и заканчивая Интернет -приложениями и распределенными приложениями.
Совместное использование кода приложениями
В начале 90-х годов прошлого века интерес разработчиков привлекали две соперничающие компонентные технологии: архитектура компонентной объектной модели (Component Object Model, СОМ) компании Microsoft и обобщенная архитектура построения брокеров объектных запросов (Common Object Request Broker Architecture, CORBA), представленная компанией OMG (Object Management Group). Обе эти технологии предоставляют функции, которые можно многократно применять как двоичные объекты, а также программное обеспечение для совместного использования кода на одном компьютере.
Однако по мере того как распределенные сети приобретали все более широкую популярность, возникла необходимость в обеспечении возможности взаимодействия отдельных компьютеров. Разработчики могли создавать собственные решения, воспользовавшись сокетами, хотя это требовало от клиентов и серверов выполнения достаточно тяжелой работы, а для кодирования и декодирования сообщений нужны были высокоуровневые протоколы. Но не только в этом состояло неудобство для разработчиков: их программы получались громоздкими и могли содержать множество ошибок.
Совместное использование кода на нескольких компьютерах
В середине 90-х годов компания Microsoft выпустила расширенную компонентную модель - DCOM ( Distributed СОМ ). Эта модель не являлась альтернативой или дополнением модели СОМ - в действительности она была лишь сетевым протоколом, определяющим способ взаимодействия СОМ -объектов различных компьютеров. Компания OMG также представила сетевой протокол, получивший название IIOP (Inter-ORB Protocol), который был разработан с целью обеспечения возможности совместной работы в Интернете отдельных объектов ORB CORBA.
Эти стандарты позволили приложению, запущенному на одном компьютере, использовать код, расположенный на другом компьютере. Но поскольку оба указанных стандарта являлись потомками стандартов разработки настольных приложений, они имели несколько уровней сложности, затрудняющих их применение (в частности, модель DCOM за это часто критиковали). Опытные разработчики считают, что эти протоколы сыграли положительную роль, обеспечив возможность создавать приложения, которые могут выполняться распределено на нескольких рабочих станциях, тем самым позволив подняться от разработки клиент-серверного программного обеспечения до так называемых 3-уровневых и n-уровневых приложений.
Совместное использование кода в различных сетях
К сожалению, ни COM/DCOM, ни CORBA/IIOP не функционировали должным образом в рамках Интернета. В частности, потому, что оба этих стандарта являются взаимно исключающими. Серверы DCOM могут взаимодействовать только с клиентами DCOM, стандарты CORBA и IIOP также имеют некоторые недостатки. Сфера применения DCOM ограничена компьютерами, оснащенными операционной системой Microsoft Windows. Модель CORBA, подобно СОМ, является сложным стандартом, не предназначенным для работы через брандмауэры. Таким образом, помимо необходимости адаптировать модели СОМ и CORBA для использования в сетевой среде, требовалось создать простые программные средства разработки распределенных приложений в сети Web.
Модель COM/DCOM
DCOM - это сетевой протокол, основанный на стандарте распределенной среды обработки DCE (Distributed Computing Environment). Достоинством протокола DCOM является используемая модель программирования. Этот протокол позволяет разработчикам применять СОМ - объекты на удаленном компьютере точно так же, как и на локальном (рис. 12.1). DCOM просто переносит локальную межпроцессную связь с помощью сетевого протокола. Вызов становится несколько более медленным, но ни клиенту, ни компоненту нет необходимости знать, что связь между ними осуществляется по сети. На рис. 12.1 показан многоуровневый протокол, позволяющий модели СОМ работать через сеть.
К сожалению, модель COM/DCOM не подходит для работы в распределенных сетях.
Применить DCОМ в сети приводит к большим издержкам из-за возникновения помех и большого количества отложенных сообщений. Очевидно, что применять DCОМ в сети Интернет тем более не имеет смысла, поскольку по мере роста числа клиентов в сети объем сетевого трафика увеличивается и необходимость обрабатывать большое количество запросов наносит серьезный вред всей системе. Таким образом, разработчики пришли к выводу, что протокол DCOM является принципиально не масштабируемым для обслуживания большого числа клиентов. Кроме того, указанные ограничения делают невозможным использование DCOM -компонента в случае ненадежной или периодически устанавливаемой связи.
Стандарт CORBA/IIOP
Модель CORBA является общим стандартом для создания брокеров объектных запросов ORB (Object Request Broker). Брокеры ORB служат для тех же целей, что и компоненты СОМ на платформе Microsoft, - они обеспечивают взаимодействие объектов. С появлением CORBA большинство разработчиков рассчитывали на то, что распределенная среда компьютерной обработки DCE (Distributed Computing Environment) станет основным сетевым протоколом, как это было с DCOM. Вместо этого был создан протокол IIOP, который определял способ коммуникации брокеров ORB по сети. Различные коммуникационные уровни в системе, основанной на CORBA, показаны на рис. 12.2.
По многим параметрам CORBA кажется идеальным средством для работы с распределенными объектами. Об этом свидетельствует, в частности, тот факт, что данная технология поддерживается внушительной группой разработчиков, включающей более 500 компаний-партнеров. Но все они и несут ответственность за снижение интереса к модели CORBA. Имеется множество реализаций CORBA, и все они обладают своими особенностями. Не существует коммерческих брокеров ORB, получивших столь широкое распространение, как компоненты СОМ компании Microsoft, и имеющих такую же, как у них, производительность.
Стандарт Java RMI
Протокол CORBA быстро теряет репутацию, становясь все более сложным и неудобным для программирования. Частично в ответ на это компания Sun создала свой собственный механизм ORB, названный RMI (Remote Method Invocation - удаленный вызов метода). Данный механизм особенно эффективен при программировании на Java, поскольку прекрасно интегрируется с ним. Однако подобное интегрирование также является и недостатком. Работа RMI зависит от многих уникальных особенностей языка Java, ни одна из которых не поддерживается популярными языками наподобие C++. Фактически RMI - не конкурент даже CORBA.