Общ преглед
Програмирането на базата на компоненти е по-популярно от всякога. Днес почти няма приложение, което да не използва компоненти в някаква форма, обикновено от различни доставчици. С усложняването на приложенията се увеличи и необходимостта от използване на компоненти, разположени на отдалечени машини.
Пример за приложение, изградено на базата на компоненти, е цялостно решение за електронна търговия. Приложение за електронна търговия, разположено в уеб ферма, трябва да изпраща поръчки към бек-енд приложение за планиране на корпоративните ресурси (ERP). В много случаи ERP приложението се намира на различен хардуер и може да работи на различна операционна система.
Моделът на Microsoft за разпределени компонентни обекти (DCOM) – инфраструктура за разпределени обекти, която позволява на дадено приложение да извиква компоненти от Модела на компонентни обекти (COM), инсталирани на друг сървър – е пренесен на редица платформи, различни от Windows. DCOM обаче никога не е намерил широко приложение на тези платформи, поради което рядко се използва за улесняване на комуникацията между компютри с Windows и такива с други операционни системи. Доставчиците на ERP софтуер често създават компоненти за платформата Windows, които комуникират със системата на сървъра чрез собствен протокол.
Някои услуги, използвани от приложение за електронна търговия, може изобщо да не се намират в центъра за данни. Например, ако приложението за електронна търговия приема плащания с кредитна карта за стоки, закупени от клиента, то трябва да се възползва от услугите на търговската банка, за да обработи данните за кредитната карта на клиента. Но от практическа гледна точка DCOM и свързаните с него технологии, като CORBA и Java RMI, са ограничени до приложения и компоненти, инсталирани в корпоративния център за данни. Две основни причини за това са, че по подразбиране тези технологии използват собственически протоколи и че тези протоколи по своята същност са ориентирани към връзката.
Клиентите, които комуникират със сървъра чрез интернет, се сблъскват с множество потенциални пречки при комуникацията със сървъра. Мрежовите администратори по целия свят, загрижени за сигурността, са внедрили корпоративни рутери и защитни стени, за да блокират практически всеки вид комуникация през интернет. Често е необходима сила, по-голяма от човешката, за да се убеди мрежовият администратор да отвори портове извън абсолютно необходимото минимум.
Ако имате късмета мрежовият администратор да отвори необходимите портове за поддръжка на вашата услуга, вероятно вашите клиенти няма да са толкова щастливи. В резултат на това собственическите протоколи, като тези, използвани от DCOM, CORBA и Java RMI, не са практични за интернет сценарии.
Другият проблем, както вече споменах, при тези технологии е, че по своята същност те са ориентирани към връзката и поради това не могат да се справят адекватно с прекъсвания на мрежовата връзка. Тъй като интернет не е под вашия пряк контрол, не можете да правите никакви предположения относно качеството или надеждността на връзката. Ако възникне прекъсване на мрежовата връзка, следващото заявка, която клиентът изпраща към сървъра, може да се провали.
Фактът, че тези технологии са ориентирани към връзката, също затруднява изграждането на инфраструктури с балансиране на натоварването, необходими за постигане на висока мащабируемост. Щом връзката между клиента и сървъра бъде прекъсната, не е възможно просто да се пренасочи следващото заявка към друг сървър.
Разработчиците са се опитали да преодолеят тези ограничения, като са се възползвали от модел, наречен без гражданство програмиране, но успехът им е бил ограничен, тъй като технологиите са доста тежки и правят възстановяването на връзката с отдалечен обект скъпо.
Тъй като обработката на кредитната карта на клиента се извършва от отдалечен сървър в интернет, DCOM не е идеалният вариант за осигуряване на комуникацията между клиента на електронната търговия и сървъра за обработка на кредитни карти. Както при ERP решенията, често в центъра за данни на клиента се инсталира компонент на трета страна (в този случай от доставчика на решението за обработка на кредитни карти). Този компонент служи като нещо повече от прокси, което улеснява комуникацията между софтуера за електронна търговия и търговската банка чрез собствен протокол.
Забелязвате ли някаква тенденция тук? Поради ограниченията на съществуващите технологии за улесняване на комуникацията между компютърните системи, доставчиците на софтуер често са прибягвали до изграждането на собствена инфраструктура. Това означава, че ресурси, които биха могли да бъдат използвани за добавяне на подобрена функционалност към ERP системата или системата за обработка на кредитни карти, вместо това са били насочени към разработването на собствени мрежови протоколи.
В стремежа си да подкрепи по-добре подобни интернет сценарии, Microsoft първоначално възприе стратегията за разширяване на съществуващите си технологии, включително COM Internet Services (CIS), която позволява установяването на DCOM връзка между клиента и отдалечения компонент през порт 80. По различни причини CIS не се наложи широко.
Стана ясно, че е необходим нов подход. Затова Microsoft реши да подходи към проблема „отдолу нагоре“. Нека разгледаме някои от изискванията, на които решението трябваше да отговаря, за да бъде успешно.
- Оперативна съвместимост Услугата за отдалечен достъп трябва да може да се използва от клиенти на други платформи.
- Удобство за ползване в интернет Решението би трябвало да функционира добре за обслужване на клиенти, които използват услугата от разстояние чрез интернет.
- Строго типизирани интерфейси Не трябва да има неясноти относно типа на данните, изпращани към и получавани от отдалечена услуга. Освен това типовете данни, дефинирани от отдалечената услуга, трябва да съответстват в достатъчна степен на типовете данни, дефинирани от повечето езици за процедурно програмиране.
- Възможност за използване на съществуващите интернет стандарти При внедряването на услугата за дистанционно обслужване трябва да се използват в максимална степен съществуващите интернет стандарти и да се избягва измислянето на нови решения за проблеми, които вече са решени. Решение, основано на широко приети интернет стандарти, може да се възползва от съществуващите набори от инструменти и продукти, създадени за тази технология.
- Поддръжка на всеки език Решението не трябва да бъде тясно обвързано с конкретен програмен език. Java RMI, например, е тясно свързано с езика Java. Би било трудно да се извика функционалност на отдалечен Java обект от Visual Basic или Perl. Клиентът трябва да може да имплементира нова уеб услуга или да използва съществуваща уеб услуга, независимо от езика за програмиране, на който е написан клиентът.
- Поддръжка на всякаква инфраструктура от разпределени компоненти Решението не трябва да е тясно обвързано с конкретна инфраструктура от компоненти. Всъщност не би трябвало да се налага да закупувате, инсталирате или поддържате инфраструктура от разпределени обекти само за да създадете нова отдалечена услуга или да използвате съществуваща такава. Базовите протоколи трябва да осигуряват минимално ниво на комуникация между съществуващите инфраструктури от разпределени обекти, като например DCOM и CORBA.
Предвид заглавието на тази книга, не би трябвало да е изненада, че решението, създадено от Microsoft, е известно като Уеб услуги. Уеб услугата предоставя интерфейс за извикване на конкретна дейност от името на клиента. Клиентът може да получи достъп до уеб услугата чрез използване на интернет стандарти.
Съставни елементи на уеб услугите
На следната диаграма са показани основните елементи, необходими за осигуряване на дистанционна комуникация между две приложения.
Нека обсъдим предназначението на всеки от тези компоненти. Тъй като много от читателите са запознати с DCOM, ще спомена и DCOM-еквивалента на всеки компонент.
- Откритие Клиентското приложение, което се нуждае от достъп до функционалността, предоставяна от уеб услуга, трябва да има начин да определи местоположението на отдалечената услуга. Това се осъществява чрез процес, който обикновено се нарича откритие. Откриването може да се улесни както чрез централизирана директория, така и чрез по-ад хок методи. В DCOM мениджърът за управление на услугите (SCM) осигурява услуги за откриване.
- Описание След като крайната точка на дадена уеб услуга бъде определена, клиентът се нуждае от достатъчно информация, за да взаимодейства правилно с нея. Описанието на уеб услугата включва структурирани метаданни за интерфейса, предназначени за използване от клиентско приложение, както и писмена документация за уеб услугата, включваща примери за употреба. DCOM компонентът предоставя структурирани метаданни за своите интерфейси чрез библиотека с типове (typelib). Метаданните в библиотеката с типове на компонента се съхраняват в собственически двоичен формат и достъпът до тях се осъществява чрез собственически интерфейс за програмиране на приложения (API).
- Формат на съобщението За да могат да обменят данни, клиентът и сървърът трябва да се споразумеят за общ начин за кодиране и форматиране на съобщенията. Стандартният начин на кодиране на данните гарантира, че данните, кодирани от клиента, ще бъдат правилно интерпретирани от сървъра. В DCOM съобщенията, изпращани между клиент и сървър, се форматират съгласно определенията на протокола DCOM Object RPC (ORPC).
Без стандартен начин за форматиране на съобщенията разработването на набор от инструменти, който да изолира разработчика от базовите протоколи, е практически невъзможно. Създаването на абстракционен слой между разработчика и базовите протоколи позволява на разработчика да се съсредоточи повече върху конкретния бизнес проблем и по-малко върху инфраструктурата, необходима за реализирането на решението.
- Кодиране Данните, предавани между клиента и сървъра, трябва да бъдат кодирани в тялото на съобщението. DCOM използва схема за двоично кодиране, за да сериализира информацията, съдържаща се в параметрите, които се обменят между клиента и сървъра.
- Транспорт След като съобщението е форматирано и данните са сериализирани в тялото на съобщението, то трябва да бъде предадено между клиента и сървъра чрез някакъв транспортен протокол. DCOM поддържа редица собственически протоколи, свързани с редица мрежови протоколи, като например TCP, SPX, NetBEUI и NetBIOS over IPX.
Решения при проектирането на уеб услуги
Нека обсъдим някои от проектните решения, които стоят в основата на тези градивни елементи за уеб услугите.
Избор на транспортни протоколи
Първата стъпка беше да се определи как клиентът и сървърът ще комуникират помежду си. Клиентът и сървърът могат да се намират в една и съща локална мрежа (LAN), но е възможно клиентът да комуникира със сървъра чрез интернет. Поради това транспортният протокол трябва да е еднакво подходящ както за LAN-среди, така и за интернет.
Както споменах по-рано, технологии като DCOM, CORBA и Java RMI не са подходящи за поддържане на комуникацията между клиента и сървъра през интернет. Протоколи като Hypertext Transfer Protocol (HTTP) и Simple Mail Transfer Protocol (SMTP) са доказани интернет протоколи. HTTP дефинира модел на обмен на съобщения от типа „заявка/отговор“ за изпращане на заявка и получаване на съответния отговор. SMTP дефинира маршрутизируем протокол за обмен на съобщения за асинхронна комуникация. Нека разгледаме защо HTTP и SMTP са подходящи за интернет.
Уеб приложенията, базирани на HTTP, по своята същност са безсъстоятелни. Те не разчитат на непрекъсната връзка между клиента и сървъра. Това прави HTTP идеален протокол за конфигурации с висока наличност, като например защитни стени. Ако сървърът, който е обработил първоначалното заявка на клиента, стане недостъпен, следващите заявки могат автоматично да бъдат пренасочени към друг сървър, без клиентът да разбере или да се притеснява от това.
Почти всички компании разполагат с инфраструктура, която поддържа SMTP. SMTP е подходящ протокол за асинхронна комуникация. При прекъсване на услугата инфраструктурата за електронна поща автоматично се занимава с повторните опити за изпращане. За разлика от HTTP, можете да препращате SMTP съобщения към локален пощенски сървър, който ще се опита да достави съобщението от ваше име.
Другото значително предимство както на HTTP, така и на SMTP е тяхната широко разпространеност. Служителите вече разчитат както на електронната поща, така и на уеб браузърите си, а мрежовите администратори се чувстват много уверени при поддръжката на тези услуги. Технологии като преобразуване на мрежови адреси (NAT) и прокси сървъри осигуряват възможност за достъп до интернет чрез HTTP от иначе изолирани корпоративни LAN мрежи. Администраторите често предоставят достъп до SMTP сървър, който се намира зад защитната стена. Съобщенията, изпратени към този сървър, след това се пренасочват към крайната си дестинация чрез интернет.
В случая със софтуера за обработка на кредитни карти е необходим незабавен отговор от търговската банка, за да се определи дали поръчката трябва да бъде предадена към ERP системата. Протоколът HTTP, със своя модел на съобщения „заявка/отговор“, е изключително подходящ за тази задача.
Повечето софтуерни пакети за ERP не са в състояние да обработват големи обеми поръчки, които потенциално могат да бъдат генерирани от приложението за електронна търговия. Освен това не е задължително поръчките да се изпращат към ERP системата в реално време. Поради това SMTP може да се използва за поставяне на поръчките в опашка, така че да могат да бъдат обработвани последователно от ERP системата.
Ако ERP-системата поддържа разпределени транзакции, друг вариант е да се използва Microsoft Message Queue Server (MSMQ). Докато приложението за електронна търговия и ERP-системата се намират в една и съща LAN, свързването чрез протоколи, различни от интернет, не представлява голям проблем. Предимството на MSMQ пред SMTP е, че съобщенията могат да се поставят и премахват от опашката в рамките на една транзакция. Ако опитът за обработка на съобщение, извадено от опашката, се провали, съобщението автоматично ще бъде върнато в опашката при прекъсване на транзакцията.
Избор на схема за кодиране
HTTP и SMTP осигуряват начин за изпращане на данни между клиента и сървъра. Нито един от двата протокола обаче не определя как трябва да се кодират данните в тялото на съобщението. На Microsoft беше необходим стандартен, независим от платформата начин за кодиране на данните, обменяни между клиента и сървъра.
Тъй като целта беше да се използват интернет-базирани протоколи, езикът за разширяема маркировка (XML) се оказа естественият избор. XML предлага много предимства, включително междуплатформена съвместимост, обща система от типове и поддръжка на стандартни за индустрията набори от символи.
Схемите за двоично кодиране, като например тези, използвани от DCOM, CORBA и Java RMI, трябва да отчитат проблемите със съвместимостта между различните хардуерни платформи. Например, различните хардуерни платформи имат различно вътрешно двоично представяне на многобайтовите числа. Платформите на Intel подреждат байтовете на многобайтово число според конвенцията „little endian“; много RISC процесори подреждат байтовете на многобайтово число според конвенцията „big endian“.
XML избягва проблемите, свързани с двоичното кодиране, тъй като използва текстова схема за кодиране, която се основава на стандартни набори от символи. Освен това някои транспортни протоколи, като например SMTP, могат да съдържат само текстови съобщения.
Двоичните методи за кодиране, като например тези, използвани от DCOM и CORBA, са тромави и изискват поддържаща инфраструктура, която да освободи разработчика от необходимостта да се занимава с подробностите. XML е много по-леко и по-лесно за работа, тъй като може да се създава и използва чрез стандартни техники за анализиране на текст.
Освен това са налице различни XML-парсери, които допълнително опростяват създаването и използването на XML-документи на практически всяка съвременна платформа. XML е лек и разполага с отлична поддръжка от инструменти, така че кодирането в XML осигурява невероятен обхват, тъй като практически всеки клиент на всяка платформа може да комуникира с вашата уеб услуга.
Избор на конвенция за форматиране
Често се налага да се включват допълнителни метаданни в тялото на съобщението. Например, може да искате да включите информация за вида услуги, които дадена уеб услуга трябва да предостави, за да изпълни вашето заявка, като например включване в транзакция или информация за маршрутизиране. XML не предоставя механизъм за разграничаване на тялото на съобщението от свързаните с него данни.
Транспортните протоколи като HTTP осигуряват разширяем механизъм за данните в заглавните редове, но някои данни, свързани със съобщението, може да не са специфични за транспортния протокол. Например, клиентът може да изпрати съобщение, което трябва да бъде маршрутизирано към няколко дестинации, евентуално чрез различни транспортни протоколи. Ако информацията за маршрутизирането бъде поставена в HTTP заглавие, тя ще трябва да бъде преобразувана, преди да бъде изпратена към следващия посредник чрез друг транспортен протокол, като например SMTP. Тъй като информацията за маршрутизирането е специфична за съобщението, а не за транспортния протокол, тя трябва да бъде част от съобщението.
Протоколът за достъп до прости обекти (SOAP) предоставя независим от протокола начин за свързване на информацията в заглавната част със съдържанието на съобщението. Всяко SOAP-съобщение трябва да дефинира „плик“. Пликът има тяло, което съдържа полезния товар на съобщението, и заглавна част, която може да съдържа метаданни, свързани със съобщението.
SOAP не налага ограничения относно начина, по който може да бъде форматирано тялото на съобщението. Това представлява потенциален проблем, тъй като без единен начин за кодиране на данните е трудно да се разработи набор от инструменти, който да ви освободи от необходимостта да се занимавате с основните протоколи. Може да се наложи да отделите значително време, за да се запознаете с интерфейса на уеб услугата, вместо да решавате конкретния бизнес проблем.
Необходим беше стандартен начин за форматиране на съобщение за отдалечено извикване на процедура (RPC) и за кодиране на списъка с неговите параметри. Точно това предвижда раздел 7 от спецификацията на SOAP. В него се описват стандартна конвенция за именуване и стил на кодиране за съобщения, ориентирани към процедури.
Тъй като SOAP предоставя стандартен формат за сериализиране на данни в XML съобщение, платформи като ASP.NET и Remoting могат да ви спестят грижата за конкретните детайли.
Избор на механизми за описание
SOAP осигурява стандартен начин за форматиране на съобщенията, обменяни между уеб услугата и клиента. Клиентът обаче се нуждае от допълнителна информация, за да може правилно да сериализира заявката и да интерпретира отговора. XML Schema предоставя възможност за създаване на схеми, които могат да се използват за описание на съдържанието на дадено съобщение.
XML Schema предоставя основен набор от вградени типове данни, които могат да се използват за описание на съдържанието на дадено съобщение. Можете също така да създавате свои собствени типове данни. Например, търговската банка може да създаде сложен тип данни, за да опише съдържанието и структурата на тялото на съобщението, използвано за подаване на заявка за плащане с кредитна карта.
Схемата съдържа набор от дефиниции на типове данни и елементи. Уеб услугата използва схемата не само за да посочи типа данни, които се очаква да се съдържат в дадено съобщение, но и за да проверява валидността на входящите и изходящите съобщения.
Сама по себе си схемата обаче не предоставя достатъчно информация за ефективното описание на уеб услугата. Схемата не описва моделите на съобщенията между клиента и сървъра. Например, клиентът трябва да знае дали да очаква отговор, когато се изпраща поръчка към ERP системата. Клиентът също така трябва да знае чрез какъв транспортен протокол уеб услугата очаква да получава заявки. Накрая, клиентът трябва да знае адреса, на който може да се свърже с уеб услугата.
Тази информация се предоставя чрез документ на езика за описание на уеб услуги (WSDL). WSDL е XML документ, който изчерпателно описва конкретна уеб услуга. Инструменти като ASP.NET WSDL.exe и Remoting SOAPSUDS.exe могат да обработват WSDL и автоматично да създават прокси за разработчика.
Както всеки компонент, използван за разработване на софтуер, така и уеб услугата трябва да бъде придружена от писмена документация за разработчиците, които пишат код, използващ тази уеб услуга. Документацията трябва да описва функциите на уеб услугата, интерфейсите, които тя предоставя, както и няколко примера за нейното използване. Качествената документация е особено важна, ако уеб услугата е достъпна за клиенти чрез интернет.
Избор на механизми за откриване
След като сте разработили и документирали уеб услуга, как потенциалните клиенти могат да я открият? Ако уеб услугата е предназначена за използване от член на вашия екип за разработка, подходът ви може да бъде доста неформален – например да споделите URL адреса на WSDL документа с колегата си, който седи на няколко кабинки по-надолу. Но когато потенциалните клиенти са в интернет, ефективното рекламиране на вашата уеб услуга е съвсем друга история.
Необходим е единен начин за обявяване на уеб услуги. UDDI (Universal Description, Discovery, and Integration) предоставя точно такъв механизъм. UDDI е централизирана директория, която е индустриален стандарт и може да се използва за рекламиране и намиране на уеб услуги. UDDI позволява на потребителите да търсят уеб услуги, използвайки множество критерии за търсене, включително име на компания, категория и тип уеб услуга.
Уеб услугите могат да се обявяват и чрез DISCO – патентован формат на XML документи, дефиниран от Microsoft, който позволява на уебсайтовете да обявяват услугите, които предоставят. DISCO дефинира прост протокол, улесняващ използването на хипервръзки за намиране на ресурси. Основният потребител на DISCO е Microsoft Visual Studio.NET. Разработчикът може да насочи вниманието си към конкретен уеб сървър и да навигира из различните уеб услуги, предоставяни от сървъра.
Какво липсва в уеб услугите?
Вероятно сте забелязали, че някои ключови елементи в инфраструктурата на разпределените компоненти не са дефинирани от уеб услугите. Две от най-забележимите пропуски са ясно дефинираният API за създаване и използване на уеб услуги, както и набор от компонентни услуги, като например поддръжка на разпределени транзакции. Нека разгледаме всеки от тези липсващи елементи.
- API, специфично за уеб услугата Повечето инфраструктури с разпределени компоненти дефинират API за изпълнение на задачи като инициализиране на средата за изпълнение, създаване на инстанция на компонент и отразяване на метаданните, използвани за описанието на компонента. Тъй като повечето езици за програмиране на високо ниво осигуряват известна степен на оперативна съвместимост с C, API-то обикновено се предоставя като плосък набор от сигнатури на методи на C. RMI стига дотам, че тясно обвързва своя API с един-единствен език от високо ниво – Java.
С цел да се гарантира, че уеб услугите са независими от езика за програмиране, Microsoft е оставила на отделните софтуерни доставчици свободата да обвържат поддръжката на уеб услугите с конкретна платформа. По-нататък в книгата ще разгледам две реализации на уеб услуги за платформата .NET – ASP.NET и Remoting.
- Услуги, свързани с компонентите Платформата за уеб услуги не предоставя много от услугите, които обикновено се срещат в инфраструктурите с разпределени компоненти, като например управление на жизнения цикъл на отдалечени обекти, пулване на обекти и поддръжка на разпределени транзакции. Реализацията на тези услуги се оставя на инфраструктурата с разпределени компоненти.
Някои услуги, като например поддръжката на разпределени транзакции, могат да бъдат въведени по-късно, с развитието на технологията. Други, като например пулването на обекти и евентуално управлението на жизнения цикъл на обектите, могат да се разглеждат като детайли от реализацията на платформата. Например, Remoting дефинира разширения, които осигуряват поддръжка за управлението на жизнения цикъл на обектите, а Microsoft Component Services осигурява поддръжка за пулването на обекти.
Обобщение
Програмирането на базата на компоненти се оказа истинско благословение за производителността на разработчиците, но някои услуги не могат да бъдат капсулирани в компонент, намиращ се в центъра за данни на клиента. Старите технологии като DCOM, CORBA и Java RMI не са подходящи за осигуряване на достъп на клиентите до услугите през интернет, затова Microsoft сметна за необходимо да започне от нулата и да създаде стандартен за индустрията начин за достъп до отдалечени услуги.
Уеб услуги е общ термин, който описва набор от стандартни за индустрията протоколи и услуги, използвани за осигуряване на базово ниво на оперативна съвместимост между приложенията. Подкрепата, която уеб услугите получиха от индустрията, е безпрецедентна. Никога досега толкова много водещи технологични компании не са се обединили, за да подкрепят стандарт, който улеснява оперативната съвместимост между приложенията, независимо от платформата, на която се изпълняват.
Един от факторите, допринасящи за успеха на уеб услугите, е, че те се основават на съществуващи интернет стандарти като XML и HTTP. В резултат на това всяка система, способна да анализира текст и да комуникира чрез стандартен интернет транспортен протокол, може да взаимодейства с уеб услуга. Компаниите също могат да се възползват от вече направените инвестиции в тези технологии.