Книга е още в много ранна фаза на написване
Изтегляне 13.53 Mb.
|
- Навигация на страницата:
- Какво е Мрежата
- Клиент/сървър обработки
- Мрежата е огромен сървър
- Програмиране на клиентската страна 8
- Скриптове и езици за тях
- Internet срещу Intranet
- Програмиране при сървъра
- Отделна арена: приложенията
Java и InternetАко Java е на практика само още един програмен език, би могло да се запита защо е толкова важен и защо е бил прокламиран като революционна стъпка в компютърното програмиране. Отговорът не е непосредствено очевиден, ако се изходи от традиционната програмистка гледна точка. Въпреки че Java може да реши традиционните, самостоятелни програмни проблеми, причината да е толкова важен е, че ще реши и проблеми свързани с World Wide Web. Какво е Мрежата?Мрежата може да изглежда мъничко мистериозна на пръв поглед с всичките тези приказки за “сърфинг,” “присъствие” и “home pages.” Винаги е имало даже постоянно нарастваща реакция срещу “Internet-манията” на съмнение в ползата и доходите от такова помитащо движение. Полезно е да се върнем стъпка назад и да видим точно за какво става въпрос, но за да се направи това, трябва да се разберат клиент/сървър системите, друг аспект на компютърните технологии, изпълнен със смущаващи въпроси. Клиент/сървър обработкиОсновната идея на клиент/сървър системата е, че има централен склад за информация – някакъв вид данни, типично в база данни – която искате да разпределяте по заявки към някакво множество хора или машини. Ключът към клиент/сървър е че складът е централно разположен така че може да бъде променян и промените да бъдат предавани до потребителите навън. Взети заедно информацията, софтуерът който я предава навън и другият спомагателен софтуер заедно с машината (или машините) също представлява сървъра. Софтуерът който работи на отдалечената машина и комуникира със сървъра, приема информацията, обработва я и я изписва на дисплея на отдалечената машина се нарича клиент. Основната идея на клиент/сървър обработките, значи, не е чак толкова сложна. Проблемите се появяват понеже има един сървър, който трябва да обслужва много клиенти наведнъж. Изобщо е налична и система за управление на база данни, така че проектантът “балансира” плана на данните в таблица за оптимална употреба. В добавка системите често позволяват клиентът да добавя данни към наличните. Това значи, че трябва да се осигури незастъпване на данните на различните клиенти, а също и че няма да се загубят в процеса на добавянето им. (Това се нарича обработка на транзакции.) Тъй като клиентският софтуер се променя и той трябва да бъде написан, тестван и внедрен, това излиза по-скъпо и трудно, отколкото може да се мисли на пръв поглед. Особено проблематично е поддържането на различни платформи. Накрая, въпросът с изпълнението: може да има стотици клиенти със заявки по едно и също време и даже малкото забавяне да е критично. За да се намали времето за отговор, програмистите работят здраво да облекчат задачите, често на клиентската машина но понякога на другите машини откъм сървърската страна използвайки т.н. middleware. (Мидълуерът също се използва за да се подобри управляемостта.) Така простата идея за разпределяне на информация се оказва с толкова много нива на сложнаст, че като цяло проблемът може да изглежда безнадеждно енигматичен. И следното също е критично: сметки за клиент/сървър обработки за грубо половината от всичката активност на машините. Те са отговорни за всичко: от приемането на поръчки до разпределението на всякакъв вид данни – борсови, научни, правителствени – кажете ги вие. Преди се правеше индивидуално решение на единичен проблем, всеки път наново. Беше трудно за произвеждане и трудно за използване и потребителят трябваше да учи всеки интерфейс отделно. Като цяло проблемът клиент/сървър се нуждае от генерално решение.
В началото беше прост еднопосочен процес. Правеше се заявка към сървъра и той изпращаше файл, който машинният броузър (т.е. клиентът) интерпретираше, форматирайки го подходящо на локалната машина. Но на бърза ръка хората поискаха да правят нещо повече от просто вземане на файлове. Те искаха пълна клиент/сървър възможност така че да може да се връща информация към сървъра, например да се преглеждат базите данни на сървъра, да се добавя информация на сървъра, да се правят поръчки (което изисква повече сигурност отколкото първоначалната система предлагаше). Това са нещата които виждахме при развитието на Web. Web броузера беше голяма стъпка напред: концепцията, че парче информация може да се изобразява на всякакъв компютър. Броузерите обаче бяха все още малко примитивни и бързо затънаха в нарастващите изисквания към тях. Те не бяха много интерактивни и имаха тенденция да спъват и Мрежата, и сървъра, понеже за всяко нещо, което изискваше програмиране трябваше да се обръщат към сървъра. Можеше да отнеме много секунди само за да се установи, че нещо е сбъркано при набирането на команда. Доколкото броузера беше само за изобразяване на информация той не можеше да извършва никакви други обработки. (От друга страна така беше по-сигурно, понеже не можеше да се изпълни програма на локалната машина, която има грешки или вируси.) Различни подходи се приемаха при решаването на този проблем. Колкото да се започне, графиката беше разширена с по-добра анимация и вградено видео. Останалата част от проблема може да бъде решена само с интегриране на възможност да се изпълняват програми на клиентската страна, чрез броузера. Това се нарича програмиране на клиентската страна. Програмиране на клиентската страна8Първоначалният дизайн на Web броузерите включваше интерактивност, но тя изцяло се доставяше от сървърите. Сървърът произвеждаше статични страници за броузера, който просто ги извеждаше на екрана. Основата на HTML съдържа някои неща за събиране на данни: полета за въвеждане на текст, за избор, "радио" бутони, списъци и падащи списъци, къкто и бутон, който бе програмиран само да изчисти данните или да ги “изпрати” на сървъра. Това изпращане минава през Common Gateway Interface (CGI) налично на всички Web сървъри. Текстът който се изпраща информира CGI какво да прави със самия него. Най-типичното нещо е стартиране на програма на сървъра, разположена най-често в директория “cgi-bin.” (Ако следите адресния прозорец на вашия броузър когато натиснете бутон на Web страница може понякога да видите “cgi-bin” сред всичкото, което минава там.) Тези програми могат да бъдат написани на повечето езици. Perl е общ избор, понеже е създаден за операции със стрингове и се интерпретира, така че може да бъде поставен на всеки сървър независимо от операционната система и типа на машината. Много от мощните Web сайтове днес са изградени изцяло с CGI и практически нищо не може да се направи с тях. Проблемът е времето за отговор. Отговорът на CGI зависи от това колко данни се препращат и от натоварването както на сървъра, така и на Мрежата. (Отгоре на това стартирането на CGI програма има тенденция да бъде бавно.) Първоначалните проектанти на Web не предвиждаха колко бързо честотната лента ще се заеме от създадените от хората приложения. Например никакъв вид динамична графика не е смислено възможен, понеже GIF файл трябва да бъде създаден и изпратен за всяка междинна поза. Несъмнено и вие сте запознати с толсова простото нещо като валидиране на данни във форма. Натискате бутона за изпращане; данните отиват до сървъра; сървърът стартира CGI която открива грешка, произвежда HTML страница която информира за грешката и я изпраща обратно при вас; трябва тогава да извикате формата и да започнете пак. Това не само е бавно, то не е елегантно. Решението е програмиране в клиентската страна. Много машини на които работят Web са мощни и способни да вършат обширна работа и с оригиналния статичен HTML подход те просто си седяха, чакайки сървърът да издуха поредната страница. Програмирането на клиентската страна значи, че Web броузерът е впрегнат да върши всякаква работа която може и резултатът за потребителя е много по-бърза и приятна работа с неговия Web сайт. Проблемът на дискусиите за сайтовете е, че той не е по-различен от дискусиите за програмирането изобщо. Парабетрите са почти същите, но платформата е друга: Web броузерът прилича на ограничена операционна система. Накрая, това си е програмиране и за негова сметка е замайващото поле от проблеми, свързани с програмирането на клиентската страна. Останалата част от тази секция дава общ поглед върху проблемите и подходите за решаването им що се отнася до програмирането на клиентската страна. Plug-insЕдна от най-съществените стъпки в развитието на програмирането на клиентската страна е развиването на plug-in. Това е начин за програмиста да включи нова функционалност в броузера чрез сваляна (при броузера - б.пр.) на парче код, което автоматично се включва само (от там и името - б.пр.) към определена точка от страницата. То казва на броузера “от сега нататък може да изпълняваш (и) нова дейност.” (Необходимо е да се свали плуг-инът само веднъж.) Бързо и мощно поведение беше въведено в броузерите по този начин, но писането на плуг-инове не е тривиална задача и не е нещото, което бихте искали да правите, занимавайки се с определена страница. Ценното на плуг-иновете е, че експерт-програмист може да напише и внедри нов програмен език за броузера без разрешение от производителя на броузера. Така плуг-иновете дават задна врата за нови езици за програмиране на клиентската страна (макар че не всички езици са намерили приложение като плуг-инове). Скриптове и езици за тяхПлуг-иновете докараха експлозия на скриптовете. Със скрипта вграждате директно в HTML страницата сорс код за програмиране на клиентската страна и плуг-инът автоматично се активира щом HTML страницата се визуализира. Скриптовите езици имат тенденция да бъдат доста прости за разбиране и понеже това е просто текст от HTML страницата се товарят бързо при простото доставяне на страницата. Недостатъкът е, че кодът е изложен пред всички да го гледат (и крадат) но изибщо казано не се правят вълнуващо сложни неща със скриптове така че това не е кой знае колко тежко. Това идва да покаже, че със скриптовете се е възнамерявало да се реши определен клас проблеми, най-напред създаването на по-богати и интерактивни потребителски интерфейси (GUIси). Скриптът обаче може да реши 80 от срещаните в програмирането на клиентската страна. Вашите проблеми може точно да се включват в тези 80 и доколкото скриптовете имат тенденция да са бързи и лесни за разработка, сигурно ще се спрете на скрипт преди да мислите за нещо като Java или ActiveX програмиране. Най-общо обсъжданите скриптови езици са JavaScript (което няма нищо общо с Java; наречен е така за да грабне от пазарната инерция на Java), VBScript (който изглежда като Visual Basic) и Tcl/Tk, който идва от популярния междуплатформен език за постройка на потребителски интерфейси. Има и други извън нашия списък и без съмнение още повече се разработват. JavaScript е вероятно най-широко поддържания. Той идва с всеки Netscape Navigator и Microsoft Internet Explorer (IE). В добавка, вероятно има повече книги за JavaScript отколкото за който и да е друг езики някои инструменти автоматично създават страници използвайки JavaScript. Ако обаче вече знаете добре Visual Basic или Tcl/Tk, би било по-продуктивно да се използват те, отколкото да се учи нов език. (Ще бъдете достатъчно заети с проблемите в Web в него момент.) JavaАко скриптът може да реши 80 от проблемите при програмирането на клиентската страна, какво става с останалите 20% –“наистина трудните?” Най-популярното решение днес е Java. Не само че е напълно развит програмен език построен за да бъде сигурен, междуплатформен и интернационален, но Java непрекъснато бива развиван за да предостави черти и библиотеки които елегантно се справят с проблемите, които са трудни в традиционните езици, като многонишковост, достъп до бази данни, мрежово програмиране и разпределени обработки. Java позволява програмиране на клиентската страна чрез applet. Аплетът е малка програма, която работи само от Web броузер. Аплетът автоматично се сваля заедно със страницата Web (точно както например картинките биват сваляни (на клиентската машина -б.пр.)). Когато аплетът се активира той се изпълнява като програма. Това е част от неговата красота – дава се възможност да се снабдяват потребителите със софтуер от сървъра когато е необходим и не по-рано. Потребителите получават последната версия без проблеми и уморителни преинсталирания. Поради начина по който Java е проектиран програмистът трябва да произведе единствена програма и тази програма автоматично работи с всички компютри които имат вградени Java интерпретатори. (Това сигурно включва преобладаващата част от съществуващите машини.) Понеже Java е пълноценен език, може да се върши колкото си искате работа както преди, така и след контакти със сървъра. Например не е необходимо да пращате поръчка през Мрежата само за да откриете, че сте сбъкали датата или нещо друго не е наред и вашият клиентски софтуер може да си види данните вместо да чака сървърът да ги прегледа, да построи съответната страница и да я изпрати. Не само че има непосредствен резултат откъм скорост и интензивност на работата, но и мрежовия трафик към сървърите се разтоварва, предотвратявайки забавянето на цялата Мрежа. Едно от предимствата които има Java аплетът пред скрипта е, че той е в компилирана форма, така че сорсът не е достъпен за потребителя. От друга страна, един Java аплет може да бъде декомпилиран без особени грижи и скриването на кода не е чак толкова важно обикновено. Два други фактора са важните. Както ще видите по-късно в тази книга един компилиран Java може да включва няколко модула и да изисква няколко “hits” (достъпа) до сървъра за да бъде разтоварен. (В Java 1.1 това е минимизирано чрез Java архивите, наречени JAR файлове, които позволяват всички необходими модули да бъдат пакетирани за разтоварване на един път.) Скриптова програма ще бъде вградена в Web страницата като част от нейния текст (и изобщо ще бъде по-малък и ще намали нитовете на сървъра). Това може да бъде важно за комуникативността на вашата страница. Друг фактор е във всяко отношение важната крива на научаването. Без значение какво сте слушали, Java не е тривиален за изучаване език. Ако сте Visual Basic програмист минаването към VBScript би било по-бързото решение и доколкото ще се решат повечето от най-типичните задачи за клиент/сървър изучаването на Java може да е много трудно за оправдаване. Ако сте опитен в скриптовете сигурно ще спечелите ако надникнете към JavaScript или VBScript преди да отидете към Java, понеже те може и да са достатъчни и вие ще бъдете по-продуктивен по-скоро.
ActiveXДо някаква степен съперник на Java е ActiveX на Microsoft, макар че подходът там е съвсем друг. ActiveX по начало е само за Windows, макар че сега е развит от независим консорциум като междуплатформен. Фактически ActiveX казва “ако вашата програма се свързва с програмното обкръжение точно еди как си, тя може да бъде в Web страница и да въвви на броузър който поддържа ActiveX.” (IE директно поддържа ActiveX и Netscape го поддържа използвайки plug-in.) Така ActiveX не ви ограничава до определен език. Ако например вече сте опитен Windows с език като C++, Visual Basic, или Delphi на Borland, може да създадете ActiveX компоненти практически без промени във вашите програмистки знания. ActiveX също дава начин за използване на съществуващ от по-рано код в Web страници. СигурностАвтоматичното разпространение на програми по мрежата може да звучи като мечта на човек, правещ вируси. ActiveX специално разглежда трънливия въпрос за сигурността на клиентското програмиране. Ако щракнете на Web бихте могли да свалите автоматично много неща заедно с HTML страницата: GIF файлове, скрипт, компилиран Java код и ActiveX компоненти. Някои от тях са лесни; GIF не могат да причинят никаква вреда и скриптовете са обикновено ограничени, до това, което могат да вършат. Java също бе проектирана да пуска своите аплети извътре на “санитарна кутия” от сигурност, което не позволява да пише по диска или да има достъп до памет извън "кутията". ActiveX е на другия край на спектъра. Програмирането с ActiveX е като програмиране на Windows – може да направите всичко, което поискате. Така че ако щракнете на страница, която съдържа ActiveX компонента, тази компонента може да причини повреждането на файлове на вашия диск. Разбира се, програмите които пускате на вашия компютър и които не са ограничени в рамките на броузър могат да направят същото. Вирусите свалени от Bulletin-Board Systems (BBSи) отдавна са проблем, но скоростта на Мрежата усилва трудността. Изглежда решението е “цифрови подписи,” които сигурно показват кой е авторът. Това е базирано на идеята, че вирусът работи защото неговият автор може да остане анонимен, та като се махне анонимността индивидите ще могат да бъдат държани отговорни за действията си. Това изглежда добър план, понеже програмите могат да бъдат много по-функционални и аз подозирам, че би могло да премахне злобната пакостливост. Ако обаче програмата има неизвестен бъг, това може все пак да предизвика проблеми. Подходът в Java е да се предпазим от възникването на такива проблеми чрез "кутията". Java интерпретаторът който живее във вашия локаленWeb броузер преглежда аплета за "опаки" инструкции докато аплетът току-що е свален. В частност аплетът не може да пише файлове по диска или да трие файлове (едни от главните места на стоене на вирусите). Аплетите изобщо се предполага да бъдат сигурни и тъй като това е основно за всички надеждни клиент/сървър системи всички бъгове, където би могло да има вируси се оправят бързо. (Не е кой знае какво че броузерите фактически нарушават изискванията за сигурност и че някои позволяват различни нива на сигурност.) Може би сте скептични относно тази драконовска мярка относно писането на файлове по вашия диск. Например може да искате да си направите локална база данни за използване оффлайн. Първоначалното виждане беше всеки да върши всичко онлайн, но скоро се видя, че това не е практично (макар че ниските цени на трафика и устройствата може да задоволят нуждите на повечето потребители). Решението е “подписан аплет” който използва публичен ключ за да докаже, че идва наистина от там, от където се твърди. Подписаният аплет може после да продължи право напред и да ви строши диска, но теорията е, че сега можете да държите автора на аплета отговорен за такива злонравни работи. Java 1.1 дава рамка за дигиталните подписи така че може да предприемете стъпки извън кутията ако е необходимо. Цифровите подписи са пропуснали вожен момент и това е скоростта, с която хората се разхождат в Мрежата. Ако сте свалили лоша програма, колко ще трябва време за да откриете това? Може би дни и даже седмици. И от тогава нататък как ще откриете коя точно програма е направила белята (и какво ако я откриете чак тогава?). Internet срещу IntranetWeb e е най-общото решение на проблема клиент/сървър така че има смисъл да използвате същите прийоми за решаване на всеки подпроблем, в частност класическия клиент-сървър проблем в рамките на компанията. С традиционните клиент/сървър подходи се явява проблемът с различните типове на клиентските компютри, както и трудността на инсталирането на клиентския софтуер, като и двата добре се решават чрез Web броузърите и програмирането на клиентската страна. Когато Web технологията се използва в информационна мрежа в рамките на една компания това се нарича Intranet. Интранет дава много по-голяма сигурност от Мрежата, тъй като достъпът до сървърите във вашата компания може физически да се контролира (т.е. да се държат заключени - бел. прев.). В термините на обучението: научаването веднъж на броузерите и евентуалните неголеми промени очевидно предполага по-голяма производителност на обучението, отколкото в другата ситуация. Проблемът със сигурността ни води към едно естествено разделение в света на клиент/сървър програмирането. Ако програмите ви ще се изпълняват в Мрежата, трябва да бъдете извънредно внимателни с тях, понеже не се знае на каква платформа ще се изпълняват. Нуждаете се от нещо многоплатформено и сигурно, като скрипт или Java. В интранет ограниченията ще бъдат други. Не е необикновено всичките машини да са от Intel/Windows платформата. В интранет сте отговорни за ваш собствен код и бъговете могат да бъдат оправени когато се открият. В добавка може да имате наследен код в голямо количество от традиционния клиент/сървър подход в който трябва физически да инсталирате програмите при всяко осъвременяване. Времето за осъвременяване е най-непреодолимата причина за минаване към броузъри, понеже с тях то става прозрачно и безболезнено. Ако имате такъв тип мрежа, най-подходящо е да минете към ActiveX наместо да прекодирате всичките си програми в нов език. Изправени пред такова объркващо разнообразие от алтернативи в клиент/сървър програмирането, намираме, че най-добрият план за атака е анализът на разходите. Имайте пред вид ограниченията на вашата инсталация и търсете най-бързия път до решението. Тъй като програмирането на клиентската страна е програмиране, винаги е добра идеята да се предприеме най-бързият подход. Това е агресивна стойка при срещите с неизбежните усложнения при програмирането на клиентсървър системите. Програмиране при сървъраВ цялата досегашна дискусия игнорирахме програмирането на сървъра. Какво става, когато му се поръча нещо? Повечето време поръчките са просто “изпрати ми този и този файл.” Вашият броузер после интерпретира файла по подходящ начин: като HTML страница, графика, Java аплет, скрипт и т.н. Една по-обща поръчка към сървъра би могла да бъде транзакция с база данни. Типичния сценарий включва поръчка за сложно търсене в база данни, като резултатите сървърът формира в HTML и ги изпраща като резултат. (Разбира се, ако клиентът има повече интелигентност чрез Java или скрипт, необработените резултати могат да бъдат изпратени към клиента и там да се форматират, което би било по-бързо и с по-малко натоварване на сървъра.) Или бихте могли да искате да си впишете името в базата данни, което ще доведе до нейната промяна. Тези операции се извършват от някакъв код на сървърската страна, като създаването му изобщо се нарича програмиране при сървъра. Традиционно това програмиране се изпълнява на Perl и CGI скриптове, но се появиха и по-усложнени системи. Те включват Java-базирани Web сървъри, които позволяват цялото програмиране на сървърската страна да се извърши на Java чрез написването на това, което се нарича servlets. Отделна арена: приложениятаПовечето от шумотевицата около Java е за аплетите. Java е език за програмиране в на-общия смисъл на думата и може да реши повечето програмистки проблеми, най-малкото на теория. И както беше посочено преди, може да има по-ефективни пътища за решаване на клиент/сървър проблемите. Когато излезете от арената на аплетите (като същевременно се освободите от ограниченията като това за писане по диска) влизате в света на общото програмиране с програми, които работят сами, без Web броузър, точно както всяка обикновена програма. Тук силата на Java е не само в преносимостта, но също така и в програмируемостта. Както ще видите през цялата тази книга, Java има много черти, които дават възможност да се страят програмни проекти за по-късо врама, отколкото с досега известните езици. Трябва да сте предупредени, че това е двулична благословия (както повечето на този свят и така трябва да бъде -б.пр.). Плаща се за напредъка с по-бавно изпълнение (макар и да се върши значителна работа в тази посока). Като всеки език Java има присъъщи ограничения, които го правят неподходящ за решаването на определен кръг от проблеми. Java е бързо развиващ се език, обаче, и с всяка нова версия става все по привлекателен за все по-разширяващо се множество от проблеми. Каталог: Java Java -> Лекция Изключения. Уравнение на КортевегДеВриз Java -> Създаване на прозорци и аплети Java -> Лекция 2 Типове данни. Класове и обекти. Числено интегриране Java -> Национална академия по разработка на софтуер Java -> Java за цифрово подписване на документи в уеб Java -> Запознаване с JavaScript. Запознаване с Java Script Java -> Програма за изчисляване на средна стойност Изтегляне 13.53 Mb. Сподели с приятели:
|