Въведение в уеб услугите - софтуерни продукти

Предговор

В целия документ тези техники се прилагат към един пример, който е функция, която връща съкращение за името на дадена компания.

Този документ е полезен за ръководители, които се нуждаят от подробно представяне на уеб услуги, както и за разработчици, които се нуждаят от технически подробности. Тъй като SOAP, WSDL и UDDI са базирани на XML стандарта, читателят трябва да има някакво основно разбиране за езика, неговите схеми и пространства от имена. Разделът за справка в края на документа показва къде можете да намерите съответната информация.

Историческа перспектива

Парадигмата на разпределените изчисления възниква едновременно с появата на компютърните мрежи. Приложенията бяха разделени на две части: първата, клиент, инициира разпределени операции, а втората, сървър, осигурява тяхното изпълнение. Тази децентрализация намали потенциала за затруднения, като разпредели натоварването между множество системи. Той също така предостави гъвкавост на дизайна на приложенията, която не беше налична преди, в ерата на централизирани мрежови възли (хостове). Но тази двустепенна архитектура имаше своите ограничения. За решаване на проблемите, свързани с толерантността към грешки и мащабируемостта, беше предложен трислоен модел, разделящ приложенията на презентационна част (междинна връзка, съдържаща бизнес логика) и трета връзка, пряко свързана с данни. Този модел на разпространение се превърна в най-популярния начин за разделяне на приложения. Това позволи да се направят приложните системи мащабируеми. Основата за взаимодействие между разпределените части на приложението в него са повикваниятаотдалечени процедури (RPC). За да спаси разработчиците от извършването на задачи от по-ниско ниво, като конвертиране на данни или подреждане байт по байт на различни машини, на пазара беше пуснато ново ниво на софтуер. Този междинен софтуер скрива разликите между типовете мрежови възли. Той се намира над операционните системи и мрежовите услуги, инсталирани на тези хостове, обслужвайки приложенията от по-високо ниво.

Първите мидълуерни продукти, като DCE, бяха базирани на модел на процедурно програмиране. Те бяха заменени от обектно-ориентиран модел, реализиран в CORBA, DCOM или RMI мидълуер, които са най-популярният софтуер от този клас в момента.

Текущо състояние

Както беше обсъдено по-рано, има три основни технологии за междинен софтуер: DCOM, CORBA и RMI. Всеки от тях има своите предимства и недостатъци. Тази глава разглежда само основните характеристики, без да навлиза в подробности за тези технологии. Това ще даде представа как уеб услугите се вписват в общата картина.

CORBA е базирано на отворени стандарти разпределено изчислително решение. Индустриалният консорциум OMG (Software Object Management Standards Development Group) разработи спецификацията за CORBA и дефинира Internet InterORB Protocol (IIOP), който е стандартният протокол за комуникация между ORBs (Object Request Brokers).

Основното предимство на CORBA е, че и клиентите, и сървърите могат да бъдат написани на всеки език за програмиране. Това става възможно, защото обектите са дефиниранис високо ниво на абстракция, осигурено от Interface Definition Language (IDL). След като дефиницията е направена в IDL файла, компилаторът гарантира, че тя е преведена на конкретен език за програмиране. Взаимодействията между обекти, клиенти и сървъри се управляват с помощта на мениджъри на заявки за обект ORB. Ако се изисква висока производителност от разпределено приложение, тогава CORBA е най-добрият избор за междинен софтуер. Писането на разпределени приложения с CORBA обаче е много трудна задача. За да се осигури превод на IDL на различни езици за програмиране, човек трябва да бъде ограничен до тези основни концепции, които са внедрени в поддържаните езици. По този начин IDL е нещо като общ знаменател за тях.

CORBA използва така наречените "услуги", за да покрие различни области на приложение. Това значително натоварва спецификацията, което я прави много сложна. Освен това доставчиците досега са пуснали сравнително малък набор от такива услуги.

За да се осигури комуникация между клиентски и сървърни обекти, мениджърите на заявки за обекти трябва да бъдат поставени от двете страни на такава връзка.

Технологията RMI (Remote Method Invocation) ви позволява да създавате разпределени приложения от Java към Java. В тях методите на отдалечени Java обекти могат да бъдат извикани от други Java виртуални машини (JVM), най-вероятно разположени на различни хостове. Програмата на Java може да извика отдалечен обект, след като получи препратка към него, или чрез търсене на отдалечения обект в пространството от имена на начално зареждане, предоставено от RMI, или като получи препратката като аргумент или върната стойност. Клиентможе да извика отдалечен обект на сървъра. Този сървър от своя страна може да бъде и клиент за други отдалечени обекти. RMI използва сериализация на обекти, за да маршалира и демаршалира техните параметри и да предотврати отрязването на типа, поддържайки истински обектно-ориентиран полиморфизъм. За комуникация се използва протоколът JRMP (Java Remote Method Protocol).

