1. Введение
Сегодня каждое предприятие ищет пути повышения эффективности своего производства, а также активно изучает возможность реорганизации ИТ-активов. ИТ-организации добились определенного прогресса в решении этих проблем с помощью технологий сервис-ориентированной архитектуры (SOA), однако в большинстве случаев реализуется лишь небольшая часть всего портфеля ИТ-услуг; В настоящее время большинство усилий в этой области направлено просто на достижение «достаточного» уровня внедрения SOA — улучшение возможностей создания приложений и их интеграции с рынком быстрее, лучше и дешевле. И, как мы узнали, о достижении этих целей легче сказать, чем сделать.
2. Традиционные составные приложения на основе промежуточного программного обеспечения.
Фактом является то, что SOA является своего рода промежуточным программным обеспечением, и в традиционных случаях промежуточное программное обеспечение часто полагается на большее количество промежуточного программного обеспечения для перевода данных в удобное для потребителя состояние. Когда вы наконец поймете, что создание составного приложения, включающего технологию SOA, требует не только использования портала (промежуточного программного обеспечения), но также может потребовать использования механизма BPEL (или даже промежуточного программного обеспечения) для его оркестрации, это, конечно, заставляет вас очень разочарован. Хуже того, вы можете работать в организации, которая публикует реестры UDDI и регистрирует многочисленные веб-сервисы. К сожалению, в большинстве случаев очень мало приложений, которые действительно используют эти услуги. Как это может быть?
Должна ли неспособность создавать приложения, использующие эти сервисы SOA, привести нас к выводу, что что-то не так? Потому ли, что разработчикам бизнес-контента слишком сложно создавать приложения, напрямую использующие сервисы SOA? полагаться на другие ИТ-организации в создании таких приложений для нас? Сдерживает ли нас отсутствие структуры управления SOA? Я думаю, что ответ на все вышеперечисленное — «да». И есть очень веская причина: только бизнес-разработчикам слишком сложно потреблять и использовать такие сервисы SOA, предоставляемые ИТ-организацией. На самом деле, настоящая проблема заключается в отсутствии простого способа добавления интерфейса SOA! в этом преимущество объединения технологии AJAX с SOA.
Обычно сервис SOA реализуется как слабосвязанный веб-сервис, который инкапсулирует и предоставляет бизнес-функциональность. Это может показаться очень простым, но это очень сложно и трудно реализовать. Разработчики часто спорят о детализации разработки сервисов SOA, однако большинство разработчиков теперь согласны с тем, что детализация разработки на «бизнес-уровне» является наиболее подходящей. Тем не менее, это по-прежнему требует привлечения большого количества соответствующих экспертов в предметной области и работы с бизнес-контентом для окончательного определения размера этих услуг.
3. Возрождение SOA
К счастью, в последнее время люди стали глубоко интересоваться SOA. Возможно, предприятия наконец осознают, что SOA действительно может им очень помочь. Возможно, это связано с лучшими инструментами разработки и веб-сервисами, продвигаемыми Amazon, Yahoo и eBay. Может быть, это AJAX? Да, именно поэтому я пишу эту статью. Серьезно, я думаю, что AJAX стал важной движущей силой в обновлении понимания людьми SOA, особенно в сегодняшних гибридных областях применения различных новых технологий. Однако как следует объединить и соединить эти две очень разные технологии, чтобы раскрыть большую мощь? Давайте сначала взглянем на определение современной технологии AJAX в Википедии? Веб-страницы задействованы, но SOA вообще не упоминается. Описание следующее:
«AJAX, что означает «Асинхронный JavaScript+XML», представляет собой технологию веб-разработки для создания интерактивных веб-приложений. Ее цель — упростить интерфейсную веб-страницу путем обмена небольшим объемом данных с сервером. в фоновом режиме он кажется более отзывчивым; поэтому каждый раз, когда пользователь вносит изменения, не нужно перезагружать всю веб-страницу. Конечная цель — дальнейшее улучшение интерактивности, оперативности и удобства использования веб-страницы.
SOA не упоминается в этом определении. Неудивительно, поскольку ранние приложения AJAX были ориентированы на повышение функциональности и удобства использования страниц. Это было доказано во многих приложениях, таких как Google Maps, Flickr и Yahoo Mail. Однако не эти потребительские приложения восхищают меня потенциалом AJAX, а бизнес-приложения, работающие за брандмауэром компании, которые действительно используют все преимущества AJAX, поскольку они показывают нам две ключевые характеристики: одна из них — клиент. Модель программирования на стороне, а другая представляет собой простую реализацию асинхронных вызовов к серверу. Эти две ключевые возможности — возможность применять логику на клиенте (браузере) и возможность доступа к данным сервера, не прерывая работу веб-страницы — открывают двери для создания новых, более богатых корпоративных приложений Web 2.0. Очень много возможных областей применения программы. .
Ранее я упоминал, что у SOA отсутствует интерфейс. Здесь на помощь приходит AJAX — он придает SOA приличный вид. Здесь, пожалуйста, позвольте мне объяснить немного больше. С таким же успехом мы могли бы подумать о том, что произойдет, если SOA-сервисы появятся в сети. Такие сервисы обычно необходимо зарегистрировать в реестре или на складе (если повезет), а затем их можно будет использовать для потребления. Например, давайте посмотрим, что доступно на веб-сайте StrikeIron ( www.StrikeIron.com ). StrikeIron успешно создал «рынок веб-сервисов» для широкой публики. На первый взгляд механизм каталогов в StrikeIron очень похож на список, представленный в приложении для малого бизнеса. Но позже вы поймете, что это не просто приложения — на самом деле это веб-сервисы. Концепция единой компании, предоставляющей веб-сервисы WSDL/REST широкому кругу потребителей, имеет множество последствий. А пока давайте посмотрим, что продает эта компания. Согласно информации, предоставленной StrikeIron (которая обеспечивает доступ к этим службам), наиболее популярные веб-услуги, которые она предоставляет, включают:
· Проверка адреса в США
· Глобальная служба SMS
· Налог с продаж и использования
· Проверка электронной почты
· Обратный поиск телефона
Ничего Без сомнения, все эти веб-сервисы весьма полезны и могут использоваться во многих различных областях. Но в то же время они слишком «товарные». Другими словами, меня может не волновать, кто предоставляет эти услуги, но я просто хочу получить нужную мне информацию. С другой стороны, стал бы я просто использовать какой-либо веб-сервис для перевода денег с моего текущего счета на сберегательный? Я бы не стал? Сначала мне нужно установить доверие к этой услуге, поэтому мне нужно установить определенные отношения с поставщиком, который ее предоставляет. Этот «круг доверия», существующий между мной (потребителем) и поставщиком услуг, также отражает отношения внутри предприятия и его партнеров.
4. Сочетание технологии AJAX + SOA.
Тот же метод, описанный выше, также может быть использован предприятиями для предоставления своих веб-сервисов более широкой базе пользователей. Через рынок веб-сервисов предприятия могут регистрировать различные веб-сервисы, и эти веб-сервисы обычно доступны только внутри предприятия или партнерам. Поставщики рынка, очевидно, хотят, чтобы это произошло, но, что более важно, мы видим возможность применить технологию AJAX+SOA для запуска нового класса бизнес-приложений Web 2.0.
Впервые люди почувствовали, что разработка приложений и SOA наконец-то объединились. У нас есть бизнес-функциональность, описанная в многократно используемой форме — SOA-сервис. У нас есть повсеместная связь — Интернет. У нас есть браузеры, которые оказались новыми контейнерами приложений. У нас есть модель программирования в контейнере/браузере приложений такого типа — JavaScript. И все они используют открытые стандарты! Чего еще мы хотим?
Мне особенно хотелось бы увидеть более быстрый способ разработки приложений на основе всех вышеперечисленных технологий — способ создания приложений без необходимости полагаться на промежуточное программное обеспечение, интегрированное с сервисами SOA. Это именно то, на что я хочу, чтобы веб-приложение было способно - «прямое подключение к SOA». Это «прямое подключение к SOA» должно позволить обойти традиционные портальные барьеры и тяжеловесные механизмы процессов и получить прямой (по крайней мере, концептуально; мы узнаем об этом больше) доступ к сервисам SOA. Под этим я имею в виду не только веб-сервисы, это также могут быть службы оркестрации BPEL, крупномасштабные POJO-сервисы, RSS-каналы или что-то еще, что можно представить как «сервис». Конечно, интерфейсы должны предоставляться с использованием открытых стандартов.
Эта новая модель разработки и выполнения создает новый способ создания составных приложений, управляемых приложениями. Он имеет привлекательность типа клиент/сервер без тяжелого багажа традиционных тяжеловесных клиент/серверов. Он работает на стороне браузера и может быть реализован в соответствии с конкретными требованиями.
5. Пользовательские составные приложения
За последние несколько лет мы все слышали о концепции «составных приложений». Однако большинство поставщиков говорят о «составных сервисах» — как о способе реструктуризации своих хост-сервисов в другие, более полезные сервисы или портальные приложения. Позвольте мне провести аналогию, чтобы объяснить дальше.
AcmeGrid, наш вымышленный поставщик грид-вычислений, упомянутый в этой статье, предоставляет услугу — грид-вычисления, — которая позволяет вашим приложениям работать как услуга. Клиенты компании рассказали, что им нужен способ объединить множество услуг в единый сервис. Поэтому, естественно, AcmeGrid выпустила AcmeGrid Composite Application Builder (CAB) на базе Eclipse. Интересно, что CAB очень похож на конструктор BPEL, но более тесно интегрирован с сервисами, публикуемыми AcmeGrid. Хоть и очень красиво, однако это не настоящее приложение, в лучшем случае это просто сервис. По сути, CAB больше похож на создателя сервисов. Но кому нужен конструктор сервисов, когда мы пытаемся создавать приложения? Вскоре другой вымышленный поставщик, назовем его AcmePortal, анонсировал свой Portal Composite Application Builder (PCAB). Он также поставляется с конструктором на основе Eclipse, хотя он также выглядит и ощущается как дизайнер BPEL, эта программа «знает», как создавать порталы. Во многих случаях портал работает так же хорошо, как и приложение. Однако если вы будете настаивать на преобразовании портала в приложение, это будет напрасно.
На самом деле я действительно хочу реализовать составное приложение на основе пользователя, а не составное приложение на основе промежуточного программного обеспечения. Для этого мне нужна была платформа разработки и выполнения, которая могла бы не только использовать AJAX и SOA, но и управлять ими обоими. Некоторые поставщики продвинули концепцию приложений AJAX на шаг дальше, вызывая веб-службы на основе WSDL непосредственно из браузера, что по сути является вызовом SOAP. У этого подхода даже есть название — «Клиент/SOA». Это может подойти для простых некорпоративных или потребительских приложений, но не для настоящих корпоративных программ. Почему? Потому что, когда вы вызываете веб-службу непосредственно из браузера, функция контроля эквивалентна передаче ее браузеру, а это просто означает, что проблемы контроля вообще нет. На рисунке 1 показана блок-схема неконтролируемого использования веб-сервиса. Я никогда не встречал компанию, которая не контролировала бы свои услуги, и я не верю, что компании позволили бы этому случиться только потому, что мы технически очень эффективны в этом. Если вы мне не верите, просто помните, что предприятия никогда не открывают свои межсетевые экраны для приложений, отличных от HTTP и SSL. Сколько бы мы не уговаривали сисадминов, другие порты они открывать не будут.
6. Нам нужна платформа нового типа.
Как видно из вышесказанного, мы говорим не только о технологиях AJAX и SOA. Фактически, что нам действительно нужно, так это платформа, которая может предоставить необходимые возможности контроля для сосуществования AJAX и SOA на предприятии. Эта платформа также обеспечивает возможность использования сервисов SOA с точки зрения клиента, а также может отслеживать потребление сервисов. На рис. 2 показано, как можно управлять веб-сервисами через шлюз служб. Шлюз служб на самом деле представляет собой абстракцию на стороне сервера, которая отслеживает и регулирует доступ к службам от имени клиента, который в случае, который мы только что обсуждали, представляет собой AJAX-приложение на основе браузера. Прелесть использования сервисного шлюза заключается в том, что вы не ограничены доступом только к службам, работающим на предприятии. Этот сервисный шлюз может контролировать любую службу, зарегистрированную на предприятии. В веб-службе на основе WSDL предприятие регистрирует WSDL, а WSDL обеспечивает привязку к службе во время выполнения. Это может быть служба, работающая в центре обработки данных предприятия, но с таким же успехом это может быть служба, работающая в центре обработки данных партнерства. Если предприятие разрешает (посредством регулирования) приложениям доступ к сервисам, не имеет значения, где эти службы работают.
7. Заключение.
Я надеюсь, что после прочтения этой статьи вы начали ценить возможности объединения AJAX и SOA, особенно то, как они могут сосуществовать и создавать новые типы веб-приложений с нормативными возможностями, необходимыми корпоративным сервисным приложениям. . Я твердо верю, что мы находимся на пороге новой эры удивительных возможностей. В эпоху Web 2.0 социальные сети, обмен изображениями и различные технологии аннотаций — это прекрасно, но что действительно оказывает влияние, так это реакция Web 2.0 на предприятия.