Програмирането с RMI не е проблем, ако разработчикът е натрупал известен опит в създаването на разпределени приложения и програмиране на езика Java. Не изисква използването на абстрактни езици (като IDL) за описание на обекта на отдалечения сървър. Освен това RMI поддържа разпределен механизъм за възстановяване на освободена памет.

От друга страна, тази технология изисква Java машини от двете страни на връзката. Поради относителната простота на този междинен софтуер, той е удобен и лесен за използване. Това не създава никакви услуги, както беше в случая с CORBA. Всички тези аспекти трябва да бъдат взети под внимание от разработчиците.

DCOM технологията (Microsoft Distributed Component Object Model) ви позволява да извършвате повиквания към отдалечени обекти, като използвате връзка, която е изградена върху механизма DCE RPC и взаимодейства с онлайн COM услуги. DCOM сървърът публикува своите методи на клиенти, като поддържа различни интерфейси. Те са написани на IDL език, подобен на C++. Този IDL компилатор създава модули за достъп (проксита), мъничета и програмни скелетни елементи по същия начин, както прави компилаторът CORBA IDL, но също така ги регистрира в системния регистър. Освен това се създават библиотеки с типове. Те са файлове, които описват отдалечени обекти и показват кои от тях могат да бъдат поискани.интерфейси, предоставени от COM двигателя.

За тази цел се използва протоколът за извикване на отдалечена процедура на обект (ORPC).

Спецификацията DCOM на двоично ниво позволява използването на различни езици за програмиране на сървърни обекти.

Подобно на RMI, DCOM поддържа разпределен механизъм за възстановяване на памет, освободена от отдалечени сървърни обекти. Това се постига чрез използване на механизъм за анкетиране, за да се провери дали клиентската връзка все още е активна. От страната на сървъра се поддържа подходящ брой препратки за клиенти. Ако стойността му се намали до нула, ресурсите, заети от обекта, се освобождават.

Повечето потребители свързват технологията DCOM с операционните системи на Microsoft. Въпреки това вече съществуват пренесени версии на DCOM за Unix, VMS и Apple Macintosh.

предварително заключение

Както е показано в предишния раздел, и трите тези технологии за междинен софтуер работят по един и същи начин. Разликите им се проявяват предимно в различните поддържани функции, както и в нивото на сложност. Всички те водят до надеждна връзка между клиента и сървъра, така че всеки от горния мидълуер е подходящ за използване. Поради разлики в протоколите не е възможно да се извика DCOM сървър от RMI клиент. (Една от стъпките за решаване на този проблем е използването на механизма, който извиква RMI върху IIOP, който се използва при разработване с Enterprise JavaBeans). Това установява връзка от точка до точка.

Трябва също да се спомене, че този междинен софтуер обикновено се използва за интранет приложения иорганизирането на работата му през защитната стена е много проблематично. За да се свържете със сървър зад защитна стена, всички тези технологии предоставят механизъм за HTTP тунелиране.

Бъдещи перспективи: уеб услуги

Този раздел описва уеб услугите и как те се свързват с традиционния междинен софтуер. След кратък преглед ще бъдат представени трите основни компонента на уеб услугите: SOAP, WSDL и UDDI.

Кратък преглед

  • получаване на информация за цената на акциите;
  • получаване на прогноза за времето;
  • резервация на самолетни билети.

Някои уеб услуги могат да използват други уеб услуги, за да изпълняват своите задачи.

Следователно няма разлика между уеб услуга и сървър за разпределено приложение. Разликата може да бъде открита по-дълбоко, на нивата, където се изпълнява логиката на приложението и се извършва обработка на данни.

Тези точки, споменати в заключението към предишната глава, са най-важните причини, поради които този междинен софтуер не може да се счита за уеб услуги. В Интернет, където може да има разнородни среди както от страна на сървъра, така и от страна на клиента, никога не се знае предварително какъв тип междинен софтуер използва всяка свързваща страна. Следователно внедряването на уеб услуги изисква принципно нов подход.

Определение

„Уеб услугите са единични, слабо свързани, компресирани функции, предлагани чрез стандартни протоколи“,

  • „Отделен в отделен елемент“ означава, че изпълнението на тази функция никога не се вижда отвън.
  • „Слабо свързано“ означава, че промяната на една функция не изисква промяна на други функции, които я извикват.
  • „Ограничено“ означава, че има публично достъпни описания на поведението, употребата и входните и изходните параметри на функцията.

Архитектура

В традиционния възглед на подхода клиент-сървър имаше сървър, който предлагаше някакъв вид функционалност, която можеше да се използва или извиква от клиента. Механизъм, подобен на услуга за търсене, действаше като агент между този клиент и сървъра.

Тъй като уеб услугите представляват просто още една парадигма за разпределени приложения, те са съставени от същите три компонента:

  • Сервизен агент, който действа като услуга за търсене между доставчика и заявителя на услугата.
  • Доставчик на услуги, който публикува услугите си на сервизен агент.
  • Инициатор на заявка за услуга, който иска от сервизния агент информация за това къде да намери подходящ доставчик на услуги и след това се свързва с този доставчик.

Следващата фигура илюстрира връзките между компонентите на уеб услугата